Community
Participate
Working Groups
Here is the testcase scenario. package test; public class TestInnerClass { public static void setReferenceClass(Class c) { System.out.println(c.getName()); } public static void main(String s[]) { TestInnerClass.setReferenceClass(com.gresham.rtn.businessif.AccountBalanceIF$Acc ountBalanceCID.class); } } //////////AccountBalanceIF.java ////////// package com.gresham.rtn.businessif; public interface AccountBalanceIF { public class AccountBalanceCID { } } On the base workbench, this code can not complile and we receive the error: "The type com.gresham.rtn.businessif.AccountBalanceIF$AccountBalanceCID is an incorrectly specified nested type; replace the '$' with '.'" Notice that the same problem does not occur with VAJ 4.0, and JDK 1.3. The problem can be get around by replacing "$" with ".". But the user would like the problem to be fixed. Is this a valid error or is it working as designed?
If compiling against sources for AccountBalanceIF, then all compilers (at least since 1.2.2 and above would complain), where VAJ never got the check right I think. When compiling against binaries, then JDK 1.2.2 did complain, and not since 1.3.0 (likely because they switched their compiler implementation to new javac). Eclipse is complaining, i.e. your source should compile in the same way against other code, no matter if it is in source or binary form. The innerclass spec used to forbide bytecode-level name for innerclasses to be specified in source. No change is planned. User code should be converted.
I think you might be incorrect regarding what javac complains about: C:\tmp\com\gresham\rtn\businessif>d:\jdk131\bin\javac AccountBalanceIF.java C:\tmp\com\gresham\rtn\businessif>cd \tmp\test C:\tmp\test>d:\jdk131\bin\javac -classpath .. TestInnerClass.java C:\tmp\test>c:\jdk122\bin\javac -classpath .. TestInnerClass.java No warnings or errors are generated using either javac compiler.
Please re-read my previous comments, there is a difference when compiling against sources or against binaries. Try to compile both classes at the same time and you'll see a difference.
C:\tmp\test>del *.class C:\tmp\com\gresham\rtn\businessif>del *.class C:\tmp>c:\jdk122\bin\javac C:\tmp\com\gresham\rtn\businessif\AccountBalanceIF.java c:\tmp\test\Test InnerClass.java C:\tmp\test>del *.class C:\tmp\com\gresham\rtn\businessif>del *.class C:\tmp>d:\jdk131\bin\javac C:\tmp\com\gresham\rtn\businessif\AccountBalanceIF.java c:\tmp\test\Test InnerClass.java Again, there don't seem to be any errors or warnings from javac.
This is a bug in javac. I see why we didn't see the same thing. Try with non qualified references, and it will start complaining. package p1; class T { class Member {} } public class X { p1.T$Member field1; // no complaint T$Member field2; // complains T.Member field3; // no complaint } We will not follow them. Ok to close ?
I think this can be closed as long as you can point us at somewhere in the Java spec where it shows that the bug is in javac. Unfortunately, unless there's documentation somewhere, people tend to treat javac as the reference implementation.
http://java.sun.com/products//jdk/1.1/docs/guide/innerclasses/spec/innerclasses. doc2.html "Likewise, bytecode-level class names like MyOuterClass$19 cannot be used by source code (except under pre-1.1 compilers, which know nothing of inner classes). "
Closing, this is a Javac bug
