Supporting multiple APIs simultaneously

[James Damour]

Andrew John Hughes <address@hidden> raised an interesting
point.  What set of Java APIs is Classpath targeting?  *Can* it target
multiple APIs simultaneously?  How much effort are we willing to expend
to support the multiple APIs.

I'm tainted by Sun source code, so I can't contribute to the efforts of
supporting the multiple APIs, but if I may be allowed to suggest a
solution that someone else will have to implement, then I have an idea.

Why not just have multiple branches in CVS?  OK, so it would be better
if we could have a single trunk, and maintain trees of patchsets to that
trunk (kind of like the way the Linux kernel hackers handle things), but
GNU Arch isn't quite ready to handle the task, and I don't see any other
Free Software SCM that can adequately handle the job, so we're left with
having multiple "production" branches.  Still, with a decent automated
testsuites like Mauve and Wonka, shouldn't we be able to have them all
moving in the same direction at the same time?

Maybe we shouldn't try to maintain *every* API set that Sun put forth,
but just selected ones.  I would suggest v1.1, 1.4.2 and 1.5.  IMHO, 1.0
APIs are missing too many important classes to be worth supporting. 
Because of the legal battles v1.1 is arguably the most
widely-distributed JVM today. The v1.2 and v1.3 APIs don't really buy us
anything that a partial implementation of v1.4.2 doesn't also give us,
but if we decide to support v1.4.2 for a "long time", then it gives
application developers a stable environment to code for.  We could also
constantly chase whatever set of Java APIs are "current" at any given
time, in case an application developer needs to have the bleeding edge,
and is willing to put up with a perpetual work in progress.
-- 
James Damour (Suvarov454) <address@hidden>

signature.asc
Description: This is a digitally signed message part