Re: GNU Classpath and JVMs

[Dalibor Topic]

theUser BL wrote:
> Hi!
>
> What me everytime wonder is, that GNU Classpath have not its own VM.

The FSF has gcj, actually. It is the 'GNU' runtime.

> To show the situation so, like I see it:
> Suns Java comes as a complete package, which includes the Classes _and_ 
> the JVM.
> Mono comes as a complete package, which includes the .net-classes and 
> the mono-runtime.
>
> Only with GNU Classpath it looks a little bit different.

That's the same as for the Linux kernel and GNU libc: one is an 
operating system core, the other one is a standard C library.

You can use the linux kernel with other C libraries, and you can use 
glibc with other kernels. They are, at the core, separate projects and 
separate tools for, I dare say, separate but often overlapping 
audiences, and nevertheless work very well together, and are both 
necessary for a distribution to deliver a GNU/Linux environment. ;)

BTW, Mono includes GNU Classpath as well, afair.

There are various projects that integrate various components into an 
equivalent of an out-of-the box environment for development and 
execution of applications useing GNU Classpath. java-gcj-compat does it 
around gcj, free-java-sdk in Debian does it around SableVM.

And of course, there is Kaffe, and probably other solutions I am not 
aware of yet.

> At first the developer changed the GNU Classpath code on any JVM, so 
> that is no longer compatible to the old one.
> So, when a new GNU Classpath version is released, there existing at 
> first, no JVMs on which it can run.

Yes. That's part of the necessity of being a work-in-progress, though: 
the VM interface is still in huge flux, and will be until GNU Classpath 
is finished. Since GNU Classpath is fortunately not tied to a single 
runtime, the VM interface is regularly improved upon to fix design 
decisions that cause problems on one runtime or another.

That obviously puts a price on some design decisions by the runtime 
developers: if they maintain their own copy of GNU Classpath, then they 
miss out on the latest features, but nothing breaks ;) If they go with 
CVS head, then they need to keep their VM up with the changes in the VM 
interface in close step. The simplest solution, afaict, is to go with 
the tested releases of GNU Classpath, and update your VM interface 
accordingly. That's what CACAO and JikesRVM do, afaik.

If that situation bothers you for a particular VM that you'd like to use 
with latest release of GNU Classpath, you can send patches to that VM 
development team and help that way. ;)

> or it (like JamVM), or it have problems with AWT and Swing (IKVM).
> And a CVS-version of Kaffe I have not tried. But Kaffe 1.1.5 don't run 
> Swing programs on my computer.

Kaffe's CVS version is up to GNU Classpath CVS HEAD of 2005-09-14, GNU 
intetlib HEAD, etc. I try to keep it largely in sync with all the major 
upstreams, every couple of days. If you have a specific bug report for 
Kaffe's CVS head, try getting in touch with the Kaffe mailing list. If 
it's not a Kaffe crash, or something like that, your bug report may be 
better filed in the GNU Classpath bug database, though, since most of 
the class library development takes place here.

> So I asked myself, what JVM does the GNU Classpath developer use?

Their own VMs CVS HEADS, or (a common favourite) JamVM (CVS HEAD). JamVM 
just got CVS access, btw, so you may want to give that a try, and hop on 
the respective mailing list.

> And I don't understand, why GNU Classpath comes not with its own JVM.

For the same reason why GNU libc does not come with its own operating 
system core: it is not necessary. (Or similarly: why doesn't the Linux 
kernel come with KDE?). The primary target group of such projects are 
not end users, but other developers and integrators, who in turn, then 
repackage, modify, integrate the code into environments that are more 
suitable for end-users. What you run on your desktop is usually a fair 
shot away from the latest CVS head of the respective project. And 
usually way more stable, too, because of the work that went into 
testing, and integrating it. ;)

As people involved in packaging efforts on systems like Fedora and 
Debian can probably elaborate for a while, that part is also lots of 
work. Separating the concerns and responsibilities here has proven to 
work well in practice, as the blooming GNU/Linux ecosystem shows.

That all being said, if you want to write your own VM, and make sure it 
is kept up to date with GNU Classpath releases, more power to you. Feel 
free to fork Kaffe anytime, if you don't want to start from scratch.

cheers,
dalibor topic