Community
Participate
Working Groups
This happens after a partial build. VerifyError on loading an aspect class (method: <clinit> signature: ()V) Stack size too large) when the aspect declares an implementation on an interface, a client class is declared to implement the interface, and the client class fails to compile. While it might seem strange to try running with compiler errors, the program I was running made no use of the client class, and I verified this happens even when the program is only trying to load the aspect class. (Obviously, I'm working in AJDT, so the result could be some better handling of incomplete compiles there.) Same result in incremental mode. In general it would be nice if the aspect loaded regardless of a broken client class, if the client class did not need to be loaded. I don't have time for a test case at present, but will work on one Friday if needed.
for investigation in aj5m3
Created attachment 27558 [details] Jar file containing testcase This jar file contains four files: an aspect, two classes and an interface. Together they reproduce the problem described in this bug.
Created attachment 27561 [details] testcase patch The attached patch is to be applied to the tests project and reproduces the failure with a simplified testcase. This is the same testcase as was posted in the previous comment as a jar, however, can be applied directly to the tests project and includes the required changes to the ajc150.xml and Ajc150Tests.java files.
it would be interesting to know if -proceedOnError gets around the problem of the broken class.
passing -proceedOnError causes the testcase to pass.
for 1.5.0 we will do nothing further on this :- the -proceedOnError flag can be used. For 1.5.1 we can look to try and behave in the same way as the JDT compiler where possible.
I'm ok with deferring to 1.5.1, but I'm also wondering where to document that users should be sure to do a full, non-incremental build before testing or before shipping production code. Otherwise they could end up with runtime VerifyError's without notice. (The -proceedOnError workaround doesn't help someone who doesn't know about the VerifyError (b/c their tests didn't hit it).) Getting a runtime error from a compiler failure is the kind of thing that can lead you to drop a compiler. Release notes?
didnt make the cut...
