Community
Participate
Working Groups
Using ajdt dev build 20050211182246 with associated aj build: File > New > Other > AspectJ > AspectJ Examples > Bean Example Open Demo.java and make a comment change and save. An incremental compile will occur, but it gives an error at line 42, saying the method is not applicable for the arguments. It is the declare parents statement in BuildPoint.aj that should make it applicable. The class files on disk are correct.
The problem here is that the unwovenclassfile produced for the Point class is not marked serializable (the weaver later applies serializable again). This is deliberate so that the weaver is responsible for all weaving. However, it creates the problem here that on a subsequent incremental compilation, because the input class for Point (the unwovenclassfile) isn't marked Serializable, the error comes out. There are two potential fixes: 1. Switch to how we had it previously where decp could be done either at compile time or weave time (then the unwovenclassfile produced would be marked serializable) 2. Enable the code that is going to put out the error to determine that in fact the type is marked serializable - it would have to go looking for declare parents that target Point. I think (2) is probably the right solution if it can be done.
i'm marking a whole bunch of related incremental things for aj5m4...
testcase added, see MultiProjectIncrementalTests where it is currently commented out.
We can't just avoid putting out the error by detecting there is a decp about - by the time the error is put out things have already gone too badly wrong. What we need to do is intercept resolution of the messagesend so that it realises Point implements (or will implement) Serializable. I think we can do this by using the intertypememberfinder - this finder is currently just used to augment the eclipse bindings type information (it knows about more fields, it knows about more methods) - I think we can extend it to know about more parents (interfaces and superclasses). However, this isn't a minor change... The method that eventually say *NO* to Point being serializable is ReferenceBinding.implementsInterface() - it calls currentType.superInterfaces() and doesn't get anything back - when what we'd like to get back is Serializable. There is a closely related problem with superclass and the method involved there is ReferenceBinding.isSuperclassOf(). We should probably change superInterfaces() and superClass() to go to a registered inter-type member finder to discover additional supertypes. The tricky thing will be ensuring the memberfinder is correctly set onto the binarytypebinding so that it can answer the questions. A crazy thought has just occurred to me that the reason ITD incremental doesnt work is that the memberfinders aren't correctly reregistered for types coming from unwovenclassfiles - let me check that right now...
nope, thats not a problem. So all we need to fix here is improving the memberfinder and modifying the compiler to ask the memberfinder for supertypes.
Woohoo!!!!!!!!!!! fixed. The problem is muting my immutables: The AspectJ typeMap within the world object holds a map from signatures to resolvedtypes. Any resolvedtypes representing 'objects' (i.e. not primitive types) have a 'delegate' and the delegate is either an EclipseSourceType or a BcelObjectType. The delegates *are supposed to be immutable* - but due to some funnies with ITD matching the parents (superclass/superinterfaces) for a bcelobjecttype can be modified (the long term fix is to address this problem, but I haven't in todays fix). During the first compile, Point is represented by an EclipseSourceType. All type checking works ok - Point gets marked serializable but when the EclipseSourceType is written to bytecode the interface is removed since after compilation we are supposed to end up with 'pure' unwoven code ready for the weeaver. The weaver processes the Point class and adds the Serializable interface again - however it does this to the BcelObjectType and this is never undone! So, on the second compile of the modified type, we pull in 'Point' and want to treat it as a binary type - unfortunately the bcelobjecttype for Point is still tagged as serializable, so the declare parents: Point implements Serializable isn't applied (its all very confusing because we have an eclipse form of the type to ask questions of and a bcel form of the type to ask questions of - basically we don't apply Serializable because the bcel form says it already has it, and later on we walk the hierarchy for the eclipse form and don't find it, hence the compile error) The right fix is (as mentioned) make BcelObjectType properly immutable. The quick fix (which is still quite robust) is that when retrieving a type and reusing it on a second compile, make sure the BcelObjectType is 'reset' (it already knows how to be reset) so that its parents are correct. I built an AJ testcase out of the bean example and that runs OK, I'll wait until AJDT confirms the fix before closing.
I can't reproduce the original problem in AJDT with AspectJ 1.5.0 M4
Hurrah!
