P4
This is a straw-man feature for working with values (specifically, Q-types)
before full language support is added. It is entered into JBS in order to
attract comments. It relates to the "minimal values proposal" at
http://cr.openjdk.java.net/~jrose/values/shady-values.html
A value-capable class, compiled from Java source, may have additional
annotations (or perhaps attributes) on selected fields and methods
which cause the introduction of Q-types, as a bytecode-level
transformation when the value-capable class's file is loaded or
compiled.
Two transformations which seem useful may be called _Q-replacement_
and _Q-overloading_. The first deletes L-types and replaces them
by L-types, while the second simply copies methods, replacing some
or all of the L-types in their descriptors by corresponding Q-types.
A `@ReplaceByValueType` annotation on a field, method parameter, or
method return type can signal a transformer to change affected L-types
to Q-type.
Q-replacement is easy to ask for but hard to implement. It must
replace not only the types, but also all bytecodes that operate on
those types. The replacement bytecodes must either be value-capable,
or suitablely formulated invokedynamic instructions.
Q-overloading is a little simpler. An `@OverloadByValueType`
annotation on a method parameter or return type can signal a
transformer to add a new overloading of the same method name with the
variant descriptor. The new overloading can delegate to the original
after boxing parameters and/or unboxing return values. Or it can have
a copy of the original method, with bytecodes pervasively replaced.
(The annotations may need options which specify whether they are
applied all at once, or independently, which potentially could cause
large combinatorial expansion of the descriptor set.)
An alternative to annotation-driven Q-replacment would be an
experimental language feature allowing Q-types to be mentioned
directly in Java source. Such experiments are likely to happen
as part of Project Valhalla, and may happen early enough to make
this transformation unnecessary.
before full language support is added. It is entered into JBS in order to
attract comments. It relates to the "minimal values proposal" at
http://cr.openjdk.java.net/~jrose/values/shady-values.html
A value-capable class, compiled from Java source, may have additional
annotations (or perhaps attributes) on selected fields and methods
which cause the introduction of Q-types, as a bytecode-level
transformation when the value-capable class's file is loaded or
compiled.
Two transformations which seem useful may be called _Q-replacement_
and _Q-overloading_. The first deletes L-types and replaces them
by L-types, while the second simply copies methods, replacing some
or all of the L-types in their descriptors by corresponding Q-types.
A `@ReplaceByValueType` annotation on a field, method parameter, or
method return type can signal a transformer to change affected L-types
to Q-type.
Q-replacement is easy to ask for but hard to implement. It must
replace not only the types, but also all bytecodes that operate on
those types. The replacement bytecodes must either be value-capable,
or suitablely formulated invokedynamic instructions.
Q-overloading is a little simpler. An `@OverloadByValueType`
annotation on a method parameter or return type can signal a
transformer to add a new overloading of the same method name with the
variant descriptor. The new overloading can delegate to the original
after boxing parameters and/or unboxing return values. Or it can have
a copy of the original method, with bytecodes pervasively replaced.
(The annotations may need options which specify whether they are
applied all at once, or independently, which potentially could cause
large combinatorial expansion of the descriptor set.)
An alternative to annotation-driven Q-replacment would be an
experimental language feature allowing Q-types to be mentioned
directly in Java source. Such experiments are likely to happen
as part of Project Valhalla, and may happen early enough to make
this transformation unnecessary.