Bug 95344 - own type of an aspect unit cannot be resolved
Summary: own type of an aspect unit cannot be resolved
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.5.0M3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-16 07:33 EDT by Eric Bodden CLA
Modified: 2007-02-14 06:00 EST (History)
0 users

See Also:


Attachments
The test case (6.74 KB, text/plain)
2005-05-16 07:34 EDT, Eric Bodden CLA
no flags Details
error detecting patch (1.75 KB, patch)
2005-06-06 05:45 EDT, Andrew J Huff CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Bodden CLA 2005-05-16 07:33:30 EDT
In the attached aspect (don't worry, it's generated code, I did not write it 
myself :-)), I get the warning, that the Type "Formula$1" cannot be found on any 
within-pointcut.

However, "Formula$1" is the aspect type itself, thus IMO it should be found. 
When I fully qualify the type with a package name, it works.
Comment 1 Eric Bodden CLA 2005-05-16 07:34:00 EDT
Created attachment 21199 [details]
The test case
Comment 2 Andrew J Huff CLA 2005-05-31 09:08:25 EDT
I had a look at this... but as I can't get the test case to compile due to
dependencies, and it has some huge lines of code it's rather tricky to work out
what's going on..

could you attatch the dependencies (or attatch a version without the
dependencies but where the bug still occurs) and also say what exactly the
warning message was?
Comment 3 Eric Bodden CLA 2005-05-31 09:26:07 EDT
Hi. I think there is no need for this. I had a further look and I saw that the 
'$' character in the class name is the problem. I think, AspectJ misinteprets 
this as separator for an inner class or something like this. Usage of '$' is 
indeed discouraged in class IDs, however it *is* legal in Java so AspectJ 
should obey this IMHO. 
 
Hope that helps. 
Comment 4 Andrew J Huff CLA 2005-06-02 09:01:10 EDT
Interesting..
Inner classes in java get put in classfiles called className$1.class,
className$2.class, etc.

After screwing around a bit with dollar signs I discovered this...

/////////////////// In the following code:
interface A$1 {}
class A{
  public A$1 a(){
    return new A$1() {};
  }
}
//////////////////////////////////////////

javac produces:
A$1.class
A$2.class
A.class

ajc produces this:
java.lang.StackOverflowError
        at java.util.HashMap.hash(HashMap.java:264)
        at java.util.HashMap.get(HashMap.java:320)
        at org.aspectj.weaver.World$TypeMap.get(World.java:518)
        at org.aspectj.weaver.World.resolve(World.java:123)
        at org.aspectj.weaver.World.resolve(World.java:108)
        at org.aspectj.weaver.World.resolve(World.java:146)
        at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:963)
        at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:974)
        at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:974)
        at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:974)
        at org.aspectj.weaver.bcel.BcelWeaver.weaveParentsFor(BcelWeaver.java:974)
... etc

Lovely!
I think the problem I've found is to do with ajc trying to call both the
anonymous inner class and the interface "A$1" (javac calls the anon. inner class
"A$2")
Comment 5 Andrew J Huff CLA 2005-06-02 10:05:23 EDT
On further investigation my above problem isn't a bug in ajc as such...
it's a bug in jdt...

//////////////////////// in the following code
interface B {void hello();}

class Main$1 {}

public class Main{
  public static B a(){
    return new B() {public void hello(){System.out.println("hello");}};
  }
  
  public static void main(String [] args){
	  a().hello();
  }
}
//////////////////////////////////////////////

javac produces the files: 
B.class
Main$1.class
Main$2.class
Main.class
and when ran says "hello"

jdt in Eclipse 3.1M6 produces the files:
B.class
Main$1.class
Main.class
and when ran says:

Exception in thread "main" java.lang.IncompatibleClassChangeError
        at Main.main(Main.java:11)

I'm going to check if this still happens in the latest version of Eclipse, and
if it does raise it as a bug on jdt. Perhaps if this bug gets fixed the original
one (Formula$1) will go away too when ajc uses the latest jdt.
Comment 6 Andrew J Huff CLA 2005-06-02 11:10:55 EDT
It is still there in Eclipse 3.1RC1, so I've reported that as jdt bug 98120
Comment 7 Andrew J Huff CLA 2005-06-06 05:45:53 EDT
Created attachment 22410 [details]
error detecting patch

This patch makes AspectJ print an error and state what happened (and the
workaround) when jdt passes the messed up data to AspectJ.
Comment 8 Adrian Colyer CLA 2005-06-09 09:28:24 EDT
Andy, please can you apply patch...
Thks :)
Comment 9 Andrew Clement CLA 2005-08-24 10:05:49 EDT
I'm worried about the performance of the algorithm in the patch - and
unfortunately the JDT guys haven't fixed the bug in 3.1 final compiler.  I'm
going to delay this to M4 to give us a chance to prod them on the compiler bug,
maybe for them to fix it in 3.1.1 - and to rework the algorithm if that doesnt work.
Comment 10 Adrian Colyer CLA 2005-10-28 08:06:07 EDT
moved to 1.5.1 since we're not fully happy with the patch, and really want to pick up the JDT fix... but JDT 
haven't fixed it in their 3.1.1 final compiler on which AJ 5 is based, and we're not going to move to a pre-
release JDT compiler for AJ 5 even if they do fix it now. Hopefully they will have something we can pick up 
for 1.5.1
Comment 11 Andrew Clement CLA 2006-06-27 10:32:57 EDT
nothing happening with the eclipse bug for this...