Andrew John Hughes <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
