Community
Participate
Working Groups
While the existing References search feature is without question very handy, at times it would be excellent to have an overview of all classes, interfaces, methods and fields not used, or more commonly no longer in use, within a package or entire project thus helping identifying obsolete code. While there exists an expensive commercial solution for, amongst others, this request called RefactorIT, with features such as besaid FindReferencesInProjectAction currently implemented, I thought it might not be an overly far step to running a search on all classes, methods etc. in a package or project and, as opposed to the References Search, list those that have no references. RefactorIt further supports a series of helpful search criteria, such as the exclusion of getter and setter accessor methods, overriding methods or JUnit test cases. Naturally this exclusion option could make the search both faster and give better results as to the goal of cleaning up the code.
No plans to add this to JDT. This would be a nice idea for an external plugin.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 480620 has been marked as a duplicate of this bug. ***
(In reply to Denis Roy from comment #2) > As of now 'LATER' and 'REMIND' resolutions are no longer supported. > Please reopen this bug if it is still valid for you. We have such an action in platform.runtime and could contribute it. Having the option to search for unused methods in the current workspace would be valuable to several customers I know of. (Also this bug is marked as helpwanted).
(In reply to Lars Vogel from comment #4) > (In reply to Denis Roy from comment #2) > > As of now 'LATER' and 'REMIND' resolutions are no longer supported. > > Please reopen this bug if it is still valid for you. > > We have such an action in platform.runtime and could contribute it. If we add such a feature, it has to be done like all other Java element searches in JDT: implemented in JDT Core, exposed as API, and offered in the UI - as Search > Unreferenced > [Workspace|Project|Package|Hierarchy|Working Set...] - on the Java Search page Is that what you are willing to contribute? If not, the better place is in an external tools plug-in as outlined in comment 1.
(In reply to Dani Megert from comment #5) > If we add such a feature, it has to be done like all other Java element > searches in JDT: implemented in JDT Core, exposed as API, and offered in the > UI > - as Search > Unreferenced > [Workspace|Project|Package|Hierarchy|Working > Set...] > - on the Java Search page I don't think new API in JDT core is need, the existing one can be used. As for the integration into the search page, I think that makes sense. Do you also want to have it in the context menu? > Is that what you are willing to contribute? Sounds good to me, except that I do not think that new core API is needed.
(In reply to Lars Vogel from comment #6) > (In reply to Dani Megert from comment #5) > > If we add such a feature, it has to be done like all other Java element > > searches in JDT: implemented in JDT Core, exposed as API, and offered in the > > UI > > - as Search > Unreferenced > [Workspace|Project|Package|Hierarchy|Working > > Set...] > > - on the Java Search page > > I don't think new API in JDT core is need, the existing one can be used. As > for the integration into the search page, I think that makes sense. Do you > also want to have it in the context menu? Yes, it should appear where all other searches like e.g. Declarations or References searches appear. > > Is that what you are willing to contribute? > > Sounds good to me, except that I do not think that new core API is needed. It needs to fit into our normal search architecture, hence it is needed, or won't be accepted. Sorry. Your call whether you want to work on it or not.
(In reply to Dani Megert from comment #7) > It needs to fit into our normal search architecture, hence it is needed, or > won't be accepted. Sorry. Your call whether you want to work on it or not. No worries, I try to have a look during 4.6. I first need to learn about the JDT search architecture. I suggest to leave that bug open and unassigned in case someone else want to help.
Some time back I wrote a little hack on top of the compiler that would perform the necessary call-graph analysis during a full build, to check if a method was unreachable from a given set of entry points. The implementation would faithfully recognize unreachable code even in the presence of a cyclic call structure (isolated islands). I guess the main reason I never proposed to include this in JDT lies in the difficulties to identify the full set of entry points. If you have an application it's just "main", but if you write a library / framework that would be at least all public API, but for classes that can be extended by clients, even all protected methods would be possible entry points etc. - Ergo: it is comparably easy to implement the core of such analysis, but not obvious how users would tell the tool from which entry points to start. I understand the search-based strategy takes a different approach. It will probably not detect isolated islands, and instead of starting from a set of entry points, it will probably filter from the search result all methods that have a good excuse for not being referenced? Am I describing it correctly?
(In reply to comment #9) > Some time back I wrote a little hack on top of the compiler that would perform > the necessary call-graph analysis during a full build, to check if a method was > unreachable from a given set of entry points. The implementation would > faithfully recognize unreachable code even in the presence of a cyclic call > structure (isolated islands). Oh, this would have been so useful for so many times! > I guess the main reason I never proposed to include this in JDT lies in the > difficulties to identify the full set of entry points. If you have an > application it's just "main", but if you write a library / framework that would > be at least all public API, but for classes that can be extended by clients, > even all protected methods would be possible entry points etc. - Ergo: it is > comparably easy to implement the core of such analysis, but not obvious how > users would tell the tool from which entry points to start. This feature should also be considered from a Java 9 module world perspective. If I understand correctly, with modules it becomes possible to create module-private APIs that are public internally only for crossing over a package boundary. Consuming what will be specifying this could be a starting point. Apart from that, looking for any @Documented annotations to indicate a public API member would already provide a consumer-extensible mechanism to mark public or reflection-accessible APIs. @SuppressWarnings("unused") would also fit nicely into this to provide a lighter-weight alternative under a well-known name.
