[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debconf Java BOF discussions

On Sun Jul 12 21:37, Johan Henriksson wrote:
> > I think we should mandate one of the standardised ways of doing dependency
> > resolution so that in most cases application writers don't need to maintain
> > recursive classpaths; java -jar should work and therefore jarwrapper can be
> > used to avoid writing any wrapper at all (In fact, -jar doesn't work at all
> > without a Class-Path attribute as -cp is ignored, so we can't make use of the
> > Main-Class attribute either). It would also allow jh_depends to generate the
> > correct dependencies.
> >   
> is there a sane way of handling JNI? in particular directories in
> addition to /usr/lib/jni , for picky libraries you don't want to modify
> all too much.

Hmm, I think things really should be in /usr/lib/jni, particularly if:

> packaging would be easier if we mandated that all JREs include
> /usr/lib/jni by default in the search path for libraries. AFAIK this is
> not the case now. or if we want to play nice with binary-only
> proprietary JREs, a jh_install that symlinks in
> /somestrangeJREdirectoryForJNI/. just an idea.

If it's not the case now then I think we should make the all include
that by default (although jarwrapper, for example,  makes sure it's on
$LD_LIBRARY_PATH anyway). Playing nice with things outside main is
always optional.

> >    - Currently the rest of 2.3 says that programs must have all the classes in
> >      /usr/share/java. Programs which aren't expecting their classes to be used
> >      as a library can surely ships jars in /usr/share/$program ? 
> if there is an advantage for programs, then why should they get special
> treatment? surely any helper programs should be able to list
> recursively? if upstream builds multiple jars then it might be best to
> keep them separated. symlinking for versions would be done on the
> directory in that case, not the contents.

Well, any jar which you expect someone to put on their classpath should
be in /usr/share/java. Hence, libraries. If a library has a separate jar
which should not be included directly, but picked up via a Class-Path:
directive, that doesn't necessarily need to be in /usr/share/java, but
it's a less common use case imo.

> given that openjdk probably becomes the most used JRE once 7 is out,
> would it make sense to try and improve the manifest with version
> numbering etc upstream? it might get java programmers to add this
> information for us, reducing the amount of work on our end.

Yes, once we decide on what we are doing, pushing it upstream is always


Matthew Johnson

Attachment: signature.asc
Description: Digital signature

Reply to: