 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007Identify unused methods??
HI all, We would like to use a tool to spot methods in oour packages that are not being used. We have the entire source set under Eclipse, so a plugin would be best. We do not want anything too complex or a graph, or statistics, just a simple report that indicates what methods are not used. Does anyone know of such a thing? I did look in the usual places; I found code formatters, style analyzers, code coverage tools...but no tool that does what I've outlined. Thanks, Alejandrina > HI all, > [quoted text clipped - 11 lines] > > Alejandrina I know in Idea you can do a source analysis, and set the options to report unused methods. What you should really do, however, is code coverage. That will tell you everything that isn't used (including methods and branches). I thought code coverage had to do with run-time behavior (ie what paths are not taken); what I wanted was static analysis. Am I wrong? > > HI all, > > [quoted text clipped - 17 lines] > What you should really do, however, is code coverage. That will tell > you everything that isn't used (including methods and branches). > I thought code coverage had to do with run-time behavior (ie what paths > are not taken); what I wanted was static analysis. Am I wrong? You're not wrong. That's indeed a big difference. I'm more the command-line freak and don't know much about existing eclipse-plugins. My approach to this task would be to use some class-file disassembler on *all* class files (perhaps even on those in the platform's rt.jar). Once you have a tree of disassembled files, you can recursively grep for any method or field names (fully qualified!) you wish to analyse. Every field that doesn't appear with either "getfield" or "putfield" is obviously unused. Every static method that doesn't appear with "invokestatic" is obviously unused. Every method that doesn't appear with any of the invoke* and that is an override of a baseclass' method is a candidate that still needs to be checked for superclass invocations. This is quite likely not the easiest way and I wish you that there exists some plugin to your liking, but if not, this hard way might be the only way that's left. PS: there exist a couple of freeware java disassemblers. PPS: javap is *not* a good choice, because it hides away private method implementations. >> I thought code coverage had to do with run-time behavior (ie what paths >> are not taken); what I wanted was static analysis. Am I wrong? [quoted text clipped - 20 lines] > there exists some plugin to your liking, but if not, this > hard way might be the only way that's left. You can use Proguard for this. It is an obfuscator/shrinker, so it already has to be able to work out which methods are not used. The website even provides an example of how to get it list dead code: http://proguard.sourceforge.net/manual/examples.html#deadcode Dan.  SignatureDaniel Dyer http://www.uncommons.org I may have to this route, but ONLY after I've exhausted other avenues :) Alejandrina > > I thought code coverage had to do with run-time behavior (ie what paths > > are not taken); what I wanted was static analysis. Am I wrong? [quoted text clipped - 24 lines] > PPS: javap is *not* a good choice, because it hides away > private method implementations. > > > HI all, > > > [quoted text clipped - 19 lines] > I thought code coverage had to do with run-time behavior (ie what paths > are not taken); what I wanted was static analysis. Am I wrong? Please don't top post.... You are right, there is a difference between static analysis and run-time behavior. I was suggesting code-coverage because it can give you a much more complete picture of whats not being used. This, of course, assumes that you have tests for all of your use cases. (unit tests or otherwise), and that you don't have tests for situations that AREN'T in your use cases. In any case, there are plenty of static analysis tools out there that will help find unused members. I already mentioned that stock IntelliJ IDEA can do this. I would be surprised if there wasn't something for Eclipse that could also. Hope this helps, Daniel. You can install PMD plugin for eclipse (http://pmd.sourceforge.net/eclipse/). Including unused methods and variables, it will tell a lot more about the code that you'd want to know :) -cheers, Manish Hmmm. I looked at PDM but it said it dealt with *private* unused methods. I need a project-wide usage report. > You can install PMD plugin for eclipse > (http://pmd.sourceforge.net/eclipse/). [quoted text clipped - 4 lines] > -cheers, > Manish Yes, I was right, I think. I installed PMD and looked at the violations. The only one (visual inspection only :)) "unused method" refers to private methods. Is there anything else I did not see? Thanks, Alejandrina > You can install PMD plugin for eclipse > (http://pmd.sourceforge.net/eclipse/). [quoted text clipped - 4 lines] > -cheers, > Manish Doesn't Eclipse already mark all the unused methods/variables? You might want to take a look at Findbugs (http://findbugs.sourceforge.net/) also. > Yes, I was right, I think. I installed PMD and looked at the > violations. The only one (visual inspection only :)) "unused method" [quoted text clipped - 12 lines] > > -cheers, > > Manish Eclipse only marks the private unused methods... I checked FindBugs, but it does not seem to trap this kind of error. Thanks anyhow. Alejandrina > Doesn't Eclipse already mark all the unused methods/variables? > You might want to take a look at Findbugs [quoted text clipped - 16 lines] > > > -cheers, > > > Manish Please do not top post. > Eclipse only marks the private unused methods... > > I checked FindBugs, but it does not seem to trap this kind of error. > Thanks anyhow. Do you consider an unused public method an error, or am I misunderstanding the point? - Lew We need to know what methods are unused so we can trim them from a library before putting it under a strict revision control: therefore we want the library to have ONLY what's needed. I do understand the issues with reflection and we can deal with that too (manually :)) Thanks, Alejandrina > Please do not top post. > [quoted text clipped - 7 lines] > > - Lew > We need to know what methods are unused so we can trim them from a > library before putting it under a strict revision control: therefore [quoted text clipped - 6 lines] > >> Please do not top post. Please do not top post. But there is no way to know with a library, which by definition is built in advance of use, to know which methods an application will use in the future. If, say, none of your applications used. java.util.LinkedHashSet, and you were their first customer, should Sun have removed it from their library before they got their second customer? - Lew Let me explain better. This is NOT for a general-purpose library where we don't know which methods will be used. Think of it as an embedded system: once you've developed the code, and tested it, there may be some code left behind that you may have used at some time but is no longer needed and we want to remove it from the "embedded" version of the library. AND even for true "utlity"-type methods, if we are not using them in this version, we want to remove them from the "released library". You can do this with Eclipse, but manually, one method at a time. What we're looking for is a report that operates on a library collection at a time. Alejandrina > > We need to know what methods are unused so we can trim them from a > > library before putting it under a strict revision control: therefore [quoted text clipped - 16 lines] > > - Lew > Let me explain better. This is NOT for a general-purpose library where > we don't know which methods will be used. Think of it as an embedded [quoted text clipped - 10 lines] > > Alejandrina please do not top post To find unused methods this might work for you: http://proguard.sourceforge.net/manual/introduction.html > Doesn't Eclipse already mark all the unused methods/variables? Only private ones I believe. I think there are a couple good reasons for this. If you're developing a library, its public API may well be unused internally, but you need it available for unknown and possibly not yet existent external code, as that's the whole purpose. If you're developing something to be called by a framework that exists outside your code, calls to some of your public methods may only come from that framework. I'd hate to get an "unused method" warning every time I write a Servlet with a doPost method. And I rarely write code that calls them... And then there's reflection. Good luck! The first might be covered if your codebase contains a good test suite calling the public API. The second issue might be covered if the container code is also included in your project as a library, and its calls to the superclass methods being implemented are detected as potential calls to your coded methods. But I suspect it's somewhat intractable. A tool that could detect such things might be nice for some cases, but it should definitely be something you can disable to deal with these cases and not get lots of spurious markings. Eclipse does have a References pull-down that is useful for verifying dead code once you have a suspect. SignatureDon Roby Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.