java.lang.Class literals

Brian Goetz brian.goetz at
Wed Aug 12 04:30:14 UTC 2015

> We can express j.l.Class literals representing specialized classes with:

… all true, and this set of behaviors is reasonable, but bear in mind that what is supported here and not supported here is mostly accidental — this is currently a very rough edge and a lot more thought is needed before you should infer anything about intent from the behavior...

> But let us take the following:
> class Double<any T, any U> {}

… which goes at least doubly true for multiple type variables.  

> What's interesting is that there is no special run-time representation for a type inbetween:
> Double<byte, byte>  <:  Double<any, byte>  <: Double<any, any>
> Double<any, byte> gets "erased" to Double<any, any>.class, but we can still write Double<any, byte>.class which just represents an alias for Double<any, any>.class.

That’s correct, though we’ve not yet explained our strategy here on the translation story for multiple type variables (writeup in progress) nor are we convinced that the current compiler behavior is exactly in line with our intentions here.  More work needed.  

> So I wonder if that Class literal limitations could be lifted and allow the following:
>   Double<?, int>.class
>   Double<int, ?>.class

Not unreasonable.  We have yet to really start working on the connection to reflection, though.  Of course, we have some ideas, but right now the compiler basically does “something” but probably best to not read too much into why it does that particular something rather than something else.  

> And, for consistency, also the following:

Rather than reasoning from “consistency with what else works now”, better to look for a credible rule that tells us what should work and what should not :)  

> What do you think?

All seems reasonable.  But dealing with the reflective story requires some other things to settle out first, and then we plan to revisit the whole reflection story.

More information about the valhalla-dev mailing list