Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

joe darcy
Hello,

With the JDK 11 line of development opening up in a few days, a few
changes are needed to prepared to turn a JDK 10 code base into a JDK 11
one including:

     JDK-8173382: Add -source 11 and -target 11 to javac
     JDK-8193291: Add SourceVersion.RELEASE_11

     Webev:
         http://cr.openjdk.java.net/~darcy/8173382.1/
     CSRs:
         JDK-8193350: Add -source 11 and -target 11 to javac
         JDK-8193351: Add SourceVersion.RELEASE_11

Please review the preliminary webrev and CSRs.

Note that breaking with previous contentions, the current iteration of
the change does *not* add -source/-target "1.11" as an alias for "11".
Only "11" is recognized.

I didn't see how to add support for an "11" value for "--release" so I
problem listed two tests until that is sorted out.

The build is simultaneously updated to user -source/-target 11, hence
the inclusion of build-dev.

Various langtools tests and test infrastructure is updated too.

Thanks,

-Joe

Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Erik Joelsson
Build change looks good.

/Erik


On 2017-12-12 08:04, joe darcy wrote:

> Hello,
>
> With the JDK 11 line of development opening up in a few days, a few
> changes are needed to prepared to turn a JDK 10 code base into a JDK
> 11 one including:
>
>     JDK-8173382: Add -source 11 and -target 11 to javac
>     JDK-8193291: Add SourceVersion.RELEASE_11
>
>     Webev:
>         http://cr.openjdk.java.net/~darcy/8173382.1/
>     CSRs:
>         JDK-8193350: Add -source 11 and -target 11 to javac
>         JDK-8193351: Add SourceVersion.RELEASE_11
>
> Please review the preliminary webrev and CSRs.
>
> Note that breaking with previous contentions, the current iteration of
> the change does *not* add -source/-target "1.11" as an alias for "11".
> Only "11" is recognized.
>
> I didn't see how to add support for an "11" value for "--release" so I
> problem listed two tests until that is sorted out.
>
> The build is simultaneously updated to user -source/-target 11, hence
> the inclusion of build-dev.
>
> Various langtools tests and test infrastructure is updated too.
>
> Thanks,
>
> -Joe
>

Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz
In reply to this post by joe darcy
Hi Joe,

I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now).

Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on.

Are there any technical impediments as to why this would be problematic?

Thanks,
Paul. 


On 11 Dec 2017, at 23:04, joe darcy <[hidden email]> wrote:

Hello,

With the JDK 11 line of development opening up in a few days, a few changes are needed to prepared to turn a JDK 10 code base into a JDK 11 one including:

   JDK-8173382: Add -source 11 and -target 11 to javac
   JDK-8193291: Add SourceVersion.RELEASE_11

   Webev:
       http://cr.openjdk.java.net/~darcy/8173382.1/
   CSRs:
       JDK-8193350: Add -source 11 and -target 11 to javac
       JDK-8193351: Add SourceVersion.RELEASE_11

Please review the preliminary webrev and CSRs.

Note that breaking with previous contentions, the current iteration of the change does *not* add -source/-target "1.11" as an alias for "11". Only "11" is recognized.

I didn't see how to add support for an "11" value for "--release" so I problem listed two tests until that is sorted out.

The build is simultaneously updated to user -source/-target 11, hence the inclusion of build-dev.

Various langtools tests and test infrastructure is updated too.

Thanks,

-Joe



signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

joe darcy
Hi Paul,

There is sense in working in including the class file version update at
the same time if the added complexity doesn't delay the changes.

Did the patch for the increment to 54 require previous changes in the
bundled ASM?

Thanks,

-Joe


On 12/12/2017 9:31 AM, Paul Sandoz wrote:

> Hi Joe,
>
> I would like to see the class file version increment [*] in the same
> patch (the unified repo makes this easier now).
>
> Then we have everything in one changeset (except for any ctsym
> changes?) that can be easily templated when the next increment is
> required, since we will be doing this far more regularly from now on.
>
> Are there any technical impediments as to why this would be problematic?
>
> Thanks,
> Paul.
>
> [*] here is the increment to 54
> http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54
>

Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz


> On 12 Dec 2017, at 09:52, joe darcy <[hidden email]> wrote:
>
> Hi Paul,
>
> There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes.
>

I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review.

