Writing Utility Tool Using Magical Java

Business without performance is FLOP... And nobody likes flop business.

What happens when we run big, mammoth java based web applications in server that does thousands of transactions each day... and enriches ROI of the business. We generally worry about the performance of the application...

But the million dollar question is how?

Some people will go in clearing the objects, basically nullifying them and making the code smell ... Some would ask for checking the usage of objects in memory in short heap memory... Some would even try to reduce the code by removing the unwanted code; popularly known as DEAD Codes.

I really appreciate all of them above & having said that, let me point out some root causes of performance in java based web applications.

1) Badly used Collection objects 2) Forgetfulness of developers in case of cleaning the mess; closing streams 3) Although Java has been always demanding to not have the dangling pointers issue of C or C++, but what about orphan references. 4) Moreover, the weak references don`t get out of memory blocks easily. 5) Resource Connections; like DB connections are very rigid of taking liberal decision :-) 6) Unwanted libraries (Javanese calls them as Jars) & duplicate classes across them.

Even if all the above 5 issues can be imposed & controlled by little awareness but the last one brings real nemesis & can be very painful in debugging.

Think of a situation where you don`t know why a method written by you is not getting reflected, even if it is available in the build... real pain....

Before even attacking the problem, one has to really go to the core of the problem.

Why do we end up loading unwanted, unused libraries. Obvious reasons are; different versions of libraries are not tracked, libraries from different vendors, libraries from different project teams...

How can we retrospect the archives which contains duplicate classes that are playing hide & seek... And even the servers have their unique way of loading classes... and you can change them in your favor; if & only if you know the locations of duplicate classes.

Now, you can easily write a tool in java to do that.

First, your program start reading the jars, one by one. Read the classes from different packages recursively & store it in a common Collection with its count.

Whenever, the same class with same package is again encountered by your program, increase the counter & also map the name of the library.

This way all the jars should be read & all classes inside those jars. Finally, you will end up getting a collection with package/class name with duplicate occurrences counter. And the mapped library (jar) file names.

This you can print in console & voila... Culprits are tracked now.

To spice it up a bit, you can extend the program with the following feature;

1) Making it as an executable jar to be reused by other people. 2) Providing Option of searching by Class Name or Wild Card Search for packages. 3) Generating PDF based reports with tabular structures.

The options are limitless.