From david.holmes at oracle.com  Fri Dec  1 00:57:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 1 Dec 2017 10:57:15 +1000
Subject: [PATCH] Mere code changes to silence some warnings
In-Reply-To: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
References: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
Message-ID: <2b34f514-d7c2-856d-dcc2-9f8a4b1d0c15@oracle.com>

Hi David,

can you please split these and take them to the component mailing lists: 
hotspot changes to hotspot-dev, and the rest to core-libs-dev.

BTW hotspot style nit - avoid implicit booleans: if (!p) -> if (p != NULL)

Thanks,
David H.

On 1/12/2017 3:06 AM, David CARLIER wrote:
> Hi dear list,
> 
> Here a tiny patch to address few compilation warnings, two concerns UB with
> define e.g #define A <cond> it is usually better this form #if <cond>
> #define A 1 ... Few types comparison miusmatches as well.
> 
> Hope is all good ... tested full build.
> 

From devnexen at gmail.com  Fri Dec  1 06:43:18 2017
From: devnexen at gmail.com (David CARLIER)
Date: Fri, 1 Dec 2017 06:43:18 +0000
Subject: [PATCH] Mere code changes to silence some warnings
In-Reply-To: <2b34f514-d7c2-856d-dcc2-9f8a4b1d0c15@oracle.com>
References: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
 <2b34f514-d7c2-856d-dcc2-9f8a4b1d0c15@oracle.com>
Message-ID: <CA+XhMqw5BEcw6M933Jf=pELij25PSTu4cAmFkhT=a0Di6tObiA@mail.gmail.com>

Hi and thanks will do. Kind regards.

On 1 December 2017 at 00:57, David Holmes <david.holmes at oracle.com> wrote:

> Hi David,
>
> can you please split these and take them to the component mailing lists:
> hotspot changes to hotspot-dev, and the rest to core-libs-dev.
>
> BTW hotspot style nit - avoid implicit booleans: if (!p) -> if (p != NULL)
>
> Thanks,
> David H.
>
>
> On 1/12/2017 3:06 AM, David CARLIER wrote:
>
>> Hi dear list,
>>
>> Here a tiny patch to address few compilation warnings, two concerns UB
>> with
>> define e.g #define A <cond> it is usually better this form #if <cond>
>> #define A 1 ... Few types comparison miusmatches as well.
>>
>> Hope is all good ... tested full build.
>>
>>

From volker.simonis at gmail.com  Fri Dec  1 11:11:18 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 1 Dec 2017 12:11:18 +0100
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <20171130101151.765472420@eggemoggin.niobe.net>
References: <20171130101151.765472420@eggemoggin.niobe.net>
Message-ID: <CA+3eh13oWNBGwoKfA+gn0zjB8_J9vKw-AsJe0TYSpxRqBD7S0Q@mail.gmail.com>

On Thu, Nov 30, 2017 at 7:11 PM,  <mark.reinhold at oracle.com> wrote:
> Thanks for all the comments on my earlier proposal [1].  Here's a draft
> JEP, based on that proposal and the feedback:
>
>   http://openjdk.java.net/jeps/8192828
>
> Further comments welcome!
>

Hi Mark,

thanks for publishing the draft. Overall it looks good!

I have just a few comment :)

1. Is this JEP (i.e. the new version scheme) intended to be targeted
for Java 10?

I would appreciate to have it in ten but aren't we already quite late?
This is specification relevant (i.e. has to go into JSR 383) because
it changes java.lang.Runtime.Version and various standard system
properties which refer to it. JSR 383 has to be renamed from "Java SE
18.3 Platform JSR" to "Java SE 10 Platform JSR" afterwards, right?

2. In the example output there a space between the date and LTS when
running java --version:

$ java --version
openjdk 11 2018-09-20 LTS

But in the formal definition of the "--version" output there is no space:

$ java --version
openjdk ${java.version} ${java.version.date}${LTS}

I suppose the example output is correct here and there should be a
space between ${java.version.date} and ${LTS} in the formal
definition, right?

3. The same applies to the space between
${java.runtime.name}/${java.vm.name} and ${JVV}

4. Finally, why are the outputs of "-version" and "--version" slightly
different? Is this to retain backwards compatibility with the former
"-version" output? But then why can't "--version" use the exact same
format? Sorry if this has been discussed before. It is obviously not a
crucial factor but I just found it confusing when looking at it.

Regards,
Volker

> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html

From daniel.daugherty at oracle.com  Fri Dec  1 15:44:41 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 1 Dec 2017 10:44:41 -0500
Subject: [PATCH] Mere code changes to silence some warnings
In-Reply-To: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
References: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
Message-ID: <a45ecd49-68e8-49df-b371-f6dcb87e72ca@oracle.com>

David,

What compiler needed these fixes?

Dan


On 11/30/17 12:06 PM, David CARLIER wrote:
> Hi dear list,
>
> Here a tiny patch to address few compilation warnings, two concerns UB with
> define e.g #define A <cond> it is usually better this form #if <cond>
> #define A 1 ... Few types comparison miusmatches as well.
>
> Hope is all good ... tested full build.


From devnexen at gmail.com  Fri Dec  1 15:46:09 2017
From: devnexen at gmail.com (David CARLIER)
Date: Fri, 1 Dec 2017 15:46:09 +0000
Subject: [PATCH] Mere code changes to silence some warnings
In-Reply-To: <a45ecd49-68e8-49df-b371-f6dcb87e72ca@oracle.com>
References: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
 <a45ecd49-68e8-49df-b371-f6dcb87e72ca@oracle.com>
Message-ID: <CA+XhMqwtaYCJk9Kev5P7rueELHhNfXBZmGs0Aw3NexN9Vg4eXA@mail.gmail.com>

Daniel,
gcc 7 I believe.

Kind regards.

On 1 December 2017 at 15:44, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> David,
>
> What compiler needed these fixes?
>
> Dan
>
>
> On 11/30/17 12:06 PM, David CARLIER wrote:
>
>> Hi dear list,
>>
>> Here a tiny patch to address few compilation warnings, two concerns UB
>> with
>> define e.g #define A <cond> it is usually better this form #if <cond>
>> #define A 1 ... Few types comparison miusmatches as well.
>>
>> Hope is all good ... tested full build.
>>
>
>

From mark.reinhold at oracle.com  Fri Dec  1 15:59:47 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 01 Dec 2017 07:59:47 -0800
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <CA+3eh13oWNBGwoKfA+gn0zjB8_J9vKw-AsJe0TYSpxRqBD7S0Q@mail.gmail.com>
References: <20171130101151.765472420@eggemoggin.niobe.net>
 <CA+3eh13oWNBGwoKfA+gn0zjB8_J9vKw-AsJe0TYSpxRqBD7S0Q@mail.gmail.com>
Message-ID: <20171201075947.99628185@eggemoggin.niobe.net>

2017/12/1 3:11:18 -0800, volker.simonis at gmail.com:
> thanks for publishing the draft. Overall it looks good!
> 
> I have just a few comment :)
> 
> 1. Is this JEP (i.e. the new version scheme) intended to be targeted
> for Java 10?

It's intended to be targeted when it's ready, just like any other JEP.
It's obviously desirable to have it in 10, but if it doesn't make it
then it'll be in 11.

> I would appreciate to have it in ten but aren't we already quite late?
> This is specification relevant (i.e. has to go into JSR 383) because
> it changes java.lang.Runtime.Version and various standard system
> properties which refer to it. JSR 383 has to be renamed from "Java SE
> 18.3 Platform JSR" to "Java SE 10 Platform JSR" afterwards, right?

That should be done anyway, regardless of whether this JEP makes it into
JDK 10.  If we change nothing in JDK 10, as it stands today, then the
JDK 10 GA release will identify itself as 10, not 18.3.

> 2. In the example output there a space between the date and LTS when
> running java --version:
> 
> $ java --version
> openjdk 11 2018-09-20 LTS
> 
> But in the formal definition of the "--version" output there is no space:
> 
> $ java --version
> openjdk ${java.version} ${java.version.date}${LTS}
> 
> I suppose the example output is correct here and there should be a
> space between ${java.version.date} and ${LTS} in the formal
> definition, right?

The JEP defines ${LTS} to expand to " LTS".  (I put a non-breaking space
after the opening double quote to try to make that clear, but to be even
clearer I could instead write "\u00020LTS".)

> 3. The same applies to the space between
> ${java.runtime.name}/${java.vm.name} and ${JVV}

Same answer.

> 4. Finally, why are the outputs of "-version" and "--version" slightly
> different? Is this to retain backwards compatibility with the former
> "-version" output? But then why can't "--version" use the exact same
> format? Sorry if this has been discussed before. It is obviously not a
> crucial factor but I just found it confusing when looking at it.

When we introduced `--version`, `--show-version`, and `--full-version`
in JDK 9 we took the opportunity to clean up and simplify the output.

- Mark

From devnexen at gmail.com  Fri Dec  1 16:14:33 2017
From: devnexen at gmail.com (David CARLIER)
Date: Fri, 1 Dec 2017 16:14:33 +0000
Subject: [PATCH] Mere code changes to silence some warnings
In-Reply-To: <CA+XhMqwtaYCJk9Kev5P7rueELHhNfXBZmGs0Aw3NexN9Vg4eXA@mail.gmail.com>
References: <CA+XhMqx-8Y9rAAdPaG1b32fHAj5tEqpdwf=80wu_CWaFfUhV8Q@mail.gmail.com>
 <a45ecd49-68e8-49df-b371-f6dcb87e72ca@oracle.com>
 <CA+XhMqwtaYCJk9Kev5P7rueELHhNfXBZmGs0Aw3NexN9Vg4eXA@mail.gmail.com>
Message-ID: <CA+XhMqx4=FugJ94qfZK9=aN7gufd44nAz_v0++SZPr_T3UnR6Q@mail.gmail.com>

I had posted also another small patchset to core-libs-dev list but does not
seem to appear.

Kindest regards.

On 1 December 2017 at 15:46, David CARLIER <devnexen at gmail.com> wrote:

> Daniel,
> gcc 7 I believe.
>
> Kind regards.
>
> On 1 December 2017 at 15:44, Daniel D. Daugherty <
> daniel.daugherty at oracle.com> wrote:
>
>> David,
>>
>> What compiler needed these fixes?
>>
>> Dan
>>
>>
>> On 11/30/17 12:06 PM, David CARLIER wrote:
>>
>>> Hi dear list,
>>>
>>> Here a tiny patch to address few compilation warnings, two concerns UB
>>> with
>>> define e.g #define A <cond> it is usually better this form #if <cond>
>>> #define A 1 ... Few types comparison miusmatches as well.
>>>
>>> Hope is all good ... tested full build.
>>>
>>
>>
>

From volker.simonis at gmail.com  Fri Dec  1 16:18:04 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 1 Dec 2017 17:18:04 +0100
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <20171201075947.99628185@eggemoggin.niobe.net>
References: <20171130101151.765472420@eggemoggin.niobe.net>
 <CA+3eh13oWNBGwoKfA+gn0zjB8_J9vKw-AsJe0TYSpxRqBD7S0Q@mail.gmail.com>
 <20171201075947.99628185@eggemoggin.niobe.net>
Message-ID: <CA+3eh10GVGFa4syXs6=8w_9RWFETP+HU+4E+Qga5vJ3oY3xjpw@mail.gmail.com>

Thanks for the quick answer!

No more objections from me. Writing "\u00020LTS" instead of " LTS" may
indeed help - I've missed that space character. Or you could just put
in a comment like "(notice the space at the beginning of the expanded
string)".

So let's try to bring this into Java 10 then.

Regards,
Volker


On Fri, Dec 1, 2017 at 4:59 PM,  <mark.reinhold at oracle.com> wrote:
> 2017/12/1 3:11:18 -0800, volker.simonis at gmail.com:
>> thanks for publishing the draft. Overall it looks good!
>>
>> I have just a few comment :)
>>
>> 1. Is this JEP (i.e. the new version scheme) intended to be targeted
>> for Java 10?
>
> It's intended to be targeted when it's ready, just like any other JEP.
> It's obviously desirable to have it in 10, but if it doesn't make it
> then it'll be in 11.
>
>> I would appreciate to have it in ten but aren't we already quite late?
>> This is specification relevant (i.e. has to go into JSR 383) because
>> it changes java.lang.Runtime.Version and various standard system
>> properties which refer to it. JSR 383 has to be renamed from "Java SE
>> 18.3 Platform JSR" to "Java SE 10 Platform JSR" afterwards, right?
>
> That should be done anyway, regardless of whether this JEP makes it into
> JDK 10.  If we change nothing in JDK 10, as it stands today, then the
> JDK 10 GA release will identify itself as 10, not 18.3.
>
>> 2. In the example output there a space between the date and LTS when
>> running java --version:
>>
>> $ java --version
>> openjdk 11 2018-09-20 LTS
>>
>> But in the formal definition of the "--version" output there is no space:
>>
>> $ java --version
>> openjdk ${java.version} ${java.version.date}${LTS}
>>
>> I suppose the example output is correct here and there should be a
>> space between ${java.version.date} and ${LTS} in the formal
>> definition, right?
>
> The JEP defines ${LTS} to expand to " LTS".  (I put a non-breaking space
> after the opening double quote to try to make that clear, but to be even
> clearer I could instead write "\u00020LTS".)
>
>> 3. The same applies to the space between
>> ${java.runtime.name}/${java.vm.name} and ${JVV}
>
> Same answer.
>
>> 4. Finally, why are the outputs of "-version" and "--version" slightly
>> different? Is this to retain backwards compatibility with the former
>> "-version" output? But then why can't "--version" use the exact same
>> format? Sorry if this has been discussed before. It is obviously not a
>> crucial factor but I just found it confusing when looking at it.
>
> When we introduced `--version`, `--show-version`, and `--full-version`
> in JDK 9 we took the opportunity to clean up and simplify the output.
>
> - Mark

From mark.reinhold at oracle.com  Fri Dec  1 16:33:27 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 01 Dec 2017 08:33:27 -0800
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <CA+3eh10GVGFa4syXs6=8w_9RWFETP+HU+4E+Qga5vJ3oY3xjpw@mail.gmail.com>
References: <20171130101151.765472420@eggemoggin.niobe.net>
 <CA+3eh13oWNBGwoKfA+gn0zjB8_J9vKw-AsJe0TYSpxRqBD7S0Q@mail.gmail.com>
 <20171201075947.99628185@eggemoggin.niobe.net>
 <CA+3eh10GVGFa4syXs6=8w_9RWFETP+HU+4E+Qga5vJ3oY3xjpw@mail.gmail.com>
Message-ID: <20171201083327.818962477@eggemoggin.niobe.net>

2017/12/1 8:18:04 -0800, volker.simonis at gmail.com:
> No more objections from me. Writing "\u00020LTS" instead of " LTS" may
> indeed help - I've missed that space character.

Done: http://openjdk.java.net/jeps/8192828#Launcher-detail .

- Mark

From scolebourne at joda.org  Fri Dec  1 17:32:48 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 1 Dec 2017 17:32:48 +0000
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <20171130101151.765472420@eggemoggin.niobe.net>
References: <20171130101151.765472420@eggemoggin.niobe.net>
Message-ID: <CACzrW9CHk2b13Tv77MyEdD6pMhm=nWTF1scE4_GHccErAkKJpw@mail.gmail.com>

The document doesn't state what happens to the --release flag in
javac, which seems a linked issue worthy of inclusion.

I and others (based on feedback I've seen) think this new flag is
great, but it only retains its usefulness if it supports older
versions over a (very) long period of time. I'm currently setting up
the Joda-* projects to use it, but some have Java 6 as a baseline. Any
move to increase the minimum from Java 6 would thus be a problem for
me.

At a minimum, I believe that Java 6 should remain the baseline of the
feature until Java 12 (ie. support for 6 removed in the release after
the LTS v11).

Ideally however, I'd prefer Java 6 support is removed in Java 18
(assuming 17 is an LTS). The feature really is that useful.

thanks
Stephen


On 30 November 2017 at 18:11,  <mark.reinhold at oracle.com> wrote:
> Thanks for all the comments on my earlier proposal [1].  Here's a draft
> JEP, based on that proposal and the feedback:
>
>   http://openjdk.java.net/jeps/8192828
>
> Further comments welcome!
>
> - Mark
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html

From martijnverburg at gmail.com  Fri Dec  1 18:20:27 2017
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 01 Dec 2017 18:20:27 +0000
Subject: JEP 320: Remove the Java EE and CORBA Modules
In-Reply-To: <20171130225223.6748710B927@eggemoggin.niobe.net>
References: <20171130225223.6748710B927@eggemoggin.niobe.net>
Message-ID: <CAP7YuAQqVr3C-H8E8+czK2T4dFVNwFcZSrRkjMaHWez_DN=7zQ@mail.gmail.com>

End of an Era!

On Thu, 30 Nov 2017 at 22:53, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/320
>
> - Mark
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From hs at tagtraum.com  Fri Dec  1 18:54:36 2017
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 1 Dec 2017 19:54:36 +0100
Subject: JEP 320: Remove the Java EE and CORBA Modules
In-Reply-To: <CAP7YuAQqVr3C-H8E8+czK2T4dFVNwFcZSrRkjMaHWez_DN=7zQ@mail.gmail.com>
References: <20171130225223.6748710B927@eggemoggin.niobe.net>
 <CAP7YuAQqVr3C-H8E8+czK2T4dFVNwFcZSrRkjMaHWez_DN=7zQ@mail.gmail.com>
Message-ID: <6349E42A-7694-4C54-AD57-0E59639311B0@tagtraum.com>

> On Dec 1, 2017, at 19:20, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 
> End of an Era!

Indeed. More so because of CORBA than the EE stuff.

Describing CORBA to young developers is like showing cassette tapes to kids.

-hendrik


From neugens.limasoftware at gmail.com  Fri Dec  1 19:14:26 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 01 Dec 2017 19:14:26 +0000
Subject: JEP 320: Remove the Java EE and CORBA Modules
In-Reply-To: <20171130225223.6748710B927@eggemoggin.niobe.net>
References: <20171130225223.6748710B927@eggemoggin.niobe.net>
Message-ID: <CAGUMyaS-XHsngEMCMEKFnV9Jdo71gSdc+dB+aoq0qUnneh9tbw@mail.gmail.com>

On Thu 30. Nov 2017 at 23:53, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/320
>
> - Mark
>
\o/

Cheers,
Mario

From paul.sandoz at oracle.com  Fri Dec  1 23:32:39 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 1 Dec 2017 15:32:39 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54 
Message-ID: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>

Hi,

This is an initial review request to increment the class file version of 10 from 53 to 54.

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>

through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.

The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)

