Develop Reference

Using cannonical constructor of local record (preview-feature) in Eclipse causes verify error

I am Trying to use records preview-feature with cannonical constructors in Eclipse .
public class Example {
public static void main(String[] args) {
record Range() {
Range {
}
}
new Range();
}
}
However, at run time a verify error is caused.
Exception in thread "main" java.lang.VerifyError: Constructor must
call super() or this() before return Exception Details: Location:
Example$1Range.(II)V #36: return Reason:
Error exists in the bytecode Bytecode:
0000000: 1b1c a400 22bb 000b 5912 0d05 bd00 0f59
0000010: 031b b800 1153 5904 1cb8 0011 53b8 0017
0000020: b700 1dbf b1 Stackmap Table:
same_frame(#36)
at Example.main(Example.java:10)
This happens both in eclipse 2020-06 with JDK 14 and eclipse 2020-19 with JDK 15.0.1 and eclipse 15 support.
There is no problem running it from the command line with bin\java and no error is thrown then.
Is this working for anyone else on their eclipse?
Are there any workarounds?

Is it possible to get the java code for a specific line from the dex file?

I am trying to analyse dex files, and I want to know if I can get the java code or what a specific bytes from the dex file mean.
Any help will be appreciated!

Getting java code from bytecode is called decompilation, and you will need to use a decompiler. Although I'm not aware of any decompiler that will do partial decompilation of just a snippet of bytecode. There may not even be enough info in that snippet to perform a proper decompilation.
"Or what specific bytes from the dex file mean" - you could try using baksmali's annotated dump functionality. It writes out a format that has the binary bytes on the left side, and a structured text view on the right side corresponding to the bytes on the left side.
e.g.
baksmali dump HelloWorld.dex
...
|-----------------------------
|code_item section
|-----------------------------
|
|[0] code_item: LHelloWorld;->main([Ljava/lang/String
|;)V
0001c4: 0200 | registers_size = 2
0001c6: 0100 | ins_size = 1
0001c8: 0200 | outs_size = 2
0001ca: 0000 | tries_size = 0
0001cc: 0000 0000 | debug_info_off = 0x0
0001d0: 0800 0000 | insns_size = 0x8
| instructions:
0001d4: 6200 0000 | sget-object v0, Ljava/lang/System;->out:Ljava/io
|/PrintStream;
0001d8: 1a01 0000 | const-string v1, "Hello World!"
0001dc: 6e20 0100 1000 | invoke-virtual {v0, v1}, Ljava/io/PrintStream;->
|println(Ljava/lang/String;)V
0001e2: 0e00 | return-void
...
On the left side we have
[offset]: [binary data] and then the right side has the interpreted view. e.g. field name and value, or disassembled instruction, etc.

java.lang.VerifyError: Stack map does not match the one at exception handler

Faced this java.lang.VerifyError with code snippet as below during JVM loading bytecode.
try{
-----
} catch (NumberFormatException|CalculationException e) {
}
Here CalculationException is custom exception which extends java.lang.RuntimeException, while NumberFormatException is standard Java RuntimeException.
While the code compile and run fine locally windows machine.
It fails with VerifyError on one of the QA/prod/Dev unix node, and works fine on other unix node. While both unix nodes have the same config (using RedHat 6.2 and 1.8 jdk and same version jar files) also compared the bytecode generated on both nodes by javap -c and found this same.
I found two ways to resolve this on erroneous node also.
1) As this error is coming at byte-code verification step, tried by disabling the bytecode verification on dev unix box as -Xverify:none (Also tried -XX:-UseSplitVerifier but dint work, as i think its disabled from jdk 8)
However as we shall not disable bytecode verification in prod, have been looking for some other workaround.
2) Another workaround is by using the parent exception: RuntimeException in catch block instead of combining two exception.
What I am not able to understand if Java does have issue with this way of catching, why compiler dint complained it and why it works on one machine and not on other which have same config.
Also the error reason is not making sense which says: CalculationException (current frame, stack[0]) is not assignable to 'java/lang/RuntimeException
While its actually assignable as tested by
if (RuntimeException.class.isAssignableFrom(CalculationException.class)){
System.out.println("Assisgnable");
}
Full Exception Details:
Location:
com/markit/valuations/marketdata/snapper/domain/credit/BeanWrapperBuilder_CDXOCompositeVolSurface.getSpreadVol(Lcom/markit/valuations/dates/ImmutableDate;Lcom/markit/valuations/marketdata/data/indexeddata/IndexedData;DLcom/markit/valuations/dates/ImmutableDate;Lcom/markit/valuations/dates/ImmutableDate;Ljava/lang/String;Ljava/lang/String;Lcom/markit/qag/analytics/credit/indexpv/swaption/CreditIndexSwaptionCalculator;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Double; #51: astore
Reason:
Type 'com/markit/valuations/common/CalculationException' (current frame, stack[0]) is not assignable to 'java/lang/RuntimeException' (stack map, stack[0])
Current Frame:
bci: #0
flags: { }
locals: { 'com/markit/valuations/marketdata/snapper/domain/credit/BeanWrapperBuilder_CDXOCompositeVolSurface', 'com/markit/valuations/dates/ImmutableDate', 'com/markit/valuations/marketdata/data/indexeddata/IndexedData', double, double_2nd, 'com/markit/valuations/dates/ImmutableDate', 'com/markit/valuations/dates/ImmutableDate', 'java/lang/String', 'java/lang/String', 'com/markit/qag/analytics/credit/indexpv/swaption/CreditIndexSwaptionCalculator', 'java/lang/String', 'java/lang/String' }
stack: { 'com/markit/valuations/common/CalculationException' }
Stackmap Frame:
bci: #51
flags: { }
locals: { 'com/markit/valuations/marketdata/snapper/domain/credit/BeanWrapperBuilder_CDXOCompositeVolSurface', 'com/markit/valuations/dates/ImmutableDate', 'com/markit/valuations/marketdata/data/indexeddata/IndexedData', double, double_2nd, 'com/markit/valuations/dates/ImmutableDate', 'com/markit/valuations/dates/ImmutableDate', 'java/lang/String', 'java/lang/String', 'com/markit/qag/analytics/credit/indexpv/swaption/CreditIndexSwaptionCalculator', 'java/lang/String', 'java/lang/String' }
stack: { 'java/lang/RuntimeException' }
Bytecode:
0x0000000: 2c19 0ab9 0015 0200 b800 cb2b 1906 ba00
0x0000010: cc00 00b6 00cd ba00 ce00 00b6 00cf 1909
0x0000020: ba00 d000 00b6 00cf 0eb8 003b b600 d1c0
0x0000030: 0091 b03a 0cbb 0048 59b7 0049 12d3 b600
0x0000040: 4b19 0ab6 004b 12d4 b600 4b2c 1254 b900
0x0000050: 1502 00b6 004b 12d5 b600 4b29 b600 4c12
0x0000060: d6b6 004b 1907 b600 4b12 d7b6 004b 1905
0x0000070: b600 5b12 d8b6 004b 1906 b600 5b12 d9b6
0x0000080: 004b 190b b600 4b12 dab6 004b 1908 b600
0x0000090: 4bb6 004d 3a0d b200 4719 0d19 0cb9 0081
0x00000a0: 0300 0eb8 003b b0
Exception Handler Table:
bci [0, 50] => handler: 51
bci [0, 50] => handler: 51
Stackmap Table:
same_locals_1_stack_item_frame(#51,Object[#535])

Cause
This happened to me when there were conflicting versions of the same library (Jar) in my dependencies. To be more specific, I was importing different versions of Jackson library v2.9.10 and v2.11.0.
Troubleshooting
Start your application in verbose mode and make java log all the classes it is loading to see where the conflicting class is coming from. This can be done by passing the flag -verbose:class
Fix
Remove conflicting versions of dependencies and make sure all related dependencies/libraries are of the same major version (at the least) and preferably the same minor version too.
Remove dependencies that transitively import conflicting version of direct dependencies.
If you are not seeing any conflicting dependencies even after using mvn dependency:tree or Maven Helper plugins, the conflicting dependency could have been imported by one of the libraries' classpath. I know this sounds weird, since only applications should have classpath, but if someone added <addClasspath>true</addClasspath> in their library pom file, it could lead to this.

The dependency crash is the cause as Aditya pointed out. If you are using SBT, here is how you can resolve it.
First, add the dependency graph to your global plugins ~/.sbt/1.0/plugins/plugins.sbt:
SBT 1.4+: add
addDependencyTreePlugin
SBT <1.3: add
addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.10.0-RC1")
Then in your project run
sbt "whatDependsOn com.fasterxml.jackson.core jackson-databind"
were com.fasterxml.jackson.core is the organization and jackson-databind is the artifact name of conflicting library. Mine also was because play-json is using 2.10.4 and Confluent packages use 2.9.9. You have to find yours based on the error messages that you received.
Then from this point forward, you need to make a decision on how to resolve it. Upgrade packages, or downgrade, or exclude libraries. In my scenario, because play-json was transitive dependency from a library that was not really critical in my application, I picked the easiest path and excluded 2.10.4 from play-json library.

you need to set the following jvm args in your config:
-XX:-UseSplitVerifier

Convert binary file data to normal .txt

I recently formatted my hard drive and forgot to save a java project from it. After trying to recover those files with recovery tools found on internet, I got the files back but... the content is unreadable; i.e. my Main.java class looks like :
108b 4424 5085 ff8b 403c 7e10 8b7c 2410
8904 2489 7c24 04e8 74b0 0200 8b74 2428
8d45 07c7 4424 2000 0000 0089 4424 1885
f60f 8e52 0100 0090 8b44 2450 8b7c 2420
8b4c 2410 8b40 1885 c98b 04b8 8944 2424
8b44 2450 8b40 248b 3cb8 8b44 2450 8b40
3c89 4424 1c0f 8e3d 0100 0031 f631 ed89
7c24 2c89 f7eb 0e90 c604 2f00 83c5 013b
6c24 1074 3f39 f57c ef8b 4424 1c8d 7436
0189 7424 0489 0424 e8f3 af02 0089 6c24
0889 7c24 0489 0424 8944 2414 e86f a202
...
What is this exactly? Is there a way I can write like a python script to translate it back to a readable java class ? Simple hexadecimal to ascii doesn't seem to work.

java.lang.VerifyError: Expecting a stackmap frame at branch target

Successfully compiled the project and build as well with Maven. This is my first maven project. But I have no idea why I'm getting the below error.
Deployeed the war on tomcat and hit my url and the below error shown in my browser.
java.lang.VerifyError: Expecting a stackmap frame at branch target 72
Exception Details:
Location:
com/ebetinc/frontend/presentation/components/Login.isToteAvailable(Ljava/lang/String;Lcom/ebetinc/frontend/dao/DatabaseDao;)Z #46: lookupswitch
Reason:
Expected stackmap frame at this location.
Bytecode:
0000000: 043d 2bb9 03a4 0100 4e2a c601 1c13 03a6
0000010: 2ab8 03aa 9900 0803 3da7 010d 2db8 03ad
0000020: 9900 692a 3a04 0236 0519 04b6 03b1 ab00
0000030: 0000 003a 0000 0002 0000 0626 0000 002c
0000040: 0000 0644 0000 001a 0019 0413 03b3 b603
0000050: b599 0017 0336 05a7 0011 1904 1303 b7b6
0000060: 03b5 9900 0604 3605 1505 ab00 0000 001c
0000070: 0000 0002 0000 0000 0000 001a 0000 0001
0000080: 0000 001a 033d a700 a02d b803 ba99 0099
0000090: 2a3a 0402 3605 1904 b603 b1ab 0000 006a
00000a0: 0000 0004 0000 af34 0000 0029 0000 af4c
00000b0: 0000 003a 0000 af4d 0000 004b 0015 51cb
00000c0: 0000 005c 1904 1303 bcb6 03b5 9900 3903
00000d0: 3605 a700 3319 0413 03be b603 b599 0028
00000e0: 0436 05a7 0022 1904 1303 c0b6 03b5 9900
00000f0: 1705 3605 a700 1119 0413 03c2 b603 b599
0000100: 0006 0636 0515 05aa 0000 001f 0000 0000
0000110: 0000 0003 0000 001d 0000 001d 0000 001d
0000120: 0000 001d 033d 1cac
Stackmap Table:
append_frame(#28,Integer,Object[#931])
append_frame(#73,Object[#200],Integer)
same_frame(#90)
same_frame(#104)
same_frame(#132)
chop_frame(#134,2)
same_frame(#137)
append_frame(#196,Object[#200],Integer)
same_frame(#213)
same_frame(#230)
same_frame(#247)
same_frame(#261)
same_frame(#292)
chop_frame(#294,2)
Can anyone throw some inputs ? Thanks for any help.
Configuration:
Java 1.7
Maven 3+

Hi this is related to some bytecode in your application. (see this note on compatibility changes for Java 7 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities, look there some lines below for JSR 202)
You can either
recompile all sources with JDK 7
or in case you have no access to the source
use java with paramter -XX:-UseSplitVerifier
or switch to Java 6 if you face promblems using the switch
edit Even the answer is already a bit old. Because of a current case I add some more detailed explanation.
The StackMapTable attribute in the class file was, even not documented at that time, introduced with Java 6.
Foo.java
public class Foo {
public static boolean bar(String s) {
if (s.length() == 0) {
return true;
}
return false;
}
}
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
$ javac Foo.java
$ javap -c -v Foo
Compiled from "Foo.java"
public class Foo extends java.lang.Object
SourceFile: "Foo.java"
minor version: 0
major version: 50
...
public static boolean bar(java.lang.String);
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokevirtual #2; //Method java/lang/String.length:()I
4: ifne 9
7: iconst_1
8: ireturn
9: iconst_0
10: ireturn
LineNumberTable:
line 3: 0
line 4: 7
line 6: 9
StackMapTable: number_of_entries = 1
frame_type = 9 /* same */
}
The class verifier did no check if the attribute was in the class or not.
Following creates the file Foo.class without the StackMatTable attribute.
FooDump.java
import org.objectweb.asm.*;
import java.io.*;
public class FooDump implements Opcodes {
public static void main(String[] args) throws Exception {
FileOutputStream fos = new FileOutputStream("Foo.class");
fos.write(dump());
fos.close();
}
public static byte[] dump() throws Exception {
ClassWriter cw = new ClassWriter(0);
FieldVisitor fv;
cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object",
null);
MethodVisitor mv = cw.visitMethod(ACC_PUBLIC, "<init>", "()V", null,
null);
mv.visitCode();
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(INVOKESPECIAL, "java/lang/Object", "<init>", "()V",
false);
mv.visitInsn(RETURN);
mv.visitMaxs(1, 1);
mv.visitEnd();
mv = cw.visitMethod(ACC_PUBLIC + ACC_STATIC, "bar",
"(Ljava/lang/String;)Z", null, null);
mv.visitCode();
mv.visitVarInsn(ALOAD, 0);
mv.visitMethodInsn(INVOKEVIRTUAL, "java/lang/String", "length", "()I",
false);
Label l0 = new Label();
mv.visitJumpInsn(IFNE, l0);
mv.visitInsn(ICONST_1);
mv.visitInsn(IRETURN);
mv.visitLabel(l0);
// this line would generate the StackMapTable attribute
// mv.visitFrame(Opcodes.F_SAME, 0, null, 0, null);
mv.visitInsn(ICONST_0);
mv.visitInsn(IRETURN);
mv.visitMaxs(1, 1);
mv.visitEnd();
cw.visitEnd();
return cw.toByteArray();
}
}
compile and run it
$ javac -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump.java
$ java -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump
check that the StackMapTable attribute is not in the file
$ javap -c -v Foo
public class Foo extends java.lang.Object
minor version: 0
major version: 50
...
public static boolean bar(java.lang.String);
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokevirtual #16; //Method java/lang/String.length:()I
4: ifne 9
7: iconst_1
8: ireturn
9: iconst_0
10: ireturn
}
FooDemo.java
public class FooDemo {
public static void main(String[] args) {
System.out.println("output: " + Foo.bar(""));
}
}
$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
$ javac FooDemo.java
$java FooDemo
output: true
With Java 7 the class verification was changed.
For class files version 50 (Java 6) the check had a failover if the StackMapTable was missing or wrong (see: jvms-4.10.1).
Run the check with the Foo class version of Java 6.
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum 5a7ea4a5dd2f6d1bcfddb9ffd720f9c9
public class Foo
minor version: 0
major version: 50 <-- class file Java 6
...
$ javac FooDemo.java
$ java FooDemo
output: true
This failover did not occur anymore for class files version 51 (Java 7).
To create a Foo class version of Java 7 amend the code of FooDump.java.
// cw.visit(V1_6, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object", null);
cw.visit(V1_7, ACC_PUBLIC + ACC_SUPER, "Foo", null, "java/lang/Object", null);
compile and run it
$ javac -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump.java
$ java -cp asm-5.2.jar:asm-util-5.2.jar:. FooDump
check that it's a class version 51
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum cfd57fb547ac98a1b2808549f5e9e8c1
public class Foo
minor version: 0
major version: 51 <-- class file Java 7
...
$ javac FooDemo.java
$ java FooDemo
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method Foo.bar(Ljava/lang/String;)Z at offset 4
In Java 7 the type check for the StackMapTable attribute can be disabled to step back to the Java 6 failover mechanism using option UseSplitVerifier.
$ java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
$ java -XX:-UseSplitVerifier FooDemo
output: true
In Java 8 the verification of the StackMapTable attribute became mandatory and the option UseSplitVerifier was removed.
$ java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
$ javap -c -v Foo
Classfile /home/suboptimal/playground/Foo.class
Last modified Jun 9, 2017; size 232 bytes
MD5 checksum cfd57fb547ac98a1b2808549f5e9e8c1
public class Foo
minor version: 0
major version: 51 <-- class file Java 7
...
$ javac FooDemo.java
$ java FooDemo
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9
$ java -XX:-UseSplitVerifier FooDemo
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option UseSplitVerifier; support was removed in 8.0
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9
note To use always the initial version of Java 6/7/8 was done by intention to show that the behaviour was there from the beginning.
You might find some suggestions to get it running with Java 8 ...
$ java -noverify FooDemo
output: true
$ java -Xverify:none FooDemo
output: true
note This disables the bytecode verifier. Keep in mind to never disable bytecode verification in a production system.

I've had the same problem running a Java 1.7 Web Application on a Java 1.7 Weblogic 12C server, while trying to deploy the error occurs:
java.lang.VerifyError: Expecting a stackmap frame at branch target 15
Exception Details: Location: aClassPathWithClassName.$javassist_write_aSpecificField(Ljava/lang/Long;)V
#6: ifnonnull Reason: Expected stackmap frame at this location.
Bytecode: 0000000: 2ab9 00cc 0100 c700 092a 2bb5 00ce b12a 0000010: 59b9 00d0 0100 2a12 d12a b400 ce2b
b900 0000020: d505 00c0 0081 b500 ceb1
From all classes within the project it happened only with the class being instrumented, aClassPathWithClassName (in the error output above).
My local solution:
Locate javassist lib being used by the application on the POM and update it. Here it was 3.10.0.GA, changed to 3.24.1-GA.