Since there is no pilot program for Sun’s implementation, there is nothing in the works of that sort. Sun would first try to build up a community around the code base, before they push it out in the open. It would be pointless for Sun to say they’d open up anything but their Java implementation, and then spend their resources doing it the other way round, wasting the positive PR effect.Į) Community. That takes time, as one can see with OpenSolaris: work on opening all of Solaris up started a few years ago, and is not finished yet, afaik. Just like with Open Solaris, Sun would have to undergo a lengthy, costly process of securing relicensing rights/copyrights to each line of code it does not hold copyrights or relicensing rights to. Sun’s implementation contains more than three million lines of source code, according to Slava Pestov’s blog. The real, licensing-cash-worthy value for Sun is in the brand, not in a particular implementation they give away gratis.ĭ) Legal. Making any release based on community patches would either require extensive compatibility testing, or, if Sun deliberately released untested, possibly incompatible implementations, dillute the Java brand’s positive connotations. It’s unlikely that Sun would want or be able to accept community patches for an old release, due to the way the Java trademark is tied with compatiblity requirements. But otoh, supporting people building and hacking on an old release would take away momentum from the new release, and simply cost money for the support engineers that Sun would probably rather invest into supporting their 1.6 release.Ĭ) Nowhere to go with patches. I’ve watched people struggle majorly on Mustang forums to build Sun’s 1.6 betas at all, and I doubt Sun could just push out the source they have for 1.5 with anyone outside Sun being able to build it without massively cleaning it up. ![]() Sun could not just open up their former crown jewels and let them bitrot in public without earning some bad press. Opening up an older version would take away momentum from that.ī) Support. In 2006, Sun Microsystems will be interested in migrating their customers to the next release of their implementation. While it is indeed correct (and great, in my opinion) that Sun Microsystem is committed to making all of their software available gratis or under open source licenses, all public comments by Sun’s management have made clear that Sun’s implementation of the J2SE specifications falls into the gratis part of that, and not at all into the open source one.Īs for Sun relicensing their implementation on Java 1.5, that’s very unlikely for a few reasons:Ī) Marketing. Unfortunately, Sun has currently no plans to release any version of their virtual machine or core class libraries under an open source license, to my best knowledge. and of course, there is #classpath on for the first hand information. If you are using an API extensively, and find bugs, please do not hesitate to feed the bug tracker, or to submit patches of your own making, but make sure to read the documentation. ![]() The GNU Classpath project dearly appreciates patches to improve the implementation. Free Software development works that way, and I personally prefer to see a class gradually growing better and better in the CVS tree, over classes being dumped finished into the tree. Ocassionally, development starts out with a stub, and gets fleshed out as the implementation of a class improves, but that’s usually only the case for hot & fresh development areas, like currently some parts of swing are. Regular visitors to know the success stories already, though. The only freely available verifiable measures of compatibility with proprietary implementations, like the Mauve test suite, and test suites of free software applications like JOnAS, do indicate that the compatiblity with proprietary implementations is getting better all the time, though, and the experiences from packaging applications and libraries written in the Java programming language are increasingly positive. Without running the official compatibility test suite, it would be hard to make an exact claim of relative compatibility, and noone working on GNU Classpath has access to such a test suite yet, afaik. The 98% above translates into the total number of symbols (packages, classes, interfaces, methods, fields) implemented, and not into a statement of relative compatiblity to some proprietary implementation. Indeed, some things still are stubs, and the code has its own share of FIXMEs in places.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |