Re: [PROPOSAL] 4. RfD for a new debian java policy
Hallo Ben,
* Ben Burton wrote:
>> >> and will let the user choose one default VM, which will be used,
>> >> when it is include in your list of 'known working VMs'.
>Not necessarily, just an understanding of what you mean. I'm still
>uncomfortable with using a hand-rolled system here where we have debian
>alternatives for everything else.
Not again :)
>If all you want is for the user to specify a "default JVM", then why not
>just let this default JVM be the alternative /usr/bin/java, just like it
>is now? [...]
IMO the alternative system can only be used in two cases:
* when all apps for the alternative are similar enough to not cause
any damage in scripts (-> awk, sendmail)
* when the alternative is uses interactivly (-> editor)
IMO java doesn't fit this requirements. In your 'way', you follow the
symlink (just curious: how? I usually do that with repeated 'ls
calles...), so effectivly doing nothing else than having a java-config
file and looking that up. You also need to maintain all java locations
(which can change) instead of package names. And IMO a app should
fail, if something will not work and it should fail with a reasonable
error message (like 'No working java found') and not with
'ClassNotFoundException' or similar.
I had a few bugreports and I've seen this problems a lot in the
eclipse.ALL newsgroups:
jan@snoopy:~$ eclipse -consolelog -vm /usr/bin/gij-3.3
Including user settings ~/.eclipse/eclipserc...
Using /home/jan/workspace for workspace
Using /usr/bin/gij-3.3 as java virtual machine...
gij: unrecognized option -- -Xmx256M'
Try gij --help' for more information.
[... This option is in my $HOME/.eclipse/eclipserc ...]
jan@snoopy:/$ eclipse -consolelog -vm /usr/bin/gij-3.3 -vmargs
Including user settings ~/.eclipse/eclipserc...
Using /home/jan/workspace for workspace
Using /usr/bin/gij-3.3 as java virtual machine...
!ENTRY org.eclipse.core.runtime 4 2 Sep 17, 2003 12:01:04.825
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.runtime".
!STACK 0
java.lang.VerifyError: verification failed at PC 577 in
org.eclipse.core.internal.resources.Resource:move((Lorg.eclipse.core.runtime.IPath;ILorg.eclipse.core.runtime.IProgressMonitor;)V):
incompatible type on stack
at _Jv_BytecodeVerifier.verify_fail(byte, int)
(/usr/lib/libgcj.so.4.0.0)
at _Jv_BytecodeVerifier.verify_instructions_0()
(/usr/lib/libgcj.so.4.0.0)
at _Jv_VerifyMethod(_Jv_InterpMethod) (/usr/lib/libgcj.so.4.0.0)
at _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.4.0.0)
[...splash screen and then death...]
jan@snoopy:/$ eclipse -consolelog -vm /usr/bin/kaffe
Including user settings ~/.eclipse/eclipserc...
Using /home/jan/workspace for workspace
Using /usr/bin/kaffe as java virtual machine...
kaffe-bin: utf8const.c:394: utf8ConstInit: Assertion hashTable !=
((void *)0)' failed.
/usr/bin/eclipse: line 79: 26044 Segmentation fault $ECLIPSE
-showsplash "$SPLASH_PARAM" $OPTIONS
[...]
jan@snoopy:~$ eclipse -consolelog -vm /usr/bin/kaffe -vmargs
Including user settings ~/.eclipse/eclipserc...
Using /home/jan/workspace for workspace
Using /usr/bin/kaffe as java virtual machine...
[... a *lot* of exceptions, my Konsole window just scrolled down, but
at least a window came up. No working perspective, though, so
eclipse wasn't useable...]
jan@snoopy:~$ eclipse -consolelog -vm /usr/bin/sablevm -vmargs
Including user settings ~/.eclipse/eclipserc...
Using /home/jan/workspace for workspace
Using /usr/bin/sablevm as java virtual machine...
SableVM version 1.0.9
[...]
java.lang.ClassNotFoundException: /usr/share/eclipse/startup.jar
at
gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
at java.lang.VirtualMachine.main(VirtualMachine.java:79)
[...]
[some other attempts, but it seems that sableVM does not even check
CLASSPATH :( Changing the eclipse start line to --classpath=".." just
fails without *any* reason. How nice.]
>[4 level if clause]
this code will be duplicated in every java package. When I would see
that in java code, the first thing I would do is refactoring the code
and put that into a common place. This is what we are doing with the
findjava code.
>This has all the properties that we want - the list of known JVMs is
>honoured, the user can specify a JVM for this run only, and the user can
>set a default JVM as /usr/bin/java which is only used by default if it's
>known to work. At yet it's still consistent with the general debian
>structure and so there's less for sysadmins to learn (because let's face
>it, people rarely read documentation until something actually breaks).
My points against this:
* User specific JVM will still require some work (env variable?)
* In x% (depends on the VM, which is setup as 'java') of the cases, the
'lookup' will come up with a 'not working' VM -> wasted.
* The fallback will result in unrecognised error messages (see above)
* The code will be duplicated in every package and it will be a lot of
code -> perfect for a refactoring
* a level of abstraction beween /usr/lib/something/bin/java and
the starter code (-> package name). The package can rely on the
package name, the binary location can change or can be replaced with
a different version (1.4 -> 1.3)
Pro:
* Uses the alternative system, but only as a last step (the second is
IMO 'working around' the alternative system)
IMO the whole discusion has showed that that the alternative system
isn't reliable enough for this case.
IMO it's a similar situation with bash and sh: /bin/sh is only used
when you made sure that this is *really* code sh understands and all
other alternatives are (at least AFAIK) a superset of /bin/sh. -> if
you write 'sh-code', everyone undertsands.
We can't do that with java code, as the differences between the VMs
are to much and we can't agree on a 'common features' set which all
VMs understand. Also this feature set would be *much* too small to run
any java app in debian...
>> I'm not happy with the words though, they sound really
>> 'constructed' to me :/
>Don't worry about that - I'm happy to put technical correctness
>ahead of sparking English wordplay,
Maybe I sould crosspost that to the i-something-english ML :)
>at least for starters. :)
I have hoped that we were over the 'starters'. This last proposal
hasn't generated much heat and I hope that I have the findjava script
ready and will post it together with some test data. I hope that I will
be able to put that all into a bugreport and we can go on from there...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: