JBalboa v0.9.7 is a small software engineering tool, useful for java developers working on small to large java projects. It consists of two parts: Links and Lookup.
Lookup allows you to retrieve a java class (or any other file actually) inside a directory containing any number of jars.
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.
The best way to use the application is via Java Web Start. Click on the button below:
For any problems / questions about Java Web Start, please see the download section.
JBalboa is a small engineering tool useful for Java developers. It requires Java 5 (or above) and is partially hosted on the famous Tigris.org site.
JBalboa is also referenced on the following sites, although not necessarily with the latest version:
Last update: July 2011. You can contact me at email@example.com.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 20 jars with thousands of classes:
For some reason, you need to locate the class
TransactionAspect and maybe some of its variants.
Or you need the reference of a specific xml file, but you're not sure of the name.
Sure, you could open all 20 jars, but you should rather use JBalboa.
Start JBalboa (Use JavaWebStart or
jgui.bat in the
jbalboa-0.9.7 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, classes matching
TransactionObject can be found in
Note that all variants of
TransactionAspect are given as well.
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. And you can use the standard wildcard operators * and ?.
By default, JBalboa will only parse the
*.jar, *.ear and
If you want it to parse the
*.gz files as well, select the option Include Zip files.
And if you want it to parse jar files included into some other jar files (e.g.
jar files in a
war file), select the option
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
All of this (and more) is possible with JBalboa!
You can see here that junit-4.8.1.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.
(As you can guess, this jar is only used for the unit tests, not for the main classes).
No java class was found in jta-1.1.jar. Actually that jar does contain classes but they all belong to the package javax.*, and they were filtered (see the Filters tab). This does not mean the jar is not useful, simply JBalboa did not parse its classes. So you should not remove that jar unless you re-run the application after removing the corresponding filter.
But you want to know more, to have more details - to be surer of that diagnostic! The next tabs will tell you all.Links
This tab allows you to know how many times a given jar is used, and by whom. For instance in the screen below, commons-lang-2.5.jar and log4j-1.2.16.jar are used by the project's classes.
Notice than junit-4.8.1.jar is not used by anybody, and that explains why you could remove it from the project.Links
This 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-lang-2.5.jar.Links
It 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
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 log4j-1.2.16.jar import
org.w3c.dom.Document but the implementation for this
class does not exist anywhere in the project.
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 appear under the node Jars with no class found.Links
The graphical mode:
jgui.bat -start links
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.Links
You'll find inside the log-debug.txt(.n) files the list of all imports for each class, as well as the list of all the parsed jars. I did not think it was necessary to add another tab just for that - too much information kill the information.
Now if you feel you need more specific information, do not hesitate to contact me, I'll see what I can do for you.Top
You might wonder about the use of the Links when a tool like Maven is most often used in the new development projects.
I strongly suggest using JBalboa with Java Web Start (that's how I do it). All the jars are automatically downloaded, you do not need to install anything and when a new version is published, it will be automatically downloaded.
This will only work if your computer associates the extension
.jnlp with Java. If it is not yet the case,
you might get such a pop-up:
Confirm the choice and go ahead (this association will be useful with all
jnlp applications, not only JBalboa).
And the application is signed, but by a self-signed authority (myself :-), meaning it will not be recognized as official by Java.
So you may get the following warning:
(In English: The numerical signature could not be verified. Do you want to execute the application?)
The security in Java Web Start relies on certificates that are signed by known and trusted root certificates and authorities. To acquire such a certificate you need to have a registered company that owns the certificate and you need to pay some money to get it. I might acquire such a certificate one day, but in the meantime you will need to trust me.
And be a litte bit patient, there is about 1 mega of jars to download.
More information about Java Web Start is available on: FAQ at ArgoUML (thanks).
If you like JBalboa, you can then create a shortcut on your desktop towards the JWS link. Or you can download the sources below (the project is built with Eclipse and Maven).
jbalboa-0.9.7.zip. It will create a new directory named
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.
jbalboa-0.9.7-src.zip contains the project code source, for the developpers.
To uninstall JBalboa, deleting the directory
jbalboa-0.9.7 will be enough.
You need Java 5 (or above) to execute JBalboa. Java 6 is advised (as Java 5 is considered obsolete anyway). You could also need to include the bin directory of your Java distribution in your PATH.
Right-click the file "jbalboa.jar" and select Open With... > Java Platform SE.
Or you can execute
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