classpath
[Top][All Lists]
Advanced

[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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]