Updated State of the Specialization

[Brian Goetz]

> Imho, a real fix would be to provide an alternative method which works
> better, not to introduce a huge language feature to work around one
> method. I don't want to imagine how the JVM/Java will look like if you
> add language feature work-arounds for every case of poor API design.

Which is exactly what the Map.get example in the document proposes; 
migrate the API to a better place, while retaining migration 
compatibility with the billions of lines of outstanding code.  But it 
needs some language help to retain compatibility.

I think this may be the actual point of contention here; it seems you're 
willing to inflict incompatibility on the user base for the sake of 
progress.  That's a fine strategy when you have no users / your users 
are all bleeding-edge adopters / you hate your users.  Unfortunately 
none of these are the case for us...so we have to do better.

That said, you've made your point, which is "I think this is a bigger 
hammer than is needed."  And you may well be right.  And once we're 
convinced the hammer offers the right degree of impulse delivery, we'll 
look for simplifications.  But we can't throw compatibility under the bus.

> (If or how the syntax will work in Java is not my main interest here.
> What matters is the bytecode. There were also a few ideas in the past to
> wrap this idiom in a "nicer" API like def default[T] =
> null.asInstanceOf[T] in Scala, but considering that a) the use of zero
> values is not that high b) null.asInstanceOf[T] works fine as an idiom,
> no further action was taken.)

This is all based on the way we reify hitherto-erased type information, 
though the BytecodeMapping attribute.  This gives us back the generic 
(not-erased) signature -- in a standard classfile signature format -- of 
the type.  If you did something like:

<any T> void foo() {
    ... T.default ... // please, don't comment on the syntax
}

the erased bytecode still has a aconst_null, but the BytecodeMapping 
attribute has a signature of TT;, so at specialization time, we'd 
specialize the aconst_null bytecode to the appropriate type (e.g., 
iconst_0).

> With the introduction of value types there needs to be a way to achieve
> this in bytecode, because an approach where you first check for every
> primitive type and return null otherwise just doesn't work with
> user-definable value types.

We've not yet settled on whether user-defined value types can define 
their own default value, or whether they just get "all fields 
initialized to their default value".  The latter is certainly simpler, 
but either way, there's a path to specializing the aconst_null to this 
(e.g., invoke no-arg "constructor".)

>> Here's another example, then: the problem of "Maps from int to int" is
>> a well-studied special case, with many clever implementation tricks
>> that are not available to more general-purpose maps.
> That's certainly a better example! I'm not sure whether creating the
> chance of having subtle behavioral differences between different
> collection instantiations is an acceptable price to pay for that, though.

Fair question.  On the other hand, its not clear that ruling it out 
without considering it is prudent either.