How to detect if files are not being used by J2EE application in Eclipse
-
Hi, I have taken over a J2EE application and there are a lot of files that I don't believe are being used (some I know aren't). I don't normally do much Java or J2EE development so I'm wondering if anyone can let me know if there is something out there that can tell me what files aren't being used by the application. I'm using Eclipse Helios as my IDE. For example, in Visual Studio apparently you can do the following: In the Solution Explorer you can select the project node and click on the Show All Files button. You will then see files and folders not referenced by the project as grayed out. Taken from http://stackoverflow.com/questions/5889082/find-files-not-referenced-by-project-vs-2010[^] Is there something similar in Eclipse and I just haven't found it yet?
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" -- Oracle CEO Larry Ellison
-
Hi, I have taken over a J2EE application and there are a lot of files that I don't believe are being used (some I know aren't). I don't normally do much Java or J2EE development so I'm wondering if anyone can let me know if there is something out there that can tell me what files aren't being used by the application. I'm using Eclipse Helios as my IDE. For example, in Visual Studio apparently you can do the following: In the Solution Explorer you can select the project node and click on the Show All Files button. You will then see files and folders not referenced by the project as grayed out. Taken from http://stackoverflow.com/questions/5889082/find-files-not-referenced-by-project-vs-2010[^] Is there something similar in Eclipse and I just haven't found it yet?
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" -- Oracle CEO Larry Ellison
-
In your IDE go to: Windows -> Preferences -> Java -> Compiler -> Errors/Warnings -> unnecessary code You'll find quite some options there. The Reult can be seen in the Problems-View (Windows -> Views). regards Torsten
I never finish anyth...
I'm not quite sure that's what the OP wants. Things that are accessible where you mentioned like unused imports are (or can be) highlighted in the IDE (and the common ones are highlighted by default). I think what he's looking for is unused references to other packages/projects on the build path and so on. Maybe OP can clarify what he's after. If it's what I think it is, I don't know of any way other than
foreach (package_reference in project) {remove_package; rebuild; check_for_errors}which is a bit painful, and probably why he asked. :) Cheers, PeterSoftware rusts. Simon Stephenson, ca 1994.
-
I'm not quite sure that's what the OP wants. Things that are accessible where you mentioned like unused imports are (or can be) highlighted in the IDE (and the common ones are highlighted by default). I think what he's looking for is unused references to other packages/projects on the build path and so on. Maybe OP can clarify what he's after. If it's what I think it is, I don't know of any way other than
foreach (package_reference in project) {remove_package; rebuild; check_for_errors}which is a bit painful, and probably why he asked. :) Cheers, PeterSoftware rusts. Simon Stephenson, ca 1994.
It may not be that straight-forward if your project is using reflection. Suppose you do something like:
Class myClass = Class.forName("com.mycompany.stuff.MyThing");
If you remove the com.mycompany.stuff package from the project, this will still compile with no errors. But when it runs it will collapse in a smoking heap. (If you are using JUnit properly, that should catch it but even so, it's not a real solution.) This could be a problem if you are using Spring, for example, which uses reflection to instantiate beans. Or there may be files that need to be in your project (e.g. log4j.properties) that are not referenced directly by your own code, but are required for some third party library you are using. Yes, you can set up the log4j.properties file (or log4j.xml if you prefer) at deployment time but most projects I've seen include it in the build for convenience. Hibernate config files are another example that springs to mind. I'm not sure that Java has the same concept of "referenced files" that .NET does. An awful lot is just picked up off the classpath at runtime. That makes it quite a bit harder to figure out which files are really "unreferenced".
-
In your IDE go to: Windows -> Preferences -> Java -> Compiler -> Errors/Warnings -> unnecessary code You'll find quite some options there. The Reult can be seen in the Problems-View (Windows -> Views). regards Torsten
I never finish anyth...
That is part of what I'm after. Thank you for that!
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" -- Oracle CEO Larry Ellison
-
I'm not quite sure that's what the OP wants. Things that are accessible where you mentioned like unused imports are (or can be) highlighted in the IDE (and the common ones are highlighted by default). I think what he's looking for is unused references to other packages/projects on the build path and so on. Maybe OP can clarify what he's after. If it's what I think it is, I don't know of any way other than
foreach (package_reference in project) {remove_package; rebuild; check_for_errors}which is a bit painful, and probably why he asked. :) Cheers, PeterSoftware rusts. Simon Stephenson, ca 1994.
What Torsten mentioned should be good enough to get me through most of the ejb stuff, I think. Maybe once I'm a little more comfortable with the app (and J2EE in general) I might go a little deeper into cleaning that part up the way you mentioned Peter. I appreciate it though. My other problem is in the web section of the J2EE app, let me know if this is veering towards another forum now. There are a lot of complete files that are not used at all(jsp, js, css, html, xml, etc.) by my application. Many of them are from third party things added in (grid controls, calendar controls, etc), you know there are documentation folders, example folders and then just files that are for different skins and who knows what else. There are also multiple jsp pages that I believe have been replaced by other jsp pages, but the originals haven't been removed. I want to make sure I don't mistakenly remove a needed one though. I'll apologize now because I've tried looking around and am just not familiar enough with J2EE and Eclipse to know if there is a simple solution for this. Thanks.
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" -- Oracle CEO Larry Ellison
-
What Torsten mentioned should be good enough to get me through most of the ejb stuff, I think. Maybe once I'm a little more comfortable with the app (and J2EE in general) I might go a little deeper into cleaning that part up the way you mentioned Peter. I appreciate it though. My other problem is in the web section of the J2EE app, let me know if this is veering towards another forum now. There are a lot of complete files that are not used at all(jsp, js, css, html, xml, etc.) by my application. Many of them are from third party things added in (grid controls, calendar controls, etc), you know there are documentation folders, example folders and then just files that are for different skins and who knows what else. There are also multiple jsp pages that I believe have been replaced by other jsp pages, but the originals haven't been removed. I want to make sure I don't mistakenly remove a needed one though. I'll apologize now because I've tried looking around and am just not familiar enough with J2EE and Eclipse to know if there is a simple solution for this. Thanks.
"The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?" -- Oracle CEO Larry Ellison
:) My best wishes go with you. This looks like another example of
inherited project == can of worms
and we all know that once you open a can of worms, you're going to need a larger can... Did a quick google for the quote, but couldn't find it. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.
-
It may not be that straight-forward if your project is using reflection. Suppose you do something like:
Class myClass = Class.forName("com.mycompany.stuff.MyThing");
If you remove the com.mycompany.stuff package from the project, this will still compile with no errors. But when it runs it will collapse in a smoking heap. (If you are using JUnit properly, that should catch it but even so, it's not a real solution.) This could be a problem if you are using Spring, for example, which uses reflection to instantiate beans. Or there may be files that need to be in your project (e.g. log4j.properties) that are not referenced directly by your own code, but are required for some third party library you are using. Yes, you can set up the log4j.properties file (or log4j.xml if you prefer) at deployment time but most projects I've seen include it in the build for convenience. Hibernate config files are another example that springs to mind. I'm not sure that Java has the same concept of "referenced files" that .NET does. An awful lot is just picked up off the classpath at runtime. That makes it quite a bit harder to figure out which files are really "unreferenced".
You're right, of course. Once reflection rears its ugly (but occasionally beautiful ;P ) head all bets are off, at least in terms of knowing where your code came from. I don't think that things picked up from the classpath are a big issue here (but of course one'll pop up to make a liar of me!) Have a 5! Cheers, Peter
Software rusts. Simon Stephenson, ca 1994.