[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
JamaicaVM and GNU Classpath
From: |
Andy Walter |
Subject: |
JamaicaVM and GNU Classpath |
Date: |
Wed, 23 Oct 2002 18:21:49 +0200 |
Hello Classpath-Developers,
at aicas GmbH (http://www.aicas.com), we are developing a Java Virtual
Machine, JamaicaVM, that comes with its own (clean room) implementation of
the standard classes. Since this is redundant work (and, as I understand it,
exactely the reason why the GNU Classpath project started), we are very
interested in joining your project.
Our VM is currently "closed source" as well as commercial. As far as I
understand the Classpath license agreement, this would not be a problem to
you. I'd appreciate if we were welcome to join you and think that everybody
could benefit.
The easiest way would be if we could get write access to the repository, so
that we can provide code and bug fixes directly. (Of course, we intend to
give something back Classpath). Providing the code to a maintainer would be
okay for us, too.
In our developer branch, we replaced our own Java API (expect from java.lang
and java.awt*) by GNU Classpath, to see whether there are any unexpected
problems. The result looks quite good: We didn't encounter much problems and
in Classpath, much more packages are implemented. The only disadvantage is,
that with GNU Classpath, JamaicaVM needs more memory and seems to be somewhat
slower. Since JamaicaVM is designed for realtime systems, which are typically
rather small, embedded systems with weak CPUs, I would expect that we can
provide optimizations here.
Another thing that might be interesting for you is that JamaicaVM is easily
portable to a variously number of platforms. Currently, it is available on
Linux, Solaris, VxWorks, QNX, embOS and Euros. We are working on a NetOS
version and RTEMS is probably coming soon. Some of those systems are somewhat
different from ordinary Unices. For the Classpath project, compatibility with
those systems was obviously not an issue. Since we need to do this anyway,
we'd volunteer to write a platform-independent layer for accessing the
operating system. (If you don't like this for some reason, no problem. In
that case, we would only use the Java code from a common repository and
continue with our own native code).
What do you think? Are we welcome?
Kind regards from Karlsruhe,
Andy.
* One thing that shouldn't be unmentioned: Unlike the rest of our current
standard classes, the AWT implementation is not completely written by
ourselves, but based on Acunia's Wonka/Rudolph.
--
aicas GmbH * Hoepfner Burg /"\ ASCII Ribbon Campaign
Haid-und-Neu-Straße 18 * 76131 Karlsruhe \ / No HTML or RTF in mail
http://www.aicas.com X No MS-Word in mail
Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards