Community
Participate
Working Groups
The class gets the following error at runtime: java.lang.VerifyError: (class: org/spec/jappserver/ruleengine/RuleParser, method: TypeDeclaration signature: ()V) Illegal target of jump or branch The test case is SPECjAppServer2002 v1.14. The ear file contains several EJB jar files, with interdependencies. RuleParser is in corp.jar. During the build, got the following msg from RMIC [*Warning] ejbModule/org/spec/jappserver/ruleengine/RuleParser.java(1995): The static method addDimension(int, LinkedList) from the type RuleProcessor should be accessed in a static way
Created attachment 4879 [details] Source code for the class that gets compiled incorrectly I will also attach the class file created from this source
Created attachment 4880 [details] The "inconsistent" class file This is the class file that gets the VerifyError at runtime
Which build are you using ?
This is occuring with driver wswb-M20030507-200305071654
I was hoping it to be a dup of bug 37040, but the timestamp looks that cannot be true. Will investigate.
Reproduced.
Working on a fix for it for 2.1.1 (not ready yet). Problem is due to statements {if (true) throw new ParserException(...)}, which are fooling us into thinking we can optimize out the trailing #return bytecode, which is a branch target (for the break inside the switch statement). Simpler test case: public class X { public static void main(String[] args) { if (args != null) { if (true) throw new NullPointerException(); } else { switch (args.length) { case 1: if (true) throw new NullPointerException (); break; case 0: break; default: throw new NullPointerException(); } } } }
Bug isolated. The flow analysis got fooled by a fake reachable 'break' statement which tricked it into ignoring subsequent valid break statements which can reach the end of the switch. Thus it thought that all subsequent statements behind the switch could be optimized out (in particular the implicit return bytecode could be thrown away). In RuleParser, you may workaround it by changing the following lines 183-184 {if (true) throw new ParseException("Interface declarations not supported in rule!");} break; into the one line below: {throw new ParseException("Interface declarations not supported in rule!");}
Fixed and released in both 2.1 maintenance and 3.0 streams.
Verified.
*** Bug 38345 has been marked as a duplicate of this bug. ***
*** Bug 38702 has been marked as a duplicate of this bug. ***
Verified for 3.0M1.
*** Bug 39020 has been marked as a duplicate of this bug. ***
