JBalboa is a small software engineering tool, useful for java developers working on medium to large java projects.
It consists of two parts: Links and Lookup.
Links allows you to retrieve, among other things, which jars in a given directory are never used (i.e. its classes are never imported). This will help you to clean up your lib directory.
Lookup allows you to retrieve a java class (or any other file actually) inside a directory containing any number of jars.
You can also launch the application via Java Web Start:
Click to launch the latest stable release.
For any problems / questions about Java Web Start, please see the
FAQ at ArgoUML (thanks).
And yes, the application is not signed, so you'll have to trust me.
Last Modification: 2009-01-01
As an example, let's use the JBalboa own jar lib. It contains the following jars: (see the image on the right).
You may want to know if any of those jar is not used at all - i.e. you could remove it without any side effect.
Or you might want to know which jar is using which, or whether some classes are imported in your code but never found
(this could provoke a ClassNotFoundError).
All of this (and more) is possible with JBalboa!
Start JBalboa (f.i. jgui.bat in the jbalboa-<version> directory), and switch to the Links tab. In the Directory input box, type (or select) your lib directory (real name does not matter). In the Jar input box, type (or select) your project class directory (the root of all your classes) or your project's main jar (containing your classes). Click on Start and there you go!
You can see here that jdom.jar was detected as "unnecessary". In other words, none of its classes are statically imported by your classes OR by another jar called directly or indirectly by your classes. Note that they could be dynamically imported (using f.i. Spring's IoC) but this could not be detected.
But you want to know more, to have more details - to be surer of that diagnostic! The next tabs will tell you all.
LinksThis tab allows you to know how many times a given jar is used, and by whom. For instance in the screen below, commons-lang.jar and commons-logging.jar are used by the project's classes. And junit-4.4.jar is used (imported) both by the classes and jdepend-2.9.jar.
Notice than jdom.jar is not used by anybody, and that explains why you could remove it from the project.
LinksThis view is symmetrical to the previous one. It shows which jar(s) any other jar is actually using.
For instance, you can see that classes uses (imports) commons-logging.jar that, in its turn, uses log4j.jar. That last jar is thus used indirectly through the commons-logging.jar (the purpose of commons-logging.jar is to be a thin layer between your project and any logging library you use).
LinksIt may happen inside the jar lib for a same class (same package and same name) to exist two times or more. Of course, this should never happen, but it does and in that case you cannot be sure which will be loaded. Let's check that here:
Ouf! The list is empty, so there can be no conflict of that kind. A real-life example is the class
org.aspectj.internal.lang.annotation.ajcDeclareAnnotation that exists both in aspectjrt.jar
and aspectjweaver.jar.
It's also possible for a class to import another one that's nowhere to be found. Most of the time, this is due to a missing jar but this is not always a problem if the "calling" class is never used anyway.
In this example, we see that commons-logging.jar classes import org.apache.avalon.(...).Logger
and org.apache.log.Hierarchy.
Nothing surprising here, those are two possible logger implementations but the one I use is Log4j. So the project does not include
the Avalon or the LogKit implementation.
When you analyze your jars, you will probably want to skip some packages. For instance, you most probably do not want to start parsing the core java classes. You can define filters in the corresponding tab:
Using the buttons on the right, you can edit, delete or create new filters. Do not forget to click on Apply once you are done. The filters given above are active by default, so the application will skip the java, javax and com.sun packages.
Tip: Do not modify the filters until you are familiar with the application.
Note: To stay on the safe side, if a jar contains at least one filtered class, it will not appear in the list of the unused jars. This is because the filtered classes may be used by your application, and you do not want that jar to appear unused when it is not. The jar will not appear either if it does not contain any java classes at all.
LinksIn console mode:
jcon.bat -start links lib jbalboa.jar
will parse all the jars in the lib directory and the main jar jbalboa.jar. You may get such a result:
Parsing: jbalboa.jar Parsing: commons-lang-2.1.jar Parsing: commons-logging-1.1.1.jar Parsing: jdepend-2.9.jar Parsing: jdom.jar Parsing: junit-4.4.jar Parsing: log4j-1.2.15.jar ---- Untouched Jars ---- jdom.jar
As above, it means that jdom.jar is never used, nor by jbalboa.jar or by any of the other jars (which are well used, directory or indirectly by jbalboa.jar).
Each time you execute the application, an ini file will be created or modified with your directory choice (default name: default.ini). So the next time you run it, the following line will be enough
jcon.bat -start links
because both the directory (lib) and the main jar file will be read from the ini file.
The graphical mode:
jgui.bat -start links
or simply
jgui.bat
In all cases, you can select a specific ini file with the -ini option:
jgui.bat -ini myinifile.ini jcon.bat -start links -ini myinifile.ini
If that ini file does not yet exist, it will be created and filled in when the application is executed.
LinksWhat if you want more information? For example, the complete list of jars inside the directory, or for each class, the list of imports?
Well, you can find that information inside the log-debug.txt, at least if the log4j.properties is correctly configured (it is by default). I did not think it was necessary to add another tab just for that - too much information kill the information.
Top
Lookup helps you to retrieve a given class (or any other file actually) inside the jars of a given directory.
Let's suppose you want to retrieve some class inside the lib directory of the latest Spring distribution.
On my computer, it contains 54 subdirectories (ant, antlr, aopalliance, ...) for a total of 107 different jars.
Because of a ClassNotFoundError, you need to localize the class org.jaxen.Context.
And you're out of luck, there is no jaxen subdirectory.
Or you need the reference of a specific xml file, but you're not sure of the name.
Sure, you could open all 107 jars, but you should rather use JBalboa.
Start JBalboa (f.i. jgui.bat in the jbalboa-<version> directory), and switch to the Lookup tab.
In the first input box, type (or select) the Spring lib directory. In the second one the class you're looking for.
Do not forget to select the checkbox Search in subdirectories, click on Start and there you go.
As you can see, the class is now found in jaxen-1.1-beta-7.jar in the dom4j subdirectory. You could also have entered Context instead of org.javen.Context to retrieve all the Context classes (there are almost 300 of them).
The search is not limited to the java classes. If you enter .xml in the second input box, you will get the list of all xml files inside the jars (74 of them). And you can use the standard wildcard operators * and ?.
In console mode, try something like: (where -s means: search subdirectories)
jcon.bat -start lookup -s <dir> <search pattern>
For instance:
jcon.bat -start lookup -s "C:/Apache/spring-2.5.6/lib" Context
For the help and the list of available options:
jcon.bat -start lookup -hTop
| Package | Release | Date | File |
|---|---|---|---|
| Binary (java 5) | 0.9.3 | Jan 2009 | jbalboa-0.9.3.zip |
| Source | 0.9.3 | Jan 2009 | jbalboa-0.9.3-src.zip |
Unzip the jbalboa-<version>.zip. It will create a new directory named jbalboa-<version>
that will contain all the necessary jar files (specially jbalboa.jar), some batch files, and the documentation.
Please do not unzip any of the jar files.
The file jbalboa-<version>-src.zip contains the project code source, for the developpers.
To uninstall JBalboa, deleting the directory jbalboa-<version> will be enough.
Important
You need Java 5 SE to execute JBalboa.
You may also need to include the bin directory of your Java distribution in your PATH.
Console Mode
Open a console window in the folder where jbalboa.jar is located and execute jcon.bat on Windows.
In this mode, you will need to type an additional argument to specify which feature you want to execute (Links or Lookup).
jcon.bat -start [links|lookup] [additional arguments]
See Lookup or Links for more information about the runtime arguments.
Graphical Mode
Right-click the file "jbalboa.jar" and select Open With... > Java Platform SE.
Or you can execute
jgui.bat
with any additional arguments.
Top
The main limitation of JBalboa is that it does not detect dynamically imported classes. This happens f.i. quite a lot with such a framework as Spring, that connects independent modules using the information given in an XML configuration file.
Morality: if you remove a jar from a java project, make sure to test it thoroughly again.
Top
The code used to parse the byte code of the class files comes from JDepend, by Mike Clark.
Top
Copyright © 2009 Bernard Jorion