Status update: generic specializer

[Brian Goetz]

You're not wrong that it *could*; it's a near-trivial extension of the 
machinery to do so.

The only question -- and this is a huge one -- is whether we *should*, 
because it will create some potentially surprising behavior and some 
potentially undesirable results.

For example, here's something that would change:

   List<String> list = new ArrayList<String>();
   if (list instanceof List) { ... }

My belief (could be wrong) is that people are more willing to accept 
drawing the "weird things happen" line at the gap between primitive and 
reference, than if that line can happen anywhere.

Second, think of the (a) footprint cost and (b) benefit.  The former is 
large; the latter has yet to be proven.

Third, think about the complexity consequences of "by opt-in, of 
course".  Who gets to determine whether a give List<String> is an 
instance of erased List or some String-specific specialization that is 
not related to raw List?  Do the two types -- List<unspecialized String> 
and List<specialized String> get spelled the same way?  If so, we've 
then "erased" the distinction for anyone who didn't directly instantiate 
the thing, which is not so good.  On the other hand, if they have to be 
spelled different ways, you've just made generics 2x more complicated. 
That doesn't seem so good either.

So while its possible that the machinery could trivially do this, I 
think there's a big "do we really want to" question lurking here.  So 
far I see lots of complexity and very little upside (other than being 
able to claim "generics are now reified", but I think such a claim would 
be somewhat hollow.)

On 8/25/2014 5:04 PM, Paul Benedict wrote:
> Thanks Brian. I've been curious if there is a reason, beyond the
> extensive use of memory, that the specializer couldn't be use to reifiy
> any generalized classes (by opt-in of course). That doesn't seem to be a
> step much further off once you have TypeVariablesMap existing. How wrong
> am I in this assessment?
>
>
> Cheers,
> Paul
>
>
> On Mon, Aug 25, 2014 at 3:36 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     We've gotten the generic specializer to a point where it can do
>     quite a lot; I've pushed code to the jdk/ repo so that
>     specialization now can happen on the fly through classloading hacks.
>
>     Maurizio has already posted details on the compiler part of the
>     implementation.  To opt into specialization, decorate a
>     specializable type variable with the "any" modifier:
>
>     class Box<any T> {
>          T element;
>
>          Box(T t) { this.t = t; }
>
>          T get() { return t; }
>
>          void set(T t) { this.t = t; }
>     }
>
>     When used as a raw type, or with reference types as the
>     instantiation of T, things will behave exactly as before.  When used
>     with primitive instantiations of T, a new class will be specialized
>     on the fly when needed, rewriting T to its specialized value in
>     interface and implementation.
>
>     There are *many* limitations.  But, it is at the point where a lot
>     of things work already, and people may well want to play with it,
>     and you should be able to just use javac and java from the valhalla
>     build and do some reasonable simple things with specialized classes.
>
>     Next up: specializing ArrayList<int>.
>
>     Have fun!
>
>