The decompiler abusively complains about an invalid
exception handler table with the following exception
trace:
jode.AssertError: ExceptionHandler order failed: not
24 < 27 <= 24
at
jode.flow.TransformExceptionHandlers.checkTryCatchOrder
(TransformExceptionHandlers.java:904)
at jode.flow.TransformExceptionHandlers.analyze
(TransformExceptionHandlers.java:928)
at jode.decompiler.MethodAnalyzer.analyzeCode
(MethodAnalyzer.java:577)
at jode.decompiler.MethodAnalyzer.analyze
(MethodAnalyzer.java:652)
at jode.decompiler.ClassAnalyzer.analyze
(ClassAnalyzer.java:359)
at jode.decompiler.ClassAnalyzer.dumpJavaFile
(ClassAnalyzer.java:624)
at jode.decompiler.Decompiler.decompile
(Decompiler.java:192)
The same class is correctly decompiler with JavaP.
Following is an extract corresponding to the exception
table output by javap:
Method void testCompleted(boolean)
0 aload_0
1 iload_1
2 putfield #14 <Field boolean success_>
5 aload_0
6 getfield #16 <Field java.lang.Object
testCompletionLock_>
9 astore_2
10 aload_2
11 monitorenter
12 aload_0
13 getfield #16 <Field java.lang.Object
testCompletionLock_>
16 invokevirtual #30 <Method void notify()>
19 aload_2
20 monitorexit
21 goto 29
24 astore_3
25 aload_2
26 monitorexit
27 aload_3
28 athrow
29 return
Exception table:
from to target type
12 21 24 any
24 27 24 any
Line numbers for method void testCompleted(boolean)
line 191: 0
line 192: 5
line 193: 12
line 194: 19
line 195: 29
Following is the corresponding original source:
public void testCompleted(boolean withSuccess) {
success_ = withSuccess;
synchronized(testCompletionLock_) {
testCompletionLock_.notify();
}
}
The source was compiled with the JDK 1.4beta3. I don't
quite understand why there is an exception handler in
this method since the source code does not have a try
block.
I can provide binary and source class if this can help
debugging the problem.
BTW, JODE is great, Thanks for this!
Regards,
Guillaume.
gberche@acm.org
Logged In: YES
user_id=18252
The VM spec lied again; section 4.9.5 said:
Java virtual machine code produced by Sun's compiler for
the Java programming language always generates exception
handlers such that: [...] The handler for an exception
will never be inside the code that is being protected.
This is the rule that I checked and that failed. The code
it produced is clear: The virtual machine locks and
unlocks monitors with monitorenter and monitorexit, so it
need to call monitorexit when an exception occurs. They
seemed to be a bit paranoid and put a second handler
around the monitorexit instruction.
I have to think how to handle this cleanly. The quick'n
dirty way is to simply remove all exception handlers that
violate this rule.
Logged In: YES
user_id=9521
I don't know whether this is the same error. During
decompilation of com.sun.tools.javac.v8.Main, I get:
$ java -cp "java-getopt-1.0.8.jar;jode.jar"
net.sf.jode.decompiler.Main --
classpath "D:\Programme\Java\j2sdk1.4.0
\jre\lib\rt.jar,D:\Programme\Java\j2sdk1.4.0\lib\tools.jar"
com.sun.tools.javac.v8.Main
java.lang.InternalError: ExceptionHandler order failed: not
22 < 22 <= 22
at
net.sf.jode.flow.TransformExceptionHandlers.checkTryCatchOrd
er(Unknown Source)
at
net.sf.jode.flow.TransformExceptionHandlers.analyze(Unknown
Source)
at net.sf.jode.decompiler.MethodAnalyzer.analyzeCode
(Unknown Source)
at net.sf.jode.decompiler.MethodAnalyzer.analyze
(Unknown Source)
at net.sf.jode.decompiler.ClassAnalyzer.analyze
(Unknown Source)
at net.sf.jode.decompiler.ClassAnalyzer.dumpJavaFile
(Unknown Source)
at net.sf.jode.decompiler.ClassAnalyzer.dumpJavaFile
(Unknown Source)
at net.sf.jode.decompiler.Main.decompileClass
(Unknown Source)
at net.sf.jode.decompiler.Main.decompile(Unknown
Source)
at net.sf.jode.decompiler.Main.main(Unknown Source)
Shouldn't 22 < 22 <= 22 be allowed, regardless of the VM
spec?!?
Dirk.
Logged In: YES
user_id=18252
Regarding Dirk's comment from today: This is exactly the
same error just in the jode-1.90-CVS variant.
BTW the error message should be "not 22 <= 22 < 22", as
this is what is checked (I changed the meaning of "try
block end" to be inclusive not exclusive).