The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.

The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.

Thanks,
Paul.

From jonathan.gibbons at oracle.com  Fri Dec  1 23:44:00 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 01 Dec 2017 15:44:00 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <5A21E940.1050309@oracle.com>

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java
The comment for JDK 10 is wrong:

  113         V53(53, 0),   // JDK 1.9: modules, indy string concat
  114         V54(54, 0);   // JDK 10: modules, indy string concat


src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java
Coordinate with Maurizio about a pending conflicting edit on this line.

-- Jon


On 12/01/2017 03:32 PM, Paul Sandoz wrote:
> Hi,
>
> This is an initial review request to increment the class file version of 10 from 53 to 54.
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>
> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>
> Thanks,
> Paul.


From coleen.phillimore at oracle.com  Sat Dec  2 00:11:06 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 1 Dec 2017 19:11:06 -0500
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <3d0a8b1a-4229-6d70-15aa-937c74f0321b@oracle.com>


Can you list the tests that you ran?? I think there are hotspot tests 
that look at classfile version numbers.
thanks,
Coleen

On 12/1/17 6:32 PM, Paul Sandoz wrote:
> Hi,
>
> This is an initial review request to increment the class file version of 10 from 53 to 54.
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>
> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>
> Thanks,
> Paul.


From paul.sandoz at oracle.com  Sat Dec  2 00:25:23 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 1 Dec 2017 16:25:23 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <3d0a8b1a-4229-6d70-15aa-937c74f0321b@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <3d0a8b1a-4229-6d70-15aa-937c74f0321b@oracle.com>
Message-ID: <812BDEB7-E8C5-4EC4-BB52-C4BB346E145E@oracle.com>



> On 1 Dec 2017, at 16:11, coleen.phillimore at oracle.com wrote:
> 
> 
> Can you list the tests that you ran?  I think there are hotspot tests that look at classfile version numbers.

So far defintely jdk tier 1 to 3 tests, i might have run some HS tiers but i don?t recall, i kicked off another test with:

  --job jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2

and will report back.

The only relevant test i could find was the specific test added to HS for the 53 change:

  test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm

but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.

Paul.

> thanks,
> Coleen
> 
> On 12/1/17 6:32 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> This is an initial review request to increment the class file version of 10 from 53 to 54.
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>> 
>> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>> 
>> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>> 
>> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>> 
>> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>> 
>> Thanks,
>> Paul.
> 


From coleen.phillimore at oracle.com  Sat Dec  2 00:36:00 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 1 Dec 2017 19:36:00 -0500
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <812BDEB7-E8C5-4EC4-BB52-C4BB346E145E@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <3d0a8b1a-4229-6d70-15aa-937c74f0321b@oracle.com>
 <812BDEB7-E8C5-4EC4-BB52-C4BB346E145E@oracle.com>
Message-ID: <843a799d-fb1b-3ee6-7372-5ad4b9708669@oracle.com>



On 12/1/17 7:25 PM, Paul Sandoz wrote:
>
>> On 1 Dec 2017, at 16:11, coleen.phillimore at oracle.com wrote:
>>
>>
>> Can you list the tests that you ran?  I think there are hotspot tests that look at classfile version numbers.
> So far defintely jdk tier 1 to 3 tests, i might have run some HS tiers but i don?t recall, i kicked off another test with:
>
>    --job jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2

Try these:

m5 remote-build-and-test -j hs-tier2,hs-tier3,hs-tier4,hs-tier5 -b 
linux-x64-debug,windows-x64-debug

m5 is however you run mach5.?? You can probably skip tier5.

I'll send you the internal wiki to help you analyze known failures.

Coleen

>
> and will report back.
>
> The only relevant test i could find was the specific test added to HS for the 53 change:
>
>    test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm
>
> but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.
>
> Paul.
>
>> thanks,
>> Coleen
>>
>> On 12/1/17 6:32 PM, Paul Sandoz wrote:
>>> Hi,
>>>
>>> This is an initial review request to increment the class file version of 10 from 53 to 54.
>>>
>>>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>>>
>>> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>>>
>>> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>>>
>>> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>>>
>>> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>>>
>>> Thanks,
>>> Paul.


From david.holmes at oracle.com  Sat Dec  2 01:00:23 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 2 Dec 2017 11:00:23 +1000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <b411e7f6-ebf1-44cc-7996-a3ff83cbdce4@oracle.com>

Hi Paul,

test/langtools/tools/javac/classfiles/ClassVersionChecker.java

don't you need to add another row to the matrix:

           int[][] ver =
!                 {{54, -1, -1, -1, -1, -1},
!                  {54, 50, 51, 52, 53, 54},
!                  {54, -1, 51, 52, 53, 54},
!                  {54, -1, -1, 52, 53, 54},
+                  {54, -1, -1, -1, 53, 54};

David

On 2/12/2017 9:32 AM, Paul Sandoz wrote:
> Hi,
> 
> This is an initial review request to increment the class file version of 10 from 53 to 54.
> 
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
> 
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
> 
> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
> 
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
> 
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
> 
> Thanks,
> Paul.
> 

From paul.sandoz at oracle.com  Sat Dec  2 01:50:57 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 1 Dec 2017 17:50:57 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <b411e7f6-ebf1-44cc-7996-a3ff83cbdce4@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <b411e7f6-ebf1-44cc-7996-a3ff83cbdce4@oracle.com>
Message-ID: <80C1206D-FD69-41D9-B225-EFFA58A92791@oracle.com>



> On 1 Dec 2017, at 17:00, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Paul,
> 
> test/langtools/tools/javac/classfiles/ClassVersionChecker.java
> 
> don't you need to add another row to the matrix:
> 
>          int[][] ver =
> !                 {{54, -1, -1, -1, -1, -1},
> !                  {54, 50, 51, 52, 53, 54},
> !                  {54, -1, 51, 52, 53, 54},
> !                  {54, -1, -1, 52, 53, 54},
> +                  {54, -1, -1, -1, 53, 54};
> 

Yes, updated, thanks,
Paul.

From Alan.Bateman at oracle.com  Sun Dec  3 14:13:43 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 3 Dec 2017 14:13:43 +0000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <4e409714-c996-c157-e228-7e09cc0f8551@oracle.com>

On 01/12/2017 23:32, Paul Sandoz wrote:
> Hi,
>
> This is an initial review request to increment the class file version of 10 from 53 to 54.
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
I looked though the changes and I think you've found all the places that 
need update. I assumed pack200 had a check in the native implementation 
but it seems not. At some point we should update ModuleInfoWriter (used 
by the tests) to generate 54.0 class files but that can be done later 
with the changes to the module-info.class parsing that need to follow 
your update.

> :
>
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
In addition, it may be worth mentioning that the classes in the 
jrt-fs.jar will be 52.0 class files so that tools/IDEs running on JDK 8 
can access the contents of a JDK 10 run-time image.


>
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>
That seems right until the issue with these JAR files is resolved.

-Alan

From david.holmes at oracle.com  Sun Dec  3 21:13:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 4 Dec 2017 07:13:29 +1000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>

Hi Paul,

Don't you also need to update:

jdk/src/java.base/share/native/include/classfile_constants.h

#define JVM_CLASSFILE_MAJOR_VERSION 53

> The only relevant test i could find was the specific test added to HS for the 53 change:
> 
>   test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm
> 
> but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.

It is the validation test for the change made in

  hotspot/src/share/vm/classfile/classFileParser.cpp

It's a sanity check to ensure we can actually read the new classfile 
version and haven't made a silly mistake somewhere. Here's one I 
prepared earlier for the nestmates work in the Valhalla project: :)

http://cr.openjdk.java.net/~dholmes/8187302/webrev/hotspot/test/runtime/classFileParserBug/Class54.jasm.html

Cheers,
David

On 2/12/2017 9:32 AM, Paul Sandoz wrote:
> Hi,
> 
> This is an initial review request to increment the class file version of 10 from 53 to 54.
> 
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
> 
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
> 
> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
> 
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
> 
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
> 
> Thanks,
> Paul.
> 

From rschmitt at pobox.com  Mon Dec  4 01:53:40 2017
From: rschmitt at pobox.com (Ryan Schmitt)
Date: Sun, 3 Dec 2017 17:53:40 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>

> The intent is that the class file version will increment with every major
release (regardless of if there are no features that mandate a class file
change).

What is the motivation for doing so?

On Fri, Dec 1, 2017 at 3:32 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> This is an initial review request to increment the class file version of
> 10 from 53 to 54.
>
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-
> version-bump-54/webrev/ <http://cr.openjdk.java.net/~
> psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>
> through searches and changeset history i think i got all the places in the
> source, nice to see it in one place, but please check closely in case i
> missed something.
>
> The intent is that the class file version will increment with every major
> release (regardless of if there are no features that mandate a class file
> change). Ideally we should be doing this early on in the release schedule,
> this case is an exception for 10, and i expect we shall update the version
> for 11 early on (and this patch will help prepare for that)
>
> The lower bound, 6, for the release/source/target options will not change
> for 10. We will for future releases review the policy of "one plus three
> back? in light of the new release process and deal with that separately
> from any version change.
>
> The patch currently clamps the version of javac generated
> module-info.class files to 53. This is due to a restriction in the build
> process where the boot JDK 9 jar tool is used, which will fail when it
> attempts to process 54 versioned module-info.class files. We hope to fix
> that (see JDK-8192771) and i can update the patch accordingly.
>
> Thanks,
> Paul.
>

From forax at univ-mlv.fr  Mon Dec  4 07:20:24 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 04 Dec 2017 07:20:24 +0000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>
Message-ID: <15A7739D-BB87-4F4B-BC3F-3AA6E791BAFD@univ-mlv.fr>



On December 4, 2017 2:53:40 AM GMT+01:00, Ryan Schmitt <rschmitt at pobox.com> wrote:
>> The intent is that the class file version will increment with every
>major
>release (regardless of if there are no features that mandate a class
>file
>change).
>
>What is the motivation for doing so?

Having a simple bijection between the Java version and the class file version.

This is not something new, the version 50 (I let you find the corresponding Java version :) ) has no new bytecode related feature by example. 

cheers,
R?mi 

>
>On Fri, Dec 1, 2017 at 3:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
>wrote:
>
>> Hi,
>>
>> This is an initial review request to increment the class file version
>of
>> 10 from 53 to 54.
>>
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-
>> version-bump-54/webrev/ <http://cr.openjdk.java.net/~
>> psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>>
>> through searches and changeset history i think i got all the places
>in the
>> source, nice to see it in one place, but please check closely in case
>i
>> missed something.
>>
>> The intent is that the class file version will increment with every
>major
>> release (regardless of if there are no features that mandate a class
>file
>> change). Ideally we should be doing this early on in the release
>schedule,
>> this case is an exception for 10, and i expect we shall update the
>version
>> for 11 early on (and this patch will help prepare for that)
>>
>> The lower bound, 6, for the release/source/target options will not
>change
>> for 10. We will for future releases review the policy of "one plus
>three
>> back? in light of the new release process and deal with that
>separately
>> from any version change.
>>
>> The patch currently clamps the version of javac generated
>> module-info.class files to 53. This is due to a restriction in the
>build
>> process where the boot JDK 9 jar tool is used, which will fail when
>it
>> attempts to process 54 versioned module-info.class files. We hope to
>fix
>> that (see JDK-8192771) and i can update the patch accordingly.
>>
>> Thanks,
>> Paul.
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From johan.vos at gluonhq.com  Mon Dec  4 09:06:13 2017
From: johan.vos at gluonhq.com (Johan Vos)
Date: Mon, 04 Dec 2017 09:06:13 +0000
Subject: JEP proposed to target JDK 10 (2017/11/27)
Message-ID: <CABxFH2E4q-yGxc+czNgvqwG9ONJXHRu6f7xSAXFJs2O38htxjQ@mail.gmail.com>

Regarding JEP 313 (removing javah): I'm all in for using javac -h instead
of javah so I think this is a good thing.

However, there is 1 usecase that I ran into last week:
Somewhere in OpenJFX, native code required access to constants in
java.lang.Character. This was previously done by running javah on
Character.class which generated the header file containing the constants.
Since javac works on source files, this approach doesn't work anymore (the
source of Character.java is not in OpenJFX).

A workaround is to have a class in OpenJFX that references the constants
from Character, and then run javac -h on that class.

I consider that workaround sufficient, so removing javah won't make it
impossible to achieve this (maybe unconventional) goal of leveraging Java
constants in native code that has no direct access to the source of the
class containing the constants.

- Johan

From mark.reinhold at oracle.com  Mon Dec  4 16:32:02 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 04 Dec 2017 08:32:02 -0800
Subject: Draft JEP: Time-Based Release Versioning
In-Reply-To: <CACzrW9CHk2b13Tv77MyEdD6pMhm=nWTF1scE4_GHccErAkKJpw@mail.gmail.com>
References: <20171130101151.765472420@eggemoggin.niobe.net>
 <CACzrW9CHk2b13Tv77MyEdD6pMhm=nWTF1scE4_GHccErAkKJpw@mail.gmail.com>
Message-ID: <20171204083202.897849120@eggemoggin.niobe.net>

2017/12/1 9:32:48 -0800, Stephen Colebourne <scolebourne at joda.org>:
> The document doesn't state what happens to the --release flag in
> javac, which seems a linked issue worthy of inclusion.

That's an important issue but it's beyond the scope of this JEP, which
is only intended to address version strings and related information.

We'll work out a policy for `javac --release` in due course, along with
policies for similar topics such as the lifecycle of incubator modules
and deprecation-for-removal.  In the meantime, `javac --release 6` will
continue to work in JDK 10.

- Mark

From mark.reinhold at oracle.com  Mon Dec  4 16:48:54 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon,  4 Dec 2017 08:48:54 -0800 (PST)
Subject: JEP 322: Time-Based Release Versioning
Message-ID: <20171204164854.6559010C4C6@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/322

- Mark

From joe.darcy at oracle.com  Mon Dec  4 17:59:45 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 4 Dec 2017 09:59:45 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <15A7739D-BB87-4F4B-BC3F-3AA6E791BAFD@univ-mlv.fr>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>
 <15A7739D-BB87-4F4B-BC3F-3AA6E791BAFD@univ-mlv.fr>
Message-ID: <6e502db5-3afd-568a-3f6d-172482b47389@oracle.com>

On 12/3/2017 11:20 PM, Remi Forax wrote:
>
> On December 4, 2017 2:53:40 AM GMT+01:00, Ryan Schmitt <rschmitt at pobox.com> wrote:
>>> The intent is that the class file version will increment with every
>> major
>> release (regardless of if there are no features that mandate a class
>> file
>> change).
>>
>> What is the motivation for doing so?
> Having a simple bijection between the Java version and the class file version.
>
> This is not something new, the version 50 (I let you find the corresponding Java version :) ) has no new bytecode related feature by example.
>

The policy of bumping the class file version with each major release 
provide a mechanism for applications and libraries to implicitly encode 
the minimum JDK version whose feature are needed to run the code in 
question.

-Joe

From magnus.ihse.bursie at oracle.com  Mon Dec  4 21:13:22 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2017 22:13:22 +0100
Subject: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171204164854.6559010C4C6@eggemoggin.niobe.net>
References: <20171204164854.6559010C4C6@eggemoggin.niobe.net>
Message-ID: <c67728ad-0110-b796-e2ac-9f9dd5603cfd@oracle.com>

On 2017-12-04 17:48, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/322
Mark,

This looks very good.

Just one remark: In the definition of java.vendor.version, the following 
statement is made:
"Its value has the same format as the |java.version| system property, 
/i.e./, |$VNUM(\-$PRE)?|".

