Summary: | AspectJ1.5 makes JVM crashed | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | zhengyunchen <czy07> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | major | ||
Priority: | P3 | ||
Version: | 1.5.0M4 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: |
Description
zhengyunchen
2005-12-02 01:51:53 EST
It *looks* like a VM problem. There shouldn't be anything a compiler can do to break a VM in such a way. Perhaps the unusual thing about AspectJ is that we create bytecode that differs from what javac produces - the bytecode we create still meets the JVM specification (or you would get verify errors) - but we have had situations in the past where certain VMs or JITs would assume patterns in the bytecode based on javac output which were simply not reliable. I see you raised it against 1.5.0M4 - and you mentioned you have tried other versions - have you tried the latest dev build of AspectJ5 (or at least a recent one) since 100s of things have been fixed since M4. To build your application without 'weaving' you simply use ajc as normal but don't include the aspects in the build (e.g your AutoTrace aspect). Have you tried this? Basically at its heart the ajc compiler is the eclipse JDT compiler - so if you don't pass any aspects to ajc then it will simply act the same as the eclipse compiler. You could also try binary weaving - so build your application with standard javac and then apply your aspects to that code through something like: ajc -inpath myJavacBuiltJar.jar AutoTrace.aj -outjar myWovenBuiltJar.jar that will allow us to do discover if it is a feature of the JDT compiler that is causing you problems. Hello Andy, Thank your kind and immediate reply. As you mentioned we can remove aspect feature from our bytecode by ajc without passing aspects to it. It's a simple method but I had not got any idea about it. I only tried to write a new aspect which won't point cut any java code of our application. I tried 1.5.0M5 but I didn't get any development builds such as 1.5.1 because I can't find them. I can't understand why aspectj produce bytecode which meets JVM specification but differs from ones produced by javac. We use the stantdard Sun java VM. And I can be sure that classes run well after the first time compiled by ajc. They were woven in binary. You can see I use the command below: ajc -inpath ../applications/insurance/web/WEB-INF/classes/(.class file) -aspectpath autoTrace.jar -outjar insuranceTrace.jar Jvm crashed only after I re-ajc those class files with the aspect I modified regular expression in point cut publicMethods(). Perhaps I went a wrong way. Should not I ajc classes which had been weaven? Anyway, I will try to do more tests on our server. After all I'm in the first step to learn AOP and more time is needed. The crash perhaps won't occur again if I weave java source files directly, I think. AOP is a graceful thinking way and you are doing a great job. Thanks again! > I tried 1.5.0M5 but I didn't get any development builds such as 1.5.1 because I can't find them. The 1.5.0 development builds available from the top of the download page are more recent than M5. > I can't understand why aspectj produce bytecode which meets JVM > specification but differs from ones produced by javac. Any compiler is free to implement any java language construct however it likes in bytecode - as long as the bytecode meets the JVM spec, then the JVM should run it. Javac chooses to implement some language features in a particular way in bytecode, the JDT compiler (which we are based on) chooses a different (possibly better performing) bytecode implementation. The problem is too many tools obey the javac output because its more common - and then fail when they hit something that is completely correct but not that common. > We use the stantdard Sun java VM. Thats fine, the SUN VM must support the full JVM spec. > And I can be sure that classes run well after the first time compiled by ajc. They were woven in binary. You can see I use the command below: ajc -inpath ../applications/insurance/web/WEB-INF/classes/(.class file) -aspectpath autoTrace.jar -outjar insuranceTrace.jar > Jvm crashed only after I re-ajc those class files with the aspect I > modified regular expression in point cut publicMethods(). Perhaps I went a > wrong way. Should not I ajc classes which had been weaven? Hmmm, that shouldn't be a problem - but I'd be interested to know if you reapplied the aspect to the original classes (rather to the previously woven classes) - does it still fail? Thanks for your patient complain which teaches me a lot. I have not done test again to reapply aspect to original class yet. Because it will make our UAT server raise errors(it is not ready for AOP). So I need one indepent server to do that. And it need time. You can get the result as soon as I did such a test. :) > To build your application without 'weaving' you simply use ajc as normal but
> don't include the aspects in the build (e.g your AutoTrace aspect). Have you
> tried this? Basically at its heart the ajc compiler is the eclipse JDT
> compiler - so if you don't pass any aspects to ajc then it will simply act the same as the eclipse compiler.
I want to remove aspect features from my classes by trying:
ajc -inpath MyClassPath -d MyClassDir
MyClassPath is my .class's directory, eg '../applications/insurance/web/WEB-INF/classes/'.
And it reports:
bad WeaverState.Kind: -115
java.lang.RuntimeException: bad WeaverState.Kind: -115
at org.aspectj.weaver.WeaverStateInfo.read(WeaverStateInfo.java:142)
at org.aspectj.weaver.AjAttribute.read(AjAttribute.java:97)
at org.aspectj.weaver.bcel.BcelAttributes.readAjAttributes(BcelAttributes.java:59)
at org.aspectj.weaver.bcel.BcelObjectType.unpackAspectAttributes(BcelObjectType.java:273)
at org.aspectj.weaver.bcel.BcelObjectType.<init>(BcelObjectType.java:134)
at org.aspectj.weaver.bcel.BcelWorld.makeBcelObjectType(BcelWorld.java:257)
at org.aspectj.weaver.bcel.BcelWorld.addSourceObjectType(BcelWorld.java:314)
at org.aspectj.weaver.bcel.BcelWeaver.addClassFile(BcelWeaver.java:378)
at org.aspectj.weaver.bcel.BcelWeaver.addClassFile(BcelWeaver.java:393)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.initBcelWorld(AjBuildManager.java:658)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:209)
at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:156)
at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:112)
at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
at org.aspectj.tools.ajc.Main.run(Main.java:326)
at org.aspectj.tools.ajc.Main.runMain(Main.java:240)
at org.aspectj.tools.ajc.Main.main(Main.java:83)
And after I remove my aspect class (AutoTrace.class) from MyClassPath and run the command again, it reports:
com/ebao/gs/query/quotation/web/OtherAction.java [error] type log.AutoTrace is needed by reweavable type com.ebao.gs.query.quotation.web.OtherAction
(no source information available)
see also: /usr/local/bea_takaful_dev/user_projects/domains/mydomain/applications/insurance/web/WEB-INF/classes/com/ebao/gs/query/quotation/web/OtherAction.class::0
How can I make my classes turn to normal classes by binary bytecode weaving?
I believe this bug pertains to development versions of ajc or the binary format of aspects, since the results are similar to other such bugs now resolved. Please reopen if reproduced. stalebug |