Bug#661464: java-propose-classpath: rewrite proposal

[Niels Thykier]

Package: java-propose-classpath
Severity: wishlist
X-Debbugs-CC: Dmitry Smirnov <onlyjob at member.fsf.org>


On 2012-02-09 12:00, Dmitry Smirnov wrote:
> Dear Niels and Java Maintainers,
> 


Hi,

Sorry for the late reply.  With this mail I will open a bug for this.  I
will mark you as the submitter when I get the bug id.  I am also
(re-)attaching your script, so we have it in the bug log.

> Let me thank you sincerely for your work.
> 

Thanks, though if you are talking about "java-propose-classpath", I
believe you want to thank Matthew Johnson.  :)

> 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.
> 

Agreed, that does sound suboptimal.

> 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.
> 

Sounds reasonable as well.

> 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.
> 

On a related note, I would love for jh_depends to be smarter and
generate ${java:Depends} based on the actual usage[0].  Actually, I
believe I have some code somewhere that might could be useful for this.

[0] Including checking for useless/overlinking and erroing out if
classes are missing etc.

> =====
> 
> 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.
> 

Ok.

> 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.
> 

While I do not have time right now to give it a detailed review, I hope
we can use it (partly or even fully).

> 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.

I appreciate the gesture, but I cannot accept it[1].  It is possible
that we could bump the license of the existing javatools code to GPL-2+
or alternatively, I can also accept an unconditional GPL-2+ license on
your code.


~Niels

[1] http://www.debian.org/social_contract

"""
8. License Must Not Be Specific to Debian
"""
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listdeps-jar.sh
Type: application/x-sh
Size: 3603 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20120227/07d3e53c/attachment-0001.sh>