Re: Supporting multiple APIs simultaneously

[Andrew John Hughes]

On Fri, 2004-07-02 at 04:29, James Damour wrote:
> 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.

That sounds like a good choice of APIs to me, at least for the present.
1.1 is pretty much here with Classpath, AFAICS, so that should give a
working Java implementation, which looks better to users wanting to use
Classpath and distros wanting to ship it.  Most applets probably only
need this level of support, I'd imagine -- don't know if things have
changed recently.
1.4.2 would give us a Swing-based implementation and some of the
features in the current Java platform that Java developers will have got
used to over the last four years or so that 1.4 has been in use.  At the
moment, Swing, CORBA and javax.imageio seem to be the main gaps in
this.  Swing is being heavily worked on in the gcj branch, so
progression is going on there.
1.5 would allow us to track the new Java once its properly available,
and will be needed by anyone who uses the new language features.  A 1.5
branch of Classpath would not compile, as far as I can tell, without a
1.5 compiler, and code created against it would also need to be 1.5
compatible.
I think 1.0 long since stopped being a useful alternative.  For one, it
has a different event model, although this is still supported by current
Classpath and Sun's Java.  More interesting is that I went through the
list of 'problems' shown up by japitools for 1.0 yesterday.  As I have
it, only 1 problem is actually real and still exists in the current
version of Sun's Java, 1.4.2.  This is the presence of some fields in
java.awt.Font.  I may even be wrong here, as it may be that japitools
expects them both to be public, while they are in fact protected in
1.4.2.  I don't think they are present at all in Classpath.  At present,
that's the only true difference between Classpath and 1.0.  The rest are
no longer supported in current versions of Sun's Java.  I don't know
what the oldest version is you can get from their web site, but I've not
seen 1.0 being offered.  I think 1.0 support has been dropped by Sun,
and can safely be dropped by Classpath too.
There are some interesting issues with maintaining multiple branches. 
The main one would be that we need to make sure the choice of branches
remain current.  Not to confuse anyone, but I think you could probably
view the current selection in the same way as the three main Debian
branches.  1.1 is just about stable, and could be set for a release
status.  1.4.2 is still pretty much 'testing', but could form the basis
of a future release to eventually replace 1.1.  1.5 is undoubtably
unstable (in fact, its not even there yet, because it doesn't exist -- I
suppose experimental would have been the better choice).  One possible
solution is that we could rotate them in a similar way to Debian, unless
there's a reason we need to keep 1.1 support when we have 1.4.  1.1
support at present would actually result in a much smaller branch than
the current Classpath, because things such as Swing would be dropped
from this branch.  
As to maintenance, this could be a problem, but I imagine 1.1 won't need
much more than fixes backporting from the main 1.4 work.  We then
basically have a status where 1.1 is a stable release for users, 1.4 is
the centre of Classpath, with a varying combination of stability and
active work.  1.5 would distinctly only for people willing to hack the
code, at present.
The interesting point to remember is that Classpath is the upstream
provider to many JVMs.  Each JVM would need to choose which version of
Classpath it wants to use, or possibly offer alternatives.  I think that
should be left to them.  Of course, you do get the interesting situation
where a JVM with 1.4 language support could be using the stable 1.1
classes.
Anyway, those are some of my ideas.  It would be nice to hear other's
suggestions on this.  I do think we need a clearer road map than 1.1 and
some 1.2, with bits of 1.3 and 1.4.
-- 
Andrew :-)
 
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
 
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.

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