Will Webstart be integrated in OpenJDK?
Geir Magnusson Jr.
geir at pobox.com
Thu Sep 11 03:57:15 PDT 2008
The lack of a free/open/public TCK for JDK 6 is simply a business
decision on Sun's part.
There's no other reason it can't be done right now, rather than have
to wait for the as-yet-not-a-JSR Java7 (see : decision, business) to
not only get started, but wait 18-24 months to complete.
On Sep 11, 2008, at 6:18 AM, Mark Wielaard wrote:
> On Thu, 2008-09-11 at 10:24 +0100, Andrew Haley wrote:
>> Andrew John Hughes wrote:
>>> The biggest problem at the moment is the JCK. I'm quite happy for
>>> Sun to use this to certify their own mashed-up proprietary/Free
>>> builds inside Sun labs, and equally it's been great to see this
>>> applied to a purely Free build by Red Hat. However, what disturbed
>>> me recently was seeing this used as a tool for patch approval during
>>> the AWT/Swing/Java2D discussion Mario mentions.
>> Why not? A gcc patch that failed Plum Hall testing would be rejected
>> too, assuming (or course) that the Plum Hall test was valid.
> I couldn't find any recent examples of Plum Hall testing against gcc
> patch reviews and rejection of patches because of them. But I am
> sure the submitter isn't responsible for getting a license agreement
> with Plum Hall for contributing to GCC.
> The problem with the TCK is precisely that you need to enter an NDA
> agreement with Sun over it and that there is no public discussion
> the validity of the tests. Publicly it isn't even know which patches
> went in because they made a TCK test pass or because they just
> invalidated a TCK test and got it added to the exception lists.
> The problem with the current NDA TCK setup is that that you cannot
> tests and code snippets from it with the rest of the community, your
> users and customers. You either end up rewriting the tests so you can
> publicly share it with others on the mailinglists. Or you have to say
> "just trust me, the TCK tests for this particular corner case in this
> particular way, so this patch is necessary even though I cannot really
> proof it". Neither is really satisfactory. But I would opt for the
> rewriting the tests so we have a free replacement.
>>> A Free project being dependent on a proprietary test suite for
>>> patches is just as bad as it being dependent on proprietary tools to
>>> build. As Mark mentioned in reply to this, we should work towards
>>> improving jtreg and Mauve to ensure a Free test suite is available
>>> and not rely on the JCK.
>> It's not going to happen. The TCK tests a whole lot of minute
>> of Java langauge compatibility that are not fully explained in the
>> Javadoc, and so any open test suite that does not derive from the TCK
>> will not be complete.
> That could be true, but if so, it is even more important to get this
> issue resoled and get a free replacement. It clearly points out a
> deficiency in our current documentation that you are unable to tell
> them what the details of a particular method or class really are.
> I think having a free TCK should be one of the goals for JDK7 at
More information about the discuss