Re: findjava is the question, is fixjava the answer?
Hi Jan, hello Ricky,
Jan Schulz wrote:
Hello Ricky,
Wednesday, October 8, 2003, 5:56:22 PM, you wrote:
Well, if the Debian Java policy were modified so that
the command line were rigorously defined (basically
take the output of java -help from the Sun JVM or
elsewhere)
I'm waiting for the screams...
/me screams: not the same discussion again! ;)
it's been a few weeks of hard work (and fun) to convince Jan to drop too
simplifying approaches (like 'why don't we make a debian policy what
java command line options should be') from the java policy proposals,
and work out something more flexible, which is his findjava scheme.
the bottom line is: sun doesn't care about debian. No matter what debian
decides, even if it's based on java 1.4.2, it won't prevent Sun from
breaking that 'interface' in, say, 1.5. They have a history of
inconsistency both with the synopsis and the semantics of their java
command's options between the releases. And even if one agrees on a
policy that would necessarily have to specify some command line options
that are not in some release of JDK, debian wouldn't be allowed to
distribute the modified source of the java script, AFAIK, so we would be
back to square one in 6 months.
And that's just the problems with Sun's implementation, I could go on
ranting about others for a while, too. But just read the thread ;)
The alternatives system works fine for
sensible-editor, where you just specify a file on the
/usr/bin/java has to garantee even much more: that the commandlien
interface is the same all over, that the JVM is able to run *all*
code, which is thrown at it. OYu can't do that with the variety of
JVMs, which are available on debian. For example all free JVMs lack
the ability to run swing code or (AFAIR) the java-1.4 NIO code.
Exactly. There is huge difference between managing application that 'do
one specific thing' and managing a java runtime. You can't guerantee
that a piece of code you supply to /usr/bin/java will also run on it. In
part because of the incomplete state the free VMs are in, but in part
also because of the miserable quality of code in some applications, that
depend on a particular undocumented mis-feature of some specific version
of Sun's offer to run, despite Sun telling people to program to the API.
Currently, for example, the Xerces-J team has got a bug filed in their
apache bugtracking system, with a ton of duplicate bug entries, because
someone checked in some code that depends on an undocumented feature of
some sun.* class to look up something about Character Encodings.
Unfortunately, the Xerces J developers don't want to lose that 'feature'
so the miserable code will stay in, preventing the next release of
Xerces-J from being buildable on any free VM. Of course they could also
use ICU4J, or ICU4JNI, or java.nio from java 1.4, but the responsible
developers seem to want to have the feature on all platforms, which for
them means using undocumented classes from Sun, that even Sun tells them
to avoid. And of course it's far from running on all platforms. ;)
Read the threads for more examples of 'unportable java code' in other
projects. ;)
I don't see why sensible-java, or just 'java' couldn't
have a standard interface, with things like java
-classpath BLAH -bootclasspath BLAH etc. Isn't that
Becuas ethe altwernative system could garantee the 'backend', like
core classes and so on.
Things like -bootclasspath are only used by broken by design
applications, anyway. It's -X*bootclasspath nowadays with Sun's VM, and
it's there for a single reason: debugging. Applications have no
buisiness replacing classes from the core libraries.
This seems to negate some of the reasons you gave,
other than 'a future VM might not do this'.
All of them try, but there is no 'official' interface and there
isn't any way to be *sure*, that this stays the 'standard interface
of sun JVMs'. I would also be happy, if I could say: here, java has
to take this arguments and it must resultin this-and-that. But this
will be *really* confusing, when future sun java versions changes
this interface.
And they have a long record of doing so in the past. Beside, that
doesn't buy you much, except knowing how to pass a few arguments around.
Most of time, when an application doesn't run, it's not because someone
forgot to set -Xmx128M, but because some amateur programmer checked in
some code that uses sun.* classes, and sun changed their internals in
the meantime.
cheers,
dalibor topic
Reply to: