Re: Supporting multiple APIs simultaneously

[Dalibor Topic]

James Damour wrote:
> 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.

Given that Classpath doesn't implement any JDK API release fully, afaik, 
i think it's a little illusionary to demand that it fully supports three 
of them, given the current man-power of the project :) We are talking 
about a few thousand classes times the number of supported platforms 
here. Chances are, that by the time Classpath has the few hundred 
regular contributors to pull that off, Java Super-XP-2010 will be out ;)

The problem doesn't lie in the APIs, it lies in the semantical changes 
that happened between JDK releases. for example, class loading is very 
different between 1.1, 1.2, 1.3 and 1.4. Each release changed it, added 
new ways to load classes, or new locations to load class from (Jars, 
extensions, ...).

Another fine example is security, which essentially gets thrown out of 
the window and rewritten with each JDK release. :)

You could solve the 'i want to have just the 1.x API' issue, by writing 
a tool that uses japtiools files to implement a set of JDK 1.x 'facade' 
classes that delegate to classpath classes for the real work. It 
wouldn't give you much, since the documented semantics of core classes 
tend to change more or (usually) less with each release, so you'd have 
to essentially fork all those classes where you want the semantics 
pinned down to 1.x interpretation. Not a lot of fun for a single person ;)

cheers,
dalibor topic