If it helps, and since i am proposing additional work, i can merge in such changes into your patch.


> Did the patch for the increment to 54 require previous changes in the bundled ASM?
>

The increment in and of itself requires only minimal changes to the internal ASM, it does not require the integration of a new version of ASM.  Constant dynamic only requires a minimal update to the internal ASM to skip over the new constant pool entry, since we don’t currently use ASM process or generate constant dynamic entries.

Paul.


> Thanks,
>
> -Joe
>
>
> On 12/12/2017 9:31 AM, Paul Sandoz wrote:
>> Hi Joe,
>>
>> I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now).
>>
>> Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this far more regularly from now on.
>>
>> Are there any technical impediments as to why this would be problematic?
>>
>> Thanks,
>> Paul.
>>
>> [*] here is the increment to 54 http://hg.openjdk.java.net/jdk/jdk/rev/89829dd3cc54
>>
>


signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz


> On 12 Dec 2017, at 10:03, Paul Sandoz <[hidden email]> wrote:
>
>
>
>> On 12 Dec 2017, at 09:52, joe darcy <[hidden email]> wrote:
>>
>> Hi Paul,
>>
>> There is sense in working in including the class file version update at the same time if the added complexity doesn't delay the changes.
>>
>
> I sense it should be so complex and delay since the additional code changes can be copied from the prior changes which recently went through significant review.
"I sense it should *not* be…”

Paul.


signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

David Holmes
In reply to this post by joe darcy
Hi Joe,

On 12/12/2017 5:04 PM, joe darcy wrote:

> Hello,
>
> With the JDK 11 line of development opening up in a few days, a few
> changes are needed to prepared to turn a JDK 10 code base into a JDK 11
> one including:
>
>      JDK-8173382: Add -source 11 and -target 11 to javac
>      JDK-8193291: Add SourceVersion.RELEASE_11
>
>      Webev:
>          http://cr.openjdk.java.net/~darcy/8173382.1/
>      CSRs:
>          JDK-8193350: Add -source 11 and -target 11 to javac
>          JDK-8193351: Add SourceVersion.RELEASE_11
>
> Please review the preliminary webrev and CSRs.

I don't see a change to the actual JDK version as part of this ?? hat's
the change that will cause hotspot to fail to build in debug mode as
soon as the version is bumped - I filed:

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

to at least get over that.

> Note that breaking with previous contentions, the current iteration of
> the change does *not* add -source/-target "1.11" as an alias for "11".
> Only "11" is recognized.
>
> I didn't see how to add support for an "11" value for "--release" so I
> problem listed two tests until that is sorted out.

Okay. It's very hard to discern what uses of "RELEASE_11" pertain to
"-release" support and what just pertain to -source/-target. ??

> The build is simultaneously updated to user -source/-target 11, hence
> the inclusion of build-dev.
>
> Various langtools tests and test infrastructure is updated too.

test/langtools/tools/javac/versions/Versions.java looks like it needed
some updates for JDK 10!

Thanks,
David

>
> Thanks,
>
> -Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

joe darcy
Hi David,


On 12/12/2017 1:11 PM, David Holmes wrote:

> Hi Joe,
>
> On 12/12/2017 5:04 PM, joe darcy wrote:
>> Hello,
>>
>> With the JDK 11 line of development opening up in a few days, a few
>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>> 11 one including:
>>
>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>
>>      Webev:
>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>      CSRs:
>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>
>> Please review the preliminary webrev and CSRs.
>
> I don't see a change to the actual JDK version as part of this ??

Correct; the webrev to date is the langtools portion of the new JDK
groundbreaking, the same subset of groundbreaking I looked at for the 9
-> 10 transition. Other pieces are needed too, including HotSpot changes
and the actual version update.

> hat's the change that will cause hotspot to fail to build in debug
> mode as soon as the version is bumped - I filed:
>
> https://bugs.openjdk.java.net/browse/JDK-8193364
>
> to at least get over that.
>
>> Note that breaking with previous contentions, the current iteration
>> of the change does *not* add -source/-target "1.11" as an alias for
>> "11". Only "11" is recognized.
>>
>> I didn't see how to add support for an "11" value for "--release" so
>> I problem listed two tests until that is sorted out.
>
> Okay. It's very hard to discern what uses of "RELEASE_11" pertain to
> "-release" support and what just pertain to -source/-target. ??

In this iteration, mostly -source/-target. The code that populates the
list of releases supported by --release has had some updates since I
last looked at it and I didn't figure that part out before sending out
this review.

>
>> The build is simultaneously updated to user -source/-target 11, hence
>> the inclusion of build-dev.
>>
>> Various langtools tests and test infrastructure is updated too.
>
> test/langtools/tools/javac/versions/Versions.java looks like it needed
> some updates for JDK 10!

Better late than never ;-)

Thanks,

-Joe

Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

David Holmes
Hi Joe,

On 13/12/2017 7:27 AM, joe darcy wrote:

> Hi David,
>
>
> On 12/12/2017 1:11 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>> Hello,
>>>
>>> With the JDK 11 line of development opening up in a few days, a few
>>> changes are needed to prepared to turn a JDK 10 code base into a JDK
>>> 11 one including:
>>>
>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>
>>>      Webev:
>>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>>      CSRs:
>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>
>>> Please review the preliminary webrev and CSRs.
>>
>> I don't see a change to the actual JDK version as part of this ??
>
> Correct; the webrev to date is the langtools portion of the new JDK
> groundbreaking, the same subset of groundbreaking I looked at for the 9
> -> 10 transition. Other pieces are needed too, including HotSpot changes
> and the actual version update.

So what is the overall transition strategy here? I don't see how you can
change javac to default to -source/-target 11 prior to bumping the
actual version to 11. Or do you expect all the additional pieces to come
together at the same time?

Thanks,
David

>> hat's the change that will cause hotspot to fail to build in debug
>> mode as soon as the version is bumped - I filed:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8193364
>>
>> to at least get over that.
>>
>>> Note that breaking with previous contentions, the current iteration
>>> of the change does *not* add -source/-target "1.11" as an alias for
>>> "11". Only "11" is recognized.
>>>
>>> I didn't see how to add support for an "11" value for "--release" so
>>> I problem listed two tests until that is sorted out.
>>
>> Okay. It's very hard to discern what uses of "RELEASE_11" pertain to
>> "-release" support and what just pertain to -source/-target. ??
>
> In this iteration, mostly -source/-target. The code that populates the
> list of releases supported by --release has had some updates since I
> last looked at it and I didn't figure that part out before sending out
> this review.
>
>>
>>> The build is simultaneously updated to user -source/-target 11, hence
>>> the inclusion of build-dev.
>>>
>>> Various langtools tests and test infrastructure is updated too.
>>
>> test/langtools/tools/javac/versions/Versions.java looks like it needed
>> some updates for JDK 10!
>
> Better late than never ;-)
>
> Thanks,
>
> -Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

joe darcy
Hi David,


On 12/12/2017 1:32 PM, David Holmes wrote:

> Hi Joe,
>
> On 13/12/2017 7:27 AM, joe darcy wrote:
>> Hi David,
>>
>>
>> On 12/12/2017 1:11 PM, David Holmes wrote:
>>> Hi Joe,
>>>
>>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>>> Hello,
>>>>
>>>> With the JDK 11 line of development opening up in a few days, a few
>>>> changes are needed to prepared to turn a JDK 10 code base into a
>>>> JDK 11 one including:
>>>>
>>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>>
>>>>      Webev:
>>>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>>>      CSRs:
>>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>>
>>>> Please review the preliminary webrev and CSRs.
>>>
>>> I don't see a change to the actual JDK version as part of this ??
>>
>> Correct; the webrev to date is the langtools portion of the new JDK
>> groundbreaking, the same subset of groundbreaking I looked at for the
>> 9 -> 10 transition. Other pieces are needed too, including HotSpot
>> changes and the actual version update.
>
> So what is the overall transition strategy here? I don't see how you
> can change javac to default to -source/-target 11 prior to bumping the
> actual version to 11. Or do you expect all the additional pieces to
> come together at the same time?
>

For background, what we've done in the past is at the very start of a
new JDK release, first create -source/-target ${N+1} that begin as
aliases for ${N} and are the default -source/-target for javac. [1] As
new language features are developed, the javac implementation adds
allowFeatureFoo() predicates which turn into

     return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature

