Hallo Ean,
* Ean Schuessler wrote:
>For instance, I can now set JAVA_HOME on my machine to /usr/lib/kaffe
>and run the standard startup scripts for Catalina, JBoss or OFBiz and
>they will make a real attempt to run. Of course, there are still
>shortfalls in the base class libraries but that is a different problem.
But they *wont* run. It's not the problem about java.home or not. The
problem is, that you can't use the alternative system to get the JVM.
Apps rely on: JAVA_HOME set, so that:
* they can get $JAVA_HOME/bin/java (lost of bootstrap scripts)
* Using java.home/bin/something to do some work (ant)
Thats why I have put this special cases, which I found usefull in the
light of debian packaging (-> running and building) into the proposal.
The new policy will require that there is a bin/java script and, if
the package includes a 'ant-environment', includes and bin/javadoc. It
also needs to set the build.compiler.
This will allow us to use this as JVM and compile environment. It
still needs. in some cases, some logic in the scripts to make up for
the different implementations.
This is IMO still better than taking the pain to make up a policy,
which tells everybody, that bin/java should accept '-classpath' and
how to deal with it or which '-X...' switches should be present.
As I already said, this isn't the main problem with a alternative
managed JVM. The big problem there is the difference between different
implementations: /usr/bin/java means that I can't know, what is
actually implemented in this VM. Are the XML APIs present, is
javax.swing.*.Spinner included? 'assert' or java NIO?
Even if you add versioned bin/java-version *only* for the
'sun-derived' VMs, you end up with one java for each version (sun java
1.4.*2* AFAIK introduced some new classes), as the discussion up to
the 4th proposal showed.
>non-standard. The /usr/lib/sablevm/jre/bin/java script should do
>whatever is necessary to adapt the "standard" Java commandline options
>to SableVM's.
Please note, that there isn't any 'standard java commandline option'.
Take for example the '-cp' option for javac. This should be
implemented in the latest sun JVM. It isn't anywhere else. There are
breaking changes inbetween versions. Which version do you want to
implement in the policy?
>It seems to me that findjava is trying to merge all of the VM adapter
>scripts into a single large script. That looks broken to me both in
>terms of introducing unnecessary dependencies and creating maintenance
>headaches for all of the VM maintainers.
Please have a look at the discription, which I posted somewhere in
this list. It describes *what* findjava does (its also in the source
of findjava in a big comment on the top). There are also some posts,
*why* it does this. In short, it makes it posisible to use different
VMs and let the user interact with that.
There are two different levels of interaction: 'Overwrite' and
'prefered'. Overwrite will make findjava *always* return one JVM. This
is for testing, or if one wants to use a VM outside of the packaging
system. Prefered will let you specifiy one VM, which should be used,
if the package maintainer of the app has already tested this VM and
found it acceptable to run the app.
Another pro (IMO) is, that you have to deal with package names and not
with binary names. This will make it possible to change path in case
of upstream renaming (like /usr/lib/kaffe -> /usr/lib/kaffe1.2)
without rendering all other packages unusable.
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
