Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

[Jan Schulz <jasc.usenet@gmx.de>]

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.

>> Sun [broke] an interface?
>They broke JDBC interfaces quite badly, for example, when they switched to the
>next JDBC version in java 1.4.

Oups, never used that. I just see all this depricated methods, which
seems to be depricated for ever :(

>> >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) 
 
>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?

Jan, never much bothered about lizensing...
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."