So the operational distinction between -source ${N} and -source ${N+1}
comes about after language changes have been made for release ${N+1}.
For -target, since there is often not a hard dependency between new Java
language features and JVM features, an operational distinction between
successive values of -target, and thus successive class file versions,
can come about later in the release. For example, in JDK 10 the language
feature var/local variable type inference enabled by -source 10 was in
JDK 10 builds a few months before -target 10 mapped to an updated class
file version.

We could follow the same path for the JDK 10 -> 11 transition. Paul has
suggested also updating the class file version at the same time this
time around.

HTH,

-Joe

[1] Way back when, the new -source/-target values were added without
simultaneously being made the default. This increased maintenance costs
of javac tests and led us to implement the current policy.
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

David Holmes
Hi Joe,

On 13/12/2017 9:20 AM, joe darcy wrote:

> Hi David,
>
>
> On 12/12/2017 1:32 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 13/12/2017 7:27 AM, joe darcy wrote:
>>> Hi David,
>>>
>>>
>>> On 12/12/2017 1:11 PM, David Holmes wrote:
>>>> Hi Joe,
>>>>
>>>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>>>> Hello,
>>>>>
>>>>> With the JDK 11 line of development opening up in a few days, a few
>>>>> changes are needed to prepared to turn a JDK 10 code base into a
>>>>> JDK 11 one including:
>>>>>
>>>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>>>
>>>>>      Webev:
>>>>>          http://cr.openjdk.java.net/~darcy/8173382.1/
>>>>>      CSRs:
>>>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>>>
>>>>> Please review the preliminary webrev and CSRs.
>>>>
>>>> I don't see a change to the actual JDK version as part of this ??
>>>
>>> Correct; the webrev to date is the langtools portion of the new JDK
>>> groundbreaking, the same subset of groundbreaking I looked at for the
>>> 9 -> 10 transition. Other pieces are needed too, including HotSpot
>>> changes and the actual version update.
>>
>> So what is the overall transition strategy here? I don't see how you
>> can change javac to default to -source/-target 11 prior to bumping the
>> actual version to 11. Or do you expect all the additional pieces to
>> come together at the same time?
>>
>
> For background, what we've done in the past is at the very start of a
> new JDK release, first create -source/-target ${N+1} that begin as
> aliases for ${N} and are the default -source/-target for javac. [1] As
> new language features are developed, the javac implementation adds
> allowFeatureFoo() predicates which turn into
>
>      return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>
> So the operational distinction between -source ${N} and -source ${N+1}
> comes about after language changes have been made for release ${N+1}.
> For -target, since there is often not a hard dependency between new Java
> language features and JVM features, an operational distinction between
> successive values of -target, and thus successive class file versions,
> can come about later in the release. For example, in JDK 10 the language
> feature var/local variable type inference enabled by -source 10 was in
> JDK 10 builds a few months before -target 10 mapped to an updated class
> file version.
>
> We could follow the same path for the JDK 10 -> 11 transition. Paul has
> suggested also updating the class file version at the same time this
> time around.

I'm a little unclear as to the distinction between allowing for
-source/-target 11 and switching them to be the default. Especially if
you incorporate the classfile version change then we would have a JDK
reporting itself as JDK 10 but which uses -source/-target 11 and
produces version 55 classfiles. I would have thought it a two step process:
- prepare for new defaults
- switch to new defaults (in conjunction with version change)

Anyway, none of the proposed changes have any impact on hotspot AFAICT.
It is only when the actual version is updated to 11 that hotspot, and
other entities will have to be updated. I'm still unclear if someone is
actually driving the entire "update to version 11" process? Is there an
umbrella issue for it?

Thanks,
David

>
> HTH,
>
> -Joe
>
> [1] Way back when, the new -source/-target values were added without
> simultaneously being made the default. This increased maintenance costs
> of javac tests and led us to implement the current policy.
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz


> On 12 Dec 2017, at 20:56, David Holmes <[hidden email]> wrote:
>
> Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it?
>

No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc.

Paul.

signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz
Joe,

Here's a patch on top of your patch:

  http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-release-classfile-version/webrev/

Currently building/testing with both patches applied.

Paul.


On 13 Dec 2017, at 08:44, Paul Sandoz <[hidden email]> wrote:



On 12 Dec 2017, at 20:56, David Holmes <[hidden email]> wrote:

Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is only when the actual version is updated to 11 that hotspot, and other entities will have to be updated. I'm still unclear if someone is actually driving the entire "update to version 11" process? Is there an umbrella issue for it?


