Community
Participate
Working Groups
In Eclipse 4.4, a possible compiler bug affects our codebase. The trigger conditions seems to be (every class is declared in an exported packaged named the same as the bundle): 1. In bundle org.example.a: a. Declare an interface A b. Declare a nested interface A.Inner 2. In bundle org.example.b: a. Import package org.example.a b. Declare a class B c. Use the type A.Inner as a type parameter in a private method return type or argument, e.g. Iterable<A.Inner> 3. In bundle org.example.c: a. Import package org.example.b b. Call a function in class B Expected behavior: Since the type A.Inner is not exposed in the public interface of the class B, it should not be necessary to import org.example.a to use B. Actual behavior: Compiler error: The type org.example.a.A$Inner cannot be resolved. It is indirectly referenced from required .class files I have created a small project that illustrates this problem: https://github.com/glerup/eclipse-pde-indirectly-referenced-bug
This applies also for "normal" Java-Projects. Following "setup" works fine in Eclipse 4.3.2: Project 1: package p1; public interface P1I0 { interface II {/*empty*/} } Project 2 - has Project 1 on classpath: package p2; import p1.P1I0; public class P2C0 { public void z(final P1I0.II... ii) {/*empty*/} } Project 3 - has Project 2 on classpath: package p3; import p2.P2C0; public class P3C0 extends P2C0 {/*empty*/} My findings: Visibility of method z does not matter. When changing z's parameter to a simple paramater, no compile errors. So it looks like the Type-Parameter "resolution" is the problematic peace of code in the Eclipse-Compiler. As we have a lot of projects, which would have to change classpath-settings, I would like to see the "Importance" of that bug to be at a higher level.
I haven't gone through the example in detail, but this sounds like another duplicate of bug 73957.
(In reply to Curtis Windatt from comment #2) > I haven't gone through the example in detail, but this sounds like another > duplicate of bug 73957. While the error message is the same, this particular problem is new in Eclipse 4.4. The reproduction scenario compiles in Eclipse 4.3, but yields a compilation error in Eclipse 4.4. The "indirectly referenced" compilation error usually appears when a type from a bundle dependency in its interface references a type from a transitive dependency. In these cases it is necessary to also import/require the transitive dependency. But in this case, the compilation error occurs even when the type is only used in a private method and is not exposed in the interface in any way, which I think is very problematic. Triggering this does require some rather specific conditions (which happened to be fulfilled in 9 places in our codebase): 1. The transitive dependency needs to be a nested type 2. The nested type must be used as a type argument (e.g. Iterable<I.Nested>) or in a varargs position (e.g. I.Nested...) Try playing around with the very simple reproduction scenario on GitHub and let me know what you think. Based on Kurt's comment #1 this may be a JDT problem since it also seem to affect non-OSGi Java projects.
I will mark for investigation in 4.5, but I don't have time to look at this in detail currently. I'm also moving it to PDE UI (where we handle the project dependencies) as well as marking it as a greatbug with clear steps to reproduce and an example project.
(In reply to Rune Glerup from comment #3) > Based on Kurt's comment #1 this may be a JDT problem since it also seem to > affect non-OSGi Java projects. I'll move to JDT for comment. PDE adds the dependencies to the JDT classpath, so this bug may originate there.
This sounds familiar, but I can't dig out the relevant bug. Srikanth, any idea?
Hello Rune, are you able to attach an example project to bugzilla here that I can simply import to observe the problem. I appreciate that you have taken the effort to stage the test case in github, but a simple importable project attached to bugzilla would work best for me. Thanks.
Sorry for the noise, my team mate showed me how to get what I wanted right from github. Thanks.
Looks like a regression brought about by the fix for bug 423849
Fix and test released here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c00079358eb2e0feded1f86b5088b09215957a9d The fix for was calling for overeager resolution of nested types. We now have built in some tolerance for missing types when evaluated eagerly.
Verified for Mars 4.5M2 using I20140915-2000 build.
I am seeing a problem that looks like this bug. The difference is, in 2.c., A.Inner is used as a parameter in a public method. Also for step 3, all I need to do is import the type (not the whole package) org.example.b.B. The error appears without using B anywhere in C. I have several projects with compile errors in 4.4 due to this bug. Can this be back ported?
I agree this looks severe enough for backporting to 4.4.2, and the fix doesn't look too complicated. Rune / Kurt, did you have a chance to test the fix in 4.5 M2 to verify that it fixes all your real-life cases?
Since we had to change to 4.4 we fixed the classpaths for the projects. The only fast check I could do, would be the testcase I provided.
Could check with Version: Mars (4.5) Build id: I20140918-0330 . Luckily I had a "backup" of the workspace, so I could check real-life-case also. Both compile without errors again (compiler-compliance level 1.6, after clean-build). Would be nice to see that backported to 4.4. Thanks Kurt
Reopening for back port.
(In reply to Markus Keller from comment #13) > Rune / Kurt, did you have a chance to test the fix in 4.5 M2 to verify that > it fixes all your real-life cases? Our real-life cases compile without errors in the 4.5 M2 build.
Shankha, can you please backport this ? TIA.
Created attachment 247701 [details] Patch: 4.4.2
(In reply to shankha banerjee from comment #19) > Created attachment 247701 [details] > Patch: 4.4.2 Hi Srikanth, Can you please review. Thanks
Backported on R4_4_maintenance Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=b1ad3a9c0fed9f836b3039d8ebc5cb946105230a. Thanks
Patch Ported to R4_4_maintenance.
Patch ported to R4_4_maintenance.
*** Bug 448922 has been marked as a duplicate of this bug. ***
Verified for 4.4.2 RC1 using build M20150114-1500.
