Community
Participate
Working Groups
bug 1: Get warning on declare parents in a subaspect of a parameterized aspect that (erroneously?) declares same parents: "The method TaggedTexts.PC.ajc$declare_parents_1() does not override the inherited method from NodeImpl<TaggedTexts.Tag,TaggedTexts.Tag> since it is private to a different package." bug 2: The subaspect must declare parents on the concrete types. -------------------- package util; public abstract aspect NodeImpl<Parent, Child> { declare parents : Child implements INode<Parent, Child>; declare parents : Parent implements INode<Parent, Child>; ... } -------------------- // somewhere else in the far reaches of the universe... static aspect PC extends NodeImpl<Tag, Tag> { // bug 1: required, though it shouldn't be // bug 2: spurious error on this line declare parents : Tag implements INode<Tag,Tag>; ... } Let me know if you need a more complete test. I believe you're working in this area and know about it, but can't tell. AspectJ version 1.5.0.20051206103951, via AJDT
Hmmmm.... I'm having trouble with this one. I think I do need a more complete example if you have the time to create one Wes? On bug #1 it could be the bridge method code misbehaving. On bug#2 - you should not have to make that declaration in the sub-aspect - the super aspect should do it. I wrote some simple code and it was behaving as expected - but I don't deny there could be something in this area, it *is* rocket science ;) It's interesting that all 3 declare parents statements resolve to be the same thing in this case... Have you read the latest ParentChildRelationship aspect in the doc (the doc in the tree, not on the website) - that shows a fully working generic aspect.
In case it helps, here's an exception I got while trying to create a smaller test case for this bug (using batch mode in same version of AJDT/AspectJ): java.lang.UnsupportedOperationException at org.aspectj.weaver.UnresolvedType.parameterize(UnresolvedType.java:218) at org.aspectj.weaver.patterns.ExactTypePattern.parameterizeWith(ExactTypePattern.java:242) at org.aspectj.weaver.patterns.TypePatternList.parameterizeWith(TypePatternList.java:195) at org.aspectj.weaver.patterns.DeclareParents.parameterizeWith(DeclareParents.java:77) at org.aspectj.weaver.ReferenceType.getDeclares(ReferenceType.java:484) at org.aspectj.weaver.ResolvedType.collectDeclares(ResolvedType.java:523) at org.aspectj.weaver.ResolvedType.collectCrosscuttingMembers(ResolvedType.java:488) at org.aspectj.weaver.CrosscuttingMembersSet.addOrReplaceAspect(CrosscuttingMembersSet.java:60) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.addCrosscuttingStructures(AjLookupEnvironment.java:378) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.addCrosscuttingStructures(AjLookupEnvironment.java:388) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.collectAllITDsAndDeclares(AjLookupEnvironment.java:314) at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.completeTypeBindings(AjLookupEnvironment.java:168) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301) at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:811) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:230) at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:156) at org.aspectj.ajde.internal.CompilerAdapter.compile(CompilerAdapter.java:122) at org.aspectj.ajde.internal.AspectJBuildManager$CompilerThread.run(AspectJBuildManager.java:191) UnsupportedOperationException thrown: resolve this type first
code: ----------------------- package bugs; import bugsOtherPackage.INode; import bugsOtherPackage.NodeImpl; public class ParameterizedDP { public static void main(String[] args) { // 1) compile-time error here without // {unneeded} subaspect declare-parent // Tag as INode<Tag, Tag> from PC extends NodeImpl<Tag, Tag> ((TaggedTexts.Tag) null).getParent(); } } class TaggedTexts { public static class Text { } public static class Tag { } static aspect PC extends NodeImpl<Tag, Tag> { // unneeded declare-parents duplicates one in NodeImpl // when here, get spurious error message // when commented out, d-p fails and get compiler error at 1) above declare parents : Tag implements INode<Tag,Tag>; } } --------------------------- package bugsOtherPackage; import java.util.ArrayList; public abstract aspect NodeImpl<Parent, Child> { declare parents : Child implements INode<Parent, Child>; declare parents : Parent implements INode<Parent, Child>; private final ArrayList<INode> INode.fChildren = new ArrayList<INode>(); // are you not supposed to use type parameters here? private INode<Parent, Child> INode.fParent; public final INode<Parent, Child> INode.getParent() { return fParent; } public final boolean INode.setParent(INode<Parent, Child> newParent) { fParent = newParent; return true; } } --------------------------- package bugsOtherPackage; public interface INode<Parent, Child> { boolean setParent(INode<Parent, Child> p); INode<Parent, Child> getParent(); } ---------------------------
Hmmm. That program compiles perfectly for me (I'm using HEAD). I tried with and without the declare parents in the subaspect and it still worked fine. I changed the body of the main() method to read: public static void main(String[] args) { TaggedTexts.Tag tag1 = new TaggedTexts.Tag(); TaggedTexts.Tag tag2 = new TaggedTexts.Tag(); tag1.getParent(); tag1.setParent(tag2); if (!tag1.getParent().equals(tag2)) throw new RuntimeException(""); } so that I could actually run something and it worked fine. I've looked at the resultant classes on the disk, in particular 'Tag' class. The signature attribute for Tag is: Ljava/lang/Object;LbugsOtherPackage/INode<Lbugs/TaggedTexts$Tag;Lbugs/TaggedTexts$Tag;>;; which says 'Tag extends Object implements bugsOtherPackage.INode<Tag,Tag>' which is what we'd expect. there are two fields in the Tag class: ArrayList ajc$interField$bugsOtherPackage_NodeImpl$bugsOtherPackage_INode$fChildren; bugsOtherPackage.INode ajc$interField$bugsOtherPackage_NodeImpl$bugsOtherPackage_INode$fParent; the methods are as expected - mangled set/get methods for the fields and: public final bugsOtherPackage.INode getParent(); public final boolean setParent(bugsOtherPackage.INode); ---- DOH!! I should read the information Wes actually supplied. I see it was raised against M4. Recompiling with M4, I get the kind of problems reported: With or without the decp I get: C:\temp\ajcSandbox\ajcTest47383.tmp\NodeImpl.java:16 [error] The field INode<Par ent,Child>.fParent is not visible return fParent; Wes - please can you retry on a recent build?
Sorry, I was wrong to put M4. I wrote AspectJ 1.5.0.20051206103951, which is what's in the AJDT I've been using. I'll update and take another look (probably in about 12 hours - I'm not too concerned if you weren't able to reproduce it, and wouldn't hold up rc1 for this).
fyi, confirmed that I too get no error from the command line using HEAD, but still get error when using AJDT (which is still using AspectJ 1.5.0.20051206103951).
Looks like some of the options are getting through differently in the AJDT environment. I've recreated Wes' scenario and get the same warning: The method TaggedTexts.PC.ajc$declare_parents_1() does not override the inherited method from NodeImpl<TaggedTexts.Tag,TaggedTexts.Tag> since it is private to a different package. ParameterizedDP.java AP/bugs line 25 12 December 2005 11:23:13 8155 when the decp is in place. Very peculiar. I've fixed the appearance of this warning. However, when I remove the declare parents, everything just works - whether I am in AJDT (20051208103628) or on the command line. Wes - when you said 'still get the error' in your last comment, did you mean the silly warning about ajc$declare_parents_1() or another error? If its another error, what is the text for it? I find the only way to see errors on this line: ((TaggedTexts.Tag) null).getParent(); is if I have ParameterizedDP open in the java editor rather than the aspectj editor - when the eager parser chokes on it (the code on disk that is built is fine). this is a known 'feature' of AJDT :)
I've gone back in time and recreated this :) At 1.3.0.20051202173447 - I can recreate it easily, so I'll now alter this eclipse I'm using to use the latest AJDT and see if it vanishes.
bingo! recreated on latest after a lot of fiddling - lucky I have the MultiProjectIncremental test mechanism in AJ. I find I have to do a full build with the decp in, then an incremental build with it commented out, then a full build - in order to see the error.
Ok, sounds resolved - except that I was getting the error without incremental and after cleaning. hmm. As you suggested, the second error is/was in the Java editor on "((TaggedTexts.Tag) null).getParent();" I'm glad you found the difference in AJDT settings - I'm curious what they were. I couldn't find them. I did a some scripting to jam the latest AspectJ classes into AJDT and was surprised to find the problem recurring (in AJDT but not from the command line), seemingly no matter what I did via the GUI settings (noinline, etc.) I figured my script wasn't right. Perhaps AJDT 1.3.0.20051202173447 will be pushed to the web?
The bingo was referring to me recreating your problem with getParent() - its not just a java/aj editor problem. I've recreated with HEAD on the command line like this: >ajc -1.5 bugs\ParameterizedDP.java bugsOtherPackage\INode.java bugsOtherPackage\NodeImpl.java K:\ws\aspectj_ws2\tests\multiIncremental\PR119570\base\bugs\ParameterizedDP.java :12 [error] The method getParent() is undefined for the type TaggedTexts.Tag ((TaggedTexts.Tag) null).getParent(); 1 error This variant compiles with no errors: >ajc -1.5 bugsOtherPackage\INode.java bugsOtherPackage\NodeImpl.java bugs\ParameterizedDP.java The bug appears to be the order processing not coping with you putting the sub-aspect as a membertype of another type - so if I compile them in one order it works, if I compile in another where ajc doesn't see the super-aspect first, then it fails.
i've fixed this other problem too now. It was (as I expected) a problem with the sub-aspect being an inner type.
fix available.
