Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> I will still ask, that all 'java' alteratives (kaffe, gcj, etc) will
> >> add as much API to their bootclasspath as possible.
> >I can only speak for kaffe, but we are gradually trying to merge in as much
> of
> >the free, GPL-compatible implementations of java APIs that are out there, as
> >possible. After the recent RMI update to Classpath's more recent version,
> the
> >next goal is to merge in an ORB to implement the CORBA APIs, and to pull in
> >rxtx for javax.comm.
>
> So what will happen if we want to have all this classes shared between
> other fre JVM? Say kaffe and gcj Depends: classpath, ... Will that
> actually work? If yes, on packager level, we can solve this already
> now.
I assume that those VM's using GNU classpath can share a significant bit or
their rt.jars. But there is all those little internal classes with native
methods that need to be different (like reflection, class loading, references,
etc.), so you can't just share everything, unless you split the rt.jars into a
'common GNU classpath rt.jar' and a 'VM specific GNU classpath rt.jar'. Package
sealing may interfer with that, although I doubt any GNU Classpath based VM
actually uses a crypto signed and sealed rt.jar.
In any case, you'd end up doing a lot of work, with little practical value.
Just like many jakarta apps come with tons of differently versioned binary jars
in their libraries directories, free VMs come with different, and adapted
versions of GNU Classpath that suit their needs best.
> >> >You can also "java-compatible-with-jdk1.3" but no Free JVM
> >> >are likely to satisfy such a constraint anytime soon.
> >There is no full free software javax.swing implementation yet, nowhere.
> there
> >is no javax.imageio and javax.print. We're trying to get the rest covered by
>
> So, basicly, these packages are the problems? If thats the only problem, we
> could make
> java2-runtime-1.4
> -> if all but this is present on the bootclasspath
> -> alternative for /usr/bin/java-less-1.4
> java2-full-1.4/java2-unfree-1.4
> -> if this three are on the bootclasspath
> -> alternative for /usr/bin/java-full-1.4
> (better names welcome)
Uh, I don't think it's an elegant approach. It encourages people to regularly
flame each other on debian-java whether package java.x.y is important enough to
be a requirement for letting a VM provide java2-runtime-1.z, or their VM would
be blocked from being a 'debian-blessed' java2 runtime.
> >merging in other people's great GPL-compatible work into kaffe. javax.crypto
> is
> >going to be problematic because of american ammunnition export laws, I
> guess.
>
> Isn't that foolishing over?
Don't know, IANAL nor am I a javax.crypto hacker. ;)
> Jan, never much bothered about lizensing...
you should. it's very rewarding and fun ;)
your 'mix-and-match' bootclasspath has some serious licensing implications. For
example, if I take a LGPL-d javax.something implementation, and add in a
GPL+linking exception licensed javax.something.else to my bootclasspath, the
resulting application needs to be licensed under the GPL, as the lowest common
license, AFAIK. It works for kaffe, since kaffe is GPL and we make sure that we
only merge in GPL-compatible code, but an ad hoc 'let me quickly add this
missing package to my bootclasspath for some application' approach could cause
some trouble.
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: