widen-unbox-widen vs JEP 455
Stephan Herrmann
stephan.herrmann at berlin.de
Sun Sep 1 08:44:46 UTC 2024
I just learned that reference widening followed by unboxing (followed by
primitive widening) is deemed a relevant conversion [1]. So I made sure that ecj
can handle this in various situation, only to find out that this will make ecj
produce code that is behaviorally different from what javac emits.
Here's my test code challenging this aspect of JEP 455:
//
<T extends Short> void typeVariableSingle(T single) {
int i1 = single;
System.out.print(i1);
if (single instanceof int i)
System.out.print(i);
else
System.out.print('-');
switch (single) {
case int i -> System.out.print(i);
default -> System.out.print('-');
}
System.out.println();
}
<T extends Short> void typeVariableList(List<T> list) {
int i1 = list.get(0);
System.out.print(i1);
if (list.get(0) instanceof int i)
System.out.print(i);
else
System.out.print('-');
switch (list.get(0)) {
case int i -> System.out.print(i);
default -> System.out.print('-');
}
System.out.println();
}
void wildcard(List<? extends Short> list) {
int i1 = list.get(0);
System.out.print(i1);
if (list.get(0) instanceof int i)
System.out.print(i);
else
System.out.print('-');
switch (list.get(0)) {
case int i -> System.out.print(i);
default -> System.out.print('-');
}
System.out.println();
}
void main() {
Short s = 1;
typeVariableSingle(s);
typeVariableList(Collections.singletonList(s));
wildcard(Collections.singletonList(s));
}
//
compiled with ecj this gives
111
111
111
compiled with javac the program prints
111
1-1
1-1
Is this a simple bug in javac, or is there more to it?
thanks
Stephan
[1] see answers to
https://mail.openjdk.org/pipermail/amber-spec-experts/2024-August/004204.html
More information about the compiler-dev
mailing list