Re: Supporting multiple APIs simultaneously

[Andrew John Hughes]

On Fri, 2004-07-02 at 14:10, Dalibor Topic wrote:

> 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 ;)
> 
Well, my suggestion would be that the branches are more for the benefit
of users rather than developers.  Correct me if I'm wrong, but the
japitools comparisons suggest that 1.1 is just about supported.  This
would seem to be a solid base to give to those who want something to
work with, at least for the time being, as a Java replacement without
having to wonder about holes.  As far as developers go, I would expect
focus to mainly stay on 1.4 as it is now, with appropriate patches that
also cover 1.1 being added there.  However, if you think that would be
too much effort, then I can see your point to an extent.  I do think
there is something to be said for giving users something more stable
though, rather than the kind of random implementation guarantees we give
now.
More important I think is dealing with the upcoming 1.5.  Unless someone
tells me different, I'm guessing that code written for 1.4 API wouldn't
compile against a 1.5 Classpath, and, at present, not even with current
Free Java compilers.  So it needs to be separate.  Once 1.5 is stable,
we are likely to need support for this, possibly just to keep our
current support for some Java bases which may start using its features
-- Ant, Tomcat and Eclipse would come to mind there.  These all are
close to fully working with current Classpath and don't need the main
missing feature (Swing).  Without 1.5 support, my view is that we may
lose support for some server-side stuff which doesn't need the graphical
client stuff missing from 1.4.
> 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 ;)
> 
I'm tempted to go for the more realistic view that we just go for a
guarantee of full 1.1 support (or whatever we get to that level).  As to
how it reacts, it should probably mirror Sun's current Java via Mauve. 
The difference from what we have now is that we effectively say 'here is
the set of x.x APIs that are fully implemented and you can use.   If you
want more cutting edge than some of x.x+1's APIs are implemented in this
version.'  At present, we could aim for 1.1 for the first and 1.4 for
the other (or maybe 1.2 if we want to do this in smaller steps).  These
would no doubt move as the Java community and our level of
implementation changes.
> cheers,
> dalibor topic
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
-- 
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