Community
Participate
Working Groups
Situation ======== Given three plugins A, B and C with C depending on B and B depending on A: A <= B <= C. B defines an interface I whose methods contain a type from A as argument or return type. package B; interface I { public TypeFromA method(); } If now C wants to implement I it has to add A to its dependancies. If that is not done, we cannon import the necessary types from A. Problem =========== When A is not in C's dependancies and we have the implementation skeleton of I which we want to complete with the quickfix "Add unimplemented methods", then the quickfix only adds those methods that contain types of dependant plugins and silently omits others leaving our implementation uncomplete: package C; public class AnImpl implements I { // we get an error marker here } The quickfix does not do anything here. In my case, I needed too long to get the point because I thought it was a bug. I tried 3.2.1 instead of 3.3M3, jdk5 instead of jdk6rc1, cleaned all projects and wrote some demo interfaces to isolate the problem. A simple message for the missing dependancy to A would be nice and time saving. Even better would be an automatic completion of the dependancy to A. A more general question: Why is C not automatically depending an A when B is depending on A?
In your scenario, the problem would have been avoided if B re-exported its dependency on A. This should be done whenever a plug-in (ie. B) exposes API from another plug-in (ie. A) to a client (ie. C). This way C would have gotten all of A's types on its classpath for free without an explicitly dependency on A. It's B's responsibility to make sure its clients (ie. C) don't have to go through the production you went through. I am not sure what quickfix you are referring, but I assume it's coming from JDT/UI. Moving there to comment on whether there is a problem in that area or not. This is not a quickfix issue however, this is a design issue that people exposing APIs (ie. B) should be aware of.
You're not the first one with this problem, it's really tricky to find out that your classpath misses some classes used in a classfile you use. This is the scenario: - project A, requires project B public class A extends B { // error on A: 'A' must implement inherited method 'bar' // no error on B } - project B, requires C public abstract class B { public abstract I bar(); } - project C: public interface I { } The quick fix can't find method 'bar' in the AST and can't do anything. Question to jdt.core. Shouldn't there be an warning on the reference to B saying that B requires I? I think that would be most helpful to the user. It would be better to not show the quick fix here, but for this we would need such a warning. Or we fix the fact that 'bar is not in the AST... But I think for the suer it would be better to learn about the classpath problem as early as possible.
From Kent (in bug 176118): Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find binary types instead of source types in cases like this one ?
(In reply to comment #3) > Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find > binary types instead of source types in cases like this one ? Unfortunatley we cannot find binary types because: - the Java model is source based - the workspace might not be built I agree that if autobuild is on, we could use the output of other projects, but this is a complete change in direction. Wassim, why don't you add project A on the buildpath of C with a **/* forbidden access rule ? This would prevent code in C to use types in A but this would make types in A available to our search environment and this solves this particular issue.
several reasons: 1. forbidden severity is customizable, which is not good. Classes from A should not be directly accessible from C under any circumstance. 2. Project A appears on the classpath of C in the UI, implying that it is there at runtime, which is not true. So while stuffing the classpath to keep the type hierarchy/search for jdt/core intact is something to consider wrt this problem, I don't want to open a whole can of worms with people seeing/using stuff that won't be there at runtime.
Sounds like the same problem as bug 73957 and bug 148844.
*** This bug has been marked as a duplicate of bug 148844 ***
