Summary: | [search] Feature proposal: Identify all unused classes, methods etc within project/package | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Andreas Klein <andiklein> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | daniel_megert, gautier.desaintmartinlacaze, Lars.Vogel, malaperle, mn, stephan.herrmann |
Version: | 3.3 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Andreas Klein
2007-02-01 21:06:36 EST
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. |