Will Webstart be integrated in OpenJDK?

[Clemens Eisserer]

Hello,

Jdk-collaboration seems quite dead now, but I have a patch which has
not been looked for some time, and I would prefer of course to
contribute that patch under the OpenJDK umbrella.
Are there plans to open-source Webstart too?

Thank you in advance, Clemens

[Mark Wielaard]

Hi Clemens,

On Wed, 2008-09-10 at 21:32 +0200, Clemens Eisserer wrote:
> Are there plans to open-source Webstart too?

IcedTea contains a free software webstart implementation that provides
you a javaws binary. Look under rt/net. It is based on NetX and
distributed under the GPL of course.

Cheers,

Mark

[Mario Torre-2]

Il giorno mer, 10/09/2008 alle 21.32 +0200, Clemens Eisserer ha scritto:
> Hello,
>
> Jdk-collaboration seems quite dead now, but I have a patch which has
> not been looked for some time, and I would prefer of course to
> contribute that patch under the OpenJDK umbrella.
> Are there plans to open-source Webstart too?
>
> Thank you in advance, Clemens

Hi Clemens!

I don't think that "jdk-collaboration seems quite dead now", we are even
talking about making a public API change for our peer project on the
awt/swing/java2d lists :)

Please, give a look at icedtea, surely the patch will go in there and
after that it will be easier make it land into openjdk.

Cheers,
Mario

[Dalibor Topic-5]

Mario Torre wrote:
> I don't think that "jdk-collaboration seems quite dead now", we are even
> talking about making a public API change for our peer project on the
> awt/swing/java2d lists :)
>  
I'm pretty sure that Clemens is talking about Peabody, aka
jdk-collaboration project, i.e. the
collaboration project around the JRLd code base.

cheers,
dalibor topic

--
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic@...
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[gnu_andrew]

2008/9/10 Clemens Eisserer <linuxhippy@...>:
> Hello,
>
> Jdk-collaboration seems quite dead now,

I think OpenJDK is anything but dead, although things have been noticeably
quieter from Sun since JavaOne and the departures in June.  There seems to be
plenty of hacking going on with the JDK7 tree however, and from what I
hear, there
is also work going on behind closed doors that will appear there.  I
suspect making
any of these changes available in OpenJDK6/IcedTea6 will however fall
upon backports
from Joe Darcy and the IcedTea team.

Free Java was around before Sun, and should the worst happen, it will
survive without them
again.  I think this is highly unlikely of course, but OpenJDK could
be maintained by the
outside community, should such an eventuality occur.

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.  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.

Cheers,
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

[Mario Torre-2]

Il giorno gio, 11/09/2008 alle 00.12 +0200, Dalibor Topic ha scritto:
> Mario Torre wrote:
> > I don't think that "jdk-collaboration seems quite dead now", we are even
> > talking about making a public API change for our peer project on the
> > awt/swing/java2d lists :)
> >  
> I'm pretty sure that Clemens is talking about Peabody, aka
> jdk-collaboration project, i.e. the
> collaboration project around the JRLd code base.

ops :)

Cheers,
Mario

[Mario Torre-2]

Il giorno mer, 10/09/2008 alle 23.27 +0100, Andrew John Hughes ha
scritto:

> was seeing this used as a tool for patch approval during the
> AWT/Swing/Java2D discussion Mario
> mentions.  A Free project being dependent on a proprietary test suite

You are completely right of course, and I totally support Mark reply to
that same post.

