From martijnverburg at gmail.com Tue Apr 4 11:23:42 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 4 Apr 2017 12:23:42 +0100
Subject: Producing community binaries for OpenJDK
In-Reply-To: <CAP7YuATBHXbVgo-uX77ic=KVF4UXq4girAvBY5PoVP3cHJSWwA@mail.gmail.com>
References: <OFD8B8A2C3.73C69040-ON802580DE.004DB23A-802580DE.00594BDE@notes.na.collabserv.com>
<bbecbb8d-7a59-c2f2-a85b-ddb09d4a86fb@gmail.com>
<CAP7YuATg+3ON2y132t4B5zMTh-hnBGYgFtp-Jnq3KRV5S++E1Q@mail.gmail.com>
<d547005b-3027-42bd-a90f-bf09d25049b2@googlegroups.com>
<CAP7YuAQ+UCVabOf5VkmZfxS+uoxCfTn27aa=5z3FrtqBaCo2zw@mail.gmail.com>
<CAP7YuARfnMnk6nMyN99tzjh==+v24-e-trYQ5s7=GH8XiRBqOA@mail.gmail.com>
<CAP7YuAQ70SvBaiU=cGeb_go_O+H55Be_2fOhMq9oRn=3fxQgNQ@mail.gmail.com>
<CAGUMyaQ+yQe3mFuRYRKZm4mRB8ZBZNh=C26cHift-txKZ-ctrg@mail.gmail.com>
<a29e5309-82f4-625b-0603-7bfa3b5946fa@gmail.com>
<CAGUMyaQ0_3abAy5p198wDghJ3NZaEhDcUGsgeVN4HAAEWZ4AOA@mail.gmail.com>
<CAP7YuATxd_A5sbf=r2XSTbAtf-gG060L3=+mkQDXZ8Z1mUpnyQ@mail.gmail.com>
<a2b049a7-fe93-ca26-2d3b-ecd5ab68b6d1@oracle.com>
<CAP7YuAToquKJnD0ApCv+-Ruc+zUC9Ddi+GvSvM7ATTxNtCXomQ@mail.gmail.com>
<51c3cc1c-f19e-a166-9c3b-623e9ee0a2a5@oracle.com>
<CABKW8Rg4wxUVatyb9b4XwYHsXA8yAZRSLWRXPRxHBY7ZygX9xQ@mail.gmail.com>
<a47bc70d-1bb2-de01-26f6-079f578d72e3@oracle.com>
<CABKW8RiEKjMp5_prHa3DqAbWZjGxckhjGYoEbqbsNg5Mxn7BJg@mail.gmail.com>
<CAP7YuAQhFS6kFs6LVUUOvjvd_cazKjKb_=_zkob0kCZpTuB0oQ@mail.gmail.com>
<CAP7YuATBHXbVgo-uX77ic=KVF4UXq4girAvBY5PoVP3cHJSWwA@mail.gmail.com>
Message-ID: <CAP7YuASH0b0QZYPHnfvDgiMZR19TNWqx7+7s2dNStZgM=bBj=w@mail.gmail.com>
Hi all,
There will be a Google hangout
<https://hangouts.google.com/hangouts/_/dnxdlutzf5echdtf456c6mxglae> tomorrow
at 1200 UK time (GMT+1) for those who want a more detailed status update
and a walkthrough on how some of the technical details work.
Cheers,
Martijn
On 30 March 2017 at 20:35, Martijn Verburg <martijnverburg at gmail.com> wrote:
> In terms of overall progress we now have builds running on several
> platforms: Linux x64, zLinux, PPC Linux, Windows, MacOS X and hopefully
> soon Solaris.
>
> We'd like to get the jtreg testsuite with jcov working before showing this
> to a wider audience (we think that minimum level of test coverage is
> important). A personal next step goal for me would then be to integrate
> the other various OpenJDK build efforts that are out there today (IcedTea,
> David Lloyd's Git clones of forests, Henri Gomez's work and many more).
>
> All of the work is happening on GitHub (http://www.github.com/adoptopenjdk)
> - feel free to ask any questions here, or submit issues over there :-).
>
>
>
> Cheers,
> Martijn
>
> On 30 March 2017 at 20:30, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I've opened up https://github.com/AdoptOpenJDK/openjdk-build/issues/16
>> to investigate this potential IP flow issue. I'll stress that it may *not*
>> actually end up being a goal to donate code to the OpenJDK project. But if
>> we can put a mechanism in place to ensure clean IP flow in case we do
>> choose to donate the code, then that's worth looking into and it's better
>> to do it earlier rather than later.
>>
>> I briefly toyed with the idea of proposing an openjdk project for this,
>> but the OpenJDK project does simply not have the infrastructure in place to
>> rapidly prototype the sort of common build infra and processes we're
>> exploring.
>>
>>
>> Cheers,
>> Martijn
>>
>> On 29 March 2017 at 16:22, Ben Evans <benjamin.john.evans at gmail.com>
>> wrote:
>>
>>> That's not at all what I mean, and well you know it.
>>>
>>> The industry has a clear, obvious example of a major corporation of
>>> the same standing as Oracle (namely Microsoft) using a contribution
>>> model which is quite literally:
>>>
>>> 1) I certify that I have the rights to contribute this code
>>>
>>> 2) I certify that I want to contribute this code under the given
>>> license & accept the terms.
>>>
>>> How much more "real world" an example would you like?
>>>
>>> Now, if your stated reason was: "Oracle's lawyers do not believe that
>>> the IP regime adopted by Microsoft is sound & do not wish to expose
>>> themselves to liabilities that they believe exist with that model"
>>> then that would be one thing.
>>>
>>> But please don't pretend that alternative models "make no sene in the
>>> real world".
>>>
>>> Ben
>>>
>>> On Wed, Mar 29, 2017 at 5:13 PM, dalibor topic <dalibor.topic at oracle.com>
>>> wrote:
>>> > On 29.03.2017 16:51, Ben Evans wrote:
>>> >>
>>> >> Microsoft have a simple click-through arrangement, on Github, where I
>>> >> certify I have the right to make the contribution and that I agree to
>>> >> the relevant licensing terms. The first time I make a PR, I am
>>> >> prompted to perform the clickthrough, and then it goes away.
>>> >>
>>> >> Why is the situation with OpenJDK any different at all to that?
>>> >
>>> >
>>> > OpenJDK does not use GitHub. It's not owned by Microsoft. It uses the
>>> OCA.
>>> > You can find out more about it here: http://openjdk.java.net/contri
>>> bute/ .
>>> >
>>> > If what you're asking here is why one can't just contribute other
>>> people's
>>> > random code off GitHub to OpenJDK, that's because one can only
>>> contribute
>>> > what's one's own. Other people's code is not.
>>> >
>>> > If there is a doubt whether something is one's own or not, it's much
>>> better
>>> > and simpler for OpenJDK developers to err on the side of caution, and
>>> > neither encourage nor accept such contributions at all.
>>> >
>>> > And that's ultimately why all the occasionally occurring ideas about
>>> > alternative contribution flows are doomed from the start. They make no
>>> sense
>>> > in the real world.
>>> >
>>> > cheers,
>>> > dalibor topic
>>> >
>>> >
>>> >> Ben
>>> >>
>>> >> On Wed, Mar 29, 2017 at 4:00 PM, dalibor topic <
>>> dalibor.topic at oracle.com>
>>> >> wrote:
>>> >>>
>>> >>> On 29.03.2017 10:59, Martijn Verburg wrote:
>>> >>>>
>>> >>>>
>>> >>>> As long as we're talking about flow of ideas, that might make
>>> sense.
>>> >>>>
>>> >>>> If the expectation is that patches and build infra code would
>>> get
>>> >>>> promoted
>>> >>>> into OpenJDK, I think that's very unlikely, as OpenJDK requires
>>> an
>>> >>>> OCA for contributions, while GitHub does not. So over time, the
>>> cost
>>> >>>> of untangling who did what in some random GitHub repo in order
>>> to
>>> >>>> arrive at something that can be contributed tends to overshadow
>>> any
>>> >>>> benefit from such accumulations of code.
>>> >>>>
>>> >>>>
>>> >>>> Sure, that's actually a cycle I want to introduce (some sort of
>>> CLA) but
>>> >>>> appreciate the IP flow here.
>>> >>>
>>> >>>
>>> >>>
>>> >>> There is no need for any cycles.
>>> >>>
>>> >>> OpenJDK Projects can not take random code from GitHub (or any other
>>> >>> place).
>>> >>> Regardless of the arrangement you arrive at for managing some GitHub
>>> >>> repo.
>>> >>>
>>> >>> As soon as you start having more than one contributor, you end up
>>> with
>>> >>> something none of them can go ahead and just contribute on their
>>> own. At
>>> >>> that point the conversation about contributions becomes exponentially
>>> >>> more
>>> >>> complicated, and in the overwhelming majority of cases it's not worth
>>> >>> spending the time or effort on.
>>> >>>
>>> >>>> Which we might do if this thing has legs, but it has a long way to
>>> go to
>>> >>>> see if it's useful or desirable yet.
>>> >>>
>>> >>>
>>> >>>
>>> >>> Sure, but in that case you should not really expect to see any of
>>> that
>>> >>> code
>>> >>> make its way back into OpenJDK. For example, you most likely won't be
>>> >>> able
>>> >>> to take any such code back into OpenJDK once you do decide to start
>>> a new
>>> >>> Project.
>>> >>>
>>> >>> Basically, once you have a PoC of some random idea for the JDK
>>> developed
>>> >>> outside OpenJDK, you might have just enough code to prove some idea
>>> >>> works,
>>> >>> but you may have too much code and history for it to be worth
>>> putting any
>>> >>> work into turning it into something that can be contributed back to
>>> >>> OpenJDK,
>>> >>> if you have more than one contributor.
>>> >>>
>>> >>> So one can assume that such externally, 'socially' developed code
>>> will be
>>> >>> in
>>> >>> the vast majority of cases undesirable for OpenJDK, regardless of its
>>> >>> utility. That means the best potential outcome for its authors is to
>>> >>> produce
>>> >>> something useful but undesirable.
>>> >>>
>>> >>>
>>> >>> cheers,
>>> >>> dalibor topic
>>> >>> --
>>> >>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>> >>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>> >>> <tel:+491737185961>
>>> >>>
>>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>> >>>
>>> >>> ORACLE Deutschland B.V. & Co. KG
>>> >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>> >>> Registergericht: Amtsgericht M?nchen, HRA 95603
>>> >>>
>>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>> >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>> >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>> >>> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>> >>>
>>> >>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>> >>> practices and products that help protect the environment
>>> >
>>> >
>>> > --
>>> > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>> > Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>> > <tel:+491737185961>
>>> >
>>> > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>> >
>>> > ORACLE Deutschland B.V. & Co. KG
>>> > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>> > Registergericht: Amtsgericht M?nchen, HRA 95603
>>> >
>>> > Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>> > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>> >
>>> > <http://www.oracle.com/commitment> Oracle is committed to developing
>>> > practices and products that help protect the environment
>>>
>>
>>
>
From martijnverburg at gmail.com Wed Apr 5 11:01:35 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 5 Apr 2017 12:01:35 +0100
Subject: Producing community binaries for OpenJDK
In-Reply-To: <CAP7YuASH0b0QZYPHnfvDgiMZR19TNWqx7+7s2dNStZgM=bBj=w@mail.gmail.com>
References: <OFD8B8A2C3.73C69040-ON802580DE.004DB23A-802580DE.00594BDE@notes.na.collabserv.com>
<bbecbb8d-7a59-c2f2-a85b-ddb09d4a86fb@gmail.com>
<CAP7YuATg+3ON2y132t4B5zMTh-hnBGYgFtp-Jnq3KRV5S++E1Q@mail.gmail.com>
<d547005b-3027-42bd-a90f-bf09d25049b2@googlegroups.com>
<CAP7YuAQ+UCVabOf5VkmZfxS+uoxCfTn27aa=5z3FrtqBaCo2zw@mail.gmail.com>
<CAP7YuARfnMnk6nMyN99tzjh==+v24-e-trYQ5s7=GH8XiRBqOA@mail.gmail.com>
<CAP7YuAQ70SvBaiU=cGeb_go_O+H55Be_2fOhMq9oRn=3fxQgNQ@mail.gmail.com>
<CAGUMyaQ+yQe3mFuRYRKZm4mRB8ZBZNh=C26cHift-txKZ-ctrg@mail.gmail.com>
<a29e5309-82f4-625b-0603-7bfa3b5946fa@gmail.com>
<CAGUMyaQ0_3abAy5p198wDghJ3NZaEhDcUGsgeVN4HAAEWZ4AOA@mail.gmail.com>
<CAP7YuATxd_A5sbf=r2XSTbAtf-gG060L3=+mkQDXZ8Z1mUpnyQ@mail.gmail.com>
<a2b049a7-fe93-ca26-2d3b-ecd5ab68b6d1@oracle.com>
<CAP7YuAToquKJnD0ApCv+-Ruc+zUC9Ddi+GvSvM7ATTxNtCXomQ@mail.gmail.com>
<51c3cc1c-f19e-a166-9c3b-623e9ee0a2a5@oracle.com>
<CABKW8Rg4wxUVatyb9b4XwYHsXA8yAZRSLWRXPRxHBY7ZygX9xQ@mail.gmail.com>
<a47bc70d-1bb2-de01-26f6-079f578d72e3@oracle.com>
<CABKW8RiEKjMp5_prHa3DqAbWZjGxckhjGYoEbqbsNg5Mxn7BJg@mail.gmail.com>
<CAP7YuAQhFS6kFs6LVUUOvjvd_cazKjKb_=_zkob0kCZpTuB0oQ@mail.gmail.com>
<CAP7YuATBHXbVgo-uX77ic=KVF4UXq4girAvBY5PoVP3cHJSWwA@mail.gmail.com>
<CAP7YuASH0b0QZYPHnfvDgiMZR19TNWqx7+7s2dNStZgM=bBj=w@mail.gmail.com>
Message-ID: <CAP7YuARQev1uTwP9ZFNHRZWXQ7ecjqRE-_NG2s-Xw394YUY1Kw@mail.gmail.com>
Hi all,
This is starting now for those of you who can join us - will post rough
minutes afterwards.
Cheers,
Martijn
On 4 April 2017 at 12:23, Martijn Verburg <martijnverburg at gmail.com> wrote:
> Hi all,
>
> There will be a Google hangout
> <https://hangouts.google.com/hangouts/_/dnxdlutzf5echdtf456c6mxglae> tomorrow
> at 1200 UK time (GMT+1) for those who want a more detailed status update
> and a walkthrough on how some of the technical details work.
>
> Cheers,
> Martijn
>
> On 30 March 2017 at 20:35, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> In terms of overall progress we now have builds running on several
>> platforms: Linux x64, zLinux, PPC Linux, Windows, MacOS X and hopefully
>> soon Solaris.
>>
>> We'd like to get the jtreg testsuite with jcov working before showing
>> this to a wider audience (we think that minimum level of test coverage is
>> important). A personal next step goal for me would then be to integrate
>> the other various OpenJDK build efforts that are out there today (IcedTea,
>> David Lloyd's Git clones of forests, Henri Gomez's work and many more).
>>
>> All of the work is happening on GitHub (http://www.github.com/adoptop
>> enjdk) - feel free to ask any questions here, or submit issues over
>> there :-).
>>
>>
>>
>> Cheers,
>> Martijn
>>
>> On 30 March 2017 at 20:30, Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> I've opened up https://github.com/AdoptOpenJDK/openjdk-build/issues/16
>>> to investigate this potential IP flow issue. I'll stress that it may *not*
>>> actually end up being a goal to donate code to the OpenJDK project. But if
>>> we can put a mechanism in place to ensure clean IP flow in case we do
>>> choose to donate the code, then that's worth looking into and it's better
>>> to do it earlier rather than later.
>>>
>>> I briefly toyed with the idea of proposing an openjdk project for this,
>>> but the OpenJDK project does simply not have the infrastructure in place to
>>> rapidly prototype the sort of common build infra and processes we're
>>> exploring.
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 29 March 2017 at 16:22, Ben Evans <benjamin.john.evans at gmail.com>
>>> wrote:
>>>
>>>> That's not at all what I mean, and well you know it.
>>>>
>>>> The industry has a clear, obvious example of a major corporation of
>>>> the same standing as Oracle (namely Microsoft) using a contribution
>>>> model which is quite literally:
>>>>
>>>> 1) I certify that I have the rights to contribute this code
>>>>
>>>> 2) I certify that I want to contribute this code under the given
>>>> license & accept the terms.
>>>>
>>>> How much more "real world" an example would you like?
>>>>
>>>> Now, if your stated reason was: "Oracle's lawyers do not believe that
>>>> the IP regime adopted by Microsoft is sound & do not wish to expose
>>>> themselves to liabilities that they believe exist with that model"
>>>> then that would be one thing.
>>>>
>>>> But please don't pretend that alternative models "make no sene in the
>>>> real world".
>>>>
>>>> Ben
>>>>
>>>> On Wed, Mar 29, 2017 at 5:13 PM, dalibor topic <
>>>> dalibor.topic at oracle.com> wrote:
>>>> > On 29.03.2017 16:51, Ben Evans wrote:
>>>> >>
>>>> >> Microsoft have a simple click-through arrangement, on Github, where I
>>>> >> certify I have the right to make the contribution and that I agree to
>>>> >> the relevant licensing terms. The first time I make a PR, I am
>>>> >> prompted to perform the clickthrough, and then it goes away.
>>>> >>
>>>> >> Why is the situation with OpenJDK any different at all to that?
>>>> >
>>>> >
>>>> > OpenJDK does not use GitHub. It's not owned by Microsoft. It uses the
>>>> OCA.
>>>> > You can find out more about it here: http://openjdk.java.net/contri
>>>> bute/ .
>>>> >
>>>> > If what you're asking here is why one can't just contribute other
>>>> people's
>>>> > random code off GitHub to OpenJDK, that's because one can only
>>>> contribute
>>>> > what's one's own. Other people's code is not.
>>>> >
>>>> > If there is a doubt whether something is one's own or not, it's much
>>>> better
>>>> > and simpler for OpenJDK developers to err on the side of caution, and
>>>> > neither encourage nor accept such contributions at all.
>>>> >
>>>> > And that's ultimately why all the occasionally occurring ideas about
>>>> > alternative contribution flows are doomed from the start. They make
>>>> no sense
>>>> > in the real world.
>>>> >
>>>> > cheers,
>>>> > dalibor topic
>>>> >
>>>> >
>>>> >> Ben
>>>> >>
>>>> >> On Wed, Mar 29, 2017 at 4:00 PM, dalibor topic <
>>>> dalibor.topic at oracle.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> On 29.03.2017 10:59, Martijn Verburg wrote:
>>>> >>>>
>>>> >>>>
>>>> >>>> As long as we're talking about flow of ideas, that might make
>>>> sense.
>>>> >>>>
>>>> >>>> If the expectation is that patches and build infra code would
>>>> get
>>>> >>>> promoted
>>>> >>>> into OpenJDK, I think that's very unlikely, as OpenJDK
>>>> requires an
>>>> >>>> OCA for contributions, while GitHub does not. So over time,
>>>> the cost
>>>> >>>> of untangling who did what in some random GitHub repo in order
>>>> to
>>>> >>>> arrive at something that can be contributed tends to
>>>> overshadow any
>>>> >>>> benefit from such accumulations of code.
>>>> >>>>
>>>> >>>>
>>>> >>>> Sure, that's actually a cycle I want to introduce (some sort of
>>>> CLA) but
>>>> >>>> appreciate the IP flow here.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> There is no need for any cycles.
>>>> >>>
>>>> >>> OpenJDK Projects can not take random code from GitHub (or any other
>>>> >>> place).
>>>> >>> Regardless of the arrangement you arrive at for managing some GitHub
>>>> >>> repo.
>>>> >>>
>>>> >>> As soon as you start having more than one contributor, you end up
>>>> with
>>>> >>> something none of them can go ahead and just contribute on their
>>>> own. At
>>>> >>> that point the conversation about contributions becomes
>>>> exponentially
>>>> >>> more
>>>> >>> complicated, and in the overwhelming majority of cases it's not
>>>> worth
>>>> >>> spending the time or effort on.
>>>> >>>
>>>> >>>> Which we might do if this thing has legs, but it has a long way to
>>>> go to
>>>> >>>> see if it's useful or desirable yet.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> Sure, but in that case you should not really expect to see any of
>>>> that
>>>> >>> code
>>>> >>> make its way back into OpenJDK. For example, you most likely won't
>>>> be
>>>> >>> able
>>>> >>> to take any such code back into OpenJDK once you do decide to start
>>>> a new
>>>> >>> Project.
>>>> >>>
>>>> >>> Basically, once you have a PoC of some random idea for the JDK
>>>> developed
>>>> >>> outside OpenJDK, you might have just enough code to prove some idea
>>>> >>> works,
>>>> >>> but you may have too much code and history for it to be worth
>>>> putting any
>>>> >>> work into turning it into something that can be contributed back to
>>>> >>> OpenJDK,
>>>> >>> if you have more than one contributor.
>>>> >>>
>>>> >>> So one can assume that such externally, 'socially' developed code
>>>> will be
>>>> >>> in
>>>> >>> the vast majority of cases undesirable for OpenJDK, regardless of
>>>> its
>>>> >>> utility. That means the best potential outcome for its authors is to
>>>> >>> produce
>>>> >>> something useful but undesirable.
>>>> >>>
>>>> >>>
>>>> >>> cheers,
>>>> >>> dalibor topic
>>>> >>> --
>>>> >>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>> >>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>> >>> <tel:+491737185961>
>>>> >>>
>>>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>>> >>>
>>>> >>> ORACLE Deutschland B.V. & Co. KG
>>>> >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>>> >>> Registergericht: Amtsgericht M?nchen, HRA 95603
>>>> >>>
>>>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>>> >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>> >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>> >>> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>> >>>
>>>> >>> <http://www.oracle.com/commitment> Oracle is committed to
>>>> developing
>>>> >>> practices and products that help protect the environment
>>>> >
>>>> >
>>>> > --
>>>> > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>> > Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>> > <tel:+491737185961>
>>>> >
>>>> > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>>> >
>>>> > ORACLE Deutschland B.V. & Co. KG
>>>> > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>>> > Registergericht: Amtsgericht M?nchen, HRA 95603
>>>> >
>>>> > Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>>> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>> > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>> >
>>>> > <http://www.oracle.com/commitment> Oracle is committed to developing
>>>> > practices and products that help protect the environment
>>>>
>>>
>>>
>>
>
From martijnverburg at gmail.com Wed Apr 5 13:48:12 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 5 Apr 2017 14:48:12 +0100
Subject: Producing community binaries for OpenJDK
In-Reply-To: <CAP7YuARQev1uTwP9ZFNHRZWXQ7ecjqRE-_NG2s-Xw394YUY1Kw@mail.gmail.com>
References: <OFD8B8A2C3.73C69040-ON802580DE.004DB23A-802580DE.00594BDE@notes.na.collabserv.com>
<bbecbb8d-7a59-c2f2-a85b-ddb09d4a86fb@gmail.com>
<CAP7YuATg+3ON2y132t4B5zMTh-hnBGYgFtp-Jnq3KRV5S++E1Q@mail.gmail.com>
<d547005b-3027-42bd-a90f-bf09d25049b2@googlegroups.com>
<CAP7YuAQ+UCVabOf5VkmZfxS+uoxCfTn27aa=5z3FrtqBaCo2zw@mail.gmail.com>
<CAP7YuARfnMnk6nMyN99tzjh==+v24-e-trYQ5s7=GH8XiRBqOA@mail.gmail.com>
<CAP7YuAQ70SvBaiU=cGeb_go_O+H55Be_2fOhMq9oRn=3fxQgNQ@mail.gmail.com>
<CAGUMyaQ+yQe3mFuRYRKZm4mRB8ZBZNh=C26cHift-txKZ-ctrg@mail.gmail.com>
<a29e5309-82f4-625b-0603-7bfa3b5946fa@gmail.com>
<CAGUMyaQ0_3abAy5p198wDghJ3NZaEhDcUGsgeVN4HAAEWZ4AOA@mail.gmail.com>
<CAP7YuATxd_A5sbf=r2XSTbAtf-gG060L3=+mkQDXZ8Z1mUpnyQ@mail.gmail.com>
<a2b049a7-fe93-ca26-2d3b-ecd5ab68b6d1@oracle.com>
<CAP7YuAToquKJnD0ApCv+-Ruc+zUC9Ddi+GvSvM7ATTxNtCXomQ@mail.gmail.com>
<51c3cc1c-f19e-a166-9c3b-623e9ee0a2a5@oracle.com>
<CABKW8Rg4wxUVatyb9b4XwYHsXA8yAZRSLWRXPRxHBY7ZygX9xQ@mail.gmail.com>
<a47bc70d-1bb2-de01-26f6-079f578d72e3@oracle.com>
<CABKW8RiEKjMp5_prHa3DqAbWZjGxckhjGYoEbqbsNg5Mxn7BJg@mail.gmail.com>
<CAP7YuAQhFS6kFs6LVUUOvjvd_cazKjKb_=_zkob0kCZpTuB0oQ@mail.gmail.com>
<CAP7YuATBHXbVgo-uX77ic=KVF4UXq4girAvBY5PoVP3cHJSWwA@mail.gmail.com>
<CAP7YuASH0b0QZYPHnfvDgiMZR19TNWqx7+7s2dNStZgM=bBj=w@mail.gmail.com>
<CAP7YuARQev1uTwP9ZFNHRZWXQ7ecjqRE-_NG2s-Xw394YUY1Kw@mail.gmail.com>
Message-ID: <CAP7YuATdXLpjBvK-2XWOy8d=S8A0hLecPgeZEUwKSdLUvFwFHQ@mail.gmail.com>
Hi all,
Meeting minutes:
--------------------
Attendees
========
* Tim Ellison
* George Adams
* Joe Brady
* Adam Farley
* Martijn Verburg
* Mani Sarkar
Progress
=======
Jtreg with jcov work progressing well, few script issues to sort out in
terms of parsing the result to go.
Transparency
==========
* Google Hangouts on air / youtube channel to be used in future for calls
* Slack channel traffic to be made public
Git-Hg Job
========
The Git-Hg (
https://github.com/AdoptOpenJDK/openjdk-build/blob/master/git-hg/git-hg.sh)
job gets run periodically by a Jenkins job (
https://ci.adoptopenjdk.net/job/git-hg/configure) - would be good to get a
further community review of this script to ensure that for the master
branch there is the smallest diff possbile between the clone in GitHub and
the forest in hg. That diff should be published.
Github OpenJDK Binary Release Team
==============================
All of the scripts and documentation are open but as GitHub secrets etc are
involved for the tagged releases we need to have a smaller, trusted release
team that has access to the actual Jenkins job that kicks off tagged
releases (e..g 1.8.0_xxx). Will follow the Node JS community and start
with one person who will then train and add further trusted folks.
Nightly/Publish jobs
===============
George covered how the backend code works to get around the GitHub API
limitation
New build platforms... Windows/x86-64 and Linux/ppc64le
=============================================
Windows build is failing towards the end, Martijn and Mani to investigate
asmtools
=======
Mani to fix (it's fixed on cloudbees, just need to do the same on new CI
server).
Restarting jenkins
==============
George will document / put into openjdk-build
cloudflare
========
* New cloudflare account (shared Adopt OpenJDK account) has been created
for DNS and SSL management
* Martijn has added an issue for website speed
* George suggested a Puppet server to manage our infrastructure going
forwards. +1'd by everyone.
Funding
========
Quick discussion of potentially crowdsourcing and/or just encouraging cloud
providers and other orgs to donate machines (pretty successful so far).
Port over other OpenJDK tools from Cloudbees
====================================
Martijn and Mani to give a list of tools such as sigtest - to port over
Security of infrastructure
=========================
* Martijn and John Oliver to start a doc and team to fix low hanging fruit
* Then get in professional Pen testers from the LJC
* Also discussion of keeping infra team small, including short expiry keys
for those that need temporary access
Cheers,
Martijn
On 5 April 2017 at 12:01, Martijn Verburg <martijnverburg at gmail.com> wrote:
> Hi all,
>
> This is starting now for those of you who can join us - will post rough
> minutes afterwards.
>
> Cheers,
> Martijn
>
> On 4 April 2017 at 12:23, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> Hi all,
>>
>> There will be a Google hangout
>> <https://hangouts.google.com/hangouts/_/dnxdlutzf5echdtf456c6mxglae> tomorrow
>> at 1200 UK time (GMT+1) for those who want a more detailed status update
>> and a walkthrough on how some of the technical details work.
>>
>> Cheers,
>> Martijn
>>
>> On 30 March 2017 at 20:35, Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> In terms of overall progress we now have builds running on several
>>> platforms: Linux x64, zLinux, PPC Linux, Windows, MacOS X and hopefully
>>> soon Solaris.
>>>
>>> We'd like to get the jtreg testsuite with jcov working before showing
>>> this to a wider audience (we think that minimum level of test coverage is
>>> important). A personal next step goal for me would then be to integrate
>>> the other various OpenJDK build efforts that are out there today (IcedTea,
>>> David Lloyd's Git clones of forests, Henri Gomez's work and many more).
>>>
>>> All of the work is happening on GitHub (http://www.github.com/adoptop
>>> enjdk) - feel free to ask any questions here, or submit issues over
>>> there :-).
>>>
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 30 March 2017 at 20:30, Martijn Verburg <martijnverburg at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've opened up https://github.com/AdoptOpenJDK/openjdk-build/issues/16
>>>> to investigate this potential IP flow issue. I'll stress that it may *not*
>>>> actually end up being a goal to donate code to the OpenJDK project. But if
>>>> we can put a mechanism in place to ensure clean IP flow in case we do
>>>> choose to donate the code, then that's worth looking into and it's better
>>>> to do it earlier rather than later.
>>>>
>>>> I briefly toyed with the idea of proposing an openjdk project for this,
>>>> but the OpenJDK project does simply not have the infrastructure in place to
>>>> rapidly prototype the sort of common build infra and processes we're
>>>> exploring.
>>>>
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> On 29 March 2017 at 16:22, Ben Evans <benjamin.john.evans at gmail.com>
>>>> wrote:
>>>>
>>>>> That's not at all what I mean, and well you know it.
>>>>>
>>>>> The industry has a clear, obvious example of a major corporation of
>>>>> the same standing as Oracle (namely Microsoft) using a contribution
>>>>> model which is quite literally:
>>>>>
>>>>> 1) I certify that I have the rights to contribute this code
>>>>>
>>>>> 2) I certify that I want to contribute this code under the given
>>>>> license & accept the terms.
>>>>>
>>>>> How much more "real world" an example would you like?
>>>>>
>>>>> Now, if your stated reason was: "Oracle's lawyers do not believe that
>>>>> the IP regime adopted by Microsoft is sound & do not wish to expose
>>>>> themselves to liabilities that they believe exist with that model"
>>>>> then that would be one thing.
>>>>>
>>>>> But please don't pretend that alternative models "make no sene in the
>>>>> real world".
>>>>>
>>>>> Ben
>>>>>
>>>>> On Wed, Mar 29, 2017 at 5:13 PM, dalibor topic <
>>>>> dalibor.topic at oracle.com> wrote:
>>>>> > On 29.03.2017 16:51, Ben Evans wrote:
>>>>> >>
>>>>> >> Microsoft have a simple click-through arrangement, on Github, where
>>>>> I
>>>>> >> certify I have the right to make the contribution and that I agree
>>>>> to
>>>>> >> the relevant licensing terms. The first time I make a PR, I am
>>>>> >> prompted to perform the clickthrough, and then it goes away.
>>>>> >>
>>>>> >> Why is the situation with OpenJDK any different at all to that?
>>>>> >
>>>>> >
>>>>> > OpenJDK does not use GitHub. It's not owned by Microsoft. It uses
>>>>> the OCA.
>>>>> > You can find out more about it here: http://openjdk.java.net/contri
>>>>> bute/ .
>>>>> >
>>>>> > If what you're asking here is why one can't just contribute other
>>>>> people's
>>>>> > random code off GitHub to OpenJDK, that's because one can only
>>>>> contribute
>>>>> > what's one's own. Other people's code is not.
>>>>> >
>>>>> > If there is a doubt whether something is one's own or not, it's much
>>>>> better
>>>>> > and simpler for OpenJDK developers to err on the side of caution, and
>>>>> > neither encourage nor accept such contributions at all.
>>>>> >
>>>>> > And that's ultimately why all the occasionally occurring ideas about
>>>>> > alternative contribution flows are doomed from the start. They make
>>>>> no sense
>>>>> > in the real world.
>>>>> >
>>>>> > cheers,
>>>>> > dalibor topic
>>>>> >
>>>>> >
>>>>> >> Ben
>>>>> >>
>>>>> >> On Wed, Mar 29, 2017 at 4:00 PM, dalibor topic <
>>>>> dalibor.topic at oracle.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> On 29.03.2017 10:59, Martijn Verburg wrote:
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> As long as we're talking about flow of ideas, that might make
>>>>> sense.
>>>>> >>>>
>>>>> >>>> If the expectation is that patches and build infra code would
>>>>> get
>>>>> >>>> promoted
>>>>> >>>> into OpenJDK, I think that's very unlikely, as OpenJDK
>>>>> requires an
>>>>> >>>> OCA for contributions, while GitHub does not. So over time,
>>>>> the cost
>>>>> >>>> of untangling who did what in some random GitHub repo in
>>>>> order to
>>>>> >>>> arrive at something that can be contributed tends to
>>>>> overshadow any
>>>>> >>>> benefit from such accumulations of code.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Sure, that's actually a cycle I want to introduce (some sort of
>>>>> CLA) but
>>>>> >>>> appreciate the IP flow here.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> There is no need for any cycles.
>>>>> >>>
>>>>> >>> OpenJDK Projects can not take random code from GitHub (or any other
>>>>> >>> place).
>>>>> >>> Regardless of the arrangement you arrive at for managing some
>>>>> GitHub
>>>>> >>> repo.
>>>>> >>>
>>>>> >>> As soon as you start having more than one contributor, you end up
>>>>> with
>>>>> >>> something none of them can go ahead and just contribute on their
>>>>> own. At
>>>>> >>> that point the conversation about contributions becomes
>>>>> exponentially
>>>>> >>> more
>>>>> >>> complicated, and in the overwhelming majority of cases it's not
>>>>> worth
>>>>> >>> spending the time or effort on.
>>>>> >>>
>>>>> >>>> Which we might do if this thing has legs, but it has a long way
>>>>> to go to
>>>>> >>>> see if it's useful or desirable yet.
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> Sure, but in that case you should not really expect to see any of
>>>>> that
>>>>> >>> code
>>>>> >>> make its way back into OpenJDK. For example, you most likely won't
>>>>> be
>>>>> >>> able
>>>>> >>> to take any such code back into OpenJDK once you do decide to
>>>>> start a new
>>>>> >>> Project.
>>>>> >>>
>>>>> >>> Basically, once you have a PoC of some random idea for the JDK
>>>>> developed
>>>>> >>> outside OpenJDK, you might have just enough code to prove some idea
>>>>> >>> works,
>>>>> >>> but you may have too much code and history for it to be worth
>>>>> putting any
>>>>> >>> work into turning it into something that can be contributed back to
>>>>> >>> OpenJDK,
>>>>> >>> if you have more than one contributor.
>>>>> >>>
>>>>> >>> So one can assume that such externally, 'socially' developed code
>>>>> will be
>>>>> >>> in
>>>>> >>> the vast majority of cases undesirable for OpenJDK, regardless of
>>>>> its
>>>>> >>> utility. That means the best potential outcome for its authors is
>>>>> to
>>>>> >>> produce
>>>>> >>> something useful but undesirable.
>>>>> >>>
>>>>> >>>
>>>>> >>> cheers,
>>>>> >>> dalibor topic
>>>>> >>> --
>>>>> >>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>> >>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>>> >>> <tel:+491737185961>
>>>>> >>>
>>>>> >>> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>>>> >>>
>>>>> >>> ORACLE Deutschland B.V. & Co. KG
>>>>> >>> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>>>> >>> Registergericht: Amtsgericht M?nchen, HRA 95603
>>>>> >>>
>>>>> >>> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>>>> >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>>> >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>>> >>> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>>> >>>
>>>>> >>> <http://www.oracle.com/commitment> Oracle is committed to
>>>>> developing
>>>>> >>> practices and products that help protect the environment
>>>>> >
>>>>> >
>>>>> > --
>>>>> > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>> > Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>>> > <tel:+491737185961>
>>>>> >
>>>>> > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
>>>>> >
>>>>> > ORACLE Deutschland B.V. & Co. KG
>>>>> > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
>>>>> > Registergericht: Amtsgericht M?nchen, HRA 95603
>>>>> >
>>>>> > Komplement?rin: ORACLE Deutschland Verwaltung B.V.
>>>>> > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>>> > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>>> > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>>> >
>>>>> > <http://www.oracle.com/commitment> Oracle is committed to developing
>>>>> > practices and products that help protect the environment
>>>>>
>>>>
>>>>
>>>
>>
>
From abdul.kolarkunnu at oracle.com Fri Apr 7 14:42:38 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 7 Apr 2017 07:42:38 -0700 (PDT)
Subject: JDK 9 Developer Preview is now available on java.net
Message-ID: <937539f5-44b9-4ab9-9c4b-2adb82559ec3@default>
Hi All,
JDK 9 Developer Preview is now available on java.net [1]
Developer Preview milestone: - A reasonably stable build suitable for broad testing by the developer community is available.
JDK 9 Builds 163 and higher include all planned features.
Attention annotation processing users and authors - Request for feedback on annotation processing API changes made in JDK 9.
As has been done previously during Java SE 7 and Java SE 8, the JSR 269 annotation processing API is undergoing a maintenance review (MR) as part of Java SE 9. Details of the changes in JDK 9 Early Access build 163 & build 164 available here [2]
Please report experiences running processors under JDK 9 and feedback on the API changes to the compiler-dev mailing list.
(If you haven?t already subscribed to that list then please do so first, otherwise your message will be discarded as spam.)
[1] https://jdk9.java.net/download/
[2] http://mail.openjdk.java.net/pipermail/compiler-dev/2017-April/010896.html
?
?
--
Regards,
Abdul Muneer Kolarkunnu
Quality Engineer
Oracle, Bangalore, India
?
From sadhak001 at gmail.com Wed Apr 19 07:44:11 2017
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 19 Apr 2017 07:44:11 +0000
Subject: Fwd: OpenJDK ARM build not using all the CPU cores
In-Reply-To: <CAGHtMWkCyVoSOwUp=Mxa=0NBrwwfnyrExnH38DoEnboej2kS8Q@mail.gmail.com>
References: <CAGHtMWkCyVoSOwUp=Mxa=0NBrwwfnyrExnH38DoEnboej2kS8Q@mail.gmail.com>
Message-ID: <CAGHtMWnKDahNhNb3AOUX3M=Uqppmu6Ra_yBYbAeR5kjamKrpAg@mail.gmail.com>
+adoption-discuss at openjdk.java.net <adoption-discuss at openjdk.java.net> to
the discussion
---------- Forwarded message ---------
From: Mani Sarkar <sadhak001 at gmail.com>
Date: Wed, 19 Apr 2017 at 08:42
Subject: OpenJDK ARM build not using all the CPU cores
To: build-dev at openjdk.java.net <build-dev at openjdk.java.net>,
build-infra-dev at openjdk.java.net <build-infra-dev at openjdk.java.net>
Hi all,
Whilst build OpenJDK (latest version from
http://hg.openjdk.java.net/jdk8u/jdk8u/), we have noticed, that the build
system does not make use of all the CPU cores available on the machine even
though it detects them all.
(see snippets from the build log below)
Detects *4 cores*
checking for number of cores... 4
But scales down to *1 core* only
Build performance summary:
* Cores to use: 1
* Memory limit: 2021 MB
* ccache status: installed and in use
We have use the --with-num-cores flag with configure but to no avail.
Has anyone else has noticed this, is this a known issue or expected
behaviour or any config that needs applying in order for this to make use
of all the cores.
Let me know if you need to see other aspects of the build log.
Thanks.
Cheers,
Mani
--
@theNeomatrix369 <http://twitter.com/theNeomatrix369>* | **Blog
<http://neomatrix369.wordpress.com/>** | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>* | **Bitbucket
<https://bitbucket.org/neomatrix369>* * | **Github
<https://github.com/neomatrix369>* * | **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2017:* http://www.devoxx.co.uk/
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
--
@theNeomatrix369 <http://twitter.com/theNeomatrix369>* | **Blog
<http://neomatrix369.wordpress.com/>** | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>* | **Bitbucket
<https://bitbucket.org/neomatrix369>* * | **Github
<https://github.com/neomatrix369>* * | **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2017:* http://www.devoxx.co.uk/
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
From abdul.kolarkunnu at oracle.com Wed Apr 26 11:52:26 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Wed, 26 Apr 2017 04:52:26 -0700 (PDT)
Subject: JDK 9 build 166 test results now available
Message-ID: <c9e1c739-4ca2-48cf-9ffb-1b9734fe3962@default>
JDK 9 ea build 166 test results are now available at
http://www.java.net/download/openjdk/testresults/9/testresults.html
The jdk test results contain 90 differences from the build 162 test results.
No new testcase failures found.
0: /home/jtest/merge9/162/jdk/JTwork pass: 6,160; fail: 6; error: 1; not run: 2,268
1: /home/jtest/merge9/166/jdk/JTwork pass: 6,220; fail: 6; error: 1; not run: 2,240
0 1 Test
--- pass com/sun/jarsigner/DefaultMethod.java
--- pass com/sun/jdi/ArgumentValuesTest.java
--- pass com/sun/jdi/FetchLocals.java
--- pass com/sun/jdi/GetLocalVariables.java
--- pass com/sun/jdi/GetSetLocalTest.java
--- pass com/sun/jdi/LineNumberOnBraceTest.java
pass --- java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
--- pass java/lang/ClassLoader/getResource/automaticmodules/Driver.java
--- pass java/lang/ModuleLayer/BasicLayerTest.java
--- pass java/lang/ModuleLayer/LayerAndLoadersTest.java
--- pass java/lang/ModuleLayer/LayerControllerTest.java
--- pass java/lang/ModuleTests/AddExportsTest.java
--- pass java/lang/ModuleTests/AnnotationsTest.java
--- pass java/lang/ModuleTests/BasicModuleTest.java
--- pass java/lang/ModuleTests/WithSecurityManager.java
--- pass java/lang/ModuleTests/access/AccessTest.java
--- pass java/lang/ModuleTests/addXXX/Driver.java
--- pass java/lang/ModuleTests/annotation/Basic.java
--- pass java/lang/System/LoggerFinder/LoggerFinderAPI/LoggerFinderAPI.java
--- pass java/lang/System/LoggerFinder/modules/JDKLoggerForImageTest.java
--- pass java/lang/System/LoggerFinder/modules/JDKLoggerForJDKTest.java
--- pass java/lang/System/LoggerFinder/modules/LoggerInImageTest.java
--- pass java/lang/System/LoggerFinder/modules/NamedLoggerForImageTest.java
--- pass java/lang/System/LoggerFinder/modules/NamedLoggerForJDKTest.java
--- pass java/lang/System/LoggerFinder/modules/UnnamedLoggerForImageTest.java
--- pass java/lang/System/LoggerFinder/modules/UnnamedLoggerForJDKTest.java
--- pass java/lang/WeakPairMap/Driver.java
--- pass java/lang/invoke/DefineClassTest.java
--- pass java/lang/module/ModuleFinderWithSecurityManager.java
pass --- java/lang/reflect/Layer/BasicLayerTest.java
pass --- java/lang/reflect/Layer/LayerAndLoadersTest.java
pass --- java/lang/reflect/Layer/LayerControllerTest.java
pass --- java/lang/reflect/Module/AddExportsTest.java
pass --- java/lang/reflect/Module/AnnotationsTest.java
pass --- java/lang/reflect/Module/BasicModuleTest.java
pass --- java/lang/reflect/Module/WithSecurityManager.java
pass --- java/lang/reflect/Module/access/AccessTest.java
pass --- java/lang/reflect/Module/addXXX/Driver.java
pass --- java/lang/reflect/Module/annotation/Basic.java
pass --- java/lang/reflect/WeakPairMap/Driver.java
pass --- java/net/MulticastSocket/JoinGroup.java
--- pass java/net/MulticastSocket/JoinLeave.java
pass --- java/net/MulticastSocket/Leave.java
--- pass java/net/NetworkConfigurationProbe.java
--- pass java/net/httpclient/APIErrors.java
--- pass java/net/httpclient/BasicAuthTest.java
--- pass java/net/httpclient/HeadersTest.java
--- pass java/net/httpclient/HeadersTest1.java
--- pass java/net/httpclient/HttpInputStreamTest.java
--- pass java/net/httpclient/HttpRequestBuilderTest.java
--- pass java/net/httpclient/ImmutableHeaders.java
--- pass java/net/httpclient/ManyRequests.java
--- pass java/net/httpclient/MessageHeadersTest.java
--- pass java/net/httpclient/MultiAuthTest.java
--- pass java/net/httpclient/ProxyAuthTest.java
--- pass java/net/httpclient/RequestBodyTest.java
--- pass java/net/httpclient/ShortRequestBody.java
--- pass java/net/httpclient/SmallTimeout.java
--- pass java/net/httpclient/SmokeTest.java
--- pass java/net/httpclient/SplitResponse.java
--- pass java/net/httpclient/TestKitTest.java
--- pass java/net/httpclient/TimeoutOrdering.java
--- pass java/net/httpclient/examples/WebSocketExample.java
--- pass java/net/httpclient/http2/BasicTest.java
--- pass java/net/httpclient/http2/ErrorTest.java
--- pass java/net/httpclient/http2/FixedThreadPoolTest.java
--- pass java/net/httpclient/http2/HpackDriver.java
--- pass java/net/httpclient/http2/HpackDriverHeaderTable.java
--- pass java/net/httpclient/http2/NoBody.java
--- pass java/net/httpclient/http2/RedirectTest.java
--- pass java/net/httpclient/http2/ServerPush.java
--- pass java/net/httpclient/http2/TLSConnection.java
--- pass java/net/httpclient/http2/Timeout.java
--- pass java/net/httpclient/security/Driver.java
--- pass java/net/httpclient/security/Security.java
--- pass java/net/httpclient/websocket/ConnectionHandover.java
--- pass java/net/httpclient/websocket/WSDriver.java
--- pass java/net/httpclient/whitebox/Driver.java
--- pass java/util/ResourceBundle/modules/casesensitive/CaseInsensitiveNameClash.java
--- pass jdk/internal/agent/AgentCMETest.java
--- pass jdk/internal/agent/AgentCheckTest.java
--- pass jdk/internal/loader/ClassLoaderValue/ClassLoaderValueTest.java
--- pass jdk/internal/util/jar/TestVersionedStream.java
--- pass sun/security/krb5/auto/ModuleName.java
--- pass sun/security/ssl/CertPathRestrictions/TLSRestrictions.java
pass --- tools/jimage/VerifyJimage.java
--- pass tools/jlink/bindservices/BindServices.java
--- pass tools/jlink/bindservices/SuggestProviders.java
--- pass tools/launcher/modules/basic/InitErrors.java
--- pass tools/launcher/modules/permit/PermitIllegalAccess.java
90 differences
The hotspot test results contain 6 differences from the build 162 test results.
No new testcase failures found.
0: /home/jtest/merge9/162/hotspot/JTwork pass: 1,448; error: 1; not run: 59
1: /home/jtest/merge9/166/hotspot/JTwork pass: 1,454; not run: 59
0 1 Test
--- pass compiler/arraycopy/TestObjectArrayCopy.java
--- pass compiler/c2/TestNPEHeapBased.java
--- pass compiler/intrinsics/string/TestStringUTF16IntrinsicRangeChecks.java
error pass compiler/jsr292/ContinuousCallSiteTargetChange.java
--- pass runtime/jni/CallWithJNIWeak/CallWithJNIWeak.java
--- pass runtime/jni/ReturnJNIWeak/ReturnJNIWeak.java
6 differences
The langtools test results contain 8 differences from the build 162 test results.
No new testcase failures found.
0: /home/jtest/merge9/162/langtools/JTwork pass: 3,589; error: 3; not run: 314
1: /home/jtest/merge9/166/langtools/jtreg/JTwork pass: 3,597; not run: 322
0 1 Test
error pass tools/javac/FinalInitializer_2.java
--- pass tools/javac/T8176714/FieldOverloadKindNotAssignedTest.java
--- pass tools/javac/T8176714/TimingOfMReferenceCheckingTest01.java
--- pass tools/javac/T8176714/TimingOfMReferenceCheckingTest02.java
error pass tools/javac/failover/CheckAttributedTree.java
--- pass tools/javac/generics/inference/8177097/T8177097a.java
--- pass tools/javac/generics/inference/8177097/T8177097b.java
error pass tools/javac/importscope/NegativeCyclicDependencyTest.java
8 differences
The nashorn tests are not able to run because of https://bugs.openjdk.java.net/browse/JDK-8178315
--
Regards,
Abdul Muneer
Quality Engineer
Oracle, Bangalore, India
From abdul.kolarkunnu at oracle.com Thu Apr 27 15:59:57 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Thu, 27 Apr 2017 08:59:57 -0700 (PDT)
Subject: JDK 8u152 b03 test results now available
Message-ID: <b7034952-a6d1-4699-9956-f0cb52bb9147@default>
JDK 8u152 ea b03 test results are now available at
http://www.java.net/download/openjdk/testresults/8/testresults.html
The jdk test results contain 5 differences from the build b02 test results. There is 1
testcase failure, this failure is under investigation.
0: /home/jtest/merge8/jdk8u152-b02/jdk/JTwork pass: 5,090; fail: 10; not run: 1,120
1: /home/jtest/merge8/jdk8u152-b03/jdk/JTwork pass: 5,093; fail: 10; not run: 1,126
0 1 Test
fail pass com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
pass fail com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java
--- pass java/lang/Thread/ITLConstructor.java
--- pass java/util/Calendar/SupplementalJapaneseEraTest.java
--- pass sun/net/ftp/FtpURLConnectionLeak.java
5 differences
The hotspot test results contain 2 differences from the build b02 test results. There is 1
testcase failure, this failure is under investigation.
0: /home/jtest/merge8/jdk8u152-b02/hotspot/JTwork pass: 661; fail: 43; error: 4; not run: 21
1: /home/jtest/merge8/jdk8u152-b03/hotspot/JTwork pass: 661; fail: 44; error: 4; not run: 21
0 1 Test
--- pass compiler/c1/TestUnresolvedFieldMain.java
pass fail gc/g1/TestShrinkAuxiliaryData10.java
2 differences
The langtools test results contain 0 difference from the build b03 test results.
The nashorn test result is available at
http://download.java.net/openjdk/testresults/8/archives8/jdk8u152-b03/emailable-report.html
--
Regards,
Abdul Muneer
Quality Engineer
Oracle, Bangalore, India
From stefan.reich.maker.of.eye at googlemail.com Thu Apr 27 20:43:16 2017
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Thu, 27 Apr 2017 22:43:16 +0200
Subject: JDK 8u152 b03 test results now available
In-Reply-To: <b7034952-a6d1-4699-9956-f0cb52bb9147@default>
References: <b7034952-a6d1-4699-9956-f0cb52bb9147@default>
Message-ID: <CAC2-jLF2xrUUG=1zGM3mL+gecBdh_3OjrKtKLF+jNxg1eT8akg@mail.gmail.com>
Is that good or bad?
Cheers from JavaX / http://ai1.lol
On Thu, Apr 27, 2017 at 5:59 PM, Muneer Kolarkunnu <
abdul.kolarkunnu at oracle.com> wrote:
>
>
> JDK 8u152 ea b03 test results are now available at
> http://www.java.net/download/openjdk/testresults/8/testresults.html
>
> The jdk test results contain 5 differences from the build b02 test
> results. There is 1
> testcase failure, this failure is under investigation.
>
> 0: /home/jtest/merge8/jdk8u152-b02/jdk/JTwork pass: 5,090; fail: 10; not
> run: 1,120
>
> 1: /home/jtest/merge8/jdk8u152-b03/jdk/JTwork pass: 5,093; fail: 10; not
> run: 1,126
>
>
>
> 0 1 Test
>
> fail pass com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
>
> pass fail com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java
>
> --- pass java/lang/Thread/ITLConstructor.java
>
> --- pass java/util/Calendar/SupplementalJapaneseEraTest.java
>
> --- pass sun/net/ftp/FtpURLConnectionLeak.java
>
>
>
> 5 differences
>
>
>
> The hotspot test results contain 2 differences from the build b02 test
> results. There is 1
> testcase failure, this failure is under investigation.
>
> 0: /home/jtest/merge8/jdk8u152-b02/hotspot/JTwork pass: 661; fail: 43;
> error: 4; not run: 21
>
> 1: /home/jtest/merge8/jdk8u152-b03/hotspot/JTwork pass: 661; fail: 44;
> error: 4; not run: 21
>
>
>
> 0 1 Test
>
> --- pass compiler/c1/TestUnresolvedFieldMain.java
>
> pass fail gc/g1/TestShrinkAuxiliaryData10.java
>
>
>
> 2 differences
>
>
>
> The langtools test results contain 0 difference from the build b03 test
> results.
>
>
> The nashorn test result is available at
> http://download.java.net/openjdk/testresults/8/archives8/jdk8u152-b03/
> emailable-report.html
>
> --
> Regards,
> Abdul Muneer
> Quality Engineer
> Oracle, Bangalore, India
>
>
>
>
From dalibor.topic at oracle.com Fri Apr 28 06:22:38 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 28 Apr 2017 08:22:38 +0200
Subject: JDK Early Access download site has moved
Message-ID: <1f640842-5248-e990-a3d2-bd2254f8544d@oracle.com>
Hi,
with the sunset of java.net forge [0], the download sites for JDK Early
Access builds have moved to
http://jdk.java.net
If you have any materials pointing to the previous location, please
update them accordingly. I have already done so for the Adoption Group Wiki.
cheers,
dalibor topic
[0] https://community.oracle.com/community/java/javanet-forge-sunset
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
From abdul.kolarkunnu at oracle.com Fri Apr 28 09:18:17 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 28 Apr 2017 02:18:17 -0700 (PDT)
Subject: JDK 8u152 b03 test results now available
In-Reply-To: <CAC2-jLF2xrUUG=1zGM3mL+gecBdh_3OjrKtKLF+jNxg1eT8akg@mail.gmail.com>
References: <b7034952-a6d1-4699-9956-f0cb52bb9147@default>
<CAC2-jLF2xrUUG=1zGM3mL+gecBdh_3OjrKtKLF+jNxg1eT8akg@mail.gmail.com>
Message-ID: <3c282aa5-fd17-4101-b7fa-d125d3655ad0@default>
Hi Stefan,
?
Test failure SocketOptionTests is an intermittent failure and already bug is there in JBS HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8141694"JDK-8141694 .
gc/g1/TestShrinkAuxiliaryData10.java is also an intermittent failure and investigations are going on.
?
Regards,
Muneer
?
From: Stefan Reich [mailto:stefan.reich.maker.of.eye at googlemail.com]
Sent: Friday, April 28, 2017 2:13 AM
To: Muneer Kolarkunnu
Cc: quality-discuss at openjdk.java.net; adoption-discuss at openjdk.java.net
Subject: Re: JDK 8u152 b03 test results now available
?
Is that good or bad?
Cheers from JavaX / http://ai1.lol
?
On Thu, Apr 27, 2017 at 5:59 PM, Muneer Kolarkunnu <HYPERLINK "mailto:abdul.kolarkunnu at oracle.com" \nabdul.kolarkunnu at oracle.com> wrote:
JDK 8u152 ea b03 test results are now available at
http://www.java.net/download/openjdk/testresults/8/testresults.html
The jdk test results contain 5 differences from the build b02 test results. There is 1
testcase failure, this failure is under investigation.
0: /home/jtest/merge8/jdk8u152-b02/jdk/JTwork? pass: 5,090; fail: 10; not run: 1,120
1: /home/jtest/merge8/jdk8u152-b03/jdk/JTwork? pass: 5,093; fail: 10; not run: 1,126
0? ? ? 1? ? ? Test
fail? ?pass? ?com/sun/nio/sctp/SctpChannel/SocketOptionTests.java
pass? ?fail? ?com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java
---? ? pass? ?java/lang/Thread/ITLConstructor.java
---? ? pass? ?java/util/Calendar/SupplementalJapaneseEraTest.java
---? ? pass? ?sun/net/ftp/FtpURLConnectionLeak.java
5 differences
The hotspot test results contain 2 differences from the build b02 test results. There is 1
testcase failure, this failure is under investigation.
0: /home/jtest/merge8/jdk8u152-b02/hotspot/JTwork? pass: 661; fail: 43; error: 4; not run: 21
1: /home/jtest/merge8/jdk8u152-b03/hotspot/JTwork? pass: 661; fail: 44; error: 4; not run: 21
0? ? ? 1? ? ? Test
---? ? pass? ?compiler/c1/TestUnresolvedFieldMain.java
pass? ?fail? ?gc/g1/TestShrinkAuxiliaryData10.java
2 differences
The langtools test results contain 0 difference from the build b03 test results.
The nashorn test result is available at
http://download.java.net/openjdk/testresults/8/archives8/jdk8u152-b03/emailable-report.html
--
Regards,
Abdul Muneer
Quality Engineer
Oracle, Bangalore, India
?
From abdul.kolarkunnu at oracle.com Fri Apr 28 10:51:10 2017
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 28 Apr 2017 03:51:10 -0700 (PDT)
Subject: JDK 9 EA Build 167 and JDK 8u152 build 03 are available on
jdk.java.net
Message-ID: <d9e0ae04-9d5c-4228-b569-48f86cba211e@default>
Hi All,
JDK 9 Early Access? build 167? is available at the new location : -? HYPERLINK "http://jdk.java.net/9/"jdk.java.net/9/?
A summary of all the changes in this build are listed HYPERLINK "http://download.java.net/java/jdk9/changes/jdk-9+167.html"here.?? One change that maybe of interest is :
? JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector [1]
?
JDK 8u152 Early Access build 03 is available at the new location : - HYPERLINK "http://jdk.java.net/8/"jdk.java.net/8/
More information on the change of location for Early Access builds. [2]
NOTE: - Oracle's JRE and JDK Cryptographic Roadmap has been updated since last availability email [3]
[1] HYPERLINK "http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html"http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/005766.html
[2] http://mail.openjdk.java.net/pipermail/adoption-discuss/2017-April/001610.html
[3] https://www.java.com/en/jre-jdk-cryptoroadmap.html
?
--
Regards,
Abdul Muneer Kolarkunnu
Quality Engineer
Oracle, Bangalore, India
?
From behrangsa at gmail.com Fri Apr 28 23:04:57 2017
From: behrangsa at gmail.com (Behrang Saeedzadeh)
Date: Fri, 28 Apr 2017 23:04:57 +0000
Subject: Suggestion for automatic wrapping of checked exceptions inside
RuntimeExceptions inside closures
In-Reply-To: <CAERAJ+-Rvaeqj5AJ-p-E8A8u_6mRYmkFeoZhZ1ooS5MOEMhWHQ@mail.gmail.com>
References: <CAERAJ+-Rvaeqj5AJ-p-E8A8u_6mRYmkFeoZhZ1ooS5MOEMhWHQ@mail.gmail.com>
Message-ID: <CAERAJ+9=jeTGaox5Lb5HFGcxffvNn5MgY3oytLir0DJu-P4jmA@mail.gmail.com>
Hi,
This has most likely been discussed before. In this yet another proposal, I
suggest adding syntax sugar to make this automated. For example, by using a
new arrow type (e.g. =>, #->, or maybe a new operator altogether: (???????
???).
So we can turn:
public class Main {
public static void main(String[] args) throws IOException {
final Path aDir = Paths.get(args[0]);
Files.list(aDir).forEach(f -> {
try {
throw new IOException();
} catch (IOException e) {
throw new RuntimeException(e);
}
});
}
}
into:
public class Main {
public static void main(String[] args) throws IOException {
final Path aDir = Paths.get(args[0]);
Files.list(aDir).forEach(f (??????? ??? {
throw new IOException();
});
}
}
What do you think?
Best regards,
Behrang Saeedzadeh
--
Best regards,
Behrang Saeedzadeh
From stefan.reich.maker.of.eye at googlemail.com Sun Apr 30 15:07:19 2017
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sun, 30 Apr 2017 17:07:19 +0200
Subject: Suggestion for automatic wrapping of checked exceptions inside
RuntimeExceptions inside closures
In-Reply-To: <CAERAJ+9=jeTGaox5Lb5HFGcxffvNn5MgY3oytLir0DJu-P4jmA@mail.gmail.com>
References: <CAERAJ+-Rvaeqj5AJ-p-E8A8u_6mRYmkFeoZhZ1ooS5MOEMhWHQ@mail.gmail.com>
<CAERAJ+9=jeTGaox5Lb5HFGcxffvNn5MgY3oytLir0DJu-P4jmA@mail.gmail.com>
Message-ID: <CAC2-jLHgsSFbym4R+Um1k2B43dKYcyBY-L=-oe48w3ntuB9kEw@mail.gmail.com>
In my language (JavaX), this is automatic ^^
On Sat, Apr 29, 2017 at 1:04 AM, Behrang Saeedzadeh <behrangsa at gmail.com>
wrote:
> Hi,
>
> This has most likely been discussed before. In this yet another proposal, I
> suggest adding syntax sugar to make this automated. For example, by using a
> new arrow type (e.g. =>, #->, or maybe a new operator altogether: (???????
> ???).
>
> So we can turn:
>
> public class Main {
> public static void main(String[] args) throws IOException {
> final Path aDir = Paths.get(args[0]);
> Files.list(aDir).forEach(f -> {
> try {
> throw new IOException();
> } catch (IOException e) {
> throw new RuntimeException(e);
> }
> });
> }
> }
>
>
> into:
>
> public class Main {
> public static void main(String[] args) throws IOException {
> final Path aDir = Paths.get(args[0]);
> Files.list(aDir).forEach(f (??????? ??? {
> throw new IOException();
> });
> }
> }
>
> What do you think?
>
>
> Best regards,
> Behrang Saeedzadeh
> --
> Best regards,
> Behrang Saeedzadeh
>