Bug 86012

Summary: aspect VerifyError when declaring implementation on uncompiled class
Product: [Tools] AspectJ Reporter: Wes Isberg <wes>
Component: CompilerAssignee: Adrian Colyer <adrian.colyer>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: aclement
Version: 1.2.1 M1   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Jar file containing testcase
none
testcase patch none

Description Wes Isberg CLA 2005-02-21 15:49:05 EST 
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.
Comment 1 Adrian Colyer CLA 2005-03-23 09:45:56 EST 
for investigation in aj5m3
Comment 2 Helen Beeken CLA 2005-09-27 09:47:41 EDT 
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.
Comment 3 Helen Beeken CLA 2005-09-27 11:05:14 EDT 
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.
Comment 4 Andrew Clement CLA 2005-10-11 07:41:23 EDT 
it would be interesting to know if -proceedOnError gets around the problem of
the broken class.
Comment 5 Helen Beeken CLA 2005-10-27 08:32:13 EDT 
passing -proceedOnError causes the testcase to pass.
Comment 6 Adrian Colyer CLA 2005-10-28 06:09:40 EDT 
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.
Comment 7 Wes Isberg CLA 2005-10-30 12:17:14 EST 
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?
Comment 8 Andrew Clement CLA 2006-04-04 14:10:47 EDT 
didnt make the cut...