-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
8
-
x86_64
-
windows_7
FULL PRODUCT VERSION :
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b123)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b65, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
independant
A DESCRIPTION OF THE PROBLEM :
Type annotations for instanceof / new are compiled differently for JDK and Eclipse.
The type structure contains an offset in this case, which points to the previous operation for JDK and not to the relevant operation.
Example:
public static String testTypeParam() {
CharSequence str = "test";
return (@Nonnull String) str;
}
Javac:
public static java.lang.String testTypeParam();
0 ldc <String "test"> [5]
2 astore_0 [str]
3 aload_0 [str]
4 checkcast java.lang.String [4]
7 areturn
Line numbers:
[pc: 0, line: 61]
[pc: 3, line: 62]
Local variable table:
[pc: 3, pc: 8] local: str index: 0 type: java.lang.CharSequence
RuntimeVisibleTypeAnnotations:
#31 @org.decojer.cavaj.test.jdk8.Nonnull(
target type = 0x47 CAST
offset = 3
type argument index = 0
)
Offset 3 should be offset 4 for the chackcast operation (like Eclipse compiler does).
The current specification for such type annotations says:
"The value of the offset item specifies the code array offset of either the
instanceof bytecode instruction corresponding to the instanceof expression, the
new bytecode instruction corresponding to the new expression, or the bytecode
instruction corresponding to the method or constructor reference expression."
I would guess the javac does it wrong / not spec conform and the offset is to small?
One serious consequence here is, that the ASM 5 visits the operations and type annotations in different orders for Eclipse and JDK. The type annotation visitor method is triggered before the operation visitor, which is very bad to handle from the customizing view point.
Thx
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b123)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b65, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
independant
A DESCRIPTION OF THE PROBLEM :
Type annotations for instanceof / new are compiled differently for JDK and Eclipse.
The type structure contains an offset in this case, which points to the previous operation for JDK and not to the relevant operation.
Example:
public static String testTypeParam() {
CharSequence str = "test";
return (@Nonnull String) str;
}
Javac:
public static java.lang.String testTypeParam();
0 ldc <String "test"> [5]
2 astore_0 [str]
3 aload_0 [str]
4 checkcast java.lang.String [4]
7 areturn
Line numbers:
[pc: 0, line: 61]
[pc: 3, line: 62]
Local variable table:
[pc: 3, pc: 8] local: str index: 0 type: java.lang.CharSequence
RuntimeVisibleTypeAnnotations:
#31 @org.decojer.cavaj.test.jdk8.Nonnull(
target type = 0x47 CAST
offset = 3
type argument index = 0
)
Offset 3 should be offset 4 for the chackcast operation (like Eclipse compiler does).
The current specification for such type annotations says:
"The value of the offset item specifies the code array offset of either the
instanceof bytecode instruction corresponding to the instanceof expression, the
new bytecode instruction corresponding to the new expression, or the bytecode
instruction corresponding to the method or constructor reference expression."
I would guess the javac does it wrong / not spec conform and the offset is to small?
One serious consequence here is, that the ASM 5 visits the operations and type annotations in different orders for Eclipse and JDK. The type annotation visitor method is triggered before the operation visitor, which is very bad to handle from the customizing view point.
Thx
REPRODUCIBILITY :
This bug can be reproduced always.
- duplicates
-
JDK-8033803 Incorrect offset for type annotations for NEW / CHECKCAST etc.
- Resolved