Comment 1 Jerome Lanneluc 2006-01-31 12:43:51 EST

We assume all over the place that $ in a .class file name is the separator for inner type. This is a design tradoff so that we don't have to open all class files when looking up type names, i.e. we know that A$B.class represents member type B of type A.

However, we should not make this assumption for .java files since A$B.java can only be the top level type A$B. I'm not sure of the extent of this wrong assumption for .java file.

Is your A$B class in a .java file, or in a .class file ? If it is in a .java file, I can look at specific problems. I.e. you would have to describe the code completion scenario where it doesn't work.

Comment 2 Eckart Langhuth 2006-02-01 05:07:22 EST

Created attachment 33928 [details]
3.2 -3.01 comarison screenshot

Comment 3 Eckart Langhuth 2006-02-01 05:08:13 EST

I’ll paste short code example below and attach a screenshot showing the different behaviour between 3.2M4 and 3.0.1(Build id: 200409161125)
This should demonstrate the main differences.
In 3.2M4
1.	T Editor marks usages of A$B as an Error. (“A$B cannot be resolved”)
2.	Code completion in T.main(…) on abInstance. -> “no default proposal”
3.	Code completion in T.main(…) on A$ -> “C t.A, B t.A” (choosing one of them does nothing)
None of these problem appear in 3.0.1

---
A$B.java:
package t;
public class A$B {
	public static void sm() {
	}
	public void m() {
	}
}
class A$C {
	public static void sm() {
	}
	public void m() {
	}
}
---
T.java:
package t;
public class T {
	public static void main(String[] args) {
		A$B.sm();
		A$B abInstance = new A$B();
		abInstance.m();
		
		A$C.sm();
		A$C acInstance = new A$C();
		acInstance.m();
	}
}

Comment 4 Jerome Lanneluc 2006-02-01 09:25:05 EST

Thanks for the test case.

Changed NameLookup#seekTypes(...) to not replace '$' with '.'.
Updated IndexBasedHierarchyBuilder#buildForProject(...) to use findType(char[], char[][]).

Added regression test ReconcilerTests#testTypeWithDollarName2()

Comment 5 Eckart Langhuth 2006-02-06 12:59:29 EST

Thanks for immediate fix. 
I was busy with some other issues, but now I introduced the described changes into the mentioned 3.2M4 and 3.1.1 versions and the described problems are fixed. (Except code completion on A$ showing t.A.B which is only a minor problem)

Introducing the changes I observed some side effects for main types with $ in their name.
(After taking a short look into the code I’m quite aware of the problems in handling such $ names. So see the mentioned issues as information. You probably have a feeling of possible problems besides the following)

1. Hovering the cursor in the provided Example between abInstance.m and () leads to 
Exception in thread "Text Viewer Hover Presenter" (See attached text file for full stack)
The Exception is caused by problems in generation of signatures from Binding keys.
(class KeyBindingParser, KeyBindingParser.Scanner)
I tried and found a similar Exception when using $ in method names. 
SourceTypeBinding computes key for a main type A$B to “Lt/A$B~A$B;”. Depending on usages of such key this might cause problems since a using implementation won’t expect such key.

2. Packing the example classes into a jar and using this jar as an external library reference in another java project.
- The main types with $ in their name are not shown in the Package Explorer inside the jar. (Default name filter *$*.class)
- creating a class using A$B works, but F3 navigation from this class fails with status line message “Current selection does not resolve to a Java element”.

(unfortunately I do not have the possibility to use Eclipse CVS connection, so I did not check with current sources)

Comment 6 Eckart Langhuth 2006-02-06 13:01:06 EST

Created attachment 34207 [details]
HoverExceptionStack

Comment 7 Frederic Fusier 2006-02-14 11:11:36 EST

Verified for 3.2 M5 using build I20060214-0010.

I confirm that there are several remaining problems:
  - comment 0:  bug 127749 for code assist issue 
  - comment 5: bug 127739 and bug 127742