Discussions

News: Sun's unification with Harmony: what possibilities?

  1. In "Sun unification with Harmony unclear for now," by Stephen Shankland, Builder UK notes that it's "'hard to say' whether Sun's decision to release Java Standard Edition as open source software will mean a unification with Harmony." However, Harmony's license model and approach offers a unique opportunity for Sun to fix Java as well. One of the barriers to opening Sun's JVM is that some code is not internal to Sun, and therefore it's not within Sun's capability to change the license for it. However, Harmony has a mandate to use Apache-compatible licenses for all code, including the runtime library. Geir Magnusson Jr. has said Harmony's runtime will be "bug-compatible" with Sun's runtime, to preserve all behaviour, good and bad. If Sun were to switch the incompatibly-licensed runtime code to the code from Harmony, it would (by mandate) be compatible with the current runtime's behaviour, except the license would be open source. This would allow coders to fix the library's inefficiencies by using a true open source model. It would be critical to govern any API changes (and bug fixes) to continue to maintain compatibility, but the process for including such changes would already be in place, and both Sun and coders would have the benefit of a true open source license. What are the issues you see with this solution? It might eliminate Harmony as a separate project, but the unification would fulfill some of its goals, and might also give Sun a workable open source implementation of the code it doesn't have the right to open at this moment. However, despite the intent to be "bug-compatible," bugs might still creep in, both in actual errors (i.e., wrong results) and in the absence of errors (i.e., the Sun VM returns an incorrect result, but Harmony's runtime does not.)
  2. We're waiting for two different shoes to fall from Sun. One, is the license of the new code. And, two, is how they intend to manage the OpenJava community. Until both of these things happen, there's isn't a lot that can be done in the OSS Java community save push on as if nothing has happened. With specific regards to Harmony, if Sun GPLs Java, then Harmony continues on unfettered as the GPL isn't compliant with Apaches license nor world view. If Sun creates it community under a similar copyright sharing umbrella that it has with both OpenSolaris and Glassfish, then Harmony may simply continue to move ahead unfettered as a potentially "more friendly" environment for those who fear the copyright sharing issues with Sun. Mind, it's hard to see how anyone could with a straight face complain about sharing copyright with Sun and then going over to Apache's more liberal license. But, whatever. If Sun releases Java with an Apache friendly license, then Harmony could very well simply implode as the code bases unite. While there's much talk about forking Java, having two competing source bases, particularly if they're capable of sharing code (unlike, say, a GPL code base and Apache code base) seems like a REAL waste of time for everyone involved. The only reason to have more than one "legitimate" OSS Javas, would be to support the different license models. As was mentioned in the article, Harmony is not looking to improve Java, they're looking to duplicate it -- bugs and all. If Sun releases an Apache happy code base, well, Harmony can acheive its goals of duplicating Java with a simple: $ cd javasrc $ checkout java $ cp -R * ../harmony $ cd ../harmony $ checkin $ blog "Harmony now passes JDK 6 Compatability Tests!" As far as using the OSS model to fix Suns closed source bits that they use in Java, that's going to happen when they OSS the system long term anyway, Harmony or no.
  3. I was trying to stay out of this thread ;) but I don't grok a few things Will said :
    Mind, it's hard to see how anyone could with a straight face complain about sharing copyright with Sun and then going over to Apache's more liberal license. But, whatever.
    What does this mean? Copyright isn't shared with Apache - everyone is on equal footing with respect to what can be done with the collective work.
    As was mentioned in the article, Harmony is not looking to improve Java, they're looking to duplicate it -- bugs and all. If Sun releases an Apache happy code base, well, Harmony can acheive its goals of duplicating Java with a simple:
    $ cd javasrc
    $ checkout java
    $ cp -R * ../harmony
    $ cd ../harmony
    $ checkin
    $ blog "Harmony now passes JDK 6 Compatability Tests!"
    First, this isn't true - the only way you can say you pass the compatibility test is by... passing the compatibility test. Second, we are looking to make improvements, but not anything that would be considered disruptive to the compatibility promise of Java. For instance, we've modularized the class library in a very nice way, so that you can easily replace a component with a bugfix, or performance improvement, or whatever, and the changes are isolated. We're looking to do similar things in the VM, where the the GC or JIT can be swapped out easily for reasons of portability, research or performance. However, in both cases, these have no effect on the "javaness" of the JRE.
  4. With regards to the impact of an open source Java and Harmony, Geir Magnusson commented in an interview recently:
    The importance of building a real community was also echoed by Geir, saying that with Glassfish, "not all participants are on equal footing", contributions must have shared copyright with Sun. "I think this is a problem because I'm guessing Sun competitors won't be interested in helping Sun do that w/o opportunity for reciprocal gain. This is the level community what we set out to achieve in Harmony - namely a broad collaborating community of peers around Java - and it could be achieved by Sun too." What will the impact of an open source Java have on Harmony? "If it's open source and closed community - I'm guessing many in the Harmony community will continue to produce a compatible implementation, under a liberal license, by an open and inclusive community," Geir said.
    Sun execs on that link also said that they would very much like to see open source versions of their licensed binaries happen, although it could be tough (and pretty boring) to produce open source versions of font rasterizers. :)
  5. Actually I think two open source implementations would be good. Strictly compatible enforced via TCK. But with room for developers to compete on performance.