Could it be possible that Sun's line of thinking might be release an unencumbered TCK to Apache for Java SE 7, when it finally becomes specified. This TCK would likely be built from the ground up to address the weaknesses in the TCK for Java SE 6. I would imagine from a cost perspective that Sun could say to ASF "Ok skip Java SE 6 and work on implementing Java SE 7 instead" A likely scenario, no?
On Apr 7, 5:12 pm, Jess Holle <je...@ptc.com> wrote: > JodaStephen wrote: > > So, the question is whether you, and the Java community in general, > > are willing to allow Sun to renege on their public commitments and > > break signed legal agreements without consequences. > > > Simply because Sun is in a parlous financial state isn't an excuse > > here. Much as it is appealing to conflate the two issues, it is > > important not to do so. > > Ah... So Sun can seemingly rightly be called a liar and run through the > mud for reneging on their commitments to the ASF. > > While that is a separate matter from their financial state, it is also a > separate matter from the openness of Java in my opinion. Sun can still > foster a rich open Java implementation community based on GPL despite a > black eye from reneging on commitments to one sub-community, ASF.> On the > broader question, I believe that having competition in the Java > > SE platform space is good for everyone. Or are we arguing that JBoss > > and Geronimo have no place as Java EE implementations given that > > Glassfish exists? I also note that Sun has taken code from Harmony > > that was performing faster than their own JDK code and reused it - > >http://blogs.sun.com/dagastine/entry/apache_harmony_thanks_for_the > > proving that competition benefits all. > > I'd generally agree, though I'd generally see more benefit as a consumer > of the various JDKs if everything started from the OpenJDK and then > deviated from it as necessary to better meet particular requirements. > [An exception would be something truly radically different like the > Maxine project, which seems like the way a JDK really ought to be > implemented rather than the C/C++ mess that exists today. Even there, > however, I'd think the Java code behind the implementation should > deviate only as necessary/compelling.] By starting from scratch Harmony > is pervasively inconsistent with Sun's implementation, which has been a > painful thing in our experience even in IBM's J9 which does pass the > TCK. IBM's Java 6 J9 is much less compatible with Sun's implementation > than in the past and many of the incompatibilities have traced directly > to them replacing Sun implementation classes with Harmony ones. > > > Finally, on the proprietary point, here is a quote with the official > > Apache position on why they believe that someone like IBM cannot use > > Harmony to sidestep paying Sun: > > > "Q : Does Apache think that Harmony could be used by commercial > > entities to avoid paying JCK licensing fees to Sun? > > A : No. The only way that could happen is if a commercial entity > > stopped shipping their own software and started shipping the > > tested binaries that were created by the Harmony project. > > Even then, they would still need to license the Java branding > > rights from Sun, as Apache does not pass those rights > > downstream to users or redistributors of our software. Note > > that if an entity made a derivative work, or used only part of > > Harmony's source code in building their implementation, they > > would still be obligated to obtain their own JCK license for, > > and test the software themselves. Apache does not make its > > TCKs available for use outside of our projects. > > " > >http://www.apache.org/jcp/sunopenletterfaq.html > > > As described above, it is in reality pretty impossible for IBM to use > > Harmony to 'steal' Java, as IBM could only use the binaries packaged > > and tested by Apache completely unaltered. > > Ah. That clarifies things. > > I wonder if the real issue here is that Sun's TCK is really too weak to > ensure adequate compatibility of a completely disparate implementations > and that Sun has only recently discovered that allowing implementations > that didn't start with their code and then deviate (and thus have many > of the same undocumented behaviors) to certify with it would allow an > unacceptable level of incompatibility. If so, my experience with J9 > would tend to suggest that the TCK is indeed too weak. Here Sun's > finances do again become relevant -- they can't afford massive > investment in the TCK or Java specification to add sufficient teeth to > ensure compatibility if sufficient teeth are not already present. > > -- > Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
