Re: Classpath & OpenJDK

[Dalibor Topic <dalibor.topic@xxxxxxxxxxxxxx>]

OneGuy schrieb:
> Hi,
>
> Since it was suggested on GCJ list to ask this question here, I will
> post it here.
>
> Is it possible for Classpath to use parts of code from OpenJDK? For
> example, there are performance probems with Classpath's regex package
> and StreamTokenizer. In cases like these, where OpenJDK has better
> implementation, why not copy and use the code that is better (30x
> faster in case of regex) ?
>   
It is possible, and you can merge them as much as you like, and publish 
merged versions yourself.
That's part of what the BrandWeg project by Andrew Hughes is about, and 
you're most welcome
to help out on it.

In FSF's case, we'd like to keep our code under GPLv2 or any later 
version, to allow the
Classpath project to be upgraded to GPLv3 or any later version by any 
user, while in
OpenJDK's case, we're on GPLv2 exclusively. The FSF is reluctant to add 
code to
GNU Classpath that would make an eventual upgrade to GPLv3 harder than 
necessary, as the
FSF strongly prefers GPLv3 to GPLv2. It's a policy issue, rather than a 
licensing issue, per se.
> Also, on a side note, why can't Classpath & OpenJDK merge? Both
> projects do the same thing
They could merge, it's just a lot of work to actually perform a manual, 
best of breed merge on two
such large, independently developped codebases, doing all the developers 
that have done the work
on them justice. When we merged Kaffe with Classpath, we eventually just 
ended up replacing large
chunks of Kaffe's code with Classpath's code, regardless whether it was 
technically better or worse,
simply to avoid having to maintain it ourselves. That worked, socially, 
because most of the developers
of the class library in Kaffe had by then moved on to other projects, 
and the next generation saw a clear
need to perform the merge. In Classpath's case, the need for a merge 
withing Classpath is offset by the
ability of VM authors to do any merge they want in their own projects, 
and adapt the VMs to work with
OpenJDK's class libraries, without having to adopt OpenJDK's policies, 
just like they don't have to adopt
FSF's policies. So we're currently seeing several different approaches 
being experimented with in different
VM projects, including OpenJDK, where Andrew is working on a stable VM 
interface to make plugging
different VMs into OpenJDK easier.

cheers,
dalibor topic