No yet, i was hoping we could consolidate as much as possible under one issue thereby minimising coordination/process i.e. combine the release and class file versions under one patch. Then stand back and see what is missing e.g. ctsym stuff etc.

Paul.


signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

joe darcy
In reply to this post by David Holmes
Hi David,


On 12/12/2017 8:56 PM, David Holmes wrote:
> Hi Joe,
>
> On 13/12/2017 9:20 AM, joe darcy wrote:
>> Hi David,
>>
>>
>> On 12/12/2017 1:32 PM, David Holmes wrote:
>>>

[snip]

>>>
>>
>> For background, what we've done in the past is at the very start of a
>> new JDK release, first create -source/-target ${N+1} that begin as
>> aliases for ${N} and are the default -source/-target for javac. [1]
>> As new language features are developed, the javac implementation adds
>> allowFeatureFoo() predicates which turn into
>>
>>      return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>>
>> So the operational distinction between -source ${N} and -source
>> ${N+1} comes about after language changes have been made for release
>> ${N+1}. For -target, since there is often not a hard dependency
>> between new Java language features and JVM features, an operational
>> distinction between successive values of -target, and thus successive
>> class file versions, can come about later in the release. For
>> example, in JDK 10 the language feature var/local variable type
>> inference enabled by -source 10 was in JDK 10 builds a few months
>> before -target 10 mapped to an updated class file version.
>>
>> We could follow the same path for the JDK 10 -> 11 transition. Paul
>> has suggested also updating the class file version at the same time
>> this time around.
>
> I'm a little unclear as to the distinction between allowing for
> -source/-target 11 and switching them to be the default. Especially if
> you incorporate the classfile version change then we would have a JDK
> reporting itself as JDK 10 but which uses -source/-target 11 and
> produces version 55 classfiles. I would have thought it a two step
> process:
> - prepare for new defaults
> - switch to new defaults (in conjunction with version change)
>
> Anyway, none of the proposed changes have any impact on hotspot
> AFAICT. It is only when the actual version is updated to 11 that
> hotspot, and other entities will have to be updated. I'm still unclear
> if someone is actually driving the entire "update to version 11"
> process? Is there an umbrella issue for it?
>

There are various changes associated with a JDK N to (N+1) update
including (but not limited to):

     1) New -source/-target value in javac
     2) Make new -source/-target value the default in javac
     3) Change build of the JDK to use new -source/-target
     4) Increment version
     5) Support new --release value in javac
     6) Output new class file format
     7) Have HotSpot accept new class file format
     ...

For the last few releases, we've done 1) through 4) in b01 of the new
release, although typically via multiple changesets since 4) has been
done separately from 1) through 3) and 3) had to be done separately from
1) and 2) since different repos were affected before the repo consolidation.

It is desirable but not strictly necessary to bundle this set of updates
into as few changesets as possible. In particular, I think it is
acceptable if the master repo has source code states before the first
promoted build where not all of 1) through 4) are fixed.

Cheers,

-Joe
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Jonathan Gibbons


On 12/13/17 10:36 AM, joe darcy wrote:

