Where did I set down my mobile phone is quickly answered by a quick telephone call or a sms from another phone. If everything were only that simple.
I receive a bit of code from a buddy at work that showed how to do a special calculation with the vendors software using one of the undocumented classes. I knew I would need it one day so it was cast into my Download directory waiting for that day.
By the time I actually needed it, my friend had long left the company. It was literally only 15 lines long including all the necessary class declarations and comments. The only thing that she didn’t tell me was which jar file(s) I would need in my classpath.
This was a real problem as the vendor has slightly under 700 jar files and only about six of them are intended to be used by the customer. The good thing about Java is that it is really easy to see which classes are the jar file. This is easy because the jar file is the same structure as a zip file. This means we can use unzip or winzip to look at the contents of the library.
> unzip -tv special.jar Archive: special.jar testing: META-INF/ OK META-INF/MANIFEST.MF OK powerfulclasses/ OK powerfulclasses/myMath.class OK powerfulclasses/bobsCode.class OK
The best course of action would be to write up a script to list the contents of each jar and do a quick grep to find the class in my example. If I find the class then I have found the jar, well or you might also find a jar that contains an interface for that class or even a jar that contains a similarly named class.
Despite the name of this post, there is really not so much effort for finding the jars. The jar files are in a series of subdirectories grouped by different subsystems. It is however much easier to use the find command to gather up the list of jar files.
find /opt/vendorsoft/support/lib -name "*jar"
I wish I could have created a single line command to gather up the jars, extract the contents and find the special class but with an eye towards expediency I simply created two small scripts.
The first script just gathers up all jar files using the find command and passes the jar files one at a time to the checkit.sh script. The find command gathers the jars while the xargs command processes them one at a time.
#searchpath=/opt/vendorsoft/support/lib searchpath=. searchfor=Gen2CatsCompany find $searchpath -name "*jar" -print | xargs -L 1 ./checkit.sh $searchfor
Each file is passed to the checkit.sh script. For this particular example each call can be thought of like this.
checkit.sh $searchfor <file here>
The checkit script is even simpler because it is essentially just doing an unzip and piping the output through grep. That part could have been done using the “-exec” option for the find command. The only problem is it would find the class but not the name or path of the jar file.
echo $2 unzip -tv $2 | grep $1 >/dev/null 2>&1 if [ $? -eq 0 ] then echo . echo found $1 in file $2 echo . fi
The requirements are simple – find the jar – and the output is also just as simple.
> ./findit.sh ./one/NCSO.jar ./one/mqTransferGenesis.jar . found ExceptionIFGenesis in file ./one/mqTransferGenesis.jar . ./one/jconn2.jar ./one/jconn3.jar ./one/jdom.jar ./one/jhall.jar ./one/junit-4.4.jar ./one/jython.jar ./one/jythonlib.jar ./one/log4j-1.2.14.jar ./one/ojdbc14.jar ./one/surf.jar ./two/mail.jar >
I did use this small helper to go through the list of all the vendor jar files. Despite having a relatively slow development environment the answer came back in under a minute.
With the necessary jar files I was able to compile my code sample.