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 [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
