Community
Participate
Working Groups
Build Identifier: 20091217-0918 Hello, If you use the JDK-Compiler The following class: -------------------- package testpackage; public class TestClass { private int Inner = 10; public class Inner { public final static int value = 10; } } -------------------- can be used by the class: -------------------- package testpackage; public class UsingClass { public static void main(String[] args) { int i = TestClass.Inner.value; } } -------------------- Error in the IDE: The field TestClass.Inner is not visible UsingClass.java /testcompiler/src/testpackage line 9 Java Problem I know it is bad style to name the Variable starting by a Capital. The code is not created by me, the others use netbeans and I am quite annoying by using eclipse. The error happens in galileo as well. Reproducible: Always Steps to Reproduce: 1.New Java Project 2. Create the two classes 3.
A slightly more convenient test case to work with: Cut & paste into package explorer: ---------------------8<-------------------------------- public class TestClass { private int Inner = 10; public class Inner { public final static int value = 20; } } class UsingClass { public static void main(String[] args) { System.out.println(TestClass.Inner.value); } } ---------------------8<-------------------------------- Compare with the behavior of javac against this test case : public class TestClass { private int Inner = 10; public class Inner { public final static int value = 20; } public static void main(String[] args) { System.out.println(TestClass.Inner.value); } } TestClass.java:7: non-static variable Inner cannot be referenced from a static c ontext System.out.println(TestClass.Inner.value); ^ TestClass.java:7: int cannot be dereferenced System.out.println(TestClass.Inner.value); ^ 2 errors -------------------------------- Eclipse behavior is consistent in both scenarios, i.e we prefer the field for TestClass.Inner in both cases, which seems to consistent with an initial read of JLS3 6.5.1 & 6.5.2
Sorry, bug in creation of the repro: change TestClass make it: package testpackage; public class TestClass { private static int Inner = 10; public class Inner { public final static int value = 10; } } now javac compiles both classes.
(In reply to comment #2) > Sorry, > bug in creation of the repro: Hello Andreas, Please try : package testpackage; public class TestClass { private static int Inner = 10; public class Inner { public final static int value = 10; } public static void main(String[] args) { System.out.println(TestClass.Inner.value); } } I get an error with javac5,6,7: testpackage\TestClass.java:11: int cannot be dereferenced System.out.println(TestClass.Inner.value); ^ 1 error I believe this is a Sun bug (Oracle bug we should start saying ?) Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6247816 Unless there is disagreement, I plan to close this as NOT_ECLIPSE. Thanks.
(In reply to comment #3) > I get an error with javac5,6,7: > > testpackage\TestClass.java:11: int cannot be dereferenced > System.out.println(TestClass.Inner.value); > ^ > 1 error > > I believe this is a Sun bug (Oracle bug we should start saying ?) > Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6247816 To clarify, that there is no error on the code fragment posted in comment#0 is a javac bug. javac behavior on the snippet posted in comment#3 is correct.
Hello, I see, i admit, I would never have found the bug in the sun database, nevertheless now I have got the problem with: Code maintained in both netbeans (majority) and eclipse (minority) IDEs will have to be changed. If your main aim is to be JLS-compliant this Bug is NOT_ECLIPSE, if your aim is to provide a development environment that compiles code also compiled by netbeans, ant, maven, ... . in my opinion it is a bug of eclipse. Greetings , Andreas
(In reply to comment #5) > Hello, > I see, i admit, I would never have found the bug in the sun database, > nevertheless now I have got the problem with: In general, our aim is not to be bug to bug compatible with javac. There have been occasions in the past when we have deliberately chosen to align with the (defective behavior) of javac rather than with JLS - but this is really a rare exception rather than the rule. Such decisions are guided by the severity and frequency of the difference being encountered by user community. In this particular case, AFAIK, this is the first time we are hearing of this difference in behavior. Olivier, what's your advice ?
(In reply to comment #5) > If your main aim is to be JLS-compliant this Bug is NOT_ECLIPSE, if your aim is > to provide a development environment that compiles code also compiled by > netbeans, ant, maven, ... . Your list means the same thing. Netbeans, ant or maven are all using javac. So this comes to the difference between javac and the Eclipse compiler on this particular issue. As Srikanth reported, the open issue in the Sun database is clearly saying this is a bug in javac that doesn't follow the JLS 3. Now the choice is to introduce a bug in the Eclipse compiler to match a bug in javac in a case the "naming conventions" are not followed. The code can clearly be rewritten using the naming conventions and then there is no more problems. Our goal is to match the JLS as closely as possible and in case of unclear specifications, we tend to match what javac is doing. We had cases in the past where the JLS were not clear enough to make a clear statement about who is right and who is wrong. Then for consistency, we prefer to match javac and wait for the JLS to clarify this area. In this case, the specification is clear and since we never heard before about such a problem, I am tempted to close as NOT_ECLIPSE. Sorry Andreas, but I am not convinced this deserves a bug to be introduced in the Eclipse compiler. I would encourage you to rewrite that code that doesn't match the naming convention anyway.
(In reply to comment #7) > Your list means the same thing. Netbeans, ant or maven are all using javac. > So this comes to the difference between javac and the Eclipse compiler on this > particular issue. Your right, I just wanted to underline the possible points where the error in the future might come up again. .. it is no bigger issue for me, the language guys might have quite good causes for this complicated rule that javac does break, for me the javac-Compilers handling is more orthogonal. I might have problems to explain the bug to my college creating the buggy code (automatically). On the other side there is a break of the java code conventions.. perhaps a good point by eclipse to show it. So in sum, no more replies from my side. Thank you for your efforts. And for this great IDE. Andreas
Resolving as NOT_ECLIPSE since this is a javac bug.
Verified for 3.6M6
Verified.