I would recommend removing that, and leaving it entirely up to the 
implementor to provide a generic string. That would solve e.g. Matthias 
Klose's issue of getting a proper Ubuntu version string into OpenJDK.

Also, it might be more sane to leave this property empty if no value is 
given, rather than to assign it to the same value as java.version. It's 
just redundant and will force all users to compare java.vendor.version 
to java.version before deciding to display anything, instead of simply 
checking if it's non-empty.

/Magnus

From paul.sandoz at oracle.com  Mon Dec  4 21:22:55 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 4 Dec 2017 13:22:55 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
Message-ID: <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>



> On 3 Dec 2017, at 13:13, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Paul,
> 
> Don't you also need to update:
> 
> jdk/src/java.base/share/native/include/classfile_constants.h
> 
> #define JVM_CLASSFILE_MAJOR_VERSION 53
> 

I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them.


>> The only relevant test i could find was the specific test added to HS for the 53 change:
>>  test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm
>> but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.
> 
> It is the validation test for the change made in
> 
> hotspot/src/share/vm/classfile/classFileParser.cpp
> 
> It's a sanity check to ensure we can actually read the new classfile version and haven't made a silly mistake somewhere. Here's one I prepared earlier for the nestmates work in the Valhalla project: :)
> 

Rethinking this... the value of such a test is not for the current version, since javac will be producing 54 versioned class files as part of the build well before this test is run by our infrastructure. It is of value when we increase the version and ensure HotSpot does not barf with prior versions.

I will include that Class54 test. Thanks!

Paul.

> http://cr.openjdk.java.net/~dholmes/8187302/webrev/hotspot/test/runtime/classFileParserBug/Class54.jasm.html
> 
> Cheers,
> David
> 
> On 2/12/2017 9:32 AM, Paul Sandoz wrote:
>> Hi,
>> This is an initial review request to increment the class file version of 10 from 53 to 54.
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>> Thanks,
>> Paul.


From david.holmes at oracle.com  Mon Dec  4 21:53:39 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 07:53:39 +1000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
Message-ID: <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>

On 5/12/2017 7:22 AM, Paul Sandoz wrote:
>> On 3 Dec 2017, at 13:13, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Paul,
>>
>> Don't you also need to update:
>>
>> jdk/src/java.base/share/native/include/classfile_constants.h
>>
>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>>
> 
> I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them.

Okay. I don't know the history or use of this file, other than it gets 
included into jvm.h to export the jvm interface to the jdk.

>>> The only relevant test i could find was the specific test added to HS for the 53 change:
>>>   test/hotspot/jtreg/runtime/classFileParserBug/Class53.jasm
>>> but how valuable is such a test? I did not think it terribly useful so i did not add one for 54.
>>
>> It is the validation test for the change made in
>>
>> hotspot/src/share/vm/classfile/classFileParser.cpp
>>
>> It's a sanity check to ensure we can actually read the new classfile version and haven't made a silly mistake somewhere. Here's one I prepared earlier for the nestmates work in the Valhalla project: :)
>>
> 
> Rethinking this... the value of such a test is not for the current version, since javac will be producing 54 versioned class files as part of the build well before this test is run by our infrastructure. It is of value when we increase the version and ensure HotSpot does not barf with prior versions.

Not quite. On the day we edit classFileParser.cpp to increase the 
version number, and we add this jasm test, we immediately test that the 
VM doesn't barf on the new classfile version. This generally 
(previously?) happens well in advance of javac being changed to generate 
new version class files. But yes once that happens the test is somewhat 
less useful - but does later serve as a sanity check that we didn't 
break older version classfile support.

Thanks,
David

> I will include that Class54 test. Thanks!
> 
> Paul.
> 
>> http://cr.openjdk.java.net/~dholmes/8187302/webrev/hotspot/test/runtime/classFileParserBug/Class54.jasm.html
>>
>> Cheers,
>> David
>>
>> On 2/12/2017 9:32 AM, Paul Sandoz wrote:
>>> Hi,
>>> This is an initial review request to increment the class file version of 10 from 53 to 54.
>>>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>>> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>>> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>>> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>>> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>>> Thanks,
>>> Paul.
> 

From paul.hohensee at gmail.com  Mon Dec  4 22:00:44 2017
From: paul.hohensee at gmail.com (Paul Hohensee)
Date: Mon, 4 Dec 2017 17:00:44 -0500
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <6e502db5-3afd-568a-3f6d-172482b47389@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>
 <15A7739D-BB87-4F4B-BC3F-3AA6E791BAFD@univ-mlv.fr>
 <6e502db5-3afd-568a-3f6d-172482b47389@oracle.com>
Message-ID: <CAAsuuZeDY-vtwozx=6xgRYQk19dUNoePOkv2oSSpyGVv9sc__w@mail.gmail.com>

Just to nail this down (i.e., correct me if I'm wrong), this means there
are two version numbers that change in lock step, namely the JDK major
version for the language and libraries and the class file version
(effectively the JVMS major version) for JVMs. A JVM executes class files,
not Java per se, so it guess it makes sense for the JVMS to have its own
version number.

On Mon, Dec 4, 2017 at 12:59 PM, joe darcy <joe.darcy at oracle.com> wrote:

> On 12/3/2017 11:20 PM, Remi Forax wrote:
>
>>
>> On December 4, 2017 2:53:40 AM GMT+01:00, Ryan Schmitt <
>> rschmitt at pobox.com> wrote:
>>
>>> The intent is that the class file version will increment with every
>>>>
>>> major
>>> release (regardless of if there are no features that mandate a class
>>> file
>>> change).
>>>
>>> What is the motivation for doing so?
>>>
>> Having a simple bijection between the Java version and the class file
>> version.
>>
>> This is not something new, the version 50 (I let you find the
>> corresponding Java version :) ) has no new bytecode related feature by
>> example.
>>
>>
> The policy of bumping the class file version with each major release
> provide a mechanism for applications and libraries to implicitly encode the
> minimum JDK version whose feature are needed to run the code in question.
>
> -Joe
>

From mark.reinhold at oracle.com  Mon Dec  4 22:11:11 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 04 Dec 2017 14:11:11 -0800
Subject: JEP 322: Time-Based Release Versioning
In-Reply-To: <c67728ad-0110-b796-e2ac-9f9dd5603cfd@oracle.com>
References: <20171204164854.6559010C4C6@eggemoggin.niobe.net>
 <c67728ad-0110-b796-e2ac-9f9dd5603cfd@oracle.com>
Message-ID: <20171204141111.499872521@eggemoggin.niobe.net>

2017/12/4 13:13:22 -0800, magnus.ihse.bursie at oracle.com:
> On 2017-12-04 17:48, mark.reinhold at oracle.com wrote:
>> New JEP Candidate: http://openjdk.java.net/jeps/322
> 
> This looks very good.

Thanks.

> Just one remark: In the definition of java.vendor.version, the following 
> statement is made:
> "Its value has the same format as the |java.version| system property, 
> /i.e./, |$VNUM(\-$PRE)?|".
> 
> I would recommend removing that, and leaving it entirely up to the 
> implementor to provide a generic string.

Okay.  I'll just check that, if specified, it only contains [:graph:]
characters.

>                                          That would solve e.g. Matthias 
> Klose's issue of getting a proper Ubuntu version string into OpenJDK.

I'm not that sure it will -- Matthias will have to comment.

> Also, it might be more sane to leave this property empty if no value is 
> given, rather than to assign it to the same value as java.version. It's 
> just redundant and will force all users to compare java.vendor.version 
> to java.version before deciding to display anything, instead of simply 
> checking if it's non-empty.

Okay, will do.

Thanks,
- Mark

From paul.sandoz at oracle.com  Mon Dec  4 22:33:57 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 4 Dec 2017 14:33:57 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
 <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
Message-ID: <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>



> On 4 Dec 2017, at 13:53, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 5/12/2017 7:22 AM, Paul Sandoz wrote:
>>> On 3 Dec 2017, at 13:13, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Paul,
>>> 
>>> Don't you also need to update:
>>> 
>>> jdk/src/java.base/share/native/include/classfile_constants.h
>>> 
>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>>> 
>> I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them.
> 
> Okay. I don't know the history or use of this file, other than it gets included into jvm.h to export the jvm interface to the jdk.
> 

And classfile_constants.h is also distributed with the image. I am unsure of the intent/history. To play it safe i will just bump the number.

Paul.



From paul.sandoz at oracle.com  Mon Dec  4 23:21:54 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 4 Dec 2017 15:21:54 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <CAAsuuZeDY-vtwozx=6xgRYQk19dUNoePOkv2oSSpyGVv9sc__w@mail.gmail.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <CABz7JBNrnaL-jo3n6tr=QRLELcMEnvBMybL_jfdk1OJk7egZ8g@mail.gmail.com>
 <15A7739D-BB87-4F4B-BC3F-3AA6E791BAFD@univ-mlv.fr>
 <6e502db5-3afd-568a-3f6d-172482b47389@oracle.com>
 <CAAsuuZeDY-vtwozx=6xgRYQk19dUNoePOkv2oSSpyGVv9sc__w@mail.gmail.com>
Message-ID: <02D2B1B4-FE58-4363-86D4-FC3D233F62A5@oracle.com>



> On 4 Dec 2017, at 14:00, Paul Hohensee <paul.hohensee at gmail.com <mailto:paul.hohensee at gmail.com>> wrote:
> 
> Just to nail this down (i.e., correct me if I'm wrong), this means there are two version numbers that change in lock step, namely the JDK major version for the language and libraries and the class file version (effectively the JVMS major version) for JVMs.

Yes.

Note that there are other changes that are not included in this patch. You may have noticed that javac was already updated to support 1.10/10 (aliased to map to class file version 53) and symbol files were already present to support the ?release flag.

For the next version bump it?s not clear to me yet how far we can go in one patch, updating all of javac too, that would be nice, but it might be preferable to separate some aspects out such as symbol file generation, which may require more time to complete. I hope we can finesse and optimize this process over the next couple iterations.

Paul.

> A JVM executes class files, not Java per se, so it guess it makes sense for the JVMS to have its own version number.
> 
> On Mon, Dec 4, 2017 at 12:59 PM, joe darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
> On 12/3/2017 11:20 PM, Remi Forax wrote:
> 
> On December 4, 2017 2:53:40 AM GMT+01:00, Ryan Schmitt <rschmitt at pobox.com <mailto:rschmitt at pobox.com>> wrote:
> The intent is that the class file version will increment with every
> major
> release (regardless of if there are no features that mandate a class
> file
> change).
> 
> What is the motivation for doing so?
> Having a simple bijection between the Java version and the class file version.
> 
> This is not something new, the version 50 (I let you find the corresponding Java version :) ) has no new bytecode related feature by example.
> 
> 
> The policy of bumping the class file version with each major release provide a mechanism for applications and libraries to implicitly encode the minimum JDK version whose feature are needed to run the code in question.
> 
> -Joe
> 


From david.holmes at oracle.com  Mon Dec  4 23:26:13 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 09:26:13 +1000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
 <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
 <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>
Message-ID: <5c603b8a-5889-6563-015f-0e67eed08c88@oracle.com>

On 5/12/2017 8:33 AM, Paul Sandoz wrote:
>> On 4 Dec 2017, at 13:53, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 5/12/2017 7:22 AM, Paul Sandoz wrote:
>>>> On 3 Dec 2017, at 13:13, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Paul,
>>>>
>>>> Don't you also need to update:
>>>>
>>>> jdk/src/java.base/share/native/include/classfile_constants.h
>>>>
>>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>>>>
>>> I cannot find any usages for this constant, nor JVM_CLASSFILE_MINOR_VERSION. I will remove them.
>>
>> Okay. I don't know the history or use of this file, other than it gets included into jvm.h to export the jvm interface to the jdk.
>>
> 
> And classfile_constants.h is also distributed with the image. I am unsure of the intent/history. To play it safe i will just bump the number.

Hmmm - that seems wrong. jvm.h is not an exported external interface 
AFAIK. And we just moved it so I don't think it will get distributed any 
more. Hmm that also suggests that classfile_constants.h may be in the 
wrong place ... I'll take this up elsewhere.

David

> Paul.
> 
> 

From mark.reinhold at oracle.com  Mon Dec  4 23:37:52 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 04 Dec 2017 15:37:52 -0800
Subject: JEP proposed to target JDK 10  (2017/11/27)
In-Reply-To: <20171127140851.148860946@eggemoggin.niobe.net>
References: <20171127140851.148860946@eggemoggin.niobe.net>
Message-ID: <20171204153752.157208876@eggemoggin.niobe.net>

2017/11/27 14:08:51 -0800, mark.reinhold at oracle.com:
> The following JEP has been placed into the "Proposed to Target" state
> by its owner after discussion and review:
> 
>   313: Remove the Native-Header Generation Tool (javah)
>        http://openjdk.java.net/jeps/313
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Monday,
> 4 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From mandy.chung at oracle.com  Mon Dec  4 23:47:30 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 4 Dec 2017 15:47:30 -0800
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <5c603b8a-5889-6563-015f-0e67eed08c88@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
 <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
 <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>
 <5c603b8a-5889-6563-015f-0e67eed08c88@oracle.com>
Message-ID: <ba17e434-6ca6-64cb-cbf4-fd3e53f51532@oracle.com>



On 12/4/17 3:26 PM, David Holmes wrote:
>
>> And classfile_constants.h is also distributed with the image. I am 
>> unsure of the intent/history. To play it safe i will just bump the 
>> number.
>
> Hmmm - that seems wrong. jvm.h is not an exported external interface 
> AFAIK. And we just moved it so I don't think it will get distributed 
> any more. Hmm that also suggests that classfile_constants.h may be in 
> the wrong place ... I'll take this up elsewhere.
>

classfile_constants.h was added to ${java.home}/include in JDK 6 [1].?? 
It was intended for BCI native agent to use.

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-5107600

From david.holmes at oracle.com  Tue Dec  5 00:10:42 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 5 Dec 2017 10:10:42 +1000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <ba17e434-6ca6-64cb-cbf4-fd3e53f51532@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
 <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
 <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>
 <5c603b8a-5889-6563-015f-0e67eed08c88@oracle.com>
 <ba17e434-6ca6-64cb-cbf4-fd3e53f51532@oracle.com>
Message-ID: <025364af-0b31-f493-0e50-f43b3095d791@oracle.com>

On 5/12/2017 9:47 AM, mandy chung wrote:
> On 12/4/17 3:26 PM, David Holmes wrote:
>>
>>> And classfile_constants.h is also distributed with the image. I am 
>>> unsure of the intent/history. To play it safe i will just bump the 
>>> number.
>>
>> Hmmm - that seems wrong. jvm.h is not an exported external interface 
>> AFAIK. And we just moved it so I don't think it will get distributed 
>> any more. Hmm that also suggests that classfile_constants.h may be in 
>> the wrong place ... I'll take this up elsewhere.
>>
> 
> classfile_constants.h was added to ${java.home}/include in JDK 6 [1].   
> It was intended for BCI native agent to use.

Thanks Mandy!

In that case Paul must not remove JVM_CLASSFILE_MAJOR_VERSION etc. but 
must update it.

David

> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-5107600

From Alan.Bateman at oracle.com  Tue Dec  5 14:39:58 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Dec 2017 14:39:58 +0000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <ba17e434-6ca6-64cb-cbf4-fd3e53f51532@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
 <6031348b-8b53-25d8-e49c-f2bbb7cf5f1e@oracle.com>
 <05CA761E-C18F-425A-9BAD-FBFAAE6033D8@oracle.com>
 <d2a6a2c6-4926-8b55-314f-316e5671828a@oracle.com>
 <D5AF6670-80FE-4590-A112-F4953FC52F93@oracle.com>
 <5c603b8a-5889-6563-015f-0e67eed08c88@oracle.com>
 <ba17e434-6ca6-64cb-cbf4-fd3e53f51532@oracle.com>
Message-ID: <3648b51c-3fdb-15cf-b7b0-3278ae208b46@oracle.com>



On 04/12/2017 23:47, mandy chung wrote:
>
>
> On 12/4/17 3:26 PM, David Holmes wrote:
>>
>>> And classfile_constants.h is also distributed with the image. I am 
>>> unsure of the intent/history. To play it safe i will just bump the 
>>> number.
>>
>> Hmmm - that seems wrong. jvm.h is not an exported external interface 
>> AFAIK. And we just moved it so I don't think it will get distributed 
>> any more. Hmm that also suggests that classfile_constants.h may be in 
>> the wrong place ... I'll take this up elsewhere.
>>
>
> classfile_constants.h was added to ${java.home}/include in JDK 6 
> [1].?? It was intended for BCI native agent to use.
Yes, the now defunct HPROF agent and its buddy java_crw_demo used this, 
also the old verifier. Nothing to do with Paul's update then it's worth 
seeing if there are usages outside of the JDK, it may be that it can be 
dropped from the include directory in the future.

-Alan

From mark.reinhold at oracle.com  Tue Dec  5 15:33:16 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 05 Dec 2017 07:33:16 -0800
Subject: JEP proposed to target JDK 10  (2017/12/5)
Message-ID: <20171205073316.302341109@eggemoggin.niobe.net>

