Community
Participate
Working Groups
Build Identifier: 3.6.0.I20100608-0911 This problem was observed with ecj standalone, outside the IDE. The Build ID I provided is the Bundle-Version in the ecj jar's MANIFEST.MF file. I was attempting to build version 2.6.1 of the open-source Janino project (http://docs.codehaus.org/display/JANINO/Home) on Fedora 7 using the 3.6 ecj compiler and ant. The author includes a package-info.java in one of the packages. When I attempt the build I get: [javac] Compiling 97 source files to /usr/local/ZedaSoft/rhatcher/BuildOutput-main/ZedaSoft/Java/ ThirdParty/Janino/1.0/classes [javac] ---------- [javac] 1. ERROR in /disk2/usr/local/ZedaSoft/rhatcher/prj-main/ZedaSoft/Java/ThirdParty/Janino/main/src/org/codehaus/commons/compiler/package-info.java (at line 1) [javac] [javac] ^ [javac] The type package-info is already defined [javac] ---------- [javac] 1 problem (1 error) However, if I touch the package-info.java file, then re-run ant, it compiles the file ok. I thought this might be related to compiling multiple files at once, but after the build has failed the first time I can touch package-info.java plus any additional combination of files inside that package and it still builds ok. If I ant clean, then ant again, the problem comes back, but again only for the first build attempt. All subsequent build attempts succeed. FWIW javac did not have a problem with it. I posted to the forum and got a lot of views, but no responses. Apologies if this is not a legit problem. This could be related to something in our build environment here, and I'm continuing to investigate when time permits. I'll post a follow-up if I learn more. Reproducible: Always Steps to Reproduce: See Details section. If I can come up with a more concise test case I'll post a follow-up.
Jay, please investigate. Thanks!
I think I saw the error once. But when I did 'ant clean' and 'ant' again, I am not seeing the error anymore. I used the ant script from V_2_6_1\janino-dist\build.xml. Could you confirm if I am doing the right thing and also what I need to do see the error again?
I am also seeing lot of other errors and warnings. So, I am not really sure if I am using the right ant script and ant task.
Created attachment 176791 [details] build.xml to reproduce the package-info compile error.
I attached a custom build.xml that mimics the build setup we use at our site, but has been simplified to focus on this issue. It's possible that some of the options we use are contributing to the problem. Here's what I did to reproduce the error: Downloaded the Janino 2.6.1 distribution. I made a directory structure like this: /tmp janino/ build.xml <-- attachment I added to this bug src/ I unzipped the commons-compiler-src.zip and janino-src.zip files into "src" in the dir structure above. I did NOT unzip the commons-compiler-jdk-src.zip file. As noted above, the build.xml is not janino's but the one I added to this bug as an attachment. You probably will need to tweek my build.xml to fix the location of the ecj jar, but the rest ought to work. To use javac instead you should only need to comment out the eclipse.ecj.jar property. The default target is "compile", and there is a "clean" target too. If I run the "compile" target after a clean I always see the noted error on the first build attempt. If I then touch the package-info.java file (there is only one of them in this code base), and recompile, and it will build ok. If you run ant -v you can verify that it's picking up package-info.java for compilation.
This is what is causing the problem: The compiler gets all the compilation units in a certain order, which includes the package-info.java. Under certain scenarios, (such as checking whether the package is deprecated or not) we have to resolve package-info type ahead of it's turn while trying to resolve some other compilation unit. Then later when the compiler tries to resolve the package-info, it sees it as an existing type and throws an error. Working on a patch.
This could be a Ant/classpath configuration issue after all. Both the following folders are being passed as classpath: <janino_home>\ <janino_home>\src This results in classes not being recognized properly.
In my environment, I had an entry "." in the CLASSPATH environment variable, which resulted in both /janino and janino/src being added to the classpath. And this was causing this behavior. Phew! Rob, I think this could be the problem at your end too. Could you please confirm?
Sure enough, I have a default CLASSPATH value of ".", and if I unsetenv CLASSPATH this problem goes away. Does that make this a "bug" or a "feature"?
(In reply to comment #9) > Sure enough, I have a default CLASSPATH value of ".", and if I unsetenv > CLASSPATH this problem goes away. > > Does that make this a "bug" or a "feature"? Nested source folders are always going to be a problem. Even in the IDE, we do not allow nested folders as two different source path entries unless the inner folder is excluded from the outer one's entry. Perhaps what is missing here is a warning message, I guess.
Dani, I would like to know what you think about this. Thanks in advance.
Agree that this is not a bug. Since we issue an error in the IDE we might also do the same for ECJ.
Before saying anything else I want to mention that none of my comments below should be interpreted as complaining. We consider ecj a large step up from javac - thanks for the great work. I am not a compiler expert so my opinion doesn't deserve much consideration, but I'd like to at least chime in with a user's perspective: At our site we have (currently) 148 Java projects, most of which are substantial. The nested CLASSPATH entry issue has existed for years, and never caused a problem until I bumped into this package-info oddity. As it happens we don't use the package-info facility in our own software, and apparently a lot of the third-party stuff we use doesn't use it either. A few years ago we started using Eclipse, so we switched from javac to ecj for our batch command line builds. Because our projects share a large set of common ant configuration I was able to get the dev group switched over simply by making adjustments to the common configuration and dropping the ecj jar in an appropriate spot on their machines - no environment adjustments required. So... I guess the fact that the other complicated things the compiler does were all working with CLASSPATH the way it was made it seem like the ostensibly simple package-info facility ought to work also, though apparently under the covers the situation is complex. Not sure there's an option to get ant to ignore the user's environment classpath, but that's what I'll hunt for next since we otherwise fabricate the required build classpath on the fly. Or... I'll see if I can add something to the common configuration to remove "." from the classpath.
Jay, in the IDE I can choose to continue compilation even if we have build path errors and then it seems to work just fine. Also, from reading the previous comment it looks like javac has no issue with this setup and only the package-info.java is causing the trouble. Please investigate whether we can make ECJ more resilient.
Created attachment 177741 [details] Proposed patch Here is a draft patch. This patch takes care of two things: 1) Fixes this bug 2) Reports a WARNING that nested folders have been added as part of classpath. Olivier, I would like you to review this patch. There might even be a better approach that you can think of. TIA.
Before releasing that patch (which looks good), I'd like to understand why only package-info is concerned with duplication.
(In reply to comment #16) > Before releasing that patch (which looks good), I'd like to understand why only > package-info is concerned with duplication. At the following method invocation, we are trying to resolve the type for package-info ahead of it's turn. Normally, since package-info is already in the list of compilation units to be compiled, the getType call here should return null. However, this doesn't happen because FileSystem.knownFileNames doesn't contain the correct path and hence FileSystem.findClass() returns a non-null NameEnvironmentAnswer. Ideally, we should fix the root cause, which lies in FileSystem.initializeKnownFileNames, where we end up choosing the wrong path when nested folders are present in classpath. But I am afraid we don't have enough details at that point be able to extract the correct path. One of my concerns with the current patch is that we might end up putting a lot of entries in the knownFileNames map. But I can't think of a better way. ---------------- at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.isViewedAsDeprecated(PackageBinding.java:213) at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.isViewedAsDeprecated(ReferenceBinding.java:1217) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.checkAndSetModifiers(ClassScope.java:421) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.buildType(ClassScope.java:377) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.buildMemberTypes(ClassScope.java:265) at org.eclipse.jdt.internal.compiler.lookup.ClassScope.buildType(ClassScope.java:379) at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:144) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:157) at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:717) at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:377) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:422) at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3716) at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1666) at org.eclipse.jdt.internal.compiler.batch.Main.main(Main.java:1379) at p.BatchCompilerTest.main(BatchCompilerTest.java:29)
(In reply to comment #9) > Sure enough, I have a default CLASSPATH value of ".", and if I unsetenv > CLASSPATH this problem goes away. > > Does that make this a "bug" or a "feature"? Should not we add the source folders first on the resulting classpath? This would solve the issue without explicitly handling it inside the compiler. Jay, could you please see if the source folders should always preceed the current classpath? If this is not explicitly specified, then we might need to go with your fix.
>Should not we add the source folders first on the resulting classpath? I don't think we should tweak the build path behind the scenes.
(In reply to comment #19) > I don't think we should tweak the build path behind the scenes. We need however to insert elements in the right order. If we don't use the right order, this would be something to fix.
This is what I was looking for: http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#searching It states that source paths must be searched before the user classpath. I'll check in what order we insert elements on the classpath.
(In reply to comment #21) > This is what I was looking for: > http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#searching > > It states that source paths must be searched before the user classpath. Where exactly? My previous comment was mainly targeted to the compiler in the IDE where the user specifies the order and where he can choose to have binary stuff before the source folders. That should stay as is.
(In reply to comment #22) > Where exactly? "If you set the -sourcepath option, the compiler searches the indicated path for source files; otherwise the compiler searches the user class path for both class files and source files." > My previous comment was mainly targeted to the compiler in the IDE where the > user specifies the order and where he can choose to have binary stuff before > the source folders. That should stay as is. This whole thread is about the batch compiler integrated with ant. Changing this won't have any effect on the compiler inside the IDE.
One thing that I find quite weird is that if the user specifies a source path (/src in this example), I don't think that the current user dir ('.') should also be added to the classpath for a source lookup. If there is a sourcepath specified on the command line, the current user dir should only be used for binary lookup. If none are specified, then the user dir should be used for binary and source lookup. I'll try to see what kind of lookup javac is doing by default with and without a source folder being specified.
Created attachment 179773 [details] Proposed fix Jay, let me know what you think. I think the problem comes from the way we "prune" the initial source file path according to the source path entries on the classpath. I tried this patch on the initial problem and it seems to work fine.
(In reply to comment #25) > Created an attachment (id=179773) [details] > Proposed fix > > Jay, let me know what you think. I think the problem comes from the way we > "prune" the initial source file path according to the source path entries on > the classpath. > I tried this patch on the initial problem and it seems to work fine. Patch looks good, Olivier. I just wanted to confirm this: apart from the user directory scenario, if the user somehow ends up with nested folders, should we really handle it? Between, this patch doesn't address that kind of scenarios.
(In reply to comment #26) > Patch looks good, Olivier. I just wanted to confirm this: apart from the user > directory scenario, if the user somehow ends up with nested folders, should we > really handle it? Between, this patch doesn't address that kind of scenarios. I think this is handled by the patch as I select the inner most source folders. This is what the user wants implicitly. If you have source folders like: /src | +-- org/eclipse/Test.java /src/src1 +-- org/eclipse/Foo.java If you have the two files listed as source files, then the first source folder will match the first file and we should record org/eclipse/Test as the known file name and the second source folder will match the second file and we should record: org/eclipse/Foo for the known file name. So I believe this works fine. Do you have an example in mind that would not compile properly ?
(In reply to comment #26) > Patch looks good, Olivier. I just wanted to confirm this: apart from the user > directory scenario, if the user somehow ends up with nested folders, should we > really handle it? Between, this patch doesn't address that kind of scenarios. Following is one of the tests cases I used. Note that I used -classpath only and no -sourcepath in this case. Perhaps a wrong test case? String[] argv = new String[] { "-noExit", "-classpath", "C:\\JDT\\workspace_HEAD\\V_2_6_1\\janino\\src;C:\\JDT\\workspace_HEAD\\V_2_6_1\\janino", "-d", "C:\\JDT\\workspace_HEAD\\V_2_6_1\\janino\\classes", "-g", "-warn:+allDeprecation", "-warn:+assertIdentifier", "-warn:+charConcat", "-warn:+conditionAssign", "-warn:+constructorName", "-warn:-dep-ann", "-warn:+deprecation", "-warn:+discouraged", "-warn:+enumSwitch", "-warn:+finally", "-warn:+forbidden", "-warn:+intfAnnotation", "-warn:+intfNonInherited", "-warn:+maskedCatchBlock", "-warn:+noEffectAssign", "-warn:+pkgDefaultMethod", "-warn:-semicolon", "-warn:+specialParamHiding", "-warn:+staticReceiver", "-warn:+typeHiding", "-warn:+unusedImport", "-warn:+unusedLabel", "-warn:+unusedLocal", "-warn:+unusedPrivate", "-warn:+varargsCast", "-warn:+warningToken", "-warn:-raw", "-warn:-serial", "-warn:-unchecked", "-Xmx256M", "C:\\JDT\\workspace_HEAD\\V_2_6_1\\janino\\src\\jp\\AbstractJavaSourceClassLoader.java", "C:\\JDT\\workspace_HEAD\\V_2_6_1\\janino\\src\\jp\\package-info.java", }; org.eclipse.jdt.internal.compiler.batch.Main.main(argv);
Created attachment 180237 [details] Proposed fix New patch that treat classpath entries the same as source path entries. The given test case works fine now with sourcepath/classpath or simply with classpath. Jay, let me know what you think.
Created attachment 180240 [details] Proposed fix Same patch as before with some cleanup. The change in ClasspathDirectory was no longer needed.
(In reply to comment #30) > Created an attachment (id=180240) [details] > Proposed fix > > Same patch as before with some cleanup. The change in ClasspathDirectory was no > longer needed. The patch looks good. All my test cases pass.
Released for 3.7M3.
Verified for 3.7M3 using build ecj-I20101025-0901.
this actually still happens reliably for me as described below: after a "clean" the package-info.java fails to compile inside the IDE. "touch" the file (insert space, remove space, save) and it's fine. running eclipse juno 20120614-1622
(In reply to comment #34) > this actually still happens reliably for me as described below: after a > "clean" the package-info.java fails to compile inside the IDE. "touch" the > file (insert space, remove space, save) and it's fine. This sounds a lot like https://bugs.eclipse.org/bugs/show_bug.cgi?id=386356#c8. Could you follow the instructions from https://bugs.eclipse.org/bugs/show_bug.cgi?id=388948#c2 and report back if the problem persists ? TIA.
it does look like that bug, but unfortunately, my eclipse set up is working the way I want ;-) and I don't want to risk trying a random beta version. If I can remember on 9/28 after the release I'll let you know.
(In reply to comment #36) > it does look like that bug, but unfortunately, my eclipse set up is working > the way I want ;-) and I don't want to risk trying a random beta version. > If I can remember on 9/28 after the release I'll let you know. Here are the release candidate builds: http://download.eclipse.org/eclipse/downloads/drops4/M20120905-1640/ http://download.eclipse.org/eclipse/downloads/drops/M20120905-1000/ One options is to test and confirm now and upgrade after 9/28.
Ok. I downloaded the M build you linked to and it does indeed fix the problem. Thanks for following up.
FYI, after going back to the stable eclipse my workspace is all messed up...
(In reply to comment #39) > FYI, after going back to the stable eclipse my workspace is all messed up... Stephan, any ideas here ?
(In reply to comment #40) > (In reply to comment #39) > > FYI, after going back to the stable eclipse my workspace is all messed up... > > Stephan, any ideas here ? Not really. We'd probably need some information on what "all messed up" stands for in this instance. @David, if you happen to run Ubuntu and possibly upgraded some packages during these days, please check this Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/1050404 (the workaround is in the 9th comment.). If that's not the cause, please describe the mess you experienced.
(In reply to comment #40) > (In reply to comment #39) > > FYI, after going back to the stable eclipse my workspace is all messed up... > > Stephan, any ideas here ? A workspaces is forward compatible but if you start a workspace with 4.x and then 3.x you are expected to get into trouble.
