Community
Participate
Working Groups
I have three java projects in my workspace -- A, B and C. B uses some classes from A, C uses some classes from B. This setup works fine with 3.1.2 but in 3.2 RC4 I get "The type XXX cannot be resolved. It is indirectly referenced from required .class files" compile error. Major regression from 3.1. I'll attach trivial test case to demo the problem shortly.
Created attachment 41605 [details] sample projects that demonstrate the problem
This is another case of bug 137710 where 2 methods have the same name but take unrelated parameters. The best solution is to rename one of the methods since the parameters are not related at all, unlike a normal overload case when one type is a subtype of the other. In 3.1.2, the 2 methods appear in a different order in the table than 3.2 so we end up resolving the parameters for importData(TaskDefinition data) before importData(String data). It compiles in 3.2 if you change the order of the methods, but the best solution is to rename one of the methods.
This is a borderline situation. However, in theory our sorting algorithm is stable, and should sort equivalent methods (selector, arity) in order of definition. Need to check for 3.2.1.
Igor, after discussing this issue we've decided the correct solution for this problem is to rename one of the two methods. Our method lookup algorithm is order dependant in this case so the error you're seeing can appear any time you change the order of the methods in the file. If you're switching between 3.1 and 3.2, there is no order which will compile in all cases, unless you rename one of the methods.
First, I do not understand why a tool would tell me how to name my methods, let alone require specific order in which I define methods in .java file. For the record, in this particular case the two methods implement basically the same logic with the only difference being parameter format (java object in one case and XML rendering of the object in the other), so I have all the reasons to name these methods the same. Second, JDT has enough information to resolve TaskDefinition if it really needs to. JDT chooses not to follow project dependencies for type resolution and this I believe is the root cause of this problem. Btw, there is a similar/related bug 73957 agains PDE which seems to have the same root cause and which is being ignored for more than a year. If you do not have immediate solution to the problem -- that's fine, but don't pretend there is no problem at all.
Igor, To reiterate. The classpath is incomplete, and a required type is missing from there. Since we lazy resolve pieces as we perform lookups, you are observing the consequence of an implementation detail. The Java spec doesn't tell anything, ie. it is up to each compiler vendor to be as resilient as he can. For instance, javac is always failing in this situation.
Bug 73957 belongs to PDE. Until PDE correctly provides the required binaries on the classpath, what you are seeing here is not going to change. PDE owns the definition of your classpath here. CC'ing Wassim, since this is just another symptom of bug 73957, for which the solution has to come from PDE I believe. Until now, you were lucky that JDT was resilient (again more than other compilers). I agree that reording methods or renaming them feels a bit of a hack, it is just a way to workaround the PDE current limitation. A better solution is for PDE to add the necessary pieces to your classpath.
We should find a resolution for bug 73957 one way or another in 3.3 One reason why I'm hesitant to put all the extra JARs on the classpath is that we would have to update classpaths for plugins more often than is really necessary. For example, now we only update the classpath of plugin X when one of its direct dependencies as changed. By putting all the indirectly referenced JARs directly on the classpath, classpath of plugin X would have to be updated when any one of this long list of plugins is updated. Another reason is performance/memory. If you look at the dependency graph of plugins in big products, each plugin already has a direct dependency on a lot of plugins. If we were to bring in all the "indirect dependencies" as well, this would result in a huge classpath and a very long list of JARs which JDT would have to index.
Re:indexing. If the JAR is present elsewhere anyway, we will only index it once, and thus there should not be any overhead for subsequent references to it.
