[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Classpath and JVMs
From: |
Dalibor Topic |
Subject: |
Re: GNU Classpath and JVMs |
Date: |
Thu, 15 Sep 2005 16:51:30 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) |
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
Re: GNU Classpath and JVMs,
Dalibor Topic <=
Re: GNU Classpath and JVMs, Meskauskas Audrius, 2005/09/15