[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JamaicaVM and GNU Classpath
From: |
Brian Jones |
Subject: |
Re: JamaicaVM and GNU Classpath |
Date: |
23 Oct 2002 20:53:27 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Andy Walter <address@hidden> writes:
> 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.
We're rather free with the CVS access.
> 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.
We haven't spent a great deal of time optimizing the library for speed
or memory usage. By chance do you also have support for the JPDA?
> 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).
A platfom independent layer, call it a library, to abstract away
socket and file i/o and other needed system calls has been on my todo
list for a while. I'd actually prefer to use NSPR or APR for this
purpose but I think they do more than Classpath needs and they also
complicate the licensing issue.
> What do you think? Are we welcome?
Yes, you're definitely welcome. I'll send you a separate email off
the list to get the ball rolling.
--
Brian Jones <address@hidden>