Hallo Jan, --- Jan Schulz <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]