Will Webstart be integrated in OpenJDK?

[Geir Magnusson Jr.]

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.

geir


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  
> pretty
> 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  
> about
> 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  
> share
> 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  
>> details
>> 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  
> TCK
> issue resoled and get a free replacement. It clearly points out a
> deficiency in our current documentation that you are unable to tell  
> from
> 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  
> least.
>
> Cheers,
>
> Mark
>