Bug 277508 - Unstable Method Names When Recompiling
Summary: Unstable Method Names When Recompiling
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.6.4   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal with 1 vote (vote)
Target Milestone: 1.6.5   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-22 13:20 EDT by Ron Bodkin CLA
Modified: 2009-06-11 20:13 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ron Bodkin CLA 2009-05-22 13:20:05 EDT
When I recompile an aspect library, making without any changes to the code, it results in incompatible binary output. This is a significant problem because it means that if you make a tiny bug fix (e.g., changing implementation logic that isn't affected by advice), all downstream clients must be recompiled and then all resulting binaries must be deployed simultaneously, making managing changes to aspect libraries far more complex.

Sample error in a downstream client that was compiled against an old version of the aspect library:
 
java.lang.NoSuchMethodError: glassbox.monitor.resource.JdbcMonitor.ajc$if_7(Ljava/sql/ResultSet;)Z
   at
Comment 1 Andrew Clement CLA 2009-05-22 15:34:42 EDT
hmmm, yes - many names are stable (like advice), but the ones generated for if clauses may not be...

looking in the code I see it is just a:

	//XXX static state bad
	private static int counter = 0;

that is used as the number suffix.

So I've reworked it.

Similar to the pointcut declaration it is now based on the source offset.  Now this isn't brilliant as anything that disturbs the position will then cause a larger incremental build than necessary, but it will at least be stable across repeated compiles.

Ideally the if name should be based on the text of the expression within the if(...) (hashcode of it) plus the advice number (or pointcut number) but then we still need a counter for the silly case of 

before(): execution(* *(..)) && if(check()) && if(check()) {

where two if clauses are identical.  Putting this counter in is more than I want to tackle right now and I worry that due to pointcut rewriting it may still lead to instability in naming.  So I'm just doing the minimum now to address this situation.  (I know the code could really share the same if_() method in that case above, but the if pointcut and its related method declaration are surprisingly tightly coupled, so attempting to share the method declaration causes other issues).

tests and fixes in


Are other names causing you a problem Ron, or just if_?
Comment 2 Andrew Clement CLA 2009-06-04 14:12:36 EDT
bug raised about if names, they are now fixed. closing.
Comment 3 Ron Bodkin CLA 2009-06-11 20:13:25 EDT
Let me try this version of the change out, and if there are other cases of instability causing a problem I'll raise another bug. Thanks for the quick fix and sorry for the delay in commenting.