Re: JamaicaVM and GNU Classpath

[Andy Walter]

Hi Mark,

On Thursday 24 October 2002 18:03, Mark Wielaard wrote:

> On Wed, 2002-10-23 at 18:21, Andy Walter wrote:
> > [...] we are very interested in joining your project.
>
> That would be very nice!

I'm glad to see that we are welcome here.


> For license questions you will have to contact address@hidden since
> they can give you advice on legal issues.

Thank you for the pointer. I will contact them soon.


> The GNU Classpath license does
> indeed allow certain kinds of derived works that are not Free Software.
> This was done because we felt that in the end this would benefit
> users/developers the most since it would result in having more free
> software available. But we do prefer working with Free Software and we
> will certainly not promote proprietary closed source software.

No problem. I understand that you don't promote closed source software  and 
didn't expect that. We try to be as open as possible, i.e. we prefer standard 
interfaces to proprietary ones whereever possible. Maybe, the sources of our 
VM will one day be open as well but I don't expect this so soon. Even if you 
convinced me (what might not be that difficult) this would be not sufficient 
...

However, I managed to convince the rest of aicas that at least merging the API 
would be a great thing to everybody. I'm afraid more is not possible at the 
moment.


> So I would ask you kindly to only distribute you VM as free software.
> See for example Ada Core Technologies <http://www.gnat.com/> for an
> example of a commercial Free Software business. Or of course
> http://wonka.acunia.com/.

Of course, I know Acunia and that there are other open source VMs. They have 
different business models. There is a binary version for Linux on our 
homepage which is legally, but not functionally, restricted to 30 days. 
Currently, more is really not possible.


> > 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.
>
> I saw that Brian already send you the information on how to contribute
> (see also http://www.gnu.org/software/classpath/doc/hacking.html#SEC2)
> It would be nice if you have CVS access to integrate changes yourself
> since merging changes from others does sometimes take a long time since
> we have only that many developers.

Sure, this is the easiest way for everybody. We use our own repository here 
and intend to synchronize with the Classpath CVS about twice in a year.


> > 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.
>
> Very nice. What tests did you use?

You'll probably happy to read that our testsuite is based on Mauve. :-) 
We have added some tests and included a small script-driven framework for our 
nightly builds. Currently, we are not happy with the generated statistics 
yet, which are rather primitive at the moment. However, one of our employees, 
Denis Theinert, is assigned to improving this. The result should be a 
statistics that says "Test ABC, which ran perfectly the day before, failed 
last night" - and vice versa.

We didn't contact the Mauve developers so far, but as soon as our testsuite 
works the way we like it, we plan to contribute to Mauve as well.

However, we have not finished the integration of all Classpath packages. There 
are some slight problems with java.io. I'm sure we can handle this within a 
couple of days. I just wanted to contact you as soon as possible to see your 
reactions. If our legal guys do not agree (what I neither hope nor expect) we 
could easily switch back now without having wasted much work.


[...]

> The native libraries of libgcj are already much better being more
> platform-independent. Sadly we don't even have a plan on how to merge
> these libraries yet. (libgcj uses the CNI interface for most native code
> since JNI is much to slow for them).

The native interface is always a problem. JNI is probably slow on every Java 
Virtual Machine. We have our own (internal) interface as well which is much 
faster but not very nice to use, because the developer has to take care about 
too many things. Whenever possible, we prefer JNI. If performance becomes too 
poor, we probably rewrite some methods in JBI (our interface), but even in 
that case we'd continue to support the JNI methods, of course.


> > What do you think? Are we welcome?
>
> Sure. I look forward to working with you.

Great. So do I.


Kind regards,

        Andy.

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