I want to add one thing though. The requirement for our code to pass the
JCK is because they want (oh, let's say we want) to include it into the
mainline, that is, Java(TM), not "just" OpenJDK. There is a big
difference in the two things, despite the code is in fact the same
(minus really minor things of course).

I'm not saying that this is ok, because I still find it odd, but I can
understand it. Despite this, I will not run the JCK without asking first
legal advice (its click through is really scaring!), but I don't care if
others do.

Finally, including the code into mailing is much more important to me
than fixing the issue with who has to run the JCK (again, I'm not saying
this is not an important issue that has to be fixed), because we are
external developers (well... ehm... at least so far... :) and this is
really a big change that can have much more impact on the way things
will work in the future, so let's do things one at a time.

Cheers,
Mario, who really wants to go to sleep now, as it was a long day...

[Mario Torre-2]

Il giorno gio, 11/09/2008 alle 01.50 +0200, Mario Torre ha scritto:
> Il giorno mer, 10/09/2008 alle 23.27 +0100, Andrew John Hughes ha
> scritto:

> Finally, including the code into mailing is much more important to me
                                  ^^^^^^^
This of course is a screwed version of "mainline" :)

Cheers and good night :)
Mario

[Clemens Eisserer]

Hello,

> I think OpenJDK is anything but dead
As Dalibor already mentioned I was talking about
jdk-collaboration.dev.java.net, not OpenJDK.
JDK-collboration is basically dead, almost no-one uses it anymore and
also Sun devs seem to ignore whats happening there.

Yes, I know the webstart implementation integrated in IcedTea.
However I've heard some rumors that it shouldn't take long until we
see Sun's implementation open-sourced, so I don't want to work on code
that will be replaced sooner or later.
Furthermore I have already written some specific patches for Sun's
implementation and well, nothing important just a few clean-ups - but
as it seems at jdk-collaboration no one is watching at all.

lg Clemens

[gnu_andrew]

2008/9/11 Mario Torre <neugens@...>:

> Il giorno mer, 10/09/2008 alle 23.27 +0100, Andrew John Hughes ha
> scritto:
>
>> was seeing this used as a tool for patch approval during the
>> AWT/Swing/Java2D discussion Mario
>> mentions.  A Free project being dependent on a proprietary test suite
>
> You are completely right of course, and I totally support Mark reply to
> that same post.
>
> I want to add one thing though. The requirement for our code to pass the
> JCK is because they want (oh, let's say we want) to include it into the
> mainline, that is, Java(TM), not "just" OpenJDK. There is a big
> difference in the two things, despite the code is in fact the same
> (minus really minor things of course).
>
> I'm not saying that this is ok, because I still find it odd, but I can
> understand it. Despite this, I will not run the JCK without asking first
> legal advice (its click through is really scaring!), but I don't care if
> others do.
>
> Finally, including the code into mailing is much more important to me
> than fixing the issue with who has to run the JCK (again, I'm not saying
> this is not an important issue that has to be fixed), because we are
> external developers (well... ehm... at least so far... :) and this is
> really a big change that can have much more impact on the way things
> will work in the future, so let's do things one at a time.
>
> Cheers,
> Mario, who really wants to go to sleep now, as it was a long day...
>
>
>

I agree pretty much with what you say, and, as I think you picked up on,
my issue is not so much that the code has to pass the JCK tests, but who is
responsible for running these and fixing any issues.  If Sun want it to remain
proprietary, then they should also be willing to take on the responsibility of
running it for and fixing up issues with external contributions.  Otherwise, you
effectively introduce a proprietary software mandate on any contributions.

FWIW, I don't think the license can be too bad if Red Hat are prepared to
sign up to it, but I'll leave others more knowledgable to comment more
on that.
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

[gnu_andrew]

2008/9/11 Clemens Eisserer <linuxhippy@...>:
> Hello,
>
>> I think OpenJDK is anything but dead
> As Dalibor already mentioned I was talking about
> jdk-collaboration.dev.java.net, not OpenJDK.

Yes.  I've never heard of this before and I guess most of the
Free Java hackers won't have.  Dalibor is one of the exceptions;
he seems to be kinda omniscient when it comes to Java stuff.

> JDK-collboration is basically dead, almost no-one uses it anymore and
> also Sun devs seem to ignore whats happening there.

Well my guess would be it's now deprecated, given OpenJDK exists.
Why would we need two, especially as I presume JDK collaboration is
a proprietary project?

>
> Yes, I know the webstart implementation integrated in IcedTea.
> However I've heard some rumors that it shouldn't take long until we
> see Sun's implementation open-sourced, so I don't want to work on code
> that will be replaced sooner or later.

Yeah, this issue is annoying and one of the areas where I think OpenJDK
is still failing as a community project.  If Sun have things like WebStart and
a plugin which are potentially going to drop from the sky, pretty much complete
at some random point, this inevitably causes issues with the external developers
who have no idea when this is going to happen and how feasible it is to work on
a replacement.

We've heard tell of a plugin over six months ago at FOSDEM. It's present in the
proprietary JDK apparently.  Yet it's still not surfaced in OpenJDK
with no news on what's
happened.  We can hardly carry on without plugin or webstart support for months
on end, in the hope that someday Sun will be benevolently release
their implementation.
Vendors like Red Hat need to be shipping such support to their customers now,
hence support is being developed in IcedTea.  It will be annoying when
Sun finally
do release their version but they've put the community in a position
where this can't be
helped.  The same happened with the binary plugs, and little seems to
have changed as yet.

> Furthermore I have already written some specific patches for Sun's
> implementation and well, nothing important just a few clean-ups - but
> as it seems at jdk-collaboration no one is watching at all.
>

Make sure they apply against OpenJDK and then mail them to the appropriate
list -- there are several to choose from :)

