java-propose-classpath proposal

[Dmitry Smirnov]

Dear Niels and Java Maintainers,

Let me thank you sincerely for your work.

I'm writing to you to share some feedback and improvements to java-propose-
classpath which I hope you might find useful.

But first please excuse me for starting with describing a problem:

java-propose-classpath in its current form is not very useful, to say the 
least.
The problem is that it makes assumptions that all the required dependencies 
can be satisfied with installed shared java libraries (jars).

If the dependency is not installed the proposed class path is incomplete and 
there is no warning for incomplete dependency. This is very misleading.

But the problem is much worse: if java-propose-classpath is given two jars, 
one primary and the other one providing needed classes, java-propose-classpath 
tries to calculate class path for both of them, completely ignoring their 
relationships. (unless all dependent jars are installed to /usr/share/java the 
calculated class path would be incorrect)

Needless to say there are many cases when application may need to install 
private jars and java-propose-classpath could be a very useful tool to help 
calculate what libraries are really needed.

Sadly many Java developers distribute their stuff as a bunch of jars some of 
which are not even needed and some of which can be substituted with debian 
packages providing needed dependencies. We need a better java-propose-
classpath to help maintainers to package not so perfect java software.

For example, java-propose-classpath could suggest what package provides the 
dependent java library. This could significantly ease tedious Depends 
calculation which for a moment can only be done manually.

=====

I experienced all the above problems when I was struggling with packaging one 
Java application. To overcome the issues I wrote a helper bash script which 
successfully deals with all described problems and more.

Initially I thought I would use my script to improve java-propose-classpath 
but this would replace over 90% of java-propose-classpath code.
It appears to me that doing it the other way (merging java-propose-classpath 
with my script or using my slightly modified script to replace java-propose-
classpath) may be an easier task. Sadly at the moment I can't afford spending 
enough time to do the merging work hence I'm sharing my script with you in 
hope that you can accommodate improvements, ideas and implementation to the 
package.

===

The attached bash script takes one or more jars as arguments and extract all 
the used classes to associative arrays using the method similar to one java-
propose-classpath uses. If the required class is present in given jars it 
considered as satisfied dependency.

Then script scans the jars installed to /usr/share/java and print out all the 
needed classes which are not provided by neither given nor shared jars.

The identified shared jars providing classes required by given jars are then 
printed out, with corresponding packages providing them, if 'dlocate' is 
installed.

My implementation is slightly faster and more flexible:

 it can use 'fastjar', but falls back to use 'jar' provided by openjdk;

 it can use 'jcf-dump' from gcj-jdk but falls back to 'javap' from openjdk.

Because script heavily rely on bash associative arrays it is very important to 
use bash (>= 4.2) because older versions affected by nasty memory leak.

Without the license my script have roughly the same number of lines as java-
propose-classpath so in the same size it does a bit more, including some 
progress indication which I find very useful when scanning large jars (it 
sometimes takes over 20 minutes).

Please let me know what do you think. 

Hopefully with your suggestions we can accommodate improvements into javatools 
package easy enough.

Please CC to me as I'm not subscribed to pkg-java-maintainers list.

All the best,
Dmitry.

P.S. Please don't worry about license compatibility because for javatools I 
give permission to use GPL-2+ license.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listdeps-jar.sh
Type: application/x-shellscript
Size: 3603 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20120209/87170434/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20120209/87170434/attachment-0001.pgp>