Re: Java wrappers and java-common

[Eric Lavarde <deb@zorglub.s.bawue.de>]

Hi Vincent,

comparing the wrapper script from FreeMind, version 0.9.0, not yet in 
Debian [1], and your script, I'm missing the following features:

- no check that JAVA_CMD actually exists and is executable if the 
variable is set.
- /usr/bin/java as last fallback if nothing else helps.
- debug output of java version found, and how the java command was found 
(it helps a great lot when users ask for help and have e.g. a dangling 
environment variable).
- a warning if the find_java_runtime is called with criteria and the 
java command returned doesn't respect those criteria: i.e. JAVA_CMD is 
set to gcj, and the script asks for 'sun'. I don't have a good solution 
for this one, but it also helps avoiding bug reports where the user 
forces the wrong Java command.
- the ability to ask for a maximum Sun version, as certain Java programs 
don't work with newer versions. Perhaps create things like sunmin5 and 
sunmax5 variables and be able to ask for those!?
- in my script, I also use JAVA_BINDIR to find the "right" java command. 
It's a SuSE thing, but if we try to be truly cross-platform, we should 
also consider it.
- I would define $DESTDIR/usr/share/java once as a variable and reuse it 
throughout the functions.
- I also defined a variable ADD_JARS which is put in front of the CLASSPATH.
- the CLASSPATH variable is also used by the java command, do we have 
here a consistent behavior across all binaries?

Cheers, Eric

[1] 
http://freemind.cvs.sourceforge.net/freemind/freemind/freemind.sh?view=log&pathrev=fm_060405_integration

Vincent Fourmond wrote:
>   Hello,
>
> Michael Koch wrote:
> > > > Before we move stuff into Debian java-common it should be completely
> > > > working for most cases. 
>
>   I've looked at a fair amount of wrapper scripts, and the wrappers.sh
> library I propose can be used to provide all their functionalities
> easily save one, for bsh, where users can provide an additional
> classpath with a -classpath option. (this can be done with wrapper.sh
> but via an environment variable, though). There are a few wrapper
> scripts (such as ant and others copied from it) which are quite complex,
> and I'm not sure that they could benefit from wrappers.sh, but this is
> just a couple.
>
>   That means that there would be no problem using this wrappers.sh for
> most of the wrapper scripts in the wild. This way, we would win:
>   * adaptability: only one package to modify for new jvms (or new
> properties)
>   * consistence: several possibilities of customization and debugging
> shared across all scripts (and that really should help, especially for
> bug reports...)
>   * and, for us maintainers, it should be painless to write wrapper scripts.
>
>   We would lose only in one point:
>   * all packages with a wrapper script would need a versioned Depends on
>  java-common. That shouldn't be much trouble, though.
>
>   The wrapper is LGPLed so it should not pose legal problems of any kind.
>
> > >   Do you mind me moving to the SVN of java-common, as I don't think it
> > > is a good idea to go on in batik ? It wouldn't be installed if a new
> > > version of java-common is necessary, it would only be present in the
> > > source tarball. (but I understand if you don't like the idea).
> > I dont like that idea, but I can understand it. I think that would be
> > acceptable as long as the packages depending on java-common have the
> > right versioned depends.
>
>   I just committed the code into the java-common SVN[1]. This code *does
> not get installed for now*. I'd like people to review and tell what they
> think.
>
> [1]: http://svn.debian.org/viewsvn/pkg-java/trunk/java-common/wrappers/
>
>   I'll let this thread stew for a while, and when everyone is happy (if
> everyone is happy), I'll start thinking about uploading a new version of
> java-common.
>
>   Cheers !
>
> 	Vincent