Community
Participate
Working Groups
The following compiler dependency error exists in both Eclipse v2.1.3 and the lastest Eclipse v3.0.2 build (as of yesterday). It seems to be resolved in the Eclipse v3.1M5a build. Create the following projects & dependencies: Child.java (in project A): public class Child extends Parent implements Intf { public void foo() { System.out.println("foo in Child"); } } Parent.java (in project 1B) public class Parent { public static void main(String[] args) { } } Intf.java (in project 1C) public interface Intf { void foo(); } Test.java (in project 1D) public class Test { public static void main(String[] args) { Child child = new Child(); child.foo(); } } Project Dependencies A: 1B, 1C 1B: 1C 1D: A, 1B This set of dependency definitions (the equivalent classpath) works for javac and ant, but the Eclipse compiler gives the following error when attempting to build Project 1D. Kind Status Priority Description Resource In Folder Location Error The project was not built since its classpath is incomplete. Cannot find the class file for Intf. Fix the classpath then try rebuilding this project. 1D Error This compilation unit indirectly references the missing type Intf (typically some required class file is referencing a type outside the classpath) Test.java 1D line 0 The work-around for this problem is to export '1C' from the Java Build Path of project 'A' however I've been told that it is not an acceptable work-around. Would it be possible to fix this problem in both 2.1.3 and 3.0.2? I will attach a ZIP file containing all 4 projects so that you can import them and reproduce. Thank you
Created attachment 18902 [details] The project files necessary to reproduce this problem.
Note: You will need to remove the '1C' dependency on project '1D' to reproduce the problem if you reconstruct this scenario using the projects given in the attached projects.zip file.
This is an area which is not spec'ed in JLS; i.e. how much a compiler needs on its classpath to perform is up to its implementation. In 3.1 stream, we reduced the need for some required types, but this cannot easily be backported since it relies on quite a lot of changes in our namelookup algorithm.
To reproduce, need to remove 1C from 1D classpath.
Bug 36397 is the one we addressed in 3.1 stream, and made problem go away there. Investigating backporting it to 3.0 maintenance stream. This is a BIG change considering a maintenance stream.
At least 14 classes are touched by this change.
Kent - I released changes to branch 3.0 maintenance. Pls double check them. It passes all tests, including NegativeTest#test424-425 modified as along the lines of 3.1 stream to demonstrate increased laziness.
(In reply to comment #7) > Kent - I released changes to branch 3.0 maintenance. Pls double check them. It > passes all tests, including NegativeTest#test424-425 modified as along the lines > of 3.1 stream to demonstrate increased laziness. Can you please specify in which Eclipse 3.0 branch is the fix, because I have taken the Maintenance Build: M20050113 and there the problem still exists.
This hasn't made it publicly out yet in any integration build. You may get the fix, it is released in branch "R3_0_maintenance".
Is there a patch for this problem which can be used for Eclipse 3.0 final release. A plugin or set of plugins which can be replaced and the Compiler dependency problem to be resolved. I have Check out the R3_0_maintenance branch of the project org.eclipse.jdt.core but the project "org.eclipse.jdt.core" can't be compiled with target platform of Eclipse 3.0. Svetoslav
That should just work. Note that you may want a 3.0.2 release instead, since it has couple fixes which got issued since 3.0; but API wise there should be no difference, so you should be able to build it against either 3.0 or 3.0.2.
It does not compile neither with 3.0 nor 3.0.2. It cannot find class org.eclipse.core.runtime.PerformanceStats, org.eclipse.core.resources.ResourceAttributes and also class org.eclipse.osgi.util.NLS. that was the R3_0_maintenance branch from 21.04.2005. org.eclipse.jdt.core - the subproject "model" does not compile only.
It does compile just fine for me. Your setup must be wrong somehow. Please provide exact steps to reproduce.
I have taken the head branch instead of R3_0_maintenance, now it compiles with target Platform 3.0.2 and 3.0 and works as desired. If we replace only this plugin in the Maintance build from 13 Jan 2005 or with Eclipse 3.0 from 25 Jun 2004 will it be stable and work without any problems?
HEAD is corresponding to 3.1 development stream, and has tons of changes you do not want in a maintenance branch, since too risky. Additionnally, there is no guarantee some internal signature did change, and some downstream components would need to be recalibrated to match our 3.1 stream (i.e. you need their 3.1 counterpart). So it is far preferrable to build a true 3.0 update, rather than pluging some 3.1 pieces into 3.0 platform. I still do not get why you cannot manage to build a 3.0 update; it shouldn't be any different from building a 3.1 update. Can you describe precisely what you tried ?
Sorry, maybe in my last post I was not clear enough. When I was unable to build the plugin org.eclipse.jdt.core it was because I have taken the HEAD branch instead of R3_0_maintenance branch. Now when I took the R3_0_maintenance branch it was bild successfully with target platform 3.0 and 3.0.2. My question is can we just replace the org.eclipse.jdt.core plugin ver.3.0.0 from Eclipse 3.0 with org.eclipse.jdt.core plugin ver.3.0.2 from maintenance branch and Eclipse 3.0 to continue to be stable and work good? Is there any majour changes in ver. 3.0.2 for this plugin since 3.0?
Oh, then you should be fine. The best would be for you to patch a 3.0.2 official release with what you created; if not then I suspect there could be issues resulting from plugin version numbers, in which case you'd have to edit the plugin.xml and change version ID from 3.0.2 to 3.0.0 if you intend to patch a 3.0.0 official release. No major change occurs in maintenance deliveries, so this should just work.
Created attachment 20461 [details] The modified projects The modified projects
There is still one problem existing which doesn't appear in Eclipse 3.1 and javac compiler. The scenario is as the original one provided from the Reporter of this bug and only one change must be made to be achieved. In the class Parent.java create new method : public Object getTest(){ return null; } call this method after the calling of child.foo(); in Test.java The following error is given: The project was not built since its build path is incomplete. Cannot find the class file for Intf. Fix the build path then try building this project. The type Intf cannot be resolved. It is indirectly referenced from required .class files The problem does not appear in Eclipse 3.1. Please, fix this also, for now when you call the methods from the interface there is no problem - before the fix there was problems with it also. I'm applying the modified projects also as an attachment
Kent - can you pls look at the last issue, there seems to be steps to reproduce.
This one slipped thru the cracks. I tried the testcase from comment #18 and it works fine in 3.3M6, 3.2.2 and 3.1.2