The following JEP is Proposed to Target JDK 10:

  314: Additional Unicode Language-Tag Extensions
       http://openjdk.java.net/jeps/314

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 16:00 UTC on Tuesday,
12 December, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Tue Dec  5 16:18:23 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue,  5 Dec 2017 08:18:23 -0800 (PST)
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
Message-ID: <20171205161823.B8F9410C794@eggemoggin.niobe.net>

JEP: http://openjdk.java.net/jeps/322
CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
RFE: https://bugs.openjdk.java.net/browse/JDK-8192833

Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/

The substantive changes are in these files:

  make/autoconf/jdk-version.m4
  make/autoconf/version-numbers
  src/java.base/share/classes/java/lang/Runtime.java
  src/java.base/share/classes/java/lang/VersionProps.java.template
  test/jdk/java/lang/Runtime/Version/Basic.java

Otherwise, this is mostly a straightforward renaming of identifiers
involving (major|minor|security) to (feature|interim|update).

We've already forked HotSpot for JDK 10 stabilization, so to reduce risk
this patch does not attempt to rename all internal identifiers of the
form .*(major|minor|security).* in the HotSpot code.  That can be done
as a cleanup later on.

jdk-tier{1,2,3} and hs-tier1 test runs are clean.

Thanks,
- Mark

From maurizio.cimadamore at oracle.com  Tue Dec  5 18:23:59 2017
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 5 Dec 2017 18:23:59 +0000
Subject: [10] RFR 8191510: Bump classfile version number to 54
In-Reply-To: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
References: <C7CC3B00-E625-4E61-8277-E0ACDCAE6098@oracle.com>
Message-ID: <da9d7f2f-0252-a786-2eb9-e7a354f8a244@oracle.com>

Langtools changes look good - sorry for the delay.

Maurizio


On 01/12/17 23:32, Paul Sandoz wrote:
> Hi,
>
> This is an initial review request to increment the class file version of 10 from 53 to 54.
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8188870-version-bump-54/webrev/>
>
> through searches and changeset history i think i got all the places in the source, nice to see it in one place, but please check closely in case i missed something.
>
> The intent is that the class file version will increment with every major release (regardless of if there are no features that mandate a class file change). Ideally we should be doing this early on in the release schedule, this case is an exception for 10, and i expect we shall update the version for 11 early on (and this patch will help prepare for that)
>
> The lower bound, 6, for the release/source/target options will not change for 10. We will for future releases review the policy of "one plus three back? in light of the new release process and deal with that separately from any version change.
>
> The patch currently clamps the version of javac generated module-info.class files to 53. This is due to a restriction in the build process where the boot JDK 9 jar tool is used, which will fail when it attempts to process 54 versioned module-info.class files. We hope to fix that (see JDK-8192771) and i can update the patch accordingly.
>
> Thanks,
> Paul.


From mark.reinhold at oracle.com  Tue Dec  5 22:50:35 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 05 Dec 2017 14:50:35 -0800
Subject: JEP proposed to target JDK 10  (2017/12/5, #2)
Message-ID: <20171205145035.32009950@eggemoggin.niobe.net>

The following JEP is Proposed to Target JDK 10:

  319: Root Certificates
       http://openjdk.java.net/jeps/319

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Tuesday,
12 December, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From erik.joelsson at oracle.com  Tue Dec  5 23:48:12 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 5 Dec 2017 15:48:12 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <f1670f57-0e69-cdf2-67d8-fe6691337f0d@oracle.com>

Build changes look good. Noticed an indentation mistake in 
jdk-version.m4 line 329.

/Erik


On 2017-12-05 08:18, mark.reinhold at oracle.com wrote:
> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
>
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
>
> The substantive changes are in these files:
>
>    make/autoconf/jdk-version.m4
>    make/autoconf/version-numbers
>    src/java.base/share/classes/java/lang/Runtime.java
>    src/java.base/share/classes/java/lang/VersionProps.java.template
>    test/jdk/java/lang/Runtime/Version/Basic.java
>
> Otherwise, this is mostly a straightforward renaming of identifiers
> involving (major|minor|security) to (feature|interim|update).
>
> We've already forked HotSpot for JDK 10 stabilization, so to reduce risk
> this patch does not attempt to rename all internal identifiers of the
> form .*(major|minor|security).* in the HotSpot code.  That can be done
> as a cleanup later on.
>
> jdk-tier{1,2,3} and hs-tier1 test runs are clean.
>
> Thanks,
> - Mark


From paul.sandoz at oracle.com  Wed Dec  6 00:44:44 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 5 Dec 2017 16:44:44 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <C7F8715F-C597-4508-9FFD-C937955D26F2@oracle.com>

+1 on the library bits.

Paul.

> On 5 Dec 2017, at 08:18, mark.reinhold at oracle.com wrote:
> 
> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
> 
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
> 
> The substantive changes are in these files:
> 
>  make/autoconf/jdk-version.m4
>  make/autoconf/version-numbers
>  src/java.base/share/classes/java/lang/Runtime.java
>  src/java.base/share/classes/java/lang/VersionProps.java.template
>  test/jdk/java/lang/Runtime/Version/Basic.java
> 
> Otherwise, this is mostly a straightforward renaming of identifiers
> involving (major|minor|security) to (feature|interim|update).
> 
> We've already forked HotSpot for JDK 10 stabilization, so to reduce risk
> this patch does not attempt to rename all internal identifiers of the
> form .*(major|minor|security).* in the HotSpot code.  That can be done
> as a cleanup later on.
> 
> jdk-tier{1,2,3} and hs-tier1 test runs are clean.
> 
> Thanks,
> - Mark


From tim.bell at oracle.com  Wed Dec  6 02:05:20 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 05 Dec 2017 18:05:20 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <5A275060.9020907@oracle.com>

Mark:

> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
>
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
>
> The substantive changes are in these files:
>
>    make/autoconf/jdk-version.m4
>    make/autoconf/version-numbers
>    src/java.base/share/classes/java/lang/Runtime.java
>    src/java.base/share/classes/java/lang/VersionProps.java.template
>    test/jdk/java/lang/Runtime/Version/Basic.java
>
> Otherwise, this is mostly a straightforward renaming of identifiers
> involving (major|minor|security) to (feature|interim|update).

Looks good.

Tim



From mandy.chung at oracle.com  Wed Dec  6 03:38:03 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 5 Dec 2017 19:38:03 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <9d92f82c-f1ce-dd45-9095-c5926bffb640@oracle.com>



On 12/5/17 8:18 AM, mark.reinhold at oracle.com wrote:
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/

@since 10 is missing in the new methods added in Runtime.Version methods.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
 ??? The fix for JDK-8185130 was pushed today that has a couple new 
calls to major/minor method.?? This file and GenerateJLIClassesPlugin 
will need to be updated once you pull down the changeset.

A few MRJAR tests still call the deprecated methods (e.g. 
test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java).? It's 
okay to leave it for future cleanup.?? I mentioned it just in case you 
intend to do the renaming in the tests as well.

Otherwise looks good.

Mandy
[1] http://hg.openjdk.java.net/jdk/jdk/rev/a5cadeee8763

From david.holmes at oracle.com  Wed Dec  6 04:01:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Dec 2017 14:01:31 +1000
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <ff909176-152d-64d7-1a6c-f119d2886f7d@oracle.com>

Hi Mark,

On 6/12/2017 2:18 AM, mark.reinhold at oracle.com wrote:
> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
> 
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
> 
> The substantive changes are in these files:
> 
>    make/autoconf/jdk-version.m4
>    make/autoconf/version-numbers
>    src/java.base/share/classes/java/lang/Runtime.java

I've commented in the CSR that I would have expected the 
no-longer-applicable Runtime.Version methods to be deprecated, not 
outright removed (and replaced with newly named methods).

David

>    src/java.base/share/classes/java/lang/VersionProps.java.template
>    test/jdk/java/lang/Runtime/Version/Basic.java
> 
> Otherwise, this is mostly a straightforward renaming of identifiers
> involving (major|minor|security) to (feature|interim|update).
> 
> We've already forked HotSpot for JDK 10 stabilization, so to reduce risk
> this patch does not attempt to rename all internal identifiers of the
> form .*(major|minor|security).* in the HotSpot code.  That can be done
> as a cleanup later on.
> 
> jdk-tier{1,2,3} and hs-tier1 test runs are clean.
> 
> Thanks,
> - Mark
> 

From mark.reinhold at oracle.com  Wed Dec  6 04:27:47 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 05 Dec 2017 20:27:47 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <ff909176-152d-64d7-1a6c-f119d2886f7d@oracle.com>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
 <ff909176-152d-64d7-1a6c-f119d2886f7d@oracle.com>
Message-ID: <20171205202747.226246415@eggemoggin.niobe.net>

2017/12/5 20:01:31 -0800, david.holmes at oracle.com:
> I've commented in the CSR that I would have expected the 
> no-longer-applicable Runtime.Version methods to be deprecated, not 
> outright removed (and replaced with newly named methods).

The old methods are still there, and are deprecated, not for removal.

Are you reading the patch correctly?  Line-by-line it does look like
the existing methods are removed, but scroll down and you'll see them
restored.

- Mark

From mark.reinhold at oracle.com  Wed Dec  6 04:29:55 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 05 Dec 2017 20:29:55 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <9d92f82c-f1ce-dd45-9095-c5926bffb640@oracle.com>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
 <9d92f82c-f1ce-dd45-9095-c5926bffb640@oracle.com>
Message-ID: <20171205202955.81293727@eggemoggin.niobe.net>

2017/12/5 19:38:03 -0800, mandy.chung at oracle.com:
> On 12/5/17 8:18 AM, mark.reinhold at oracle.com wrote:
>> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
>> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
> 
> @since 10 is missing in the new methods added in Runtime.Version methods.

Oops!  I'll add them.

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
>   The fix for JDK-8185130 was pushed today that has a couple new 
> calls to major/minor method. This file and GenerateJLIClassesPlugin 
> will need to be updated once you pull down the changeset.

Thanks for the warning.  I'll fix this when I rebase.

> A few MRJAR tests still call the deprecated methods (e.g. 
> test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java). It's 
> okay to leave it for future cleanup. I mentioned it just in case you 
> intend to do the renaming in the tests as well.

I don't plan to rename invocations of the old methods in existing tests,
other than what I've done in the test for `Runtime.Version` itself.

Thanks!

- Mark

From david.holmes at oracle.com  Wed Dec  6 04:39:12 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 6 Dec 2017 14:39:12 +1000
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205202747.226246415@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
 <ff909176-152d-64d7-1a6c-f119d2886f7d@oracle.com>
 <20171205202747.226246415@eggemoggin.niobe.net>
Message-ID: <ee680125-8e6c-9f8b-89a9-662c547c8130@oracle.com>

On 6/12/2017 2:27 PM, mark.reinhold at oracle.com wrote:
> 2017/12/5 20:01:31 -0800, david.holmes at oracle.com:
>> I've commented in the CSR that I would have expected the
>> no-longer-applicable Runtime.Version methods to be deprecated, not
>> outright removed (and replaced with newly named methods).
> 
> The old methods are still there, and are deprecated, not for removal.
> 
> Are you reading the patch correctly?  Line-by-line it does look like
> the existing methods are removed, but scroll down and you'll see them
> restored.

Sorry. Tricked by the side-by-side diffs. I didn't see them re-added at 
the bottom.

David

> - Mark
> 

From iris.clark at oracle.com  Wed Dec  6 05:32:40 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 5 Dec 2017 21:32:40 -0800 (PST)
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <<20171205161823.B8F9410C794@eggemoggin.niobe.net>>
References: <<20171205161823.B8F9410C794@eggemoggin.niobe.net>>
Message-ID: <433ac098-f08f-4d64-8ed5-d18483f6a4ca@default>

Hi, Mark.

> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
>
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/

These changes look good to me.  

In addition to jdk/jdk code you'll also need to make a minor update to the tag regex in jcheck.py, line 147 to allow for $PATCH:

    http://hg.openjdk.java.net/code-tools/jcheck/file/tip/jcheck.py

change:  (\.[0-9]){0,3})
to:           (\.[0-9]){0,4})

Thanks,
Iris

From magnus.ihse.bursie at oracle.com  Wed Dec  6 11:41:34 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 6 Dec 2017 12:41:34 +0100
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
Message-ID: <6e0679d7-1a5e-e246-914c-c1ff937c2585@oracle.com>

On 2017-12-05 17:18, mark.reinhold at oracle.com wrote:
> JEP: http://openjdk.java.net/jeps/322
> CSR: https://bugs.openjdk.java.net/browse/JDK-8192855
> RFE: https://bugs.openjdk.java.net/browse/JDK-8192833
>
> Specdiff: http://cr.openjdk.java.net/~mr/jeps/322/specdiff/
> Webrev:   http://cr.openjdk.java.net/~mr/jeps/322/rev/
Looks good to me.

/Magnus
>
> The substantive changes are in these files:
>
>    make/autoconf/jdk-version.m4
>    make/autoconf/version-numbers
>    src/java.base/share/classes/java/lang/Runtime.java
>    src/java.base/share/classes/java/lang/VersionProps.java.template
>    test/jdk/java/lang/Runtime/Version/Basic.java
>
> Otherwise, this is mostly a straightforward renaming of identifiers
> involving (major|minor|security) to (feature|interim|update).
>
> We've already forked HotSpot for JDK 10 stabilization, so to reduce risk
> this patch does not attempt to rename all internal identifiers of the
> form .*(major|minor|security).* in the HotSpot code.  That can be done
> as a cleanup later on.
>
> jdk-tier{1,2,3} and hs-tier1 test runs are clean.
>
> Thanks,
> - Mark


From lennart.borjeson at cinnober.com  Wed Dec  6 11:56:10 2017
From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=)
Date: Wed, 6 Dec 2017 11:56:10 +0000
Subject: JEP proposed to target JDK 10  (2017/11/28)
In-Reply-To: <20171128144440.468654491@eggemoggin.niobe.net>
References: <20171128144440.468654491@eggemoggin.niobe.net>
Message-ID: <C4053DEB-0B77-4C2C-AB3A-32CA36B69561@cinnober.com>

28 nov. 2017 kl. 23:44 skrev mark.reinhold at oracle.com:
> 
> The following JEP has been placed into the "Proposed to Target" state
> by its owner after discussion and review:
> 
>  317: Experimental Java-Based JIT Compiler
>       http://openjdk.java.net/jeps/317
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
> 5 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.
> 
> - Mark
> 
> 
> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html


It would really be nice if Graal could be enabled on MacOS, too.

Since it already is in the source, and maintained by the developers, it would also primarily be "a testing and debugging effort", and as such, probably only a small extension of the Linux/x86 effort.

Please?

/Lennart

From mark.reinhold at oracle.com  Wed Dec  6 18:36:13 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 06 Dec 2017 10:36:13 -0800
Subject: 10 RFR 8192833: JEP 322: Time-Based Release Versioning
In-Reply-To: <f1670f57-0e69-cdf2-67d8-fe6691337f0d@oracle.com>
References: <20171205161823.B8F9410C794@eggemoggin.niobe.net>
 <f1670f57-0e69-cdf2-67d8-fe6691337f0d@oracle.com>
Message-ID: <20171206103613.333368741@eggemoggin.niobe.net>

2017/12/5 15:48:12 -0800, erik.joelsson at oracle.com:
> Build changes look good. Noticed an indentation mistake in 
> jdk-version.m4 line 329.

Fixed -- thanks.

- Mark

From mark.reinhold at oracle.com  Wed Dec  6 22:25:55 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 06 Dec 2017 17:25:55 -0500
Subject: JEP proposed to target JDK 10  (2017/12/6)
Message-ID: <20171206172555.202701390@eggemoggin.niobe.net>

The following JEP is Proposed to Target JDK 10:

  322: Time-Based Release Versioning
       http://openjdk.java.net/jeps/322

Feedback on this proposal is more than welcome, as are reasoned
objections.  If no such objections are raised by 23:00 UTC on Wednesday,
13 December, or if they're raised and then satisfactorily answered, then
per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Wed Dec  6 22:37:43 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 06 Dec 2017 17:37:43 -0500
Subject: JEP proposed to target JDK 10  (2017/11/28)
In-Reply-To: <20171128144440.468654491@eggemoggin.niobe.net>
References: <20171128144440.468654491@eggemoggin.niobe.net>
Message-ID: <20171206173743.461223088@eggemoggin.niobe.net>

2017/11/28 17:44:40 -0500, mark.reinhold at oracle.com:
> The following JEP has been placed into the "Proposed to Target" state
> by its owner after discussion and review:
> 
>   317: Experimental Java-Based JIT Compiler
>        http://openjdk.java.net/jeps/317
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
> 5 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From vladimir.kozlov at oracle.com  Thu Dec  7 02:27:23 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 6 Dec 2017 18:27:23 -0800
Subject: JEP proposed to target JDK 10 (2017/11/28)
In-Reply-To: <C4053DEB-0B77-4C2C-AB3A-32CA36B69561@cinnober.com>
References: <20171128144440.468654491@eggemoggin.niobe.net>
 <C4053DEB-0B77-4C2C-AB3A-32CA36B69561@cinnober.com>
Message-ID: <1a6d2faa-a067-1d16-82ad-4dec7bd271cc@oracle.com>

