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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
