Bug 37747 - Invalid output for "thisJointPoint.getSignature().toLongString()"
Summary: Invalid output for "thisJointPoint.getSignature().toLongString()"
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Jim Hugunin CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-16 05:50 EDT by Matthew Webster CLA
Modified: 2003-05-23 12:48 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 Matthew Webster CLA 2003-05-16 05:50:59 EDT
Eclipse: 2.1.0, 200302211557
AspectJ: 1.1.1

When "thisJoinPoint" is used for an execution joinpoint where at least one 
argument is an array e.g. "main" method of HelloWorld you get the following:

    public static void HelloWorld.main(java.lang.ClassNotFoundException)
    Hello World!

I would have expected something like:

    public static void HelloWorld.main(java.lang.String[])
    Hello World!

Source:

public class HelloWorld {

	public static void main(String[] args) {
		System.out.println("Hello World!");
	}
}

public aspect TestTJP {

	pointcut mainMethods () :
		execution(public void HelloWorld.main(..));
		
	before () : mainMethods () {
		System.out.println(thisJoinPoint.getSignature().toLongString
());
	}
}
Comment 1 Jim Hugunin CLA 2003-05-16 12:18:11 EDT
This bug should be fixed in the 1.1rc2 release of AspectJ.  Please confirm 
that it is in fact fixed if you use the latest version.

This was caused by a difference in behavior on the IBM JDK and the Sun JDK for 
handling Class.forName of an array class.  I bet you're running on an IBM JDK.
Comment 2 Matthew Webster CLA 2003-05-19 09:42:41 EDT
I am using the IBM 1.3.1 JVM. When using Sun 1.4.0 I do not see the problem. I 
will try AspectJ 1.1.2 when I get the chance; I am doing Eclipse demos at a 
conference right now and don't want to destabilize my system.
Comment 3 Matthew Webster CLA 2003-05-22 12:12:28 EDT
I would also expect the output to match Java reflection for inner classes. For 
instance the attached program running under Sun 1.4.0 gives:

public static void InnerClasses.main(java.lang.String[])
private InnerClasses.PrivateInner InnerClasses.getPrivate()
? InnerClasses.main() class=class InnerClasses$PrivateInner
private InnerClasses.PublicInner InnerClasses.getPublic()
? InnerClasses.main() class=class InnerClasses$PublicInner
private InnerClasses.StaticInner InnerClasses.getStatic()
? InnerClasses.main() class=class InnerClasses$StaticInner

In each case the class name given by thisJoinPoint has a "." instead of a "$".

Source:

public class InnerClasses {

	public static void main(String[] args) {
		InnerClasses ic = new InnerClasses();
		Object obj = ic.getPrivate();
		System.out.println("? InnerClasses.main() class=" + 
obj.getClass());
		obj = ic.getPublic();
		System.out.println("? InnerClasses.main() class=" + 
obj.getClass());
		obj = ic.getStatic();
		System.out.println("? InnerClasses.main() class=" + 
obj.getClass());
	}
	
	private PrivateInner getPrivate () {
		return new PrivateInner();
	}
	
	private PublicInner getPublic () {
		return new PublicInner();
	}
	
	private StaticInner getStatic () {
		return new InnerClasses.StaticInner();
	}
	
	private class PrivateInner {
	}
	
	public class PublicInner {
	}
	
	public static class StaticInner {
	}

}

Comment 4 Jim Hugunin CLA 2003-05-23 12:48:24 EDT
This was a deliberate design decision to match the syntax of the Java language 
rather than the reflection API -- I believe it was a poor choice on someone's 
part to let these be two different things.  The actual Class objects are 
easily available if you would like to produce different string representations.