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?
oxbow_lakes
  • 133,303
  • 56
  • 317
  • 449
  • Would this mean that you could get the class of a generic type at runtime? (if so, I have an example!) – James B Dec 18 '09 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. – kdgregory Dec 18 '09 at 14:51
  • 2
    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. – kdgregory Dec 18 '09 at 15:01
  • 1
    Actually, **Java does provide reified generics in a very restricted way**. I provide more details in this SO thread: http://stackoverflow.com/questions/879855/what-are-reified-generics-how-do-they-solve-the-type-erasure-problem-and-why-ca – Richard Gomes Jul 05 '12 at 02:09
  • The [JavaOne Keynote](http://mreinhold.org/blog/_aux/j1-2012-tech-keynote-fx+se+em.pdf) indicates that Java 9 will support reification. – Rangi Keen Jan 07 '14 at 21:44

13 Answers13

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) { ... }
RHSeeger
  • 16,034
  • 7
  • 51
  • 41
  • 5
    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. – Tom Hawtin - tackline Dec 18 '09 at 13:25
  • 27
    @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 void my_method(List input) {}` isn't a better idea. – BalusC Dec 18 '09 at 13:51
  • 1
    Hm, I would tend to avoid overloading with identical number of parameters altogether, and prefer something like `myStringsMethod(List input)` and `myIntegersMethod(List input)` even if overloading for such a case was possible in Java. – Fabian Steeg Dec 18 '09 at 14:58
  • 4
    @Fabian: Which means you've got to have separate code, and prevent the sort of advantages you get from `` in C++. – David Thornley Dec 18 '09 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? – rsp Dec 18 '09 at 17:00
  • @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 as List. 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. – RHSeeger Dec 18 '09 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. – rsp Dec 18 '09 at 20:15
  • @BalusC Old comment, but isn't `T extends Object` redundant since everything extends object and `List` is the same as `List>`? – Navin Aug 06 '13 at 04:24
  • @Navin the first part of your statement is correct, but the latter is not. `List` means "`List` holding objects of the class represented by generic parameter `T`", while `List>` means "List holding objects of an unknown type". http://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html – JAB Jan 10 '14 at 13:57
  • @JAB 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` to a method (where `T` can be anything) is better than accepting a `List>`? – Navin Jan 13 '14 at 00:36
  • @Navin 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. – JAB Jan 13 '14 at 12:58
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:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 5
    This works (for example) in C#? How do you know that T has a default constructor? – Thomas Jung Dec 18 '09 at 12:11
  • 4
    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. – BalusC Dec 18 '09 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. – Thomas Jung Dec 18 '09 at 12:27
  • 3
    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. – oxbow_lakes Dec 18 '09 at 12:28
  • 1
    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` field, but not from `List` class. – BalusC Dec 18 '09 at 12:29
  • @BalusC - Super type tokens (new Type>(){}) are a workaround to transport generic type information and there are Scala's Manifest. – Thomas Jung Dec 18 '09 at 12:35
  • @Thomas: this workaround require that you know the type during build/compile. In some cases you just don't know. – BalusC Dec 18 '09 at 12:35
  • @BalusC - That's the same for reified types. The type information has to be there at compile time. – Thomas Jung Dec 18 '09 at 12:38
  • Back to the starting point: new T() does not compile in C#, right? – Thomas Jung Dec 18 '09 at 12:41
  • 35
    It does compile in C# provided that you declare the type as: public class Foo where T : new(). Which will limit the valid types of T to those that contain a parameterless constructor. – Martin Harris Dec 18 '09 at 12:55
  • Would using t.clone() be of any use here? – OscarRyz Dec 18 '09 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. – PSpeed Dec 18 '09 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". – Ran Biron Dec 18 '09 at 19:04
  • 1
    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... – Toaster Dec 12 '13 at 16:20
  • 3
    @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 http://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.) – JAB Jan 08 '14 at 19:00
  • @JAB 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) – Toaster Jan 10 '14 at 13:22
  • @Colin Yes, if you supply the class objects of the types in question when instantiating the classes. http://stackoverflow.com/questions/51582/java-generics-comparing-the-class-of-object-o-to-e – JAB Jan 10 '14 at 13:46
  • @JAB 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. – Toaster Jan 12 '14 at 10:13
  • 1
    @Colin Which is why I suggested using class objects (e.g. `Class` and `Class`). 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 `Object`s, 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). – JAB Jan 13 '14 at 13:23
  • @JAB 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. – Toaster Jan 13 '14 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. – JAB Jan 13 '14 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). – JAB Jan 13 '14 at 17:44
  • 1
    Very professional communication indeed. And good day to you, too. – Fyodor Soikin May 19 '14 at 22:19
35

Type safety comes to mind. Downcasting to a parametrized type will always be unsafe without reified generics:

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!?

Also, abstractions would leak less - at least the ones which may be interested in runtime information about their type parameters. Today, if you need any kind of runtime information about the type of one of the generic parameters you have to pass its Class along as well. That way, your external interface depends on your implementation (whether you use RTTI about your parameters or not).

gustafc
  • 28,465
  • 7
  • 73
  • 99
  • 1
    Yes - I have a way around this in that I create a `ParametrizedList` which copies the data in the source collection checking types. It'sa bit like `Collections.checkedList` but can be seeded with a collection to start with. – oxbow_lakes Dec 18 '09 at 12:39
  • @tackline - well, *a few* abstractions would leak less. If you need access to type metadata in your implementation, the external interface will tell on you because clients need to send you a class object. – gustafc Dec 18 '09 at 13:55
  • ... meaning that with reified generics, you could add stuff like `T.class.getAnnotation(MyAnnotation.class)` (where `T` is a generic type) without changing the external interface. – gustafc Dec 18 '09 at 14:03
  • @gustafc: if you think that C++ templates give you complete type safety, read this: http://www.kdgregory.com/index.php?page=java.generics.cpp – kdgregory Dec 18 '09 at 14:47
  • @kdgregory: I never said that C++ was 100% type safe - just that erasure damages type safety. As you say yourself, "C++, it turns out, has its own form of type erasure, known as the C-style pointer cast." But Java only does dynamic casts (not reinterpreting), so reification would plug this whole in the type system. – gustafc Dec 18 '09 at 15:17
  • Been there - gone all the way from "lets put a thing", to "lets put a list of things" to "oh noes, I need more than one type of thing". Always end up building a wrapper around the session to handle type casts (a la "spring recommended" style - don't mix cache/factory code with your real code). – Ran Biron Dec 18 '09 at 19:07
  • I'm a bit late to the party, but does it *really* improve type safety? Your program will crash sooner, but it still crashes at runtime. – Jasper-M Sep 22 '15 at 13:02
27

You'd be able to create generic arrays in your code.

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}
Turnor
  • 1,836
  • 12
  • 14
  • what's wrong with Object? An array of objects is array of references anyway. It's not like the object data is sitting on the stack - it's all in the heap. – Ran Biron Dec 18 '09 at 19:11
  • 20
    Type safety. I can put whatever I want in Object[], but only Strings in String[]. – Turnor Dec 18 '09 at 19:44
  • 3
    Ran: Without being sarcastic: You might like using a scripting language instead of Java, then you have the flexibility of untyped variables anywhere! – flying sheep Mar 21 '13 at 18:04
  • 2
    Arrays are covariant (and hence not typesafe) in both languages. `String[] strings = new String[1]; Object[] objects = strings; objects[0] = new Object();` Compiles fine in both languages. Runs notsofine. – Martijn Aug 07 '15 at 11:06
18

This is an old question, there are a ton of answers, but I think that the existing answers are off the mark.

"reified" just means real and usually just means the opposite of type erasure.

The big problem related to Java Generics:

  • This horrible boxing requirement and disconnect between primitives and reference types. This isn't directly related to reification or type erasure. C#/Scala fix this.
  • No self types. JavaFX 8 had to remove "builders" for this reason. Absolutely nothing to do with type erasure. Scala fixes this, not sure about C#.
  • No declaration side type variance. C# 4.0/Scala have this. Absolutely nothing to do with type erasure.
  • Can't overload void method(List<A> l) and method(List<B> l). This is due to type erasure but is extremely petty.
  • No support for runtime type reflection. This is the heart of type erasure. If you like super advanced compilers that verify and prove as much of your program logic at compile time, you should use reflection as little as possible and this type of type erasure shouldn't bother you. If you like more patchy, scripty, dynamic type programming and don't care so much about a compiler proving as much of your logic correct as possible, then you want better reflection and fixing type erasure is important.
user2684301
  • 2,550
  • 1
  • 24
  • 33
  • 1
    Mostly I find it hard with serialization cases. You often would like to be able to sniff out the class types of generic things getting serialized but you are stopped short because of type erasure. It makes it hard to do something like this `deserialize(thingy, List.class)` – Cogman Aug 06 '14 at 23:10
  • 3
    I think this is the best answer. Especially parts describing what issues are really fundametally due to type erasure and what are just Java language design problems. The first thing I tell people starting erasure-whining is that Scala and Haskell are working by type erasure too. – aemxdp Oct 05 '14 at 13:23
15

Serialization would be more straightforward with reification. What we would want is

deserialize(thingy, List<Integer>.class);

What we have to do is

deserialize(thing, new TypeReference<List<Integer>>(){});

looks ugly and works funkily.

There are also cases where it would be really helpful to say something like

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

These things don't bite often, but they do bite when they happen.

Cogman
  • 2,070
  • 19
  • 36
  • This. A thousand times this. Every time I try to write deserialization code in Java I spend the day lamenting that I'm not working in something else – Basic Dec 29 '14 at 20:21
11

My exposure to Java Geneircs is quite limited, and apart from the points other answers have already mentioned there is a scenario explained in the book Java Generics and Collections, by Maurice Naftalin and Philip Walder, where the reified generics are useful.

Since the types are not reifiable, it is not possible to have Parameterized exceptions.

For example the declaration of below form is not valid.

class ParametericException<T> extends Exception // compile error

This is because the catch clause checks whether the thrown exception matches a given type. This check is same as the check performed by instance test and since the type is not reifiable the above form of statement is invalid.

If the above code was valid then exception handling in the below manner would have been possible:

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

The book also mentions that if Java generics are defined similar to the way C++ templates are defined (expansion) it may lead to more efficient implementation as this offers more opportunities for optimization. But doesn't offer any explanation more than this, so any explanation (pointers) from the knowledgeable folks would be helpful.

omiel
  • 1,573
  • 13
  • 16
sateesh
  • 27,947
  • 7
  • 36
  • 45
  • 1
    It's a valid point but I'm not quite sure why an exception class so parametrized would be useful. Could you modify your answer to contain a brief example of when this might be useful? – oxbow_lakes Dec 18 '09 at 18:22
  • @oxbow_lakes:Sorry My knowledge of Java Generics is quite limited and I am making an attempt to improve upon it. So now I am not able to think of any example where parametrized exception could be useful. Will try to think about it. Thx. – sateesh Dec 18 '09 at 19:23
  • It could act as a substitute for multiple inheritance of exception types. – meriton Dec 19 '09 at 15:33
  • 1
    The performance improvment is that currently, a type parameter must inherit from Object, requiring boxing of primitive types, which imposes an execution and memory overhead. – meriton Dec 19 '09 at 15:34
8

Arrays would probably play much nicer with generics if they were reified.

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • 2
    Sure, but they would still have problems. `List` is not a `List`. – Tom Hawtin - tackline Dec 18 '09 at 13:18
  • Agree - but only for primitives (Integer, Long, etc). For "regular" Object, this is the same. Since primitives can't be a parameterized type (a far more serious issue, at least IMHO), I don't see this as a real pain. – Ran Biron Dec 18 '09 at 19:10
  • 3
    The problem with arrays is their covariance, nothing to do with reification. – Recurse Jul 30 '10 at 06:01
5

I have a wrapper that presents a jdbc resultset as an iterator, (it means I can unit test database-originated operations a lot easier through dependency injection).

The API looks like Iterator<T> where T is some type that can be constructed using only strings in the constructor. The Iterator then looks at the strings being returned from the sql query and then tries to match it to a constructor of type T.

In the current way that generics are implemented, I have to also pass in the class of the objects that I will be creating from my resultset. If I understand correctly, if generics were reified, I could just call T.getClass() get its constructors, and then not have to cast the result of Class.newInstance(), which would be far neater.

Basically, I think it makes writing APIs (as opposed to just writing an application) easier, because you can infer a lot more from objects, and thereby less configuration will be necessary...I didn't appreciate the implications of annotations until I saw them being used in things like spring or xstream instead of reams of config.

James B
  • 3,692
  • 1
  • 25
  • 34
  • But passing in the class seems safer all round to me. In any case, reflectively creating instances from database queries is extremely brittle to changes such as refactoring anyway (in both your code and the database). I guess I was looking for things whereby it is just *not possible* to provide the class – oxbow_lakes Dec 18 '09 at 12:31
5

One nice thing would be avoiding boxing for primitive (value) types. This is somewhat related to the array complaint that others have raised, and in cases where memory use is constrained it could actually make a significant difference.

There are also several types of problems when writing a framework where being able to reflect over the parameterized type is important. Of course this can be worked around by passing a class object around at runtime, but this obscures the API and places an additional burden on the user of the framework.

kvb
  • 54,864
  • 2
  • 91
  • 133
3

It's not that you will achieve anything extraordinary. It will just be simpler to understand. Type erasure seems like a hard time for beginners, and it ultimately requires one's understanding on the way the compiler works.

My opinion is, that generics are simply an extra that saves a lot of redundant casting.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • This is certainly what generics are _in Java_. In C# and other languages they're a powerful tool – Basic Dec 29 '14 at 20:19
1

Something that all the answers here have missed that is constantly a headache for me is since the types are erased, you cannot inherit a generic interface twice. This can be a problem when you want to make fine grained interfaces.

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!
ExCodeCowboy
  • 870
  • 7
  • 10
0

Here's one that's caught me today: without reification, if you write a method that accepts a varargs list of generic items ... callers can THINK they're typesafe, but accidentally pass in any-old crud, and blow up your method.

Seems unlikely that would happen? ... Sure, until ... you use Class as your datatype. At this point, your caller will happily send you lots of Class objects, but a simple typo will send you Class objects that don't adhere to T, and disaster strikes.

(NB: I may have made a mistake here, but googling around "generics varargs", the above appears to be just what you'd expect. The thing that makes this a practical problem is the use of Class, I think - callers seem to be less careful :( )

For instance, I'm using a paradigm that uses Class objects as a key in maps (it's more complex than a simple map - but conceptually that's what's going on).

e.g. this works great in Java Generics (trivial example) :

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

e.g. without reification in Java Generics, this one accepts ANY "Class" object. And it's only a tiny extension of the previous code :

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

The above methods have to be written out thousands of times in an individual project - so the possibility for human error becomes high. Debugging mistakes is proving "not fun". I'm currently trying to find an alternative, but don't hold much hope.

Adam
  • 32,900
  • 16
  • 126
  • 153