> lg Clemens
>

Cheers,
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

[Andrew Haley]

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.

> 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.

Andrew.

[gnu_andrew]

2008/9/11 Andrew Haley <aph@...>:

> 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'm not saying that ensuring a patch doesn't cause a regression with the
test suite is not important; on the contrary, I think it's very important and
wish it was more strongly enforced for GNU Classpath.

The problem is -- who's going to run the test suite?  Besides the legal problems
with the JCK (which I assume would also prevent any kind of public
continuous integration
testing), from what you say it is non-trivial to get this set up.
Should that be a requirement
on every possible contributor or should it be handled further up?

>> 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 language 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.
>

Yes, unfortunately I don't see it happening either, but it's a
disturbing state of
affairs.  For one thing, such details not being documented is a
barrier to alternate
implementations and I can see why the TCK is restricted to derivations
of OpenJDK.

> Andrew.
>
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

[Mark Wielaard]

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

[Geir Magnusson Jr.-3]

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
>

[Frans Thamura-2]

i wish all as open as we want

F

On Thu, Sep 11, 2008 at 5:57 PM, Geir Magnusson Jr. <geir@...> wrote:

> 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
>>
>
>

--
--
Frans Thamura
Meruvian Group
One Stop Java and Enterprise OSS Provider
Technopreneurship, Training, Internship, Outsourcing and Corporate
Competency Center

Mobile: [phone]
Blog & Profile: http://frans.thamura.info

Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan...
URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco

[Onno Kluyt]

We have not yet decided on a specific plan regarding open sourcing of  
the plugin and webstart code. We may eventually add this to OpenJDK  
but it is certainly not imminent.

Onno.

On Sep 11, 2008, at 4:46 AM, Clemens Eisserer wrote:

> Hello,
>
>> I think OpenJDK is anything but dead
> As Dalibor already mentioned I was talking about
> jdk-collaboration.dev.java.net, not OpenJDK.
> JDK-collboration is basically dead, almost no-one uses it anymore and
> also Sun devs seem to ignore whats happening there.
>
> Yes, I know the webstart implementation integrated in IcedTea.
> However I've heard some rumors that it shouldn't take long until we
> see Sun's implementation open-sourced, so I don't want to work on code
> that will be replaced sooner or later.
> Furthermore I have already written some specific patches for Sun's
> implementation and well, nothing important just a few clean-ups - but
> as it seems at jdk-collaboration no one is watching at all.
>
> lg Clemens

[Frans Thamura-2]

On Thu, Sep 11, 2008 at 9:18 PM, Onno Kluyt <Onno.Kluyt@...> wrote:
> We have not yet decided on a specific plan regarding open sourcing of the
> plugin and webstart code. We may eventually add this to OpenJDK but it is
> certainly not imminent.

the ads said that 100% OpenSource..

any list that is not openso