Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable
John Rose
john.r.rose at oracle.com
Wed Mar 18 22:01:26 UTC 2020
On Mar 18, 2020, at 8:54 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> Overall, the approach seems sound, and I like that you are introducing only one new bootstrap that is usable for a range of things. A few comments and questions.
>
> 1. Not sure the explicit source type carries its weight, but whether it does or not is probably informed by whatever we do for (3) below.
It seems true to me that Object is an acceptable universal source
type. You can convert anything in the CP to Object without loss
of information. IIRC this is true even for the asType rules; they
are designed to take most of their information (when deciding
which conversions to apply) from the target type, not the source
type.
> 2. Naming: “convert” seems kind of general; the name should suggest some sort of asType conversion. asType is pretty rich, and will get richer in the future, so aligning with that is probably a good move.
+1 Suggest “convertAsType”.
> 3. The spec on convert() needs to be fleshed out, as to exactly which set of conversions are supported. “Exactly the same set as asType” is OK; “similar to asType” is kind of vague. Similarly, the spec on parameters and exceptions could be fleshed out a bit too.
+1 I suggest a formal semantics along these lines:
var id = identity(sourceType); // could be destType also
var mt = methodType(destType, sourceType);
var conv = explicitCastArguments(id, mt);
return conv.invoke(x);
The explicitCastArguments is linked to asType but adjusts
the handling of interfaces and of subword types (char
and boolean, byte and short) to more closely match the
conventions used by JVM bytecodes, when that differs
from the conventions used in the Java language.
I think it covers the conversions of JVM-level values
you are likely to encounter in the constant pool.
— John
More information about the core-libs-dev
mailing list