Hi, Lennart

We can't officially "support" a feature, even experimental, without proper testing. For JDK 10 we 
tested Graal as JIT compiler only for Linux-x64 based on available resources. We are planning to add 
support on other platforms in future releases. With current short Java release circle it should not 
be long time.

Regards,
Vladimir

On 12/6/17 3:56 AM, Lennart B?rjeson wrote:
> 28 nov. 2017 kl. 23:44 skrev mark.reinhold at oracle.com:
>>
>> The following JEP has been placed into the "Proposed to Target" state
>> by its owner after discussion and review:
>>
>>   317: Experimental Java-Based JIT Compiler
>>        http://openjdk.java.net/jeps/317
>>
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
>> 5 December, or if they're raised and then satisfactorily answered, then
>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.
>>
>> - Mark
>>
>>
>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
> 
> 
> It would really be nice if Graal could be enabled on MacOS, too.
> 
> Since it already is in the source, and maintained by the developers, it would also primarily be "a testing and debugging effort", and as such, probably only a small extension of the Linux/x86 effort.
> 
> Please?
> 
> /Lennart
> 

From doug.simon at oracle.com  Thu Dec  7 09:08:08 2017
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 7 Dec 2017 10:08:08 +0100
Subject: JEP proposed to target JDK 10 (2017/11/28)
In-Reply-To: <1a6d2faa-a067-1d16-82ad-4dec7bd271cc@oracle.com>
References: <20171128144440.468654491@eggemoggin.niobe.net>
 <C4053DEB-0B77-4C2C-AB3A-32CA36B69561@cinnober.com>
 <1a6d2faa-a067-1d16-82ad-4dec7bd271cc@oracle.com>
Message-ID: <3D130034-0E48-4925-B5E2-C1B1AB682482@oracle.com>

Hi Lennart,

Even though it's not officially supported, it seems to work on macOS. With the latest macOS jdk 10 EA build (http://jdk.java.net/10/):

~$ java -version
java version "10-ea"
Java(TM) SE Runtime Environment (build 10-ea+34)
Java HotSpot(TM) 64-Bit Server VM (build 10-ea+34, mixed mode)

~$ java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:+BootstrapJVMCI -Dgraal.PrintCompilation=true -version
Bootstrapping JVMCIHotSpotCompilation-146  Ljava/lang/String; hashCode  ()I  |  349ms    49B   288B 1240kB

-Doug

> On 7 Dec 2017, at 03:27, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Hi, Lennart
> 
> We can't officially "support" a feature, even experimental, without proper testing. For JDK 10 we tested Graal as JIT compiler only for Linux-x64 based on available resources. We are planning to add support on other platforms in future releases. With current short Java release circle it should not be long time.
> 
> Regards,
> Vladimir
> 
> On 12/6/17 3:56 AM, Lennart B?rjeson wrote:
>> 28 nov. 2017 kl. 23:44 skrev mark.reinhold at oracle.com:
>>> 
>>> The following JEP has been placed into the "Proposed to Target" state
>>> by its owner after discussion and review:
>>> 
>>>  317: Experimental Java-Based JIT Compiler
>>>       http://openjdk.java.net/jeps/317
>>> 
>>> Feedback on this proposal is more than welcome, as are reasoned
>>> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
>>> 5 December, or if they're raised and then satisfactorily answered, then
>>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.
>>> 
>>> - Mark
>>> 
>>> 
>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>> It would really be nice if Graal could be enabled on MacOS, too.
>> Since it already is in the source, and maintained by the developers, it would also primarily be "a testing and debugging effort", and as such, probably only a small extension of the Linux/x86 effort.
>> Please?
>> /Lennart


From lennart.borjeson at cinnober.com  Thu Dec  7 09:15:37 2017
From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=)
Date: Thu, 7 Dec 2017 09:15:37 +0000
Subject: JEP proposed to target JDK 10 (2017/11/28)
In-Reply-To: <3D130034-0E48-4925-B5E2-C1B1AB682482@oracle.com>
References: <20171128144440.468654491@eggemoggin.niobe.net>
 <C4053DEB-0B77-4C2C-AB3A-32CA36B69561@cinnober.com>
 <1a6d2faa-a067-1d16-82ad-4dec7bd271cc@oracle.com>
 <3D130034-0E48-4925-B5E2-C1B1AB682482@oracle.com>
Message-ID: <C392A381-E500-48D9-93A6-72312E845ACB@cinnober.com>



> 7 dec. 2017 kl. 10:08 skrev Doug Simon <doug.simon at oracle.com>:
> 
> Hi Lennart,
> 
> Even though it's not officially supported, it seems to work on macOS. With the latest macOS jdk 10 EA build (http://jdk.java.net/10/):
> 
> ~$ java -version
> java version "10-ea"
> Java(TM) SE Runtime Environment (build 10-ea+34)
> Java HotSpot(TM) 64-Bit Server VM (build 10-ea+34, mixed mode)
> 
> ~$ java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal -XX:+BootstrapJVMCI -Dgraal.PrintCompilation=true -version
> Bootstrapping JVMCIHotSpotCompilation-146  Ljava/lang/String; hashCode  ()I  |  349ms    49B   288B 1240kB
> 

Oh yes, I know it works in the EA! At least well enough for my purposes.

It used to be in the EA of jdk 9, too, but was removed in the final release, and I was hoping it would remain this time. I shall just have to bide my time.

/Lennart


From mark.reinhold at oracle.com  Thu Dec  7 15:58:44 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  7 Dec 2017 07:58:44 -0800 (PST)
Subject: JDK 10 enters Rampdown Phase One in one week
Message-ID: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>

