In message: <[EMAIL PROTECTED]> Jan Schulz <[EMAIL PROTECTED]> writes:
[a minor rant about how there's not much progress on Java in Debian] I don't anything particularly useful to reply to the points that Jan makes, largely because I've given up on Java per se as part of Debian. There's a very fundamental reason for this: Debian is about free software, and Java is not free. Don't get me wrong; free things can be made with Java, just as they can be with any other language... and once compiled (preferably to native code) they can be distributed just like any other free code. They have dependencies which need to be fulfilled to run (libraries, VMs, what have you), and those can also be handled in all the normal ways. We don't need a special policy for that. The only complication for Java really is in this odd idea that you should be able to run bytecode designed for one VM in a different VM... and that somehow we as designers of the Debian system ought to support this idea. Yes, I know that various vendors have hyped this idea a lot, but the various VM incompatibilities that have turned up in discussion reveal the relative unworkability of this idea. It's like asking code to work under Windows and Linux and AIX and MacOS 9 all at the same time... for simple stuff, it's no big deal, but as soon as you try to use any advanced features of any environment (like file-locking, perhaps), compatibility with the other environments pretty much vanishes (unless you have separate code for each environment, which is a maintenance nightmare). The whole reason we're even having this discussion is that people find it unpalatable to install multiple VMs because different packages that they've installed prefer different environments. After watching the arguments and learning of the difficulties, I just say "get over it". Guess what? If you have programs written in csh and bash and ksh, then you have to install multiple shells. The same is basically true of Java: if you have programs written for kaffe and for sablevm and for Sun's Java, then you have to install multiple VMs. Trying to convince programs to run in a non-preferred environment is just asking for pain. Java libraries are perhaps a sticking point; most people won't want to install a separate version of xerces or cryptix for each and every VM. However, once we dispense with this notion of trying to make programs run under any VM, then libraries can just be installed int some well known directory, and the programs can include all the appropriate things in their classpaths without difficulty. It's trying to make the classpath generation generic that complicates things. So no, I don't think we need the sorts of changes to the Java Policy that have been proposed. I think we ought to define a library location, specify that programs should have wrappers to invoke a package-preferred VM with a workable classpath, and leave the rest up to standard policy and dependency handling. If a package wants to support multiple VMs, that's fine... but the differences are great enough that I can't imagine any end-user packages actually doing so. This all wouldn't be an issue if the primary implementation (Sun's) was free software... then we wouldn't have any more difficulty than perl, as an example. But that's not the case for Java, and the fracturing of the execution environment that results from having multiple competing implementations makes it completely unrealistic to treat Java as a plug-and-play environment where the end user can pick and choose base components without affecting the things they put on top of it. - Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]