Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
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 ean@brainfood.com
Brainfood, Inc. http://www.brainfood.com
Reply to: