Question on layer/peeling
john.r.rose at oracle.com
Tue Jan 6 06:26:47 UTC 2015
On Jan 5, 2015, at 8:36 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> There's a relatively short path to getting this working:
> - Compiler accepts invocations of these methods on any-typed expressions, and emits calls to the Object methods;
> - Compiler includes receiver metadata in the bytecode mapping attribute (already done)
> - Specializer handles the case where you invoke one of these methods on a raw "any T" and rewrites as invocations to (say) Integer.toString().
I.e., Object is an honorary supertype of all types, by virtue of boxing conversions.
This trick is a good one, and it can go a bit farther with primitives, if you think about the other supertypes of Integer, Double, etc., especially Comparable. (I'd kind of like to define an interface Objectable to carry toS/eq/hC.)
The trick can also be coaxed to give semi-plausible semantics to seemingly bogus expressions like "x == null" or "x == (Object)y" (for any x). If "x" is a primitive, since autobox conversions never produce "null", then "x == null" and "x == (Object)y" are complicated ways of saying "false". But this doesn't help with nulling assignments like "a[i] = null"; there you need "T.null" (my bikeshed preference to "default(T)").
It might possibly help to add interfaces to the existing box types to factor out additional common behaviors, such as "+". Or, it might be an intractable can of worms, to enumerate and refactor all the primitive operations. Check Haskell's prelude definitions on arithmetics, for many interesting examples of bridges too far (for Java).
In any case, the value types draft allows values to implement interfaces, which can factor common behaviors across disparate values.
For example, a TreeMap will be able to contain value types that implement Comparable. (This fact is independent of whether and how TreeMap instances would be able to specialize to the value types, or would just use the generic erased structure to hold boxed values.)
P.S. The "nulling" operation is tricky for the reason Mike points out: You can't tell whether a value type embeds a pointer or not. VarHandles might be able to help with this, with a "resetReference" operation which is elidable if the target type has no references.
More information about the valhalla-dev