Rémi Forax's Blog

Reified generics in Java

Neal Gafter post a blog entry about adding reified generics to Java. I likethat proposal mostly because developpers will have the choice betweeen reified or not reified generics.

About the syntax, i think it's better to use an anotation than to re-use the keyword class. Annotating a type variable is not currently allowed but it seems that the upcoming JSR 308 will allow that.

 class ArrayList<@Reified E> {
   ...
 }

 class ArrayList<class E> {
   ...
 }

The big question is why tagging the type variable and not the parametrized type.
I'm not sure that allowing to declare on a same parametrized type refied type variable and non refied is a good idea, because i don't see a use case.

 class HashMap<@Reified K,V> {

 }

Here, HashMap is not refiable because V is not refiable. So what is the need of half reified type ?

Else, i not sure about the fact that allowing reified generics requires to change collection interfaces. Allowing reified interfaces will just allow safe cast/instanceof, i wonder if it worth all problems linked to the introduction of a new collection hierarchy. It's perhaps up to a collection implementor to decide if a collection implentation will use or not reified generics.

To end, i've recently read a paper of Mirko Viroli about how to represent wildcard types at compiler level but i'am not aware of any work about that at VM level.

Rémi

Comments

• Your suggestion would make annotations change language semantics. That wont be popular in some quarters.

  Posted by: tackline on November 06, 2006 at 04:14 AM

• 
  Meta annotations like Retention or Target already change the semantic,
  but i understand that it could hurt.

  I'm not a big fan of keyword reuse, an intermediary solution could be
  to use a new keyword reified and only activated it
  as a keyword between '<' and '>' as export is
  only activated in super package of JSR 294.

  
  Rémi
  

  Posted by: forax on November 06, 2006 at 07:45 AM

• IMO having both "real" generics and non real (current) generics in the same code is too complex. I would instead make this a job for the new Compatibility API or if that's not possible create Java3 and get rid of all the baggage.

  Cheers,
  Mikael

  Posted by: mikaelgrev on November 06, 2006 at 08:46 AM

• 
  mikael, having both generics could be usefull, by example, when you code
  a LinkedList, the class itself can be a reified generics but the inner class
  that defined a link can use erased generics.
  You have the better of the both world, the linked list is safe at runtime
  and you don't have to carry a type argument for each link of the list.

  
  Remi
  

  Posted by: forax on November 06, 2006 at 02:07 PM

• Rémi, yes, you are right. What I am concerned about though is how many "average Java Joes" that will use and understand this feature. It will make Java too complex and we are firmly on the path towards the C++ debacle if we continue on this path.

  Cheers,
  Mikael

  Posted by: mikaelgrev on November 06, 2006 at 03:00 PM

• "Meta annotations like Retention or Target already change the semantic"

  Yes, sort of - and that's why they are meta-annotations. It's a corner case. They change the semantics of other annotations, not of arbitrary language features. It's light-years away from what you're trying to do.

  Not to mention that this use of annotation would be butt-ugly...

  What about reusing operators instead of keywords (or annotations)? Example:

  
  class ArrayList {
  ...
  }

  
  Not very intuitive (but "class E" isn't either), not very beautiful too, but at least it's very terse - good for really complex generic declarations, especially important as we have no typedefs...

  Posted by: opinali on November 08, 2006 at 07:21 AM

• Damn, forgot to escape the code.

  
  class ArrayList<+E> {
  ...
  }

  
  Another advantage of this operator synatx (over 'class') is that we can support primitive types -- passing "int" to "class E" would be really confusing. (I know this support for primitives is a hard call, but I can dream...)

  Posted by: opinali on November 08, 2006 at 07:25 AM

• 
  @opinali, first meta annotation changes annotation semantic
  because they are tagged with the meta annotation @Target(ElementType.ANNOTATION_TYPE) so i don't
  see a difference with an annotation tagged with
  @Target(ElementType.TYPE_VARIABLE).

  
  Else, your syntax is very close to the syntax proposed in order
  to add variance on generics.
  This syntax was rejected and
  remplaced by the wilcard syntax, so for me, your proposal is a
  step backward.
  

  Posted by: forax on November 09, 2006 at 12:25 AM

This work is licensed under a Creative Commons License.