Static fields in specialized classes

Brian Goetz brian.goetz at
Wed Oct 15 15:32:49 UTC 2014

In a perfect world, of course that's what we'd do.  For examples of how 
the world is imperfect, I refer you to the experience of Scala in trying 
to unify primitives and references -- it was a disaster.  (See Paul 
Philip's talk at JVMLS 2013 for one example of this.)

In light of this, our conclusion is that the schism between values and 
references is real, and what is needed is to treat it in a less ad-hoc 
way, but not make attempts to hide it, since such attempts usually fail 
(and when they do, the failures are even more painful.)

Is this unfortunate?  Sure.  Should we give up because its hard?  Of 
course not.

On 10/15/2014 11:24 AM, Paul Benedict wrote:
> For the record, I don't find it funny or annoying how erasures exist. I am
> generally content with the current all-to-1 mapping. I was hoping when
> valhalla started, the implementation sought would be to unify primitives
> and objects into one type hierarchy (could be represented in <?>), but the
> current implementation does seem to further the schism of objects and
> primitives. Schisms are bad. I agree with Stephen again on this. I think
> specializing with primitives should keep the current all-to-1 mapping --
> despite whatever happens to the bytecode underneath.
> Cheers,
> Paul
> On Wed, Oct 15, 2014 at 10:11 AM, Stephen Colebourne <scolebourne at>
> wrote:
>> On 15 October 2014 15:19, Brian Goetz <brian.goetz at> wrote:
>>> The fundamental question for an implementation of generics is the mapping
>>> between types and classes.  (List<String> is a type; List.class is a
>> class.)
>> Isn't the issue that the class concept is being split into two
>> different meanings?
>> List<String> is a type (unchanged)
>> List<int> and List<T> are distinct bytecode units
>> List is the single piece of source code and overall concept
>> Are we not debating which of the last two the current Class concept
>> best maps to?
>> I'm arguing that it is the concept that I want to refer to in code
>> (instanceof, method signature, overloads), as that is far more common
>> than a need to think about the bytecode unit (reflection).
>>> In Java 5, all instantiations of List<X>, for reference X, mapped to
>> class
>>> List.class; this is an all-to-1 mapping.  This is simple but everyone
>> seems
>>> to think this is smelly and complains about it a lot.
>> I think those are mostly "noise" complaints. Developers have fully
>> internalised this all to 1 mapping at this point and I'd disagree with
>> the "everyone complains" statement.
>> Stephen

More information about the valhalla-dev mailing list