> Hi David,
>
>
> On 12/12/2017 8:56 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 13/12/2017 9:20 AM, joe darcy wrote:
>>> Hi David,
>>>
>>>
>>> On 12/12/2017 1:32 PM, David Holmes wrote:
>>>>
>
> [snip]
>
>>>>
>>>
>>> For background, what we've done in the past is at the very start of
>>> a new JDK release, first create -source/-target ${N+1} that begin as
>>> aliases for ${N} and are the default -source/-target for javac. [1]
>>> As new language features are developed, the javac implementation
>>> adds allowFeatureFoo() predicates which turn into
>>>
>>>      return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>>>
>>> So the operational distinction between -source ${N} and -source
>>> ${N+1} comes about after language changes have been made for release
>>> ${N+1}. For -target, since there is often not a hard dependency
>>> between new Java language features and JVM features, an operational
>>> distinction between successive values of -target, and thus
>>> successive class file versions, can come about later in the release.
>>> For example, in JDK 10 the language feature var/local variable type
>>> inference enabled by -source 10 was in JDK 10 builds a few months
>>> before -target 10 mapped to an updated class file version.
>>>
>>> We could follow the same path for the JDK 10 -> 11 transition. Paul
>>> has suggested also updating the class file version at the same time
>>> this time around.
>>
>> I'm a little unclear as to the distinction between allowing for
>> -source/-target 11 and switching them to be the default. Especially
>> if you incorporate the classfile version change then we would have a
>> JDK reporting itself as JDK 10 but which uses -source/-target 11 and
>> produces version 55 classfiles. I would have thought it a two step
>> process:
>> - prepare for new defaults
>> - switch to new defaults (in conjunction with version change)
>>
>> Anyway, none of the proposed changes have any impact on hotspot
>> AFAICT. It is only when the actual version is updated to 11 that
>> hotspot, and other entities will have to be updated. I'm still
>> unclear if someone is actually driving the entire "update to version
>> 11" process? Is there an umbrella issue for it?
>>
>
> There are various changes associated with a JDK N to (N+1) update
> including (but not limited to):
>
>     1) New -source/-target value in javac
>     2) Make new -source/-target value the default in javac
>     3) Change build of the JDK to use new -source/-target
>     4) Increment version
>     5) Support new --release value in javac
>     6) Output new class file format
>     7) Have HotSpot accept new class file format
>     ...
>
> For the last few releases, we've done 1) through 4) in b01 of the new
> release, although typically via multiple changesets since 4) has been
> done separately from 1) through 3) and 3) had to be done separately
> from 1) and 2) since different repos were affected before the repo
> consolidation.
>
> It is desirable but not strictly necessary to bundle this set of
> updates into as few changesets as possible. In particular, I think it
> is acceptable if the master repo has source code states before the
> first promoted build where not all of 1) through 4) are fixed.
>
> Cheers,
>
> -Joe

There's also

3a) Update build of the INTERIM components (used for bootstrapping the
build) to use latest GA release

Somewhat related, as a one-off,   JDK 9 javac added a class called
JDK9Wrappers to provide reflective access to new-in-JDK-9 API. These
wrappers can now be removed, and the API used directly.

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

mark.reinhold
In reply to this post by Paul Sandoz
2017/12/13 8:44:33 -0800, [hidden email]:

>> On 12 Dec 2017, at 20:56, [hidden email] wrote:
>>
>> Anyway, none of the proposed changes have any impact on hotspot
>> AFAICT. It is only when the actual version is updated to 11 that
>> hotspot, and other entities will have to be updated. I'm still
>> unclear if someone is actually driving the entire "update to version
>> 11" process? Is there an umbrella issue for it?
>
> No yet, i was hoping we could consolidate as much as possible under
> one issue thereby minimising coordination/process i.e. combine the
> release and class file versions under one patch. Then stand back and
> see what is missing e.g. ctsym stuff etc.

How much of this can we parameterize and/or automate?  We are going to
have to do it every six months, after all.

Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
then propagate that value everywhere else?  (In any actual release it'll
be VERSION_FEATURE + 44, but make it a separate variable to allow for
experimentation as with, e.g., MVT.)

Looking at Joe's webrev, many of the changes from 10 to 11 could instead
be changed to Runtime.getRuntime().version().major() (in Java code) or
VERSION_FEATURE (in Makefiles).

In javax.lang.model.SourceVersion we could define a new constant, say
RELEASE_CURRENT, whose value is that of the latest release.  Then
annotations such as

  @SupportedSourceVersion(SourceVersion.RELEASE_11)

could be replaced by

  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)

Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
and then many references to JDK10 could instead refer to that.

In cases where additional code is needed, can we generate it during
the build via another Gensrc*.gmk Makefile?  That'd be more work now,
but it could save us a lot of time in the long run.

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz


> On 13 Dec 2017, at 13:18, [hidden email] wrote:
>
> 2017/12/13 8:44:33 -0800, [hidden email]:
>>> On 12 Dec 2017, at 20:56, [hidden email] wrote:
>>>
>>> Anyway, none of the proposed changes have any impact on hotspot
>>> AFAICT. It is only when the actual version is updated to 11 that
>>> hotspot, and other entities will have to be updated. I'm still
>>> unclear if someone is actually driving the entire "update to version
>>> 11" process? Is there an umbrella issue for it?
>>
>> No yet, i was hoping we could consolidate as much as possible under
>> one issue thereby minimising coordination/process i.e. combine the
>> release and class file versions under one patch. Then stand back and
>> see what is missing e.g. ctsym stuff etc.
>
> How much of this can we parameterize and/or automate?
I suspect quite a bit, as you present below, and i agree we should try and automate as much as possible. At the moment it’s very spaghetti-like and quite fragile.

