I have a series of eclipse projects that use a bunch of third party jars.
So many are included of different versions.
But I have noticed that some of these libraries, due to code changes over the time, are not used any more but the reference to the library is there.
Is there any plugin that shows the jar dependencies of each project and which I can remove safely?
JarAnalyzer can be used for this purpose.
I am not aware of any plugin or tool that helps in doing what you want to do. However, there may be rules or procedures that help to reach the final end: a reduced set of libraries that is needed and consistent.
I have found the the "Java API Compliance Checker" which allows to compare two versions of the same library. May help to reduce the number of the used libraries for the same purpose. I have not used it, so I cannot tell you about my experience.
Define if it is allowed to have the same kind of library in different version available. Depending on the environment, this may or may not allowed.
Incremental process to reduce the amount of libraries needed:
Remove one library each time from eclipse.
Look if compile errors result from that.
If yes resolve the compile errors.
When all are resolved, start your unit tests (you have unit tests, of course :-)) and see if any unit test breaks.
Do these steps for each library you want to remove.
At the end it could be worthwhile to look at a tool like ivy that allows you to manage the libraries explicitly. Or even switch to Maven which allows you the same.
Final remark: The usage of a library should be
decided by the architect of an application only and
documented in the architecture handbook together with the reasons for doing that.
Try open your Manifest file. You can edit and remove the dependency from there
Related
I'm writing an applet, which uses ~10 external libraries. Together they occupy more than 2 megabytes. In some libs we use only 1-2 classes, so a lot of others can be safely deleted. So the question is how to remove unused classes from jar libraries?
A lot of other questions link to Proguard. But it doesn't process libraries (or I am doing something wrong) and also ruins parts of code which use reflection.
You could use the maven-shade-plugin and tell it to build a minimized jar file that combines your code and libs.
You could use something like ClassDep, which statically identifies which classes you will use.
However it's possible to easily fool this. Imagine some of your code contains:
Class.forName(className);
so you can dynamically build a classname and load that class. Tools like ClassDep can't identify these cases, so you'd need to perform comprehensive testing on your shrunken jars.
ProGuard can process your code together with the libraries (with the option -injars). You can still keep external libraries that you don't want to process (with the option -libraryjars).
Any automatic shrinking tool will have problems with reflection. ProGuard recognizes some basic reflection and it allows you to specify the parts of the internal API that should be preserved for the sake of reflection. ProGuard supports some powerful configuration, but depending on the amount of reflection in the libraries, it may still require trial and error.
You can simply "unzip" the JAR's, take only the classes you want from each, and place them in a custom archive. Brian A. gave a good suggestion on how to identify those classes and some caveats. I would add they you may be violating licenses as well...
I was trying to get started with using (not making contributions to) the geotools lib yesterday,but i ended up trying to figure out what purpose does maven serve when it comes to someone that just wants to build a small/medium app based on geotools;At first i thought that using maven spares the dev on writing all the imports ( that's what i recon dependencies are BTW) but after reading a blog that had a somewhat modified version of the quickstart tutorial i'm not that sure anymore..Could someone make clarify what is maven's use for someone that just wants to build some apps and not make contributions?
Maven has nothing to do with saving you from import declarations in Java source files. It is about handling your whole project and that might include dependencies. But you still have to write imports in Java. If your project is to small for maven to be useful, don't use it. But in larger project a declarative build description, dependency management tool is definitely useful.
I wouldn't attempt to use the GeoTools library without Maven, it is a large and quite complex project with 10s of jars. Your app will probably only need 5-10 of those jars but without Maven it is almost impossible to work out which 5-10 you'll need. For example you will probably want to read in some data, so you'll need gt-data and at least one specific datastore gt-shapefile or gt-postgis. I'm pretty sure one of those will need to use a coordinate system so gt-referencing (and a specific implementation, say gt-epsg-hsql).
Anyway you should probably work through at least the quick start tutorial to see what Maven does for you.
I know there are some similar questions around in Stackoverflow, but they were either .Net related or didn't have any answer that helped us.
The case is as follows: with some friends we are starting an open source project. While setting the foundations of the hopefully successful project, a question arose: how to enforce the code conventions of the project?
The reasoning is that being an open source project, if people starts reformatting the code as they like, the patches will become cluttered with changes due to formatting that will hide the real "value" of the patch. So we want something that forces users to abide to a specific formatting, breaking the build if they don't.
The project is using Struts 2 + Spring + Hibernate, using Maven 2 (thinking on moving to Maven 3). We know we can use "CheckStyle" to test the Java files, but this leaves some questions open that hopefully someone can answer:
There is some tool to check the style of XML and SQL files, breaking the build if they don't abide to the rules?
There is some tool that automatically reformats the source files (Java, XML, SQL) to the desired convention? Can ti be integrated with Maven somehow?
We could find Jalopy for Java files, but we would prefer a free tool (as far as we know, the latest version is paid one). And we still couldn't find anything for SQL/XML.
UPDATE: just to make it clear: I'm not asking about PMD, Checkstyle or these tools. I'm asking for tools that:
Automatically format SQL, XML and/or Java files to a desired coding convention (4 spaces, etc)
Detect SQL and XML files with the wrong format and break a build because of that.
The standard tools I would use for java are
CheckStyle
FindBugs
PMD
All of these are capable of failing a Maven build when a certain threshold was reached.
But the question is of course: who runs those tools, and when?
My suggestion would be to get a Continuous Integration Server like hudson and configure it to run the maven checkstyle, findbugs and pmd goals (hudson has plugins to display graphs for all these tools), and you will always see who failed the build, because you can see who committed what between two builds.
It sounds to me like you're going along the route of creating an open source project and then giving commit access to all. I'd advise against this, whatever measures you try to put in place, someone stupid will come along at some point and sod the whole lot up.
Instead, I'd advise taking a different approach with commit access and handing it out only to people that prove they pay attention to the rules and restrictions you've put in place. They can generate patches, submit them to you and eventually if they're regular and trustworthy enough, you can hand out commit access.
One other point, something like Hudson may be of use here (it has a checkstyle plugin as well.) It won't prevent people committing crap code, but it can create a build and run checkstyle every so often, notifying people on a mailing list if someone screws up the code (either because it won't build or because someone's broken checkstyle rules.) Not foolproof, but this would enable you to keep an eye on things more easily.
Each of PMD, Checkstyle, Findbugs etc have Eclipse and other IDE plugins. You can also configure your IDE of choice to format according to the style you want, and then share this configuration (as a file) among members of the team.
I don't think you want your SCM server formatting files for you, otherwise after a check-in your local copy might be immediately out of date with whats in SCM. Everyone on the project would have to get used to doing an update immediately after a commit then, which sounds like a brittle process.
Instead, share your IDE configuration with the team (checking this config file in would be a good idea for what you want) and then fail the build if anyone violates the policy.
Yes, since eclipse, for example, has a build-in code-formatter, it could be possible that you may use the formatting-plugin to format all the java-code along a fixed configuration file, even without eclipse or any other GUI in a build process.
I have a Java project and internally it is dependent on asm jar. Strangely, I don't even know why my project somehow is dependent on this library (might be brought in by maven as a transitive dependency)?
Can anyone help me know why some one needs asm jar?
Thanks in advance !
EDIT:
Can you also mention for what purposes/use-cases one might need asm jar?
ASM is a bytecode manipulation framework (see this page for a nice introduction) and is used by many things performing... bytecode manipulation: frameworks using proxy generation and reflection (Spring, Hibernate, etc), mocking frameworks (EasyMock, JMock, etc), code analysis tools (PMD, Findbugs, etc). Actually, the ASM project maintains a list of users organized by category, check it out.
As mentioned by Vincent, if you are depending transitively on ASM, the dependency:tree goal or the dependency report (see the PMD and Findbugs links above for examples) can help to analyze the situation and to find out from where its coming from. But this won't take into account dependencies of maven plugins that you are using, only dependencies of your project.
Maven-2 requires asm.jar to compile and run the application.
Here for more information.
EDIT:
Due to the many possible usages of program analysis, generation and transfor-
mation techniques, many tools to analyze, generate and transform programs
have been implemented, for many languages, Java included. ASM is one of
these tools for the Java language, designed for runtime – but also offline – class generation and transformation. The ASM1 library was therefore designed to
work on compiled Java classes. It was also designed to be as fast and as small
as possible. Being as fast as possible is important in order not to slow down
too much the applications that use ASM at runtime, for dynamic class gener-
ation or transformation. And being as small as possible is important in order
to be used in memory constrained environments, and to avoid bloating the
size of small applications or libraries using ASM.
ASM is not the only tool for generating and transforming compiled Java
classes, but it is one of the most recent and efficient. It can be downloaded
from http://asm.objectweb.org. Its main advantages are the following:
1) It has a simple, well designed and modular API that is easy to use.
2) It is well documented and has an associated Eclipse plugin.
3) It provides support for the latest Java version, Java 6.
4) It is small, fast, and very robust.
5) Its large user community can provide support for new users.
6) Its open source license allows you to use it in almost any way you want.
Found from this pdf file. I am under the impression that along with Java EE 6 also came a built-in tool, ASM for class generation and transformation. The PDF gives you detail in greater depth about ASM.
Hope this helps.
What other dependencies does your project have ? I suspect one of the jars you've decided you require (e.g. Spring or Hibernate) itself requires asm.jar ?
It is possible to use the dependency plugin for Maven to see which library has asm as a dependency.
I'm about to inherit a rather large Java enterprise project that has a large amount of third party dependencies. There is at least seventy JARs included and some of them would seem to be unused e.g. spring.jar which I know isn't used.
It seems that over the years as various developers have touched upon the code base they have all tried out new project-of-the-month type libraries.
How does one go about getting rid of these? Within reason of course, as clearly some dependencies are helpful to not have to re-invent the wheel.
I'm obviously interested in java based projects but I'm welcome to answers across languages that people think will be helpful.
Personally, I think you have to start by assessing the scale of the problem. It's going to be fairly painful, but I'd make a list of the dependencies and work out exactly which parts of the project use which ones.
Then I'd work out exactly what features of each you're actually making use of (in many cases, you'll end up having a massive third party library which you're using a tiny part of).
Once you have this information, you'll at least know what you're dealing with.
My next step would be to look at all of the dependencies that you only use to a small extent. Checking around might uncover things that you could use from other libraries that would eliminate the lesser used libraries.
I'd also have a look around to see if there's anything small that you could just re-write and include in your own code-base.
Finally, I'd have a look around at the vendors of your dependencies and their competitors to see if the latest versions contain more functionality that will allow you to eliminate a few others.
Then you're just left wondering whether it's better to be highly dependent on a few vendors, or less dependent on a lot of vendors!! ;o)
structure101 http://www.headwaysoftware.com/products/structure101/index.php
It's a great tool for showing dependencies. I've been using it for a couple of years.
If you have a good set of automated tests, and you're looking to remove libraries which are not used at all, you could just use trial and error. One at a time, remove a library, and run your tests to see if everything still works. If not, put it back. Of course, if you can't even build without a library, you probably need it.
Basically, however you go about it, my idea is to remove them one at a time and see what breaks. If nothing breaks, odds are good you can just toss the library. If the problem is very minor (e.g. you need one method of one class in a large library), you might be able to code around it.
If you're dealing with a standalone application, you could give the JVM the -verbose:class option to see which classes are being loaded. This should give you messages like:
[Opened C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]
[Loaded java.util.regex.Pattern$Single from C:\Program Files\Java\jre1.6.0_04\lib\rt.jar]
I read about an approach using instrumentation here, never tried it, but sounds reasonable.
We went through an exercise like this, on a delphi codebase. We dramatically simplified our external dependancies. Basically, we went about it like this:
Catalogued all external libraries and components
Catalogued (using a file search tool) where they were used, and what for.
Removed everything we didn't use or didn't need (some libraries were used in code that was no longer needed).
Made a ranking of which libraries we favored, basing this on whether the library was actively developed, how much functionality it offered that we used, how difficult it was to port the code that used it to another library that we already used and so on.
Finally, we iteratively removed dependancies on libraries low on the list by porting that functionality to another library.
This was, however, quite a lot of work.
If you take the approach of "remove things until it won't compile" you need to be very careful about transitive runtime dependencies. If there's a good quality test suite, it can help, but you'll certainly need to run a test coverage tool like Cobertura to make sure that enough of the code is getting tested to exercise your full dependency graph.
How much code are you talking about? The review-based approach suggested by Joeri frankly seems the best to me; it has the added advantage of making you at least superficially familiar with all parts of the system. If you're just inheriting a big project, this is something you should probably take the time to do anyway.
if you have a full regression test suite for this project, all you have to do is run the regression suite while running with 1 less JAR each time in a loop. it is NOT fast BUT it is easy to do.