Community
Participate
Working Groups
Build Identifier: I20100608-0911 I am having "The package COM.KKAZMIERCZYK.test.Broken collides with a type". The problem is caused I am having also my com.kkazmierczyk.test.Broken class in my project. Although there is convention to name packages with lower case, it is a bug in Eclipse compiler. Given code compiles in Java compiler. Reproducible: Always Steps to Reproduce: 1. Create class com.kkazmierczyk.test.Broken 2. Try to create class COM.KKAZMIERCZYK.test.Broken. You will receive error
Created attachment 175395 [details] testing project.zip Attaching project with classes com.kkazmierczyk.test.Broken and COM.KKAZMIERCZYK.test.Broken
(In reply to comment #1) > Created an attachment (id=175395) [details] > testing project.zip > > Attaching project with classes com.kkazmierczyk.test.Broken and > COM.KKAZMIERCZYK.test.Broken I think the problem here is not about lowercase or uppercase. You have a TYPE com.kkazmierczyk.test.Broken already defined, and then you're trying to define a PACKAGE with the same name. This is where the conflict is and this is what Eclipse is warning you about. So I think this is a legal error. Srikanth, what do you think?
Created attachment 175400 [details] error message
> I think the problem here is not about lowercase or uppercase. You have a TYPE > com.kkazmierczyk.test.Broken already defined, and then you're trying to define > a PACKAGE with the same name. This is where the conflict is and this is what > Eclipse is warning you about. So I think this is a legal error. > Srikanth, what do you think? Ayushman is Java case insensitive on package names? I have type com.kkazmierczyk.test.Broken and want to create package COM.KKAZMIERCZYK.test.Broken which differs than type in case.
Ayushman, Srikanth: according to the comment 4 and other, is it valid bug for you?
(In reply to comment #5) > Ayushman, Srikanth: according to the comment 4 and other, is it valid bug for > you? We're still not very clear if this is a bug. Here's what I did to reproduce the case: 1) Create a package com.kkazmierczyk.test 2) In above package, create class Broken.java 3) Create another package COM.KKAZMIERCZYK.test.Broken 4) <LINUX ONLY> Create D.java in above package. In Linux, Eclipse allowed me to do the step 3, and the file D.java had no conflict errors. In Windows, I was not allowed to do step 3 at all! So this seems more like an OS-related issue to me. I want to ask you: - Which OS are you using? - Did you create the project on Linux and import it on Eclipse in windows? Please clarify the above points. Thanks
(In reply to comment #4) [...] > Ayushman is Java case insensitive on package names? I have type > com.kkazmierczyk.test.Broken and want to create package > COM.KKAZMIERCZYK.test.Broken which differs than type in case. (In reply to comment #5) > Ayushman, Srikanth: according to the comment 4 and other, is it valid bug for > you? Though the JLS3 does not spell this explicitly, from a reading of section 7.2 Host Support for Packages and 7.2.1 Storing Packages in a File System we can conclude that a host may be constrained by external limitation to make package names case insensitive. The type collides with package diagnostic is a valid one as it creates room for ambiguity: should a type reference Broken.D at some place refer to (the non existent) inner type D of Broken class or to a top level type D of the package Broken ?
See that on Windows, javac fails with the exact same message: C:\jtests>type bug\Broken.java package bug; public class Broken { } C:\jtests>type bug\Broken\D.java package bug.Broken; public class D { } C:\jtests>C:\ibm-java2-sdk-50-win-i386\bin\javac.exe -Xlint:unchecked -Xlint:dep recation -Xlint:rawtypes -classpath . -sourcepath c:\jtests;c:\jtests\bug;c:\jte sts\bug\broken bug\broken\D.java bug\broken\D.java:1: package bug.Broken clashes with class of same name package bug.Broken; ^ 1 error
See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4376513 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4037490 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4421728 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4188645 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4120355 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4041034 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4346857 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4988649 I plan to close this as NOT_ECLIPSE. I don't think there is anything that can be done here.
(In reply to comment #8) > See that on Windows, javac fails with the exact same message srikanth, please notice that my case is slightly different than yours: C:\jtests>type bug\Broken.java package bug; public class Broken { } C:\jtests>type bug\Broken\D.java package BUG.Broken; public class D { } javac.exe -Xlint:unchecked -Xlint:dep recation -Xlint:rawtypes -classpath . -sourcepath c:\jtests;c:\jtests\bug;c:\jte sts\bug\broken bug\broken\D.java Note - I am using Oracle JVM
(In reply to comment #10) > (In reply to comment #8) > > See that on Windows, javac fails with the exact same message > > srikanth, please notice that my case is slightly different than yours: > C:\jtests>type bug\Broken.java > package bug; > public class Broken { > } > > C:\jtests>type bug\Broken\D.java > package BUG.Broken; > public class D { > } Here is a sequence of things as they happen, as I import the project into eclipse (on windows) 1. Eclipse compiles Broken.java without an error. 2. When compiling D.java, eclipse first issues an error message saying: "The declared package "COM.KKAZMIERCZYK.test.Broken" does not match the expected package com.kkazmierczyk.test.Broken" - This is because the compiler treats the package names as being case sensitive as it should. (3) Then the compiler internally adjusts the package to be com.kkazmierczyk.test.Broken to reflect the class's real position in the hierarchical folder structure that models the package structure. (4) Having done that the compiler finds that the package name collides with a type and reports an error. I don't think there is a bug anywhere here. Perhaps my code example in comment#8 instead of serving the intended purpose, only added to the confusion. comment#8 was just highlighting the fact that javac is also susceptible to the package name case sensitivity issue. Given the input is ill formed, the compiler behavior need not necessarily converge. (I would actually argue that it is a bug in javac that it does not report the package collides with type message for the snippet in comment #10) Bottom line is that case sensitivity or otherwise at the file system level is outside of a compiler/class loader's purview and it is a hole in the spec that it does not spell out how an implementation should handle these issues in a comprehensive manner. Some of the defects against javac cited earlier pertain to the specification hole. Hope this helps.
I have found following issue: My code: List<String> classFiles = new ArrayList<String>(); classFiles.add("C:\\workspaces\\platform\\test\\src\\com\\kkazmierczyk\\test\\Broken.java"); classFiles.add("C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\C.java"); new org.eclipse.jdt.internal.compiler.batch.Main(new PrintWriter(System.out), new PrintWriter(System.err), false).compile((String[]) classFiles.toArray(new String[classFiles.size()])); Class Broken is in package com.kkazmierczyk.test Class C is in package COM.kkazmierczyk.test.Broken; When executing the code getting following message: ---------- 1. WARNING in C:\workspaces\platform\test\src\com\kkazmierczyk\test\Broken.java (at line 3) public class Broken { ^^^^^^ The type Broken collides with a package ---------- ---------- 2. ERROR in C:\workspaces\platform\test2\src\COM\kkazmierczyk\test\Broken\C.java (at line 1) package COM.kkazmierczyk.test.Broken; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The package COM.kkazmierczyk.test.Broken collides with a type ---------- 2 problems (1 error, 1 warning) Is this the bug for you?
(In reply to comment #12) > I have found following issue: > > My code: > List<String> classFiles = new ArrayList<String>(); > classFiles.add("C:\\workspaces\\platform\\test\\src\\com\\kkazmierczyk\\test\\Broken.java"); > classFiles.add("C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\C.java"); > new org.eclipse.jdt.internal.compiler.batch.Main(new PrintWriter(System.out), > new PrintWriter(System.err), false).compile((String[]) classFiles.toArray(new > String[classFiles.size()])); > > Class Broken is in package com.kkazmierczyk.test > Class C is in package COM.kkazmierczyk.test.Broken; Could you show the contents of the files ? If I have: C:\>type C:\\workspaces\\platform\\test\\src\\com\\kkazmierczyk\\test\\Broken.ja va package com.kkazmierczyk.test; public class Broken { // Empty } and C:\>type C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\ C.java package com.kkazmierczyk.test.Broken; public class C { // Empty. } I get: ---------- 1. ERROR in C:\workspaces\platform\test2\src\COM\kkazmierczyk\test\Broken\C.java (at line 1) package com.kkazmierczyk.test.Broken; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The package com.kkazmierczyk.test.Broken collides with a type ---------- 1 problem (1 error) While if the contents of C.java were to be C:\>type C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\ C.java package COM.kkazmierczyk.test.Broken; public class C { // Empty. } I don't get a compile error. A package can come from multiple fragments and these can be hosted in different parts of the file system. However many fragments it comes from there cannot be a collision between a top level type and a package. This explains the first (error) case. The second (no error) case shows that package names are case sensitive and the compiler is indeed treating them as such. I think in both instances the compiler behavior is correct and I don't see a bug here.
(In reply to comment #13) [..] > If I have: > > C:\>type > C:\\workspaces\\platform\\test\\src\\com\\kkazmierczyk\\test\\Broken.ja > va > package com.kkazmierczyk.test; > public class Broken { > // Empty > } > > and > > C:\>type > C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\ > C.java > package com.kkazmierczyk.test.Broken; > public class C { > // Empty. > } > > > I get: > > ---------- > 1. ERROR in > C:\workspaces\platform\test2\src\COM\kkazmierczyk\test\Broken\C.java (at line > 1) > package com.kkazmierczyk.test.Broken; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The package com.kkazmierczyk.test.Broken collides with a type > ---------- > 1 problem (1 error) > > While if the contents of C.java were to be > > C:\>type > C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\ > C.java > package COM.kkazmierczyk.test.Broken; > public class C { > // Empty. > } > > I don't get a compile error. > > A package can come from multiple fragments and these can be hosted in > different parts of the file system. However many fragments it comes > from there cannot be a collision between a top level type and a package. > This explains the first (error) case. > > The second (no error) case shows that package names are case sensitive > and the compiler is indeed treating them as such. > > I think in both instances the compiler behavior is correct and I don't > see a bug here. Even I dont see a bug here. As stated in comment 6, the Eclipse compiler correctly treats the package names in a case sensitive way. It is actually the operating system which sometimes changes the case. It will be good if you can try this on both linux and windows as per comment 6 and see the difference for yourself.
My files: My content of the files: C:\workspaces\platform\test\src\com\kkazmierczyk\test\Broken.java: package com.kkazmierczyk.test; public class Broken {} C:\workspaces\platform\test2\src\COM\kkazmierczyk\test\Broken\C.java package COM.kkazmierczyk.test.Broken; public class C {} and from another class executing: public static void main(String[] args) { List<String> classFiles = new ArrayList<String>(); classFiles.add("C:\\workspaces\\platform\\test\\src\\com\\kkazmierczyk\\test\\Broken.java"); classFiles.add("C:\\workspaces\\platform\\test2\\src\\COM\\kkazmierczyk\\test\\Broken\\C.java"); new org.eclipse.jdt.internal.compiler.batch.Main(new PrintWriter( System.out), new PrintWriter(System.err), false).compile((String[]) classFiles.toArray(new String[classFiles.size()])); } I am having following error: ---------- 1. WARNING in C:\workspaces\platform\test\src\com\kkazmierczyk\test\Broken.java (at line 2) public class Broken {} ^^^^^^ The type Broken collides with a package ---------- ---------- 2. ERROR in C:\workspaces\platform\test2\src\COM\kkazmierczyk\test\Broken\C.java (at line 1) package COM.kkazmierczyk.test.Broken; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The package COM.kkazmierczyk.test.Broken collides with a type ---------- 2 problems (1 error, 1 warning) Srikanth, can you now reproduce the issue?
(In reply to comment #15) > Srikanth, can you now reproduce the issue? No, this compiles without a problem for me on HEAD (3.7 stream).
Frederic, Perhaps another pair of eyes would help here. Are you able to see the problem mentioned in comment# 15 using the examples given there ? I am not.
(In reply to comment #17) > Frederic, > > Perhaps another pair of eyes would help here. Are you able > to see the problem mentioned in comment# 15 using the examples > given there ? I am not. I also do not see any trouble with the comment 15 sample. Which version of batch compiler do you use to run your class which compiles the two sources? Personally, I used ecj-head.jar built from the scripts/export-ecj.xml on top of org.eclipse.jdt.core project R3_6 version. As I said, with this jar, I confirm there's no error while compiling those two sources...
Created attachment 176214 [details] two projects from test (In reply to comment #18) > > Which version of batch compiler do you use to run your class which compiles the > two sources? I checked out org.eclipse.jdt.core (HEAD version) and made dependency to the project from which I am compiling. I am attaching also my two projects located in c:\workspaces\platform
(In reply to comment #19) > Created an attachment (id=176214) [details] > two projects from test > > (In reply to comment #18) > > > > Which version of batch compiler do you use to run your class which compiles the > > two sources? > > I checked out org.eclipse.jdt.core (HEAD version) and made dependency to the > project from which I am compiling. > > I am attaching also my two projects located in c:\workspaces\platform I can reproduce while running the compilation from an eclipse session. Hence, it looks like the compiler behavior is different when invoked from batch or from eclipse...
(In reply to comment #19) > Created an attachment (id=176214) [details] > two projects from test > > (In reply to comment #18) > > > > Which version of batch compiler do you use to run your class which compiles the > > two sources? > > I checked out org.eclipse.jdt.core (HEAD version) and made dependency to the > project from which I am compiling. > > I am attaching also my two projects located in c:\workspaces\platform This has quite a bit of extraneous stuff that is causing build path problems. After I get rid of the swt libraries dependencies and the associated code, I do get the messages you describe. I'll investigate and see whether there is a bug here.
(In reply to comment #21) > > This has quite a bit of extraneous stuff that is causing build path > problems. After I get rid of the swt libraries dependencies and the > associated code, I do get the messages you describe. I'll investigate > and see whether there is a bug here. The class A in test project does not have path issue as soon as you import the org.eclipse.jdt.core plugin in your wksp. It seems that the snippet is not meaningful for this bug, hence can be ignored...
Frederic, in comment 20 you mentioned you reproduced it while running the compilation from an eclipse session. Did you use jar dependency or project dependency in that case?
(In reply to comment #23) > Frederic, in comment 20 you mentioned you reproduced it while running the > compilation from an eclipse session. Did you use jar dependency or project > dependency in that case? Only the dependency to org.eclipse.jdt.core project which was already set in test project. Of course I imported this plugin in my workspace before to have this dependency honored...
(In reply to comment #24) > (In reply to comment #23) > > Frederic, in comment 20 you mentioned you reproduced it while running the > > compilation from an eclipse session. Did you use jar dependency or project > > dependency in that case? > > Only the dependency to org.eclipse.jdt.core project which was already set in > test project. Of course I imported this plugin in my workspace before to have > this dependency honored... Frederic, I am not sure you properly. What is the difference between environment from comment 20 when you reproduced the issue and comment 22?
(In reply to comment #25) > > Frederic, I am not sure you properly. > What is the difference between environment from comment 20 when you reproduced > the issue and comment 22? In fact I did exactly the same that what you did in comment 19 and so, I was able to reproduce the compiler errors while running test/src/com/kkazmierczyk/A as a Java Application inside my eclipse session. I just added comment 22 to precise that I also imported the org.eclipse.jdt.core plugin to honor the test project dependency. Of course, that was necessary to run A as a Java Application... It seems that Srikanth was puzzled (as I was initially) by the Snippet262.java class which contains many compiler errors due to unresolved dependency to org.eclipse.swt plugin. But I discovered it was not necessary to use this class to be able to reproduce the problem. That's why I advice him to ignore it. Hope this is clear now...
(In reply to comment #21) > I'll investigate and see whether there is a bug here. Krzysztof, I confirm that this is an eclipse bug. Thanks for your patience and persistence. If we had the projects zipped up initially itself, we would have discovered it sooner. With plain file system entries, this problem does not/will not show up which is what we trying to do based on the initial instructions. This needs an eclipse project with class path set up to show up. I have a tentative fix. Stay tuned.
Created attachment 176298 [details] Patch under consideration This bug does not show up inside the IDE if the IDE is used build the two projects. Nor will the problem show up if the batch compiler is invoked directly to compile the files. Only when a hybrid model is contrived by invoking the batch compiler programmatically from within a workspace project AND by passing to the invocation of the compiler files spanning multiple workspace projects can one see the problem. Ayush, please review. There is no regression test. I don't think it is worth it and the code is straight forward enough.
Comment on attachment 176298 [details] Patch under consideration This patch fails some tests, Looking into it.
Created attachment 176382 [details] Revised patch Fixes the problem with the earlier patch. All tests pass, Ayush please review. TIA.
Created attachment 176430 [details] Same patch with several regression tests Ayush, please review, TIA.
(In reply to comment #31) > Created an attachment (id=176430) [details] > Same patch with several regression tests > > Ayush, please review, TIA. The fix is fine. However, tests test0307, test0307b and test0307c dont really look like they have anything to do with the fix. They pass without the fix as well. Is this intended?
(In reply to comment #32) > The fix is fine. However, tests test0307, test0307b and test0307c dont really > look like they have anything to do with the fix. They pass without the fix as > well. Is this intended? Yes, the other tests are simply asserting that our behavior with respect to type names, nested members etc is case sensitive. Released in HEAD for 3.7 M2.
Verified for 3.7M2 using build I20100909-1700.
