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... Lets see: java -help will output something different beween almost all version. Let it be small changes in internal -X.. things or simple the -cp options, which is possible since sometimes back. Also, there isn't any guideline what for example '-classpath' includes. Is it with or without the core classes? > The alternatives system works fine for > sensible-editor, where you just specify a file on the sensible editor only has one thing to garantee: that sensible-editor file will open the file. The rest is interactive. /usr/bin/sendmail for example would be one app, which could be used as alternative (but for other reasons it cannot). awk has two implementors on debian. www-browser is again an interactive tool, which only garantees that 'www-browser http://adress/' work, nothing fancy as 'www-browser openURL(...)', which all the latest browser support. /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. > 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. > why Sun made the -X command line options, so that they > could implement wierd options without worrying about > breaking compatibility (because no-one relies on the > -Xmx flag, right? :). This could sensible be implemented: if your app has the ability to run with some allocated memmory: add it to the 'SERVER' line and be happy about it. Or I will add a '--mem128' and '--mem256' option to findjava, which is using a 'MEM128' field in the java-config files. > If findjava does stuff with apt-get or dpkg, then > perhaps it should be more of a debugging tool, rather Please do me a favour: try the tool and read the manpages, which are in the 'new-java-policy' package, which is available from deb http://www.katzien.de/debian/java ./ -> java-config-file(5) -> findjava(1) -> findjavarc(5) > than something that happens every time a Java program > is launched. Startup time for Java programs is > already a contentious issue, especially for servers. And thats why findjava was asked for. >> AFAIK: no. > 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. > I should > read the bug report and associated threads before > writing further emails. Please also read the manpages and the included policy (in /usr/share/doc/new-java-policy/policy.txt.gz) Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
