Your proposal has merit but I don't think it goes far enough to really solve the problem. At the center of the issue is the fact that Java has grown so large that depending on a Sun Java release version is like depending on Sun Solaris 2.6 because of some POSIX feature. To achieve something usable we need a dependency scheme that isolates the various functional components of the VMs. This will allow packages to require only those VM features which they actually need rather than a single monolithic kernel revision.
Kaffe, for instance, provides a hodge podge of support for various VM revisions ranging from 1.1 to 1.4. If you need something like weak references or proxies it might be there but if you need swing it won't be. Some of NIO might be available but 1.4 security contexts may be non-existant. Therefore, I imagine something more like: Kaffe 1.1.1 provides: java.awt1.1 java.io1.3 java.lang.persist1.2 java.net1.2 java.net.rmi1.3 Then you may have: Jetty 4.2 depends: java.net1.2 javax.servlet2.2 and so forth... or alternatively you could use something more symbolic than version numbers. For instance: depends: java.lang.reflect.Proxy java.text.Bidi.reorderVisually java.io.ObjectOutputStream.useProtocolVersion.int This would allow a package to express dependencies down to the exact critical facility. Some might think it better to use a more compact form like "java-objectstream-byversion" but I think using the existing semantics is more elegant and less prone to error. The real task will be determining how fine grained a dependency we will allow. I would say it should be handled on a case by case basis. Before anyone freaks on how much work this might be for VM maintainers keep in mind that we may be able to leverage a tool like the mauve test suite to generate dependency information automatically. This granular dependency system would allow far more packages to either work or not work sensibly with Kaffe. I imagine other VMs would benefit as well. The risk is that such fine grained micropackaging could turn apt into some kind of run time autoconf. On the other hand that may be exactly the perfect solution to the Java problem. E On Mon, 2003-08-25 at 17:53, Jan Schulz wrote: > This is a draft for a Proposel to rearange most parts of the debian > java policy. Most of the things have been discusssed in the last > weeks and I hope I was able to get the main points into this draft. [SNIP] > Thanks for going through this :) -- _____________________________________________________________________ Ean Schuessler [EMAIL PROTECTED] Brainfood, Inc. http://www.brainfood.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
