Community
Participate
Working Groups
Here's another fun case of indirect references. Consider the following classes: class Foo { int x = 5; } class Bar { Foo myFoo = new Foo(); } class Baz { int fooX = Bar.myFoo.x; } If these three classes are put in three separate plugins, the Bar plugin must depend on the Foo one, and the Baz plugin must depend on both Bar and Foo. Baz uses a field of Foo, so the definition of Foo is needed both to compile Baz and for the field access to be carried out at run time. However, since Baz does not mention the type name Foo explicitly, "Find unused dependencies" incorrectly announces that Foo is an unused dependency of Baz. This bug is reminiscent of bug 73957, in which certain indirectly referenced classes are needed at compile time but not at run time and are missed by "Find unused dependencies", but the classes referenced by the field and method uses in this bug /are/ needed at run time. These references used to evade access rule checking (see bug 76266), but now, the compiler checks access rules whenever a field or method is used, even if the type is not named. The necessary fix to PDE "Find unused dependencies" is analogous. Have "Find unused dependencies" search for references to the fields and methods of the types defined by a dependency in addition to the types themselves. However, this may slow down the search considerably. For the long term, I'm thinking it might make more sense if Eclipse's Java compiler, when compiling a class X, made a list of classes upon which X depends, grouped by build path entry. Then, to determine whether plugin A depends on plugin B, the PDE could check the class dependency lists for all the classes in A for mentions of the "Plug-in Dependency" build path entry for B. This way, a single scan through dependencies noted at build time would replace a large number of individual searches for references. More importantly, the JDT and PDE ideas of what constitutes a use of a dependency could no longer get out of sync. (Note bug 78829.)
We need Frederic's input on this one...
I'm not sure it would be feasible. Your request sounds like an additional storage in search indexes, but to be able to do it, these kind of references need resolution. In your example, compiler needs to resolve the expression Bar.myFoo.x (I guess myFoo field is static otherwise the code is not correct...) to know that myFoo is a field of Foo class. Without resolving, myFoo is just a name reference nothing else and currently indexer does not store anything for this. The problem is that resolution during indexing is forbidden as it would take too much time. So, I'm afraid we can't apply your suggestion and if PDE absolutely needs to find this kind of dependencies, it has to perform real search requests as searchDeclarationsOfAccessedFields and searchDeclarationsOfSentMessages...
thanks Frederic. resolving to later as I don't see us doing anything of the sort in the near future.
(In reply to comment #2) > I'm not sure it would be feasible. Your request sounds like an additional > storage in search indexes, but to be able to do it, these kind of references > need resolution. True, a new index would be needed to make the search for field and method references efficient. I was proposing a simpler technique: the PDE could do an individual search for references on each field and method defined by each type in each dependency. However, since there are so many fields and methods, I'm guessing the fix would make "Find unused dependencies" take 10 times as long or even longer. What do you think about having the Java builder note dependencies as it encounters them? Is this too much work to consider for 3.3?
This isn't a search issue I think. The Java builder already deals with such dependencies. Either we'd expose the build state internals, or we would take over the problem of finding unused entries on the build path. I would rather envisage the latter at this point. Then PDE would need to leverage this in term of plugin dependencies. We already have a request for this in JDT/Core. Frederic - can you pls add a pointer to it ?
The JDT/Core pointer is bug 24471
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
