Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: 20090920-1017 Stack trace: java.lang.IllegalStateException at org.aspectj.apache.bcel.generic.InstructionBranch.updatePosition(InstructionBranch.java:176) at org.aspectj.apache.bcel.generic.BranchHandle.updatePosition(BranchHandle.java:92) at org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:934) at org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:858) at org.aspectj.apache.bcel.generic.InstructionL ... ternal.jobs.Worker.run(Worker.java:55) Error message: Compile error: IllegalStateException thrown: Unable to pack method, jump (with opcode=153) is too far: 41164 Reproducible: Always Steps to Reproduce: 1. Start Eclipse with: eclipse.exe -Xmx1024M Without -Xmx1024M the compiler constantly runs out of heap memory. 2. Re-build project
I'm afraid this is a known limitation of AspectJ. If you weave a big method and that causes it to become *too big* then we cannot cope. Are you able to refactor the large method prior to weaving it?
Is there a way to tell which method is it? Actually this is a project that I am porting from AspectJ 1.5.2 so it used to work. Is this a new limitation? (In reply to comment #1) > I'm afraid this is a known limitation of AspectJ. If you weave a big method > and that causes it to become *too big* then we cannot cope. Are you able to > refactor the large method prior to weaving it?
It is not a new limitation, it is a JVM spec thing - but it is possible that for 1.5.2 it either: - wasn't policed (so produced broken bytecode that may never have actually been executed - or executed and worked by accident) - is affected by some fixes to weaving that are now doing something more correctly but is taking up a little more space. I suspect the former... I'll look to improve diagnostics to include the method name. unfortunately at the moment the problem is discovered at a very low level where the method is not known. if you use -debug when building you may get an indication of the class name in which the problem method exists.
which is the big problematic method? the advice or the advised method described in the point cut? This is not production code so I can't really verify it worked perfectly in version 1.5.2, but it did compile and some examples worked.
the problematic method will be the advised one - the addition of code to call the advise is making it too large (or rather making some of the jumps within it too far)
