| Summary: | Invisible "indirectly referenced" compilation error causes runtime problems | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ville Oikarinen <ville> | ||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | amj87.iitr, satyam.kandula, srikanth_sankaran, stephan.herrmann, ville | ||||
| Version: | 3.8 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Ville Oikarinen
Created attachment 209369 [details]
Set of projects to reproduce
Here is the set of projects to reproduce the bugs.
Then some more detailed analysis: I'm not sure if all aspects are absolutely needed, but the compilation problems are caused when we have: - code generation (ant builder) - exporting generated classes that are outside the project that does the exporting (inside a project dedicated to building) - inner classes and interfaces - referring to outside inner interface from generated code - overloaded method using generated interfaces For example, applying "Move Type to New File" refactoring to Library.LibraryInterface solves all problems (our current workaround). On the other hand, inner interfaces are not a problem in other contexts that miss some other aspects of this scenario. Another interesting fact is that the compilation actually seems to succeed under hood! Open HandWrittenImplForInnerInterfaceTwo.java. Again, the editor complains about not finding an indirectly referenced class. But the class works when running GenProviderMain.java as an application! The compiler reports two missing types: eclipsebug.generated.Generated.InnerClass.InnerInterfaceOne; eclipsebug.generated.Generated.InnerClass.InnerInterfaceTwo; And indeed these types are missing in the set of projects. So, I don't see the problem here In both HandWrittenImplForInnerInterfaceTwo.java and BrokenTest.java the error is about the missing interfaces. But it looks like what you see is different from what I see. Can you tell me the exact steps to follow after importing all these projects into Eclipse? Thanks! (In reply to comment #4) > In both HandWrittenImplForInnerInterfaceTwo.java and BrokenTest.java the error > is about the missing interfaces. > But it looks like what you see is different from what I see. Can you tell me > the exact steps to follow after importing all these projects into Eclipse? > Thanks! Yes, like I described in the steps, _initially_ eclipse complains. Those interfaces are code-generated, and it takes some cleaning and source-touching to make eclipse find those classes. Oh, and refreshing is needed, too. But once you get the files generated and their location properly refreshed for all needers, then you'll see what I see. (In reply to comment #4) > But it looks like what you see is different from what I see. Can you tell me > the exact steps to follow after importing all these projects into Eclipse? And I'd very much like to give you the _exact_ steps, but I don't have them. Maybe I'll file that as another bug some day :) Anyway, I'm sure you can clear the problems tab by hitting clean, refresh and touching files, eventually. (In reply to comment #5) > Yes, like I described in the steps, _initially_ eclipse complains. Those > interfaces are code-generated, and it takes some cleaning and source-touching > to make eclipse find those classes. Oh, and refreshing is needed, too. > > But once you get the files generated and their location properly refreshed for > all needers, then you'll see what I see. That's the problem in my workspace. I am unable to generate these classes. The build itself fails with the message "build.xml:22: Unable to find a javac compiler". Do I need to have javac in some specified directory? I'll take a look at this for M6 along with a couple of other indirect reference issues already in my plate. (bug 328057, bug 320965) Don't expect to get to this in M6. I think this got fixed through bug 372418. Can you please verify with 3.8M6? (In reply to comment #10) > I think this got fixed through bug 372418. Can you please verify with 3.8M6? I am mistaken. This shouldn't be to do with 372418. I am able to reproduce this issue partially:). Before I explain the problems, the solution for your problem is to change the following preference. Under Preferences->Java->Compiler->Building->Build Path Problems, deselect 'Abort build when build path errors occur'. After doing this refresh the project 'build'. I see that you are refreshing the folders through the builder. I will investigate that issue. >So, the first serious bug in the chain of problems is this compilation error. >There is nothing wrong in the code or in the classpaths. As you would seen from my solution, we have a preference to stop building if they are build errors causing this issue. >The second serious bug is that this compilation error can only be seen in the >editor. Not in the problems tab nor in the Package explorer. I am not able to see this problem. I do see 'build path errors' on the package explorer and problems tab. > The third serious bug is that the junit test finder silently fails when it >stumbles upon this problem file. Either it tells there are no tests (which was >how I found this bug) or, which is worse, pretends all is well and just runs >some of the tests. The test finder should clearly report the compilation error >instead. This is just like the second serious bug you have mentioned. I am seeing the 'build path' errors in the package explorer. (In reply to comment #7) > (In reply to comment #5) > > Yes, like I described in the steps, _initially_ eclipse complains. Those > > interfaces are code-generated, and it takes some cleaning and source-touching > > to make eclipse find those classes. Oh, and refreshing is needed, too. > > > > But once you get the files generated and their location properly refreshed for > > all needers, then you'll see what I see. > > That's the problem in my workspace. I am unable to generate these classes. The > build itself fails with the message "build.xml:22: Unable to find a javac > compiler". Do I need to have javac in some specified directory? Ayush, you need to use the jdk to launch Eclipse as the build.xml uses javac. We will not be able to do anything for M7. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |