Why should I care that Java doesn't have reified generics?

U

13

104

This came up as a question I asked in an interview recently as something the candidate wished to see added to the Java language. It's commonly-identified as a pain that Java doesn't have reified generics but, when pushed, the candidate couldn't actually tell me the sort of things that he could have achieved were they there.

Obviously because raw types are allowable in Java (and unsafe checks), it is possible to subvert generics and end up with a List<Integer> that (for example) actually contains Strings. This clearly could be rendered impossible were type information reified; but there must be more than this!

Could people post examples of things that they would really want to do, were reified generics available? I mean, obviously you could get the type of a List at runtime - but what would you do with it?

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

EDIT: A quick update to this as the answers seem mainly to be concerned about the need to pass in a Class as a parameter (for example EnumSet.noneOf(TimeUnit.class)). I was looking more for something along the lines of where this just isn't possible. For example:

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

Unripe answered 18/12, 2009 at 11:54 Comment(5)

Would this mean that you could get the class of a generic type at runtime? (if so, I have an example!) – Lorusso 18/12, 2009 at 11:58

I think most of the desire with reifiable generics are from people who use generics primarily with collections, and want those collections to behave more like arrays. – Extraction 18/12, 2009 at 14:51

The more interesting question (to me): what would it take to implement C++ style generics in Java? It certainly seems do-able in the runtime, but would break all existing classloaders (because findClass() would have to ignore parameterization, but defineClass() couldn't). And as we know, The Powers That Be hold backwards compatibility paramount. – Extraction 18/12, 2009 at 15:1

Actually, Java does provide reified generics in a very restricted way. I provide more details in this SO thread: #880355 – Boutwell 5/7, 2012 at 2:9

The JavaOne Keynote indicates that Java 9 will support reification. – Trow 7/1, 2014 at 21:44

E

81

From the few times that I came across this "need", it ultimately boils down to this construct:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

This does work in C# assuming that T has a default constructor. You can even get the runtime type by typeof(T) and get the constructors by Type.GetConstructor().

The common Java solution would be to pass the Class<T> as argument.

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

(it does not necessarily need to be passed as constructor argument, as a method argument is also fine, the above is just an example, also the try-catch is omitted for brevity)

For all other generic type constructs, the actual type can easily be resolved with a bit help of reflection. The below Q&A illustrate the use cases and possibilities:

Eupheemia answered 18/12, 2009 at 12:5 Comment(23)

This works (for example) in C#? How do you know that T has a default constructor? – Newsworthy 18/12, 2009 at 12:11

Yes, it do. And this is just a basic example (let assume that we work with javabeans). The whole point is that with Java you cannot get the class during runtime by T.class or T.getClass(), so that you could access all its fields, constructors and methods. It makes construction also impossible. – Eupheemia 18/12, 2009 at 12:20

This would use reflection APIs: T.class.newInstance(). Otherwise you would have to add the type information for T. It has to be a class with such and such constructor. – Newsworthy 18/12, 2009 at 12:27

This seems really weak to me as the "big problem", particularly as this is only likely to be useful in conjunction with some very brittle reflection around constructors/parameters etc. – Unripe 18/12, 2009 at 12:28

No, there are no workarounds for this particular issue. Those workarounds only work if the parameterized type is not a generic type. E.g. you can extract java.lang.String from List<String> field, but not from List<T> class. – Eupheemia 18/12, 2009 at 12:29

@Eupheemia - Super type tokens (new Type<List<String>>(){}) are a workaround to transport generic type information and there are Scala's Manifest. – Newsworthy 18/12, 2009 at 12:35

@Thomas: this workaround require that you know the type during build/compile. In some cases you just don't know. – Eupheemia 18/12, 2009 at 12:35

@Eupheemia - That's the same for reified types. The type information has to be there at compile time. – Newsworthy 18/12, 2009 at 12:38

Back to the starting point: new T() does not compile in C#, right? – Newsworthy 18/12, 2009 at 12:41

It does compile in C# provided that you declare the type as: public class Foo<T> where T : new(). Which will limit the valid types of T to those that contain a parameterless constructor. – Surrey 18/12, 2009 at 12:55

Would using t.clone() be of any use here? – Dithyrambic 18/12, 2009 at 15:31

What would you be cloning? ...For me this comes up when say initializing a wrapper around something like Number. Anything the user passes as the parameterized type has a default value (new Integer(), new Double(), etc.) but to have the wrapper initialized with it then I have to let them provide it on the constructor. Ugly. – Litmus 18/12, 2009 at 18:13

Always when I choose the "workaround" solution I ended up providing the "delegator" solution. Calling the default constructor just doesn't scale to "special needs". – Gilgai 18/12, 2009 at 19:4

Don't underestimate how badly java templates are hamstrung. It's quite a bit worse than described. One can't even ask general questions about type. For instance it's a small stretch of the imagination that one might like to detect whether variables are of type, say Float. Reasonable tricks that you could play to help you out are also off limits, e.g. you can't tell java that a given generic type is required to extend more than one class or interface. Throw in other limitations such as that static member variables can't be of generic types and try to do something practical and general... – Exemplificative 12/12, 2013 at 16:20

@Colin You actually can tell java that a given generic type is required to extend more than one class or interface. See the "Multiple Bounds" section of docs.oracle.com/javase/tutorial/java/generics/bounded.html. (Of course, you can't tell it that the object will be one of a specific set that do not share methods that could be abstracted into an interface, which could be somewhat implemented in C++ using template specialization.) – Buskin 8/1, 2014 at 19:0

@Buskin Thank you, good point. I stand corrected. btw Is there a way to tell java that a generic type used in class A is the same as the generic type in class B? (without using inner classes) – Exemplificative 10/1, 2014 at 13:22

@Colin Yes, if you supply the class objects of the types in question when instantiating the classes. #52082 – Buskin 10/1, 2014 at 13:46

@Buskin As far as I can tell the compiler can't determine that template variable E in class A is of the same type as the template variable T in class B, so the compiler won't allow passing E and T between classes A and B. – Exemplificative 12/1, 2014 at 10:13

@Colin Which is why I suggested using class objects (e.g. Class<E> and Class<T>). Not a perfect solution, especially because that wouldn't work if E and/or T were generics themselves due to type erasure and you'd have to be handling a lot of stuff as Objects, but you don't have to worry about the actual type of a class object when doing a comparison as a class's class object will be the same object for all instances (they're singletons, basically). – Buskin 13/1, 2014 at 13:23

@Buskin I am surprised the compiler will accept that solution. If that works then in some sense you may as well use Object pointers as type safety is out the window. Anyway, interesting. – Exemplificative 13/1, 2014 at 17:30

@Colin That's how things were done before generics. Objects obtained from a Java collection would be of type Object and you'd have to cast them to the desired type, but you'd have to be careful because you could also add any type of object to a collection without needing to cast. That is, the old style of collections (also called "raw" collections) are roughly equivalent to a generic version with Object as its type parameter. – Buskin 13/1, 2014 at 17:41

Note that with this method, you should be able to use the cast method of the class objects to cast the objects to their desired types at runtime and call methods of them (but be careful about supplying those cast objects to methods expecting specific types for parameters, as that is determined at compile-time rather than runtime, so you may get unexpected behavior with overloaded methods). – Buskin 13/1, 2014 at 17:44

Very professional communication indeed. And good day to you, too. – Misleading 19/5, 2014 at 22:19

G

102

The thing that most commonly bites me is the inability to take advantage of multiple dispatch across multiple generic types. The following isn't possible and there are many cases where it would be the best solution:

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

Gabbro answered 18/12, 2009 at 12:35 Comment(11)

There is absolutely no need for reification to be able to do that. Method selection is done at compile time when the compile-time type information is available. – Schlock 18/12, 2009 at 13:25

@Tom: this doesn't even compile because of type erasure. Both get compiled as public void my_method(List input) {}. I have however never came across this need, simply because they would not have the same name. If they have the same name, I'd question if public <T extends Object> void my_method(List<T> input) {} isn't a better idea. – Eupheemia 18/12, 2009 at 13:51

Hm, I would tend to avoid overloading with identical number of parameters altogether, and prefer something like myStringsMethod(List<String> input) and myIntegersMethod(List<Integer> input) even if overloading for such a case was possible in Java. – Lengthways 18/12, 2009 at 14:58

@Fabian: Which means you've got to have separate code, and prevent the sort of advantages you get from <algorithm> in C++. – Ibadan 18/12, 2009 at 15:15

I am confused, this is essentially the same as my second point, yet I got 2 downvotes on it? Anybody care to enlighten me? – Oxbow 18/12, 2009 at 17:0

@rsp: I didn't downvote you but, even with you saying your point was the same as mine, I still can't read it that way. What you seemed to say was that you want to be able to use List<Integer> as List<Object>. What I'm saying is that I want to be able to dynamic dispatch based on the generic type. For example, if I wanted to have debug routines that printed out the contents of the List, I could have one for generic Objects, and then one for each more specific types that I know I want to display differently... but have the name the same for all of them. – Gabbro 18/12, 2009 at 19:10

@RHSeeger, thanks for your answer. I see we did mean different things, your point is about getting Java generics to be more like C++ template behaviour while mine is about using inheritance rules between container contents. – Oxbow 18/12, 2009 at 20:15

@Eupheemia Old comment, but isn't T extends Object redundant since everything extends object and List<T> is the same as List<?>? – Bevatron 6/8, 2013 at 4:24

@Bevatron the first part of your statement is correct, but the latter is not. List<T> means "List holding objects of the class represented by generic parameter T", while List<?> means "List holding objects of an unknown type". docs.oracle.com/javase/tutorial/extra/generics/wildcards.html – Buskin 10/1, 2014 at 13:57

@Buskin I meant to say that due to type erasure, the symbol T does not really mean anything within the method. Is there a case where accepting a List<T> to a method (where T can be anything) is better than accepting a List<?>? – Bevatron 13/1, 2014 at 0:36

@Bevatron When the T is defined by the enclosing type or the method itself is a generic. You use ? in non-generic methods/methods where the compiler will not be able to determine the type from the compile-time context. – Buskin 13/1, 2014 at 12:58

E

81

From the few times that I came across this "need", it ultimately boils down to this construct:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

This does work in C# assuming that T has a default constructor. You can even get the runtime type by typeof(T) and get the constructors by Type.GetConstructor().

The common Java solution would be to pass the Class<T> as argument.

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}