I suggest we get the initial version bump for 11 out of the way as soon as JDK 10 branches off from the mainline then work on automation for subsequent releases.

Paul.

>  We are going to
> have to do it every six months, after all.
>
> Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
> then propagate that value everywhere else?  (In any actual release it'll
> be VERSION_FEATURE + 44, but make it a separate variable to allow for
> experimentation as with, e.g., MVT.)
>
> Looking at Joe's webrev, many of the changes from 10 to 11 could instead
> be changed to Runtime.getRuntime().version().major() (in Java code) or
> VERSION_FEATURE (in Makefiles).
>
> In javax.lang.model.SourceVersion we could define a new constant, say
> RELEASE_CURRENT, whose value is that of the latest release.  Then
> annotations such as
>
>  @SupportedSourceVersion(SourceVersion.RELEASE_11)
>
> could be replaced by
>
>  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)
>
> Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
> and then many references to JDK10 could instead refer to that.
>
> In cases where additional code is needed, can we generate it during
> the build via another Gensrc*.gmk Makefile?  That'd be more work now,
> but it could save us a lot of time in the long run.
>
> - Mark


signature.asc (890 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Brian Goetz-2
In reply to this post by joe darcy
Don't forget to add the new version to the list of validated versions in
multi-release JARs...

On 12/13/2017 1:36 PM, joe darcy wrote:

>
> There are various changes associated with a JDK N to (N+1) update
> including (but not limited to):
>
>     1) New -source/-target value in javac
>     2) Make new -source/-target value the default in javac
>     3) Change build of the JDK to use new -source/-target
>     4) Increment version
>     5) Support new --release value in javac
>     6) Output new class file format
>     7) Have HotSpot accept new class file format

Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

mark.reinhold
In reply to this post by Paul Sandoz
2017/12/13 14:09:44 -0800, [hidden email]:

>> On 13 Dec 2017, at 13:18, [hidden email] wrote:
>> How much of this can we parameterize and/or automate?
>
> I suspect quite a bit, as you present below, and i agree we should try
> and automate as much as possible. At the moment it’s very
> spaghetti-like and quite fragile.
>
> I suggest we get the initial version bump for 11 out of the way as
> soon as JDK 10 branches off from the mainline then work on automation
> for subsequent releases.

I understand that other incoming changes are waiting for the 11 version
bump, but can't we at least do the straightforward parameterizations and
introduce _CURRENT constants in this round?  We can leave anything that
requires code generation to post-11.

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Paul Sandoz


> On 13 Dec 2017, at 14:36, [hidden email] wrote:
>
> 2017/12/13 14:09:44 -0800, [hidden email]:
>>> On 13 Dec 2017, at 13:18, [hidden email] wrote:
>>> How much of this can we parameterize and/or automate?
>>
>> I suspect quite a bit, as you present below, and i agree we should try
>> and automate as much as possible. At the moment it’s very
>> spaghetti-like and quite fragile.
>>
>> I suggest we get the initial version bump for 11 out of the way as
>> soon as JDK 10 branches off from the mainline then work on automation
>> for subsequent releases.
>
> I understand that other incoming changes are waiting for the 11 version
> bump, but can't we at least do the straightforward parameterizations and
> introduce _CURRENT constants in this round?  We can leave anything that
> requires code generation to post-11.
>
On the lang tools side that does seem easy, but I’ll defer to Joe.

With some guidance from the build engineers i would gladly consolidate class file version declaration in C/++ files with a passed in macro, if this can be expediently worked out. I wanna push condy as early as possible in 11 :-)
If we could do something in jvm.h that would be ideal. We already have the definitions JVM_CLASSFILE_MAJOR_VERSION and JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so how can the build process inject values into those macros?

For class file versions embedded in Java code it would make it easier if we had programmatic access. Perhaps we could have static methods on Runtime.Version to get the major/minor class file versions?

Paul.

signature.asc (890 bytes) Download Attachment
12