JDK 14 EA b32 compiles
class Example {
static void example(Object e) {
if (e instanceof String s) {
nop(s);
}
}
public static void main(String[] args) {
example(new Object());
example("");
}
static void nop(String s) {
}
}
into
static void example(java.lang.Object);
descriptor: (Ljava/lang/Object;)V
flags: (0x0008) ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: astore_2
2: aload_2
3: instanceof #7 // class java/lang/String
6: ifeq 26
9: aload_2
10: checkcast #7 // class java/lang/String
13: dup
14: astore_1
15: aload_2
16: checkcast #7 // class java/lang/String
19: if_acmpne 26
22: aload_1
23: invokestatic #9 // Method nop:(Ljava/lang/String;)V
26: return
which contains two comparisons (at offsets 6 and 19).
Presence of the second one is redundant,
and quite unfortunate for bytecode analysis tools,
such as code coverage tool JaCoCo,
because one of the two branches of this comparison is never executed
and will be present in code coverage report as uncovered,
whereas looking at the source code users will expect to see only one comparison.
See attached screenshots.
Also see https://mail.openjdk.java.net/pipermail/amber-dev/2020-January/005477.html
according to Remi Forax
> clearly the generated bytecode should be cleaned up
class Example {
static void example(Object e) {
if (e instanceof String s) {
nop(s);
}
}
public static void main(String[] args) {
example(new Object());
example("");
}
static void nop(String s) {
}
}
into
static void example(java.lang.Object);
descriptor: (Ljava/lang/Object;)V
flags: (0x0008) ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: aload_0
1: astore_2
2: aload_2
3: instanceof #7 // class java/lang/String
6: ifeq 26
9: aload_2
10: checkcast #7 // class java/lang/String
13: dup
14: astore_1
15: aload_2
16: checkcast #7 // class java/lang/String
19: if_acmpne 26
22: aload_1
23: invokestatic #9 // Method nop:(Ljava/lang/String;)V
26: return
which contains two comparisons (at offsets 6 and 19).
Presence of the second one is redundant,
and quite unfortunate for bytecode analysis tools,
such as code coverage tool JaCoCo,
because one of the two branches of this comparison is never executed
and will be present in code coverage report as uncovered,
whereas looking at the source code users will expect to see only one comparison.
See attached screenshots.
Also see https://mail.openjdk.java.net/pipermail/amber-dev/2020-January/005477.html
according to Remi Forax
> clearly the generated bytecode should be cleaned up
- duplicates
-
JDK-8236911 Extra checkcast instruction in compiled code with "Pattern Matching" feature
- Closed
- relates to
-
JDK-8231826 Implement javac changes for pattern matching for instanceof
- Resolved