JDK 10 will enter Rampdown Phase One in one week, on Thursday, 14
December.  Changes intended for JDK 10 should be in the main-line
repository (http://hg.openjdk.java.net/jdk/jdk), or one of the two
repositories that feed it (jdk/hs or jdk/client), by 16:00 UTC on
that day [1].

After next week's build (jdk-10+36) is promoted we'll open a jdk/jdk10
repository, initialized from that tag in the main line, to host the
remaining stabilization work for JDK 10.  This will include any last
changes that trickle in from jdk/hs and jdk/client, most likely early
the following week.  Further JDK 10 EA builds will be done from this
repository.

We'll semi-automatically merge changes pushed to JDK 10 into the
main-line jdk/jdk repository, as we did for the transition from JDK 9
to JDK 10.  This means that:

  - If you make a change in JDK 10 then you needn't do any extra
    work to get it into the main line, though if a merge conflict
    arises then you might be asked to help resolve it.

  - If you need to make a change in both JDK 10 and the main line
    then just push it to JDK 10, and wait for the automatic merge
    to complete.

Changes pushed into the main-line repositories (jdk/{jdk,client,hs})
after the above deadline will be destined for JDK 11 unless they're
back-ported.  When back-ports turn out to be necessary then they'll be
easier to do than in the past: Duplicate bugids are permitted in the
new repository layout, so a change can be pushed to both code lines
using the same bugid if needed.

The Rampdown Phase One process will be similar to that of JDK 9 [2].
I'll post a detailed proposal for that shortly.

- Mark


[1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+10+Rampdown+Phase+One&iso=20171214T16
[2] http://openjdk.java.net/projects/jdk9/rdp-1

From james.laskey at oracle.com  Thu Dec  7 22:45:50 2017
From: james.laskey at oracle.com (James Laskey)
Date: Thu, 7 Dec 2017 18:45:50 -0400
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
Message-ID: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>

I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.

Priya is part of the Langtools team since May 2017 and has made many
contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
at Dell EMC for 10 years and has a patent related to cloud based
information retrieval[1].

I have included 10 of the the most significant change sets.

Votes are due by December 22, 2017.

Only current JDK Committers [2] are eligible to vote on this nomination.
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

? Jim

[1] https://patents.justia.com/patent/20170344203
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/bylaws#lazy-consensus

Contributions

JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
https://bugs.openjdk.java.net/browse/JDK-8190391
http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182

JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
https://bugs.openjdk.java.net/browse/JDK-8186807
http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7

JDK-8185252: Unary minus and plus use wrong node Kind
https://bugs.openjdk.java.net/browse/JDK-8185252
http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5

JDK-8185194: Missing anchor for package description in package-summary.html pages
https://bugs.openjdk.java.net/browse/JDK-8185194
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5

JDK-8183582: Rationalize doclet -docencoding and -charset options
https://bugs.openjdk.java.net/browse/JDK-8183582
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a

JDK-8177048: javadoc should support -version and/or --version
https://bugs.openjdk.java.net/browse/JDK-8177048
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d

JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
https://bugs.openjdk.java.net/browse/JDK-8175362
http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a

JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
https://bugs.openjdk.java.net/browse/JDK-8165198
http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8

JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
https://bugs.openjdk.java.net/browse/JDK-8058408
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7

JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
https://bugs.openjdk.java.net/browse/JDK-8057647
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887



From Roger.Riggs at Oracle.com  Thu Dec  7 22:52:03 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 7 Dec 2017 17:52:03 -0500
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <d739797a-9901-36a5-b584-c5f40f2b2dc4@Oracle.com>

Vote: Yes

On 12/7/2017 5:45 PM, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>


From jesper.wilhelmsson at oracle.com  Fri Dec  8 02:18:04 2017
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Fri, 8 Dec 2017 03:18:04 +0100
Subject: Result: New JDK Committer: Ujwal Vangapally
Message-ID: <7DDAAA9F-76C4-4D4A-A19C-83E9F54A8D98@oracle.com>

Voting for Ujwal Vangapally [1] is now closed.

Yes: 19
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

/Jesper

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000233.html

From nishit.jain at oracle.com  Fri Dec  8 06:38:36 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 8 Dec 2017 12:08:36 +0530
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <15e9eeb6-6f48-607f-fc09-561009ce90c1@oracle.com>

Vote: Yes

Regards,
Nishit Jain
On 08-12-2017 04:15, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
>
> I have included 10 of the the most significant change sets.
>
> Votes are due by December 22, 2017.
>
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> ? Jim
>
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
> Contributions
>
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
>
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
>
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
>
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
>
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
>
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
>
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
>
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
>
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
>
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
>
>


From rachna.goel at oracle.com  Fri Dec  8 06:45:40 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 8 Dec 2017 12:15:40 +0530
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <aa51c70e-22d6-d8e2-0ee6-22c3e09b186b@oracle.com>

Vote : yes


On 08/12/17 4:15 AM, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
>
> I have included 10 of the the most significant change sets.
>
> Votes are due by December 22, 2017.
>
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> ? Jim
>
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
> Contributions
>
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
>
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
>
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
>
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
>
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
>
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
>
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
>
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
>
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
>
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
>
>

-- 
Thanks,
Rachna


From goetz.lindenmaier at sap.com  Fri Dec  8 07:37:38 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 8 Dec 2017 07:37:38 +0000
Subject: JDK 10 enters Rampdown Phase One in one week
In-Reply-To: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>
References: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>
Message-ID: <9c912e42a7434565a3e0cb152961bd38@sap.com>

Hi Mark, 

I appreciate a lot that fixes in jdk10 will be merged to jdk
by Oracle. Because of the bunch of recent integrations of 
JEPs and other changes, we see increasing tests failing on our 
platforms (ppc, s390) which else would mean a lot of overhead 
to fix in two code lines.

Also we found very useful  that tag jdk9+181 is in the jdk repository
when we started to consume the jdk10 changes for our commercial
SAP JVM.  It would be great if this would be similar for jdk10.

Best regards,
  Goetz



-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com
Sent: Thursday, December 7, 2017 4:59 PM
To: jdk-dev at openjdk.java.net
Subject: JDK 10 enters Rampdown Phase One in one week

JDK 10 will enter Rampdown Phase One in one week, on Thursday, 14
December.  Changes intended for JDK 10 should be in the main-line
repository (http://hg.openjdk.java.net/jdk/jdk), or one of the two
repositories that feed it (jdk/hs or jdk/client), by 16:00 UTC on
that day [1].

After next week's build (jdk-10+36) is promoted we'll open a jdk/jdk10
repository, initialized from that tag in the main line, to host the
remaining stabilization work for JDK 10.  This will include any last
changes that trickle in from jdk/hs and jdk/client, most likely early
the following week.  Further JDK 10 EA builds will be done from this
repository.

We'll semi-automatically merge changes pushed to JDK 10 into the
main-line jdk/jdk repository, as we did for the transition from JDK 9
to JDK 10.  This means that:

  - If you make a change in JDK 10 then you needn't do any extra
    work to get it into the main line, though if a merge conflict
    arises then you might be asked to help resolve it.

  - If you need to make a change in both JDK 10 and the main line
    then just push it to JDK 10, and wait for the automatic merge
    to complete.

Changes pushed into the main-line repositories (jdk/{jdk,client,hs})
after the above deadline will be destined for JDK 11 unless they're
back-ported.  When back-ports turn out to be necessary then they'll be
easier to do than in the past: Duplicate bugids are permitted in the
new repository layout, so a change can be pushed to both code lines
using the same bugid if needed.

The Rampdown Phase One process will be similar to that of JDK 9 [2].
I'll post a detailed proposal for that shortly.

- Mark


[1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+10+Rampdown+Phase+One&iso=20171214T16
[2] http://openjdk.java.net/projects/jdk9/rdp-1

From michael.mueller at mueller-bruehl.de  Fri Dec  8 08:29:27 2017
From: michael.mueller at mueller-bruehl.de (=?UTF-8?Q?Michael_M=c3=bcller?=)
Date: Fri, 8 Dec 2017 09:29:27 +0100
Subject: unsubscribe
Message-ID: <03e8bbfc-fdd8-4642-1992-774b7e5386a4@mueller-bruehl.de>


-- 

Herzliche Gr??e - Best Regards,

Michael M?ller
Br?hl, Germany
blog.mueller-bruehl.de <http://blog.mueller-bruehl.de/>
it-rezension.de <http://it-rezension.de/>
@muellermi


Read my books
 ? "Web Development with Java and JSF" (available for short time only): 
https://leanpub.com/jsf
 ? "Practical JSF in Java EE 8" (from 2018): 
http://www.apress.com/us/book/9781484230299
 ? "Java Lambdas and Parallel Streams": 
http://www.apress.com/de/book/9781484224861
 ? "Visitors" a photographic image book: https://leanpub.com/visitors



From hannes.wallnoefer at oracle.com  Fri Dec  8 08:35:23 2017
From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=)
Date: Fri, 8 Dec 2017 09:35:23 +0100
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <0BF0C62E-EFB1-481F-9D7D-DACFAF74164B@oracle.com>

Vote: yes

Hannes

> Am 07.12.2017 um 23:45 schrieb James Laskey <james.laskey at oracle.com>:
> 
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
> 
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
> 
> I have included 10 of the the most significant change sets.
> 
> Votes are due by December 22, 2017.
> 
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [3].
> 
> ? Jim
> 
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
> 
> Contributions
> 
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
> 
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
> 
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
> 
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
> 
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
> 
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
> 
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
> 
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
> 
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
> 
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
> 
> 


From ujwal.vangapally at oracle.com  Mon Dec 11 04:39:12 2017
From: ujwal.vangapally at oracle.com (Ujwal Vangapally)
Date: Mon, 11 Dec 2017 10:09:12 +0530
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <796e1680-6c58-7477-e02b-597d65c7a2f2@oracle.com>

Vote : yes

Thanks,

Ujwal


On 12/8/2017 4:15 AM, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
>
> I have included 10 of the the most significant change sets.
>
> Votes are due by December 22, 2017.
>
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> ? Jim
>
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
> Contributions
>
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
>
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
>
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
>
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
>
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
>
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
>
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
>
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
>
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
>
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
>
>


From christoph.langer at sap.com  Mon Dec 11 16:25:46 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 11 Dec 2017 16:25:46 +0000
Subject: Mails from do-not-reply@scaaa288.us.oracle.com - Mach 5 PRD - jdk...
Message-ID: <d215fe97264d4c9ab6c2156f116cb9f8@sap.com>

Hi,

after my latest pushs to the jdk repo, I got mails from do-not-reply at scaaa288.us.oracle.com<mailto:do-not-reply at scaaa288.us.oracle.com> with the title Mach 5 PRD - jdk... This seems like some automatic build/test report mail. However, the links in that mail refer to places on java.se.oracle.com which I guess is Oracle internal.

My question: What can I do with these mails? Were they sent accidentally or is this some new mechanism? Or shall I just ignore them?

Thanks & Best regards
Christoph


From tim.bell at oracle.com  Mon Dec 11 16:37:47 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 11 Dec 2017 08:37:47 -0800
Subject: Mails from do-not-reply@scaaa288.us.oracle.com - Mach 5 PRD -
 jdk...
In-Reply-To: <d215fe97264d4c9ab6c2156f116cb9f8@sap.com>
References: <d215fe97264d4c9ab6c2156f116cb9f8@sap.com>
Message-ID: <5A2EB45B.9090900@oracle.com>

Hello Christoph:

> This seems like some automatic build/test report mail.

That is exactly what it is.  Mach 5 is an internal build & test system 
that we recently started using.

> My question: What can I do with these mails? Were they sent accidentally or is this some new mechanism? Or shall I just ignore them?

We will stop sending them, since they contain a lot of internal 
information that won't be useful to external contributors.

> Thanks & Best regards
> Christoph

Thank you-

Tim Bell


From coleen.phillimore at oracle.com  Mon Dec 11 16:36:59 2017
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 11 Dec 2017 11:36:59 -0500
Subject: Result: New JDK Committer: John Paul Adrian Glaubitz
Message-ID: <463f0e64-0d18-80c1-afe7-3e05578656da@oracle.com>

Voting for John Paul Adrian Glaubitz [1] is now closed.

Yes: 28
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the nomination.

Coleen

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000214.html

From thomas.schatzl at oracle.com  Mon Dec 11 18:17:29 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 11 Dec 2017 19:17:29 +0100
Subject: Result: New JDK Committer: Alexander Harlap
In-Reply-To: <1511449925.2477.20.camel@oracle.com>
References: <1511449925.2477.20.camel@oracle.com>
Message-ID: <1513016249.14292.2.camel@oracle.com>

Voting for Alexander Harlap [1] is now closed.

Yes: 19
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Thomas Schatzl

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000248
.html

From yuji.okamoto at oracle.com  Tue Dec 12 04:53:21 2017
From: yuji.okamoto at oracle.com (Mike Okamoto)
Date: Mon, 11 Dec 2017 20:53:21 -0800
Subject: Mails from do-not-reply@scaaa288.us.oracle.com - Mach 5 PRD -
 jdk...
In-Reply-To: <d215fe97264d4c9ab6c2156f116cb9f8@sap.com>
References: <d215fe97264d4c9ab6c2156f116cb9f8@sap.com>
Message-ID: <e7ac4cba-2ea1-a5bd-fb11-f7c7c28bf570@oracle.com>

hi Christoph,

Our apologies.  These were sent accidentally.  Please ignore them.

Thank you and regards,

Mike

On 12/11/17 8:25 AM, Langer, Christoph wrote:
> Hi,
>
> after my latest pushs to the jdk repo, I got mails from do-not-reply at scaaa288.us.oracle.com<mailto:do-not-reply at scaaa288.us.oracle.com> with the title Mach 5 PRD - jdk... This seems like some automatic build/test report mail. However, the links in that mail refer to places on java.se.oracle.com which I guess is Oracle internal.
>
> My question: What can I do with these mails? Were they sent accidentally or is this some new mechanism? Or shall I just ignore them?
>
> Thanks & Best regards
> Christoph
>


From mark.reinhold at oracle.com  Tue Dec 12 18:16:42 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 12 Dec 2017 10:16:42 -0800
Subject: JEP proposed to target JDK 10  (2017/12/5)
In-Reply-To: <20171205073316.302341109@eggemoggin.niobe.net>
References: <20171205073316.302341109@eggemoggin.niobe.net>
Message-ID: <20171212101642.567057139@eggemoggin.niobe.net>

2017/12/5 7:33:16 -0800, mark.reinhold at oracle.com:
> The following JEP is Proposed to Target JDK 10:
> 
>   314: Additional Unicode Language-Tag Extensions
>        http://openjdk.java.net/jeps/314
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 16:00 UTC on Tuesday,
> 12 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From mark.reinhold at oracle.com  Tue Dec 12 23:14:17 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 12 Dec 2017 15:14:17 -0800
Subject: JEP proposed to target JDK 10  (2017/12/5, #2)
In-Reply-To: <20171205145035.32009950@eggemoggin.niobe.net>
References: <20171205145035.32009950@eggemoggin.niobe.net>
Message-ID: <20171212151417.35550803@eggemoggin.niobe.net>

2017/12/5 14:50:35 -0800, mark.reinhold at oracle.com:
> The following JEP is Proposed to Target JDK 10:
> 
>   319: Root Certificates
>        http://openjdk.java.net/jeps/319
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Tuesday,
> 12 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From kumar.x.srinivasan at oracle.com  Tue Dec 12 23:21:40 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 12 Dec 2017 15:21:40 -0800
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <5A306484.3080600@oracle.com>

Vote: yes

On 12/7/2017 2:45 PM, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
>
> I have included 10 of the the most significant change sets.
>
> Votes are due by December 22, 2017.
>
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> ? Jim
>
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
> Contributions
>
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
>
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
>
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
>
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
>
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
>
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
>
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
>
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
>
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
>
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
>
>


From jonathan.gibbons at oracle.com  Wed Dec 13 00:39:45 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 12 Dec 2017 16:39:45 -0800
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
In-Reply-To: <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
References: <14111456-3EF6-4668-9638-9967A0A986AE@oracle.com>
 <6EF94CC3-3736-4DA9-9CEB-8A72F42DA5DF@oracle.com>
Message-ID: <abd68fca-6079-cd61-6b79-bf4aa1532229@oracle.com>

Vote: yes


On 12/7/17 2:45 PM, James Laskey wrote:
> I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.
>
> Priya is part of the Langtools team since May 2017 and has made many
> contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
> at Dell EMC for 10 years and has a patent related to cloud based
> information retrieval[1].
>
> I have included 10 of the the most significant change sets.
>
> Votes are due by December 22, 2017.
>
> Only current JDK Committers [2] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [3].
>
> ? Jim
>
> [1] https://patents.justia.com/patent/20170344203
> [2] http://openjdk.java.net/census
> [3] http://openjdk.java.net/bylaws#lazy-consensus
>
> Contributions
>
> JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
> https://bugs.openjdk.java.net/browse/JDK-8190391
> http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182
>
> JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
> https://bugs.openjdk.java.net/browse/JDK-8186807
> http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7
>
> JDK-8185252: Unary minus and plus use wrong node Kind
> https://bugs.openjdk.java.net/browse/JDK-8185252
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5
>
> JDK-8185194: Missing anchor for package description in package-summary.html pages
> https://bugs.openjdk.java.net/browse/JDK-8185194
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5
>
> JDK-8183582: Rationalize doclet -docencoding and -charset options
> https://bugs.openjdk.java.net/browse/JDK-8183582
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a
>
> JDK-8177048: javadoc should support -version and/or --version
> https://bugs.openjdk.java.net/browse/JDK-8177048
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d
>
> JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
> https://bugs.openjdk.java.net/browse/JDK-8175362
> http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a
>
> JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
> https://bugs.openjdk.java.net/browse/JDK-8165198
> http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8
>
> JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
> https://bugs.openjdk.java.net/browse/JDK-8058408
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7
>
> JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
> https://bugs.openjdk.java.net/browse/JDK-8057647
> http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887
>
>


From gnu.andrew at redhat.com  Wed Dec 13 16:36:44 2017
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 13 Dec 2017 16:36:44 +0000
Subject: JDK 10 enters Rampdown Phase One in one week
In-Reply-To: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>
References: <20171207155844.A8FCA110E83@eggemoggin.niobe.net>
Message-ID: <CABi63P6_4aQE41uRSKWSfJ5pn2_SJK8woNgoDKQJ=zO7g1BL-g@mail.gmail.com>

On 7 December 2017 at 15:58,  <mark.reinhold at oracle.com> wrote:
> JDK 10 will enter Rampdown Phase One in one week, on Thursday, 14
> December.  Changes intended for JDK 10 should be in the main-line
> repository (http://hg.openjdk.java.net/jdk/jdk), or one of the two
> repositories that feed it (jdk/hs or jdk/client), by 16:00 UTC on
> that day [1].
>
> After next week's build (jdk-10+36) is promoted we'll open a jdk/jdk10
> repository, initialized from that tag in the main line, to host the
> remaining stabilization work for JDK 10.  This will include any last
> changes that trickle in from jdk/hs and jdk/client, most likely early
> the following week.  Further JDK 10 EA builds will be done from this
> repository.
>
> We'll semi-automatically merge changes pushed to JDK 10 into the
> main-line jdk/jdk repository, as we did for the transition from JDK 9
> to JDK 10.  This means that:
>
>   - If you make a change in JDK 10 then you needn't do any extra
>     work to get it into the main line, though if a merge conflict
>     arises then you might be asked to help resolve it.
>
>   - If you need to make a change in both JDK 10 and the main line
>     then just push it to JDK 10, and wait for the automatic merge
>     to complete.
>
> Changes pushed into the main-line repositories (jdk/{jdk,client,hs})
> after the above deadline will be destined for JDK 11 unless they're
> back-ported.  When back-ports turn out to be necessary then they'll be
> easier to do than in the past: Duplicate bugids are permitted in the
> new repository layout, so a change can be pushed to both code lines
> using the same bugid if needed.
>
> The Rampdown Phase One process will be similar to that of JDK 9 [2].
> I'll post a detailed proposal for that shortly.
>
> - Mark
>
>
> [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+10+Rampdown+Phase+One&iso=20171214T16
> [2] http://openjdk.java.net/projects/jdk9/rdp-1

I'd just like to say thanks for making jdk/jdk10 available publicly and I hope
this continues beyond the first stage, and also for future releases under the
new model.

Having 8u releases disappear from public view in stage 2 and only re-appear
at GA has introduced delays in making these releases available in downstream
releases.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From mark.reinhold at oracle.com  Wed Dec 13 23:04:48 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 15:04:48 -0800
Subject: JEP proposed to target JDK 10  (2017/12/6)
In-Reply-To: <20171206172555.202701390@eggemoggin.niobe.net>
References: <20171206172555.202701390@eggemoggin.niobe.net>
Message-ID: <20171213150448.419773547@eggemoggin.niobe.net>

2017/12/6 14:25:55 -0800, mark.reinhold at oracle.com:
> The following JEP is Proposed to Target JDK 10:
> 
>   322: Time-Based Release Versioning
>        http://openjdk.java.net/jeps/322
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Wednesday,
> 13 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.

Hearing no objections, I've targeted this JEP to JDK 10.

- Mark

From hufeng1987 at gmail.com  Thu Dec 14 01:31:48 2017
From: hufeng1987 at gmail.com (Netroby)
Date: Thu, 14 Dec 2017 09:31:48 +0800
Subject: JEP proposed to target JDK 10 (2017/12/6)
In-Reply-To: <20171213150448.419773547@eggemoggin.niobe.net>
References: <20171206172555.202701390@eggemoggin.niobe.net>
 <20171213150448.419773547@eggemoggin.niobe.net>
Message-ID: <CAEZo+geSXB4wj-sn+=qW7rMmgWhU45cTkvfKN0JykkiOeE3NJA@mail.gmail.com>

Hello. What does the LTS means ? did it restrict some limit about the
release progress?

For similar example. ubuntu lts will provided 5year or longer support.

How about the LTS means with the new Time-Based Release Versioning with JDK?
Appreciate your time.
----------------------------
Netroby


2017-12-14 7:04 GMT+08:00  <mark.reinhold at oracle.com>:
> 2017/12/6 14:25:55 -0800, mark.reinhold at oracle.com:
>> The following JEP is Proposed to Target JDK 10:
>>
>>   322: Time-Based Release Versioning
>>        http://openjdk.java.net/jeps/322
>>
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Wednesday,
>> 13 December, or if they're raised and then satisfactorily answered, then
>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10.
>
> Hearing no objections, I've targeted this JEP to JDK 10.
>
> - Mark

From mark.reinhold at oracle.com  Thu Dec 14 01:42:42 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 13 Dec 2017 17:42:42 -0800
Subject: JEP proposed to target JDK 10 (2017/12/6)
In-Reply-To: <CAEZo+geSXB4wj-sn+=qW7rMmgWhU45cTkvfKN0JykkiOeE3NJA@mail.gmail.com>
References: <20171206172555.202701390@eggemoggin.niobe.net>
 <20171213150448.419773547@eggemoggin.niobe.net>
 <CAEZo+geSXB4wj-sn+=qW7rMmgWhU45cTkvfKN0JykkiOeE3NJA@mail.gmail.com>
Message-ID: <20171213174242.435390476@eggemoggin.niobe.net>

2017/12/13 17:31:48 -0800, hufeng1987 at gmail.com:
> Hello. What does the LTS means ? did it restrict some limit about the
> release progress?
> 
> For similar example. ubuntu lts will provided 5year or longer support.
> 
> How about the LTS means with the new Time-Based Release Versioning with JDK?

The meaning of LTS is up to the implementor.  One implementor might
provide five-year LTS releases every other year, another might choose
to provide twenty-year LTS releases every four years.  JEP 322 doesn't
assign any specific meaning to "LTS", it merely provides a standard way
to indicate that one release is part of a series of long-term-support
releases from its implementor.

- Mark

From joe.darcy at oracle.com  Thu Dec 14 05:56:15 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 13 Dec 2017 21:56:15 -0800
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the JDK
Message-ID: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>

Hello,

FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to 
live alongside the existing license-related files at the top level of 
the JDK repo, which clarifies the licensing of non-GPL components of the 
JDK.

Cheers,

-Joe

--- /dev/null
+++ b/ADDITIONAL_LICENSE_INFO
@@ -0,0 +1,37 @@
+                      ADDITIONAL INFORMATION ABOUT LICENSING
+
+Certain files distributed by Oracle America, Inc. and/or its affiliates 
are
+subject to the following clarification and special exception to the GPLv2,
+based on the GNU Project exception for its Classpath libraries, known 
as the
+GNU Classpath Exception.
+
+Note that Oracle includes multiple, independent programs in this software
+package.  Some of those programs are provided under licenses deemed
+incompatible with the GPLv2 by the Free Software Foundation and others.
+For example, the package includes programs licensed under the Apache
+License, Version 2.0 and may include FreeType. Such programs are licensed
+to you under their original licenses.
+
+Oracle facilitates your further distribution of this package by adding the
+Classpath Exception to the necessary parts of its GPLv2 code, which 
permits
+you to use that code in combination with other independent modules not
+licensed under the GPLv2. However, note that this would not permit you to
+commingle code under an incompatible license with Oracle's GPLv2 licensed
+code by, for example, cutting and pasting such code into a file also
+containing Oracle's GPLv2 licensed code and then distributing the result.
+
+Additionally, if you were to remove the Classpath Exception from any of 
the
+files to which it applies and distribute the result, you would likely be
+required to license some or all of the other code in that distribution 
under
+the GPLv2 as well, and since the GPLv2 is incompatible with the license 
terms
+of some items included in the distribution by Oracle, removing the 
Classpath
+Exception could therefore effectively compromise your ability to further
+distribute the package.
+
+Failing to distribute notices associated with some files may also create
+unexpected legal consequences.
+
+Proceed with caution and we recommend that you obtain the advice of a 
lawyer
+skilled in open source matters before removing the Classpath Exception or
+making modifications to this package which may subsequently be 
redistributed
+and/or involve the use of third party software.


From srinivas.dama at oracle.com  Thu Dec 14 06:09:22 2017
From: srinivas.dama at oracle.com (Srinivas Dama)
Date: Wed, 13 Dec 2017 22:09:22 -0800 (PST)
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy
Message-ID: <a96b3772-8c69-4762-9a1a-5a8643e14f08@default>

Vote : yes
----- Original Message -----
From: james.laskey at oracle.com
To: jdk-dev at openjdk.java.net
Sent: Friday, December 8, 2017 4:16:10 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: CFV: New JDK Committer: Priya Lakshmi pMuthuswamy

I hereby nominate Priya Lakshmi Muthuswamy to JDK Committer.

Priya is part of the Langtools team since May 2017 and has made many
contributions to JDK 9 and 10.  Prior to Oracle, Priya worked
at Dell EMC for 10 years and has a patent related to cloud based
information retrieval[1].

I have included 10 of the the most significant change sets.

Votes are due by December 22, 2017.

Only current JDK Committers [2] are eligible to vote on this nomination.
Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [3].

? Jim

[1] https://patents.justia.com/patent/20170344203
[2] http://openjdk.java.net/census
[3] http://openjdk.java.net/bylaws#lazy-consensus

Contributions

JDK-8190391: nashorn: "!!" of nonzero even integer var becomes false when returned
https://bugs.openjdk.java.net/browse/JDK-8190391
http://hg.openjdk.java.net/jdk/jdk/rev/d0c784151182

JDK-8186807: JSObject gets ScriptFunction when ScriptObjectMirror is expected.
https://bugs.openjdk.java.net/browse/JDK-8186807
http://hg.openjdk.java.net/jdk/jdk/rev/8c0c0aec3ae7

JDK-8185252: Unary minus and plus use wrong node Kind
https://bugs.openjdk.java.net/browse/JDK-8185252
http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/9133969febb5

JDK-8185194: Missing anchor for package description in package-summary.html pages
https://bugs.openjdk.java.net/browse/JDK-8185194
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/d61fd08322b5

JDK-8183582: Rationalize doclet -docencoding and -charset options
https://bugs.openjdk.java.net/browse/JDK-8183582
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/403e8e04395a

JDK-8177048: javadoc should support -version and/or --version
https://bugs.openjdk.java.net/browse/JDK-8177048
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/fe229ee12a5d

JDK-8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc')
https://bugs.openjdk.java.net/browse/JDK-8175362
http://hg.openjdk.java.net/jdk10/jdk10/nashorn/rev/03d3d3c6bc5a

JDK-8165198: Inconsistent values with JavaImporter after accessing undefined variable
https://bugs.openjdk.java.net/browse/JDK-8165198
http://hg.openjdk.java.net/jdk10/master/rev/54a2f246edd8

JDK-8058408: Compiler should emit a clearer message for invalid parenthesized expression
https://bugs.openjdk.java.net/browse/JDK-8058408
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/c342fff3c5f7

JDK-8057647: javac parser needs updates to have better error recovery for error cases of new array creation with dimensions
https://bugs.openjdk.java.net/browse/JDK-8057647
http://hg.openjdk.java.net/jdk10/jdk10/langtools/rev/4070d214e887



From erik.joelsson at oracle.com  Thu Dec 14 08:12:48 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 14 Dec 2017 09:12:48 +0100
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
Message-ID: <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com>

Hello,

Adding build-dev. Here is a webrev with this file and the necessary 
build changes to make it end up in the built images.

http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/

/Erik

On 2017-12-14 06:56, joe darcy wrote:
> Hello,
>
> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to 
> live alongside the existing license-related files at the top level of 
> the JDK repo, which clarifies the licensing of non-GPL components of 
> the JDK.
>
> Cheers,
>
> -Joe
>
> --- /dev/null
> +++ b/ADDITIONAL_LICENSE_INFO
> @@ -0,0 +1,37 @@
> +????????????????????? ADDITIONAL INFORMATION ABOUT LICENSING
> +
> +Certain files distributed by Oracle America, Inc. and/or its 
> affiliates are
> +subject to the following clarification and special exception to the 
> GPLv2,
> +based on the GNU Project exception for its Classpath libraries, known 
> as the
> +GNU Classpath Exception.
> +
> +Note that Oracle includes multiple, independent programs in this 
> software
> +package.? Some of those programs are provided under licenses deemed
> +incompatible with the GPLv2 by the Free Software Foundation and others.
> +For example, the package includes programs licensed under the Apache
> +License, Version 2.0 and may include FreeType. Such programs are 
> licensed
> +to you under their original licenses.
> +
> +Oracle facilitates your further distribution of this package by 
> adding the
> +Classpath Exception to the necessary parts of its GPLv2 code, which 
> permits
> +you to use that code in combination with other independent modules not
> +licensed under the GPLv2. However, note that this would not permit 
> you to
> +commingle code under an incompatible license with Oracle's GPLv2 
> licensed
> +code by, for example, cutting and pasting such code into a file also
> +containing Oracle's GPLv2 licensed code and then distributing the 
> result.
> +
> +Additionally, if you were to remove the Classpath Exception from any 
> of the
> +files to which it applies and distribute the result, you would likely be
> +required to license some or all of the other code in that 
> distribution under
> +the GPLv2 as well, and since the GPLv2 is incompatible with the 
> license terms
> +of some items included in the distribution by Oracle, removing the 
> Classpath
> +Exception could therefore effectively compromise your ability to further
> +distribute the package.
> +
> +Failing to distribute notices associated with some files may also create
> +unexpected legal consequences.
> +
> +Proceed with caution and we recommend that you obtain the advice of a 
> lawyer
> +skilled in open source matters before removing the Classpath 
> Exception or
> +making modifications to this package which may subsequently be 
> redistributed
> +and/or involve the use of third party software.
>


From monika.schnizer at ts.fujitsu.com  Thu Dec 14 08:28:19 2017
From: monika.schnizer at ts.fujitsu.com (monika.schnizer at ts.fujitsu.com)
Date: Thu, 14 Dec 2017 08:28:19 +0000
Subject: License: openjdk version 9: files under GPL v2.0 only - (outside of
 hotspot) - please review
Message-ID: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>

Dear developers of openjdk,

thank you very much for providing this open version of java.
It is really great!

We recently run a Fossology license scan on openjdk version 9 and identified the following files to be under
GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
Please could you kindly investigate into this (possibly together with your license expert).

jdk/src/java.base/share/classes/java/lang/PublicMethods.java
jdk/src/java.base/share/classes/java/lang/StringConcatHelper.java
jdk/src/java.base/share/classes/java/lang/invoke/StringConcatException.java
jdk/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java
jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaderValue.java
jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.c
jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h
jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.cpp
jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.h
jdk/make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java
langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java
langtools/make/tools/crules/AbstractCodingRulesAnalyzer.java
langtools/make/tools/crules/AssertCheckAnalyzer.java
langtools/make/tools/crules/CodingRulesAnalyzerPlugin.java
langtools/make/tools/crules/DefinedByAnalyzer.java
langtools/make/tools/crules/MutableFieldsAnalyzer.java
langtools/make/tools/propertiesparser/gen/ClassGenerator.java
langtools/make/tools/propertiesparser/parser/Message.java
langtools/make/tools/propertiesparser/parser/MessageFile.java
langtools/make/tools/propertiesparser/parser/MessageInfo.java
langtools/make/tools/propertiesparser/parser/MessageLine.java
langtools/make/tools/propertiesparser/parser/MessageType.java
nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
nashorn/buildtools/nasgen/build.xml
nashorn/buildtools/nasgen/nasgen.iml
nashorn/buildtools/nashorntask/build.xml
nashorn/buildtools/nashorntask/project.properties

Thank you very much,
Monika Schnizer



---
Sent from my Fujitsu LIFEBOOK T904

With best regards

Monika Schnizer
Senior Software Developer
FJ EMEIA PR PSO PM&D SVR SW Server View? Configuration Dev



FUJITSU
Mies-van-der-Rohe-Str. 8, 80807 Munich, Germany
Tel.: +49 (89) 62060 2995
E-mail: Monika.Schnizer at ts.fujitsu.com<mailto:Monika.Schnizer at ts.fujitsu.com>
Web: ts.fujitsu.com<http://ts.fujitsu.com/>
Company details: ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint.html>

This communication contains information that is confidential, proprietary in nature and/or privileged.  It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.
Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.




From magnus.ihse.bursie at oracle.com  Thu Dec 14 11:38:41 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 14 Dec 2017 12:38:41 +0100
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
 <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com>
Message-ID: <7CB19AFD-90BA-40B4-9BB0-B5FE7D400D03@oracle.com>

Looks good to me. 

/Magnus

> 14 dec. 2017 kl. 09:12 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello,
> 
> Adding build-dev. Here is a webrev with this file and the necessary build changes to make it end up in the built images.
> 
> http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/
> 
> /Erik
> 
>> On 2017-12-14 06:56, joe darcy wrote:
>> Hello,
>> 
>> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to live alongside the existing license-related files at the top level of the JDK repo, which clarifies the licensing of non-GPL components of the JDK.
>> 
>> Cheers,
>> 
>> -Joe
>> 
>> --- /dev/null
>> +++ b/ADDITIONAL_LICENSE_INFO
>> @@ -0,0 +1,37 @@
>> +                      ADDITIONAL INFORMATION ABOUT LICENSING
>> +
>> +Certain files distributed by Oracle America, Inc. and/or its affiliates are
>> +subject to the following clarification and special exception to the GPLv2,
>> +based on the GNU Project exception for its Classpath libraries, known as the
>> +GNU Classpath Exception.
>> +
>> +Note that Oracle includes multiple, independent programs in this software
>> +package.  Some of those programs are provided under licenses deemed
>> +incompatible with the GPLv2 by the Free Software Foundation and others.
>> +For example, the package includes programs licensed under the Apache
>> +License, Version 2.0 and may include FreeType. Such programs are licensed
>> +to you under their original licenses.
>> +
>> +Oracle facilitates your further distribution of this package by adding the
>> +Classpath Exception to the necessary parts of its GPLv2 code, which permits
>> +you to use that code in combination with other independent modules not
>> +licensed under the GPLv2. However, note that this would not permit you to
>> +commingle code under an incompatible license with Oracle's GPLv2 licensed
>> +code by, for example, cutting and pasting such code into a file also
>> +containing Oracle's GPLv2 licensed code and then distributing the result.
>> +
>> +Additionally, if you were to remove the Classpath Exception from any of the
>> +files to which it applies and distribute the result, you would likely be
>> +required to license some or all of the other code in that distribution under
>> +the GPLv2 as well, and since the GPLv2 is incompatible with the license terms
>> +of some items included in the distribution by Oracle, removing the Classpath
>> +Exception could therefore effectively compromise your ability to further
>> +distribute the package.
>> +
>> +Failing to distribute notices associated with some files may also create
>> +unexpected legal consequences.
>> +
>> +Proceed with caution and we recommend that you obtain the advice of a lawyer
>> +skilled in open source matters before removing the Classpath Exception or
>> +making modifications to this package which may subsequently be redistributed
>> +and/or involve the use of third party software.
> 


From volker.simonis at gmail.com  Thu Dec 14 14:25:56 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 14 Dec 2017 15:25:56 +0100
Subject: License: openjdk version 9: files under GPL v2.0 only - (outside
 of hotspot) - please review
In-Reply-To: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
References: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
Message-ID: <CA+3eh109o_NULd9xhSj+Hj7gjp3LZYwJiZh0OCg1YMTkwx7hNw@mail.gmail.com>

Hi Monika,

it seems that at least the files from jdk/src/java.base are relatively
new files (they have all been added in 2016) so I assume this may be a
simple "copy and paste" error which should be fixed.

I'm not so sure about the make and build tools files. I think they
don't necessarily need to have the ClassPath Exception because they
are used only during the build. But of course it will be simpler if
all Java files would have the same license.

Regards,
Volker


On Thu, Dec 14, 2017 at 9:28 AM, monika.schnizer at ts.fujitsu.com
<monika.schnizer at ts.fujitsu.com> wrote:
> Dear developers of openjdk,
>
> thank you very much for providing this open version of java.
> It is really great!
>
> We recently run a Fossology license scan on openjdk version 9 and identified the following files to be under
> GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
> Please could you kindly investigate into this (possibly together with your license expert).
>
> jdk/src/java.base/share/classes/java/lang/PublicMethods.java
> jdk/src/java.base/share/classes/java/lang/StringConcatHelper.java
> jdk/src/java.base/share/classes/java/lang/invoke/StringConcatException.java
> jdk/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoaderValue.java
> jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaderValue.java
> jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.c
> jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h
> jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.cpp
> jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale.h
> jdk/make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java
> langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java
> langtools/make/tools/crules/AbstractCodingRulesAnalyzer.java
> langtools/make/tools/crules/AssertCheckAnalyzer.java
> langtools/make/tools/crules/CodingRulesAnalyzerPlugin.java
> langtools/make/tools/crules/DefinedByAnalyzer.java
> langtools/make/tools/crules/MutableFieldsAnalyzer.java
> langtools/make/tools/propertiesparser/gen/ClassGenerator.java
> langtools/make/tools/propertiesparser/parser/Message.java
> langtools/make/tools/propertiesparser/parser/MessageFile.java
> langtools/make/tools/propertiesparser/parser/MessageInfo.java
> langtools/make/tools/propertiesparser/parser/MessageLine.java
> langtools/make/tools/propertiesparser/parser/MessageType.java
> nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/mozilla_compat.js
> nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
> nashorn/buildtools/nasgen/build.xml
> nashorn/buildtools/nasgen/nasgen.iml
> nashorn/buildtools/nashorntask/build.xml
> nashorn/buildtools/nashorntask/project.properties
>
> Thank you very much,
> Monika Schnizer
>
>
>
> ---
> Sent from my Fujitsu LIFEBOOK T904
>
> With best regards
>
> Monika Schnizer
> Senior Software Developer
> FJ EMEIA PR PSO PM&D SVR SW Server View? Configuration Dev
>
>
>
> FUJITSU
> Mies-van-der-Rohe-Str. 8, 80807 Munich, Germany
> Tel.: +49 (89) 62060 2995
> E-mail: Monika.Schnizer at ts.fujitsu.com<mailto:Monika.Schnizer at ts.fujitsu.com>
> Web: ts.fujitsu.com<http://ts.fujitsu.com/>
> Company details: ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint.html>
>
> This communication contains information that is confidential, proprietary in nature and/or privileged.  It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.
> Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
>
>
>

From monika.schnizer at ts.fujitsu.com  Thu Dec 14 14:36:18 2017
From: monika.schnizer at ts.fujitsu.com (monika.schnizer at ts.fujitsu.com)
Date: Thu, 14 Dec 2017 14:36:18 +0000
Subject: License: openjdk version 9: files under GPL v2.0 only - (outside
 of hotspot) - please review
In-Reply-To: <CA+3eh109o_NULd9xhSj+Hj7gjp3LZYwJiZh0OCg1YMTkwx7hNw@mail.gmail.com>
References: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
 <CA+3eh109o_NULd9xhSj+Hj7gjp3LZYwJiZh0OCg1YMTkwx7hNw@mail.gmail.com>
Message-ID: <051ccf57092d4087b9c44deccf5e4d9e@R01UKEXCASM111.r01.fujitsu.local>

Hi Volker,
	Thank you very much for your response.
I completely agree for build and make files. They can be GPL only.
Best regards,
Monika

-----Original Message-----
From: Volker Simonis [mailto:volker.simonis at gmail.com] 
Sent: Thursday, December 14, 2017 3:26 PM
To: Schnizer, Monika
Cc: jdk-dev at openjdk.java.net
Subject: Re: License: openjdk version 9: files under GPL v2.0 only - (outside of hotspot) - please review

Hi Monika,

it seems that at least the files from jdk/src/java.base are relatively new files (they have all been added in 2016) so I assume this may be a simple "copy and paste" error which should be fixed.

I'm not so sure about the make and build tools files. I think they don't necessarily need to have the ClassPath Exception because they are used only during the build. But of course it will be simpler if all Java files would have the same license.

Regards,
Volker


On Thu, Dec 14, 2017 at 9:28 AM, monika.schnizer at ts.fujitsu.com <monika.schnizer at ts.fujitsu.com> wrote:
> Dear developers of openjdk,
>
> thank you very much for providing this open version of java.
> It is really great!
>
> We recently run a Fossology license scan on openjdk version 9 and 
> identified the following files to be under GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
> Please could you kindly investigate into this (possibly together with your license expert).
>
> jdk/src/java.base/share/classes/java/lang/PublicMethods.java
> jdk/src/java.base/share/classes/java/lang/StringConcatHelper.java
> jdk/src/java.base/share/classes/java/lang/invoke/StringConcatException
> .java 
> jdk/src/java.base/share/classes/jdk/internal/loader/AbstractClassLoade
> rValue.java 
> jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaderValue.j
> ava 
> jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.c
> jdk/src/java.desktop/unix/native/common/awt/systemscale/systemScale.h
> jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale
> .cpp 
> jdk/src/java.desktop/windows/native/common/awt/systemscale/systemScale
> .h 
> jdk/make/src/classes/build/tools/blacklistedcertsconverter/Blacklisted
> CertsConverter.java 
> langtools/src/jdk.jshell/share/classes/jdk/internal/jshell/debug/Inter
> nalDebugControl.java 
> langtools/make/tools/crules/AbstractCodingRulesAnalyzer.java
> langtools/make/tools/crules/AssertCheckAnalyzer.java
> langtools/make/tools/crules/CodingRulesAnalyzerPlugin.java
> langtools/make/tools/crules/DefinedByAnalyzer.java
> langtools/make/tools/crules/MutableFieldsAnalyzer.java
> langtools/make/tools/propertiesparser/gen/ClassGenerator.java
> langtools/make/tools/propertiesparser/parser/Message.java
> langtools/make/tools/propertiesparser/parser/MessageFile.java
> langtools/make/tools/propertiesparser/parser/MessageInfo.java
> langtools/make/tools/propertiesparser/parser/MessageLine.java
> langtools/make/tools/propertiesparser/parser/MessageType.java
> nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/r
> untime/resources/mozilla_compat.js
> nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/r
> untime/resources/parser.js
> nashorn/buildtools/nasgen/build.xml
> nashorn/buildtools/nasgen/nasgen.iml
> nashorn/buildtools/nashorntask/build.xml
> nashorn/buildtools/nashorntask/project.properties
>
> Thank you very much,
> Monika Schnizer
>
>
>
> ---
> Sent from my Fujitsu LIFEBOOK T904
>
> With best regards
>
> Monika Schnizer
> Senior Software Developer
> FJ EMEIA PR PSO PM&D SVR SW Server View? Configuration Dev
>
>
>
> FUJITSU
> Mies-van-der-Rohe-Str. 8, 80807 Munich, Germany
> Tel.: +49 (89) 62060 2995
> E-mail: 
> Monika.Schnizer at ts.fujitsu.com<mailto:Monika.Schnizer at ts.fujitsu.com>
> Web: ts.fujitsu.com<http://ts.fujitsu.com/>
> Company details: 
> ts.fujitsu.com/imprint<http://ts.fujitsu.com/imprint.html>
>
> This communication contains information that is confidential, proprietary in nature and/or privileged.  It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation.
> Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
>
>
>

From tim.bell at oracle.com  Thu Dec 14 15:40:21 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 14 Dec 2017 07:40:21 -0800
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for
 the JDK
In-Reply-To: <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
 <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com>
Message-ID: <5A329B65.90708@oracle.com>

Erik, Joe:

> Hello,
>
> Adding build-dev. Here is a webrev with this file and the necessary
> build changes to make it end up in the built images.
>
> http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/
>
> /Erik
>
> On 2017-12-14 06:56, joe darcy wrote:
>> Hello,
>>
>> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to
>> live alongside the existing license-related files at the top level of
>> the JDK repo, which clarifies the licensing of non-GPL components of
>> the JDK.
>>
>> Cheers,
>>
>> -Joe

Looks good.

Tim


From mark.reinhold at oracle.com  Thu Dec 14 16:00:45 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 Dec 2017 08:00:45 -0800 (PST)
Subject: jdk/jdk open for JDK *11* changes
Message-ID: <20171214160045.C697E12C1A1@eggemoggin.niobe.net>

Reminder: As of now, changes pushed to jdk/{jdk,client,hs} are
destined for JDK 11 unless they're back-ported to JDK 10.

The jdk/jdk10 repository will be available shortly, after build
36 is promoted.

- Mark

From abhi.saha at oracle.com  Thu Dec 14 16:13:54 2017
From: abhi.saha at oracle.com (Abhijit Saha)
Date: Thu, 14 Dec 2017 08:13:54 -0800
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <5A329B65.90708@oracle.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
 <b333c69f-d5cf-21b2-c9f3-a478b658d094@oracle.com> <5A329B65.90708@oracle.com>
Message-ID: <431469c8-ab1d-fd98-0778-cadf343b6fed@oracle.com>

Looks good.

-Abhijit

On 12/14/2017 7:40 AM, Tim Bell wrote:
> Erik, Joe:
>
>> Hello,
>>
>> Adding build-dev. Here is a webrev with this file and the necessary
>> build changes to make it end up in the built images.
>>
>> http://cr.openjdk.java.net/~erikj/8193208/webrev.jdk10.01/
>>
>> /Erik
>>
>> On 2017-12-14 06:56, joe darcy wrote:
>>> Hello,
>>>
>>> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to
>>> live alongside the existing license-related files at the top level of
>>> the JDK repo, which clarifies the licensing of non-GPL components of
>>> the JDK.
>>>
>>> Cheers,
>>>
>>> -Joe
>
> Looks good.
>
> Tim
>

-- 
Java Platform Group
Oracle Corporation.
(408)276-7564


From mark.reinhold at oracle.com  Thu Dec 14 17:52:19 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 14 Dec 2017 09:52:19 -0800
Subject: JEP proposed to target JDK *11*  (2017/11/30)
In-Reply-To: <20171130143244.451070172@eggemoggin.niobe.net>
References: <20171130143244.451070172@eggemoggin.niobe.net>
Message-ID: <20171214095219.533079782@eggemoggin.niobe.net>

2017/11/30 14:32:44 -0800, mark.reinhold at oracle.com:
> The following JEP is Proposed to Target JDK *11*:
> 
>   309: Dynamic Class-File Constants
>        http://openjdk.java.net/jeps/309
> 
> My understanding is that Lois intends to merge this work into the JDK
> main line shortly after we fork it to stabilize JDK 10.
> 
> Feedback on this proposal is more than welcome, as are reasoned
> objections.  If no such objections are raised by 23:00 UTC on Thursday,
> 7 December, or if they're raised and then satisfactorily answered, then
> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.

Hearing no objections, I've targeted this JEP to JDK 11.

- Mark

From volker.simonis at gmail.com  Fri Dec 15 08:53:23 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 15 Dec 2017 09:53:23 +0100
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
Message-ID: <CA+3eh11_qa_g167D9aSYcH_Lh4qe5=Ev+YVfewmFdWPei+EYtw@mail.gmail.com>

Hi Joe,

if Oracle takes this so seriously, can you please also comment on
Monika's recent mail [1].

It seems that several Java files which have been added recently are
missing the Classpath Exception in their license header.

Thank you and best regards,
Volker

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000383.html


On Thu, Dec 14, 2017 at 6:56 AM, joe darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> FYI, please review the ADDITIONAL_LICENSE_INFO file (patch below), to live
> alongside the existing license-related files at the top level of the JDK
> repo, which clarifies the licensing of non-GPL components of the JDK.
>
> Cheers,
>
> -Joe
>
> --- /dev/null
> +++ b/ADDITIONAL_LICENSE_INFO
> @@ -0,0 +1,37 @@
> +                      ADDITIONAL INFORMATION ABOUT LICENSING
> +
> +Certain files distributed by Oracle America, Inc. and/or its affiliates are
> +subject to the following clarification and special exception to the GPLv2,
> +based on the GNU Project exception for its Classpath libraries, known as
> the
> +GNU Classpath Exception.
> +
> +Note that Oracle includes multiple, independent programs in this software
> +package.  Some of those programs are provided under licenses deemed
> +incompatible with the GPLv2 by the Free Software Foundation and others.
> +For example, the package includes programs licensed under the Apache
> +License, Version 2.0 and may include FreeType. Such programs are licensed
> +to you under their original licenses.
> +
> +Oracle facilitates your further distribution of this package by adding the
> +Classpath Exception to the necessary parts of its GPLv2 code, which permits
> +you to use that code in combination with other independent modules not
> +licensed under the GPLv2. However, note that this would not permit you to
> +commingle code under an incompatible license with Oracle's GPLv2 licensed
> +code by, for example, cutting and pasting such code into a file also
> +containing Oracle's GPLv2 licensed code and then distributing the result.
> +
> +Additionally, if you were to remove the Classpath Exception from any of the
> +files to which it applies and distribute the result, you would likely be
> +required to license some or all of the other code in that distribution
> under
> +the GPLv2 as well, and since the GPLv2 is incompatible with the license
> terms
> +of some items included in the distribution by Oracle, removing the
> Classpath
> +Exception could therefore effectively compromise your ability to further
> +distribute the package.
> +
> +Failing to distribute notices associated with some files may also create
> +unexpected legal consequences.
> +
> +Proceed with caution and we recommend that you obtain the advice of a
> lawyer
> +skilled in open source matters before removing the Classpath Exception or
> +making modifications to this package which may subsequently be
> redistributed
> +and/or involve the use of third party software.
>

From Alan.Bateman at oracle.com  Fri Dec 15 09:49:45 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 15 Dec 2017 09:49:45 +0000
Subject: License: openjdk version 9: files under GPL v2.0 only - (outside
 of hotspot) - please review
In-Reply-To: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
References: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
Message-ID: <41c77b60-c7c1-4905-c74e-b147e4df5936@oracle.com>



On 14/12/2017 08:28, monika.schnizer at ts.fujitsu.com wrote:
> Dear developers of openjdk,
>
> thank you very much for providing this open version of java.
> It is really great!
>
> We recently run a Fossology license scan on openjdk version 9 and identified the following files to be under
> GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
> Please could you kindly investigate into this (possibly together with your license expert).
>
Thanks, sometimes mistakes can happen. I've created JDK-8193609 [1] to 
track this. Note that your scan is JDK 9, the list of files might be a 
bit different for jdk/jdk and jdk/jdk10.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8193609


From monika.schnizer at ts.fujitsu.com  Fri Dec 15 14:02:28 2017
From: monika.schnizer at ts.fujitsu.com (monika.schnizer at ts.fujitsu.com)
Date: Fri, 15 Dec 2017 14:02:28 +0000
Subject: License: openjdk version 9: files under GPL v2.0 only - (outside
 of hotspot) - please review
In-Reply-To: <41c77b60-c7c1-4905-c74e-b147e4df5936@oracle.com>
References: <bd051291d87b4515bb3471e551a502d5@R01UKEXCASM111.r01.fujitsu.local>
 <41c77b60-c7c1-4905-c74e-b147e4df5936@oracle.com>
Message-ID: <087814e94cc54dfe9cd41e6641949dd1@R01UKEXCASM111.r01.fujitsu.local>

Alan,
thank you very much, 
Monika

-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Friday, December 15, 2017 10:50 AM
To: Schnizer, Monika; jdk-dev at openjdk.java.net
Subject: Re: License: openjdk version 9: files under GPL v2.0 only - (outside of hotspot) - please review



On 14/12/2017 08:28, monika.schnizer at ts.fujitsu.com wrote:
> Dear developers of openjdk,
>
> thank you very much for providing this open version of java.
> It is really great!
>
> We recently run a Fossology license scan on openjdk version 9 and 
> identified the following files to be under GPL v2.0 only. We assume that most of them should be GPL v2.0 + Java Classpath Exception.
> Please could you kindly investigate into this (possibly together with your license expert).
>
Thanks, sometimes mistakes can happen. I've created JDK-8193609 [1] to track this. Note that your scan is JDK 9, the list of files might be a bit different for jdk/jdk and jdk/jdk10.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8193609


From mark.reinhold at oracle.com  Fri Dec 15 16:35:29 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 15 Dec 2017 08:35:29 -0800 (PST)
Subject: JDK 10 Rampdown Phase One: Process proposal
Message-ID: <20171215163529.1FA0412C3B3@eggemoggin.niobe.net>

Per the JDK 10 schedule [1], we are now in Rampdown Phase One.  The
overall feature set is frozen.  No further JEPs will be targeted to
this release.

The goal of this phase is the same as it was for JDK 9: Ensure that we
fix the bugs that need to be fixed, and understand why we're not going
to fix some bugs that perhaps ought to be fixed.

I propose that we use the same process as in JDK 9, with one significant
change: From this point forward any further enhancements require advance
approval, using a simple request process along the lines of our other
request processes.  In such a short release cycle there's hardly any
time to repair enhancements gone wrong, so let's keep an eye on them.

I've drafted an RDP 1 page along with bug-deferral and late-enhancement
process pages, based upon the corresponding JDK 9 pages, and posted them
here:

  http://openjdk.java.net/projects/jdk/10/rdp-1
  http://openjdk.java.net/projects/jdk/10/bug-deferral-process
  http://openjdk.java.net/projects/jdk/10/late-enhancement-process

JDK Committers are invited to comment on this process proposal.  If
no objections are raised in one week's time, by 17:00 UTC next Friday,
22 December, then this is the process that we'll use.

Given that we're already in Rampdown Phase One, and that this process
is nearly the same as that for JDK 9, I suggest that we start using
this process immediately, prior to its formal approval.  Let's not make
any negative decisions involving the new aspect of the process, namely
the approval of late enhancements, until the process has been approved.

- Mark


[1] http://openjdk.java.net/projects/jdk/10/#Schedule

From iris.clark at oracle.com  Fri Dec 15 17:00:53 2017
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 15 Dec 2017 09:00:53 -0800 (PST)
Subject: jdk/jdk10 open for JDK *10* stabilization changes
Message-ID: <8deb41c3-5f25-4f65-a384-d2fb8135d2eb@default>

Hi.

http://hg.openjdk.java.net/jdk/jdk10 for JDK 10 stabilization is open.

Thanks,
Iris

From aph at redhat.com  Mon Dec 18 10:44:24 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 18 Dec 2017 10:44:24 +0000
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <CA+3eh11_qa_g167D9aSYcH_Lh4qe5=Ev+YVfewmFdWPei+EYtw@mail.gmail.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
 <CA+3eh11_qa_g167D9aSYcH_Lh4qe5=Ev+YVfewmFdWPei+EYtw@mail.gmail.com>
Message-ID: <9b7d7e09-934b-7915-280c-13c211524060@redhat.com>

On 15/12/17 08:53, Volker Simonis wrote:
> if Oracle takes this so seriously, can you please also comment on
> Monika's recent mail [1].
> 
> It seems that several Java files which have been added recently are
> missing the Classpath Exception in their license header.

Yes, those files have got to be fixed.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From mark.reinhold at oracle.com  Mon Dec 18 17:49:19 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 18 Dec 2017 09:49:19 -0800
Subject: JDK 10 RFR of JDK-8193208: Add additional licensing file for the
 JDK
In-Reply-To: <CA+3eh11_qa_g167D9aSYcH_Lh4qe5=Ev+YVfewmFdWPei+EYtw@mail.gmail.com>
References: <f2b26236-46d3-3e9c-8787-f6abba2dfafb@oracle.com>
 <CA+3eh11_qa_g167D9aSYcH_Lh4qe5=Ev+YVfewmFdWPei+EYtw@mail.gmail.com>
Message-ID: <20171218094919.608038324@eggemoggin.niobe.net>

2017/12/15 0:53:23 -0800, volker.simonis at gmail.com:
> if Oracle takes this so seriously, can you please also comment on
> Monika's recent mail [1].
> 
> It seems that several Java files which have been added recently are
> missing the Classpath Exception in their license header.

Alan already filed an issue for this, as he noted in reply to Monika:

  https://bugs.openjdk.java.net/browse/JDK-8193609

We'll fix these ASAP.

- Mark

From kevin.rushforth at oracle.com  Tue Dec 19 19:25:13 2017
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 19 Dec 2017 11:25:13 -0800
Subject: Bug in gradle when parsing the new JEP-322 version string format
Message-ID: <5A396799.8060102@oracle.com>

As a heads-up to anyone else who might be using gradle, we ran into a 
latent bug in gradle that was exposed by the recent changes to the 
version string for JEP-322 [1]. If you use jdk-10-ea+36 (or later) to 
run your unit tests, it can fail to determine the version of java when 
parsing the output of 'java -version'. I filed a bug against gradle [2] 
to track this.

We discovered this while using jdk-10+36 to build / test FX 10. 
Fortunately I was able to find a workaround that works for us (for now 
anyway), which avoids the buggy code path in gradle [3].

I will follow-up with the gradle folks on this to encourage them to fix it.

-- Kevin

[1] http://openjdk.java.net/jeps/322

[2] https://github.com/gradle/gradle/issues/3849

[3] https://bugs.openjdk.java.net/browse/JDK-8193823


From volker.simonis at gmail.com  Wed Dec 20 10:15:10 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 Dec 2017 11:15:10 +0100
Subject: ASSEMBLY_EXCEPTION should be removed ?
Message-ID: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>

Hi,

in the course of the recent licensing cleanups I've just realized that
the OpenJDK sources as well as the generated images still contain the
ASSEMBLY_EXCEPTION license file [1].

I think this is just a leftover of the first OpenJDK versions which
still required some binary parts provided by Sun at time in order to
build and run successfully. As far as I can tell, this is not
necessary since at least OpenJDK 7 so I think the ASSEMBLY_EXCEPTION
file could also be removed.

What do you think?

Thank you and best regards,
Volker

[1] http://hg.openjdk.java.net/jdk/jdk10/file/tip/ASSEMBLY_EXCEPTION

From mark.reinhold at oracle.com  Thu Dec 21 15:10:01 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 21 Dec 2017 07:10:01 -0800
Subject: ASSEMBLY_EXCEPTION should be removed ?
In-Reply-To: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>
References: <CA+3eh1109wuMqnQcFZwB1mNn3uKP2+8Y0aQb6ADWsRURch8trA@mail.gmail.com>
Message-ID: <20171221071001.932596078@eggemoggin.niobe.net>

2017/12/20 2:15:10 -0800, volker.simonis at gmail.com:
> in the course of the recent licensing cleanups I've just realized that
> the OpenJDK sources as well as the generated images still contain the
> ASSEMBLY_EXCEPTION license file [1].
> 
> I think this is just a leftover of the first OpenJDK versions which
> still required some binary parts provided by Sun at time in order to
> build and run successfully. As far as I can tell, this is not
> necessary since at least OpenJDK 7 so I think the ASSEMBLY_EXCEPTION
> file could also be removed.
> 
> What do you think?

I think this is a legal question, so I've asked a lawyer.
At this point I don't expect an answer until January.

- Mark

From james.laskey at oracle.com  Sat Dec 23 21:40:58 2017
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Sat, 23 Dec 2017 17:40:58 -0400
Subject: Result: New JDK Committer: Priya Lakshmi Muthuswamy
Message-ID: <A7776209-9E8C-4C99-9792-AB2A1BAF99C2@oracle.com>

Voting for Priya Lakshmi Muthuswamy [1][2] is now closed.

Yes: 11
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Jim Laskey

[1] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-December/000595.html <http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-December/000595.html>
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000358.html <http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000358.html>


From mark.reinhold at oracle.com  Sun Dec 24 04:49:29 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Sat, 23 Dec 2017 18:49:29 -1000
Subject: JDK 10 Rampdown Phase One: Process proposal
In-Reply-To: <20171215163529.1FA0412C3B3@eggemoggin.niobe.net>
References: <20171215163529.1FA0412C3B3@eggemoggin.niobe.net>
Message-ID: <20171223184929.667672111@eggemoggin.niobe.net>

2017/12/15 6:35:29 -1000, mark.reinhold at oracle.com:
> ...
> 
> I've drafted an RDP 1 page along with bug-deferral and late-enhancement
> process pages, based upon the corresponding JDK 9 pages, and posted them
> here:
> 
>   http://openjdk.java.net/projects/jdk/10/rdp-1
>   http://openjdk.java.net/projects/jdk/10/bug-deferral-process
>   http://openjdk.java.net/projects/jdk/10/late-enhancement-process
> 
> JDK Committers are invited to comment on this process proposal.  If
> no objections are raised in one week's time, by 17:00 UTC next Friday,
> 22 December, then this is the process that we'll use.

Hearing no objections, these are the processes that we'll use for JDK 10
Rampdown Phase One.

- Mark