From itakiguchi at openjdk.java.net  Mon Nov  1 16:10:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 1 Nov 2021 16:10:26 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - 8274544: Langtools command's usage were garbled on Japanese Windows
 - Langtools command's usage were grabled on Japanese Windows

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5771&range=04
  Stats: 104 lines in 17 files changed: 74 ins; 0 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5771/head:pull/5771

PR: https://git.openjdk.java.net/jdk/pull/5771

From itakiguchi at openjdk.java.net  Tue Nov  2 00:19:15 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 2 Nov 2021 00:19:15 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <LN2laH6f1Iev8itWARImc-iyulBKM3xgmWCFSRxTfi0=.b232f0c7-4955-40c8-8dca-e126fa3260c3@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

I needed to rebase my fixed code since JavapTask.java and JdepsTask.java were updated.

Hello @jonathan-gibbons .
Could you check new fixes ?
I changed following parts:
* Native charset is generated on com/sun/tools/javac/util/Log.java.
* module-info.java was updated

Hello @naotoj .
Could you check new fixes again ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From darcy at openjdk.java.net  Tue Nov  2 00:28:48 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Nov 2021 00:28:48 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v5]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <ufZcIc6p_95USw7AoqrvecfJiYQZqLH4unM4IFb9mSw=.f27b861c-cdbb-428b-ba0d-2abc3af19643@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into JDK-8224922
 - Update spec.
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - 8224922: Access JavaFileObject from Element(s)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/9cdb6c93..d1b6fab1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=03-04

  Stats: 863 lines in 29 files changed: 673 ins; 124 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From jlahoda at openjdk.java.net  Tue Nov  2 10:59:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 2 Nov 2021 10:59:35 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for switch
 (Second Preview)
Message-ID: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>

The specification for pattern matching for switch (preview)[1] has been updated with two changes:
-any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in `Attr.java`.)
-for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:

sealed interface I<T> {}
final class A implements I<String> {}
final class B<T> implements I<T> {}
...
I<Integer> i = ...;
switch (i) {
     case A a -> {} //case not allowed as I<Integer> is not castable to A
     case B b -> {}
}


But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including `A`, are covered by the switch, which forced a `default` clause in place of `case A a` for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:


I<Integer> i = ...;
switch (i) {
     case B b -> {}
}


compiles OK.
(See the change in `Flow.java`.)

[1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html

-------------

Commit messages:
 - Fixing tests.
 - Merge branch 'master' into JDK-8273328
 - Updating to reflect the new spec.

Changes: https://git.openjdk.java.net/jdk/pull/6209/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6209&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273328
  Stats: 223 lines in 9 files changed: 174 ins; 16 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6209.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6209/head:pull/6209

PR: https://git.openjdk.java.net/jdk/pull/6209

From gli at openjdk.java.net  Tue Nov  2 11:31:26 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 2 Nov 2021 11:31:26 GMT
Subject: RFR: 8263153: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
Message-ID: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>

Hi all,

Currently, the compiler doesn't `annotate` the internal type annotations of the annotation element value so that the field `JCAnnotation.attribute` is `null` and the compiler crashes. This patch adds the missed scaning step and the corresponding test case.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

-------------

Commit messages:
 - 8263153: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)

Changes: https://git.openjdk.java.net/jdk/pull/6210/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6210&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263153
  Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6210/head:pull/6210

PR: https://git.openjdk.java.net/jdk/pull/6210

From darcy at openjdk.java.net  Tue Nov  2 13:55:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Nov 2021 13:55:37 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v6]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <uV_6GiofcYy_szsgPzzfRhHYMQ_kBFRfdUycJyT9yvk=.1accf0d2-6776-4565-894d-d10e0554a6ba@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with 10 additional commits since the last revision:

 - Merge pull request #3 from lahodaj/JDK-8224922
   
   Improvements to JDK-8224922
 - Test cleanup.
 - Cleanup.
 - Cleanup.
 - Merge remote-tracking branch 'darcy/JDK-8224922' into JDK-8224922
 - Attempting to fix tests.
 - Merge remote-tracking branch 'JDK-8224922' into JDK-8224922
 - Fixing behavior for nested classes
 - Attempting to improve Elements.getFileObjectOf
 - Merge branch 'master' into JDK-8224922

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/d1b6fab1..1584c4b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=04-05

  Stats: 344 lines in 5 files changed: 330 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Tue Nov  2 14:04:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Nov 2021 14:04:51 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v7]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <NPuqqRdSD0sWDUbQVKy3HaMH2xdDleVSc2w_0MLx-H0=.38b77af2-7cd9-4d70-bd35-4258793f02a6@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/1584c4b4..50ce61b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From vromero at openjdk.java.net  Tue Nov  2 16:25:14 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 2 Nov 2021 16:25:14 GMT
Subject: RFR: 8263153: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
In-Reply-To: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
References: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
Message-ID: <jiapnbQRHMhDraUnlmSkb0nAQls_wwa38L5cIxMl6ys=.ab6a4afa-d822-41b7-b57a-676c03944aa8@github.com>

On Tue, 2 Nov 2021 11:23:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Currently, the compiler doesn't `annotate` the internal type annotations of the annotation element value so that the field `JCAnnotation.attribute` is `null` and the compiler crashes. This patch adds the missed scaning step and the corresponding test case.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

approved with minor suggestion, thanks for fixing this!

nit: please sync this PR title with the but title in JIRA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java line 677:

> 675: 
> 676:         // Scan the annotation element value and then attribute
> 677:         // the internal annotations to prevent the compiler from crashing

I would remove the: `to prevent the compiler from crashing` part, suggestion:


Scan the annotation element value and then attribute nested
annotations if present

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6210

From vromero at openjdk.java.net  Tue Nov  2 19:36:08 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 2 Nov 2021 19:36:08 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
Message-ID: <2KA1N_-YT02116JqrfhaVFURCntMDBzm7L-jQ3Z1QKM=.204fae4e-dcd5-4917-9d30-c0c5454ccf8f@github.com>

On Tue, 2 Nov 2021 10:51:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The specification for pattern matching for switch (preview)[1] has been updated with two changes:
> -any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in `Attr.java`.)
> -for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:
> 
> sealed interface I<T> {}
> final class A implements I<String> {}
> final class B<T> implements I<T> {}
> ...
> I<Integer> i = ...;
> switch (i) {
>      case A a -> {} //case not allowed as I<Integer> is not castable to A
>      case B b -> {}
> }
> 
> 
> But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including `A`, are covered by the switch, which forced a `default` clause in place of `case A a` for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:
> 
> 
> I<Integer> i = ...;
> switch (i) {
>      case B b -> {}
> }
> 
> 
> compiles OK.
> (See the change in `Flow.java`.)
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6209

From gli at openjdk.java.net  Wed Nov  3 01:52:43 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 3 Nov 2021 01:52:43 GMT
Subject: RFR: 8274942: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) [v2]
In-Reply-To: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
References: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
Message-ID: <kCw4CGFunSFp7OVC-_ayHHTIhByEPiNI6vhbVbIwOyI=.b37a873c-ba23-4687-a2f1-6ca4d2aefa71@github.com>

> Hi all,
> 
> Currently, the compiler doesn't `annotate` the internal type annotations of the annotation element value so that the field `JCAnnotation.attribute` is `null` and the compiler crashes. This patch adds the missed scaning step and the corresponding test case.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6210/files
  - new: https://git.openjdk.java.net/jdk/pull/6210/files/05d2f715..379268c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6210&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6210&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6210/head:pull/6210

PR: https://git.openjdk.java.net/jdk/pull/6210

From gli at openjdk.java.net  Wed Nov  3 01:52:47 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 3 Nov 2021 01:52:47 GMT
Subject: RFR: 8274942: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) [v2]
In-Reply-To: <jiapnbQRHMhDraUnlmSkb0nAQls_wwa38L5cIxMl6ys=.ab6a4afa-d822-41b7-b57a-676c03944aa8@github.com>
References: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
 <jiapnbQRHMhDraUnlmSkb0nAQls_wwa38L5cIxMl6ys=.ab6a4afa-d822-41b7-b57a-676c03944aa8@github.com>
Message-ID: <hcfhsSXZR0fT5q5yBpvJs1fuz1T3G1RpgESYc1-YP6A=.0d5fc5df-e31c-4554-a889-d22ffbb7de13@github.com>

On Tue, 2 Nov 2021 16:19:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java line 677:
> 
>> 675: 
>> 676:         // Scan the annotation element value and then attribute
>> 677:         // the internal annotations to prevent the compiler from crashing
> 
> I would remove the: `to prevent the compiler from crashing` part, suggestion:
> 
> 
> Scan the annotation element value and then attribute nested
> annotations if present

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6210

From gli at openjdk.java.net  Wed Nov  3 02:02:16 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 3 Nov 2021 02:02:16 GMT
Subject: RFR: 8274942: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
In-Reply-To: <jiapnbQRHMhDraUnlmSkb0nAQls_wwa38L5cIxMl6ys=.ab6a4afa-d822-41b7-b57a-676c03944aa8@github.com>
References: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
 <jiapnbQRHMhDraUnlmSkb0nAQls_wwa38L5cIxMl6ys=.ab6a4afa-d822-41b7-b57a-676c03944aa8@github.com>
Message-ID: <iUrIdBGwG3i-i5ti3gSPM_oDmouEAx6Te_Umtl3UMm0=.880b79ec-af5a-4929-bad6-6d7624e96adc@github.com>

On Tue, 2 Nov 2021 16:22:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, the compiler doesn't `annotate` the internal type annotations of the annotation element value so that the field `JCAnnotation.attribute` is `null` and the compiler crashes. This patch adds the missed scaning step and the corresponding test case.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> nit: please sync this PR title with the but title in JIRA

@vicente-romero-oracle Thanks for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6210

From gli at openjdk.java.net  Wed Nov  3 02:02:19 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 3 Nov 2021 02:02:19 GMT
Subject: Integrated: 8274942: AssertionError at
 jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
In-Reply-To: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
References: <qszKVEHuP2vTsbM7eBmDkHabcPNlFuQORla2yGCv8oo=.b72afe77-4c86-495f-9f1d-e387d088ee02@github.com>
Message-ID: <FzGR8MKQAtxxq_isnlaKbXRlVhETBtEidqtbtk7t65A=.e71a25d5-1687-4ff1-a56e-0bfa4b62bc5b@github.com>

On Tue, 2 Nov 2021 11:23:05 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> Currently, the compiler doesn't `annotate` the internal type annotations of the annotation element value so that the field `JCAnnotation.attribute` is `null` and the compiler crashes. This patch adds the missed scaning step and the corresponding test case.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 2b02b6f5
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b02b6f513b062261195ca1edd059d16abb7bec6
Stats:     63 lines in 2 files changed: 63 ins; 0 del; 0 mod

8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/6210

From shade at openjdk.java.net  Wed Nov  3 12:02:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 3 Nov 2021 12:02:22 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
Message-ID: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>

JDK-8182285 added the incremental build capabilities for modules, by hashing the APIs of each module.

The original change uses MD5, which is quite weak, and JDK-8214483 allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.

Additional testing:
 - [x] Linux x86_64 fastdebug build completes
 - [x] Linux x86_64 fastdebug build times do not regress

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/6231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6231&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276550
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6231/head:pull/6231

PR: https://git.openjdk.java.net/jdk/pull/6231

From adinn at openjdk.java.net  Wed Nov  3 14:13:18 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 3 Nov 2021 14:13:18 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <DQBDGNpr6xZunN8QEXczBUKXOBux6v0_pSH1wmn2AV8=.6412ac76-3164-4621-8f4e-c289d1b11d3b@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8182285 added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and JDK-8214483 allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

Looks good.

-------------

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6231

From aph at openjdk.java.net  Wed Nov  3 14:37:13 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Nov 2021 14:37:13 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <APghJzwOR03dx7qRU3QrNrpu8Fot0n5mGib-7XW09NM=.82db2c2e-67c0-4c42-9bbd-0044e5743f8f@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From naoto at openjdk.java.net  Wed Nov  3 18:44:17 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 3 Nov 2021 18:44:17 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead.
As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From darcy at openjdk.java.net  Wed Nov  3 20:24:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Nov 2021 20:24:46 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v8]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <_gUWNqd9ISKyk-qzSKGQ8SkUu7sTPqbJXgbpgVyJP0c=.75387bf4-1d45-43f3-b3e1-9cfe9eae2d90@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Ancillary improvements to the spec.
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Appease jcheck.
 - Merge pull request #3 from lahodaj/JDK-8224922
   
   Improvements to JDK-8224922
 - Test cleanup.
 - Cleanup.
 - Cleanup.
 - Merge remote-tracking branch 'darcy/JDK-8224922' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/60d70e72...1599509b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/50ce61b2..1599509b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=06-07

  Stats: 1121 lines in 121 files changed: 632 ins; 121 del; 368 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Wed Nov  3 20:41:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Nov 2021 20:41:16 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v8]
In-Reply-To: <_gUWNqd9ISKyk-qzSKGQ8SkUu7sTPqbJXgbpgVyJP0c=.75387bf4-1d45-43f3-b3e1-9cfe9eae2d90@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
 <_gUWNqd9ISKyk-qzSKGQ8SkUu7sTPqbJXgbpgVyJP0c=.75387bf4-1d45-43f3-b3e1-9cfe9eae2d90@github.com>
Message-ID: <EQZkBgtbVq2ZFJhPoqZ0RjXmBU1rDopFqWUBnz4Hs7w=.cb5229a1-1756-4483-946e-0e41beeb8c90@github.com>

On Wed, 3 Nov 2021 20:24:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Ancillary improvements to the spec.
>  - Merge branch 'master' into JDK-8224922
>  - Merge branch 'master' into JDK-8224922
>  - Appease jcheck.
>  - Merge pull request #3 from lahodaj/JDK-8224922
>    
>    Improvements to JDK-8224922
>  - Test cleanup.
>  - Cleanup.
>  - Cleanup.
>  - Merge remote-tracking branch 'darcy/JDK-8224922' into JDK-8224922
>  - Merge branch 'master' into JDK-8224922
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0f04a159...1599509b

test/langtools/tools/javac/processing/model/element/TestFileObjectOf.java line 59:

> 57: import toolbox.ToolBox;
> 58: 
> 59: public class TestFileObjectOf extends TestRunner {

Other situations to test include unnamed packages and modules, which should get a corresponding spec update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5038

From andrew at openjdk.java.net  Wed Nov  3 21:03:13 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 3 Nov 2021 21:03:13 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <T9b77yhYwPCaFfMlrzkFu9bbhTAYY3NEp_8opNiOJwU=.2b2fd4c6-eec4-424b-a48d-7082cd284771@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

SHA-256 is the right choice here from the small list of required algorithms in the boot JDK. MD5 has already been removed from the list of required algorithms and SHA-1 deprecation for JARs is planned: https://java.com/en/jre-jdk-cryptoroadmap.html

-------------

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6231

From aivanov at openjdk.java.net  Wed Nov  3 23:28:11 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 3 Nov 2021 23:28:11 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <XXF_y6y6b8zGJYTq-z98k7zcR2_9V_mjDThKBdmMJz0=.1411e4be-7563-4e58-9b53-86af170378e7@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

I can confirm that these fixes make these tests pass in Russian locale.

Two of the tests fail with timeout for me: `ToolBasicTest.java` and `ToolSimpleTest.java`; the other two `LambdaTranslationTest{1,2}.java` fail without the fix and pass with the proposed fix applied. I'm inclined to trust that the first pair also passes successfully with the fix.

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5098

From ihse at openjdk.java.net  Thu Nov  4 11:18:31 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 11:18:31 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
Message-ID: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>

I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

-------------

Commit messages:
 - 8276629: Use blessed modifier order in core-libs code

Changes: https://git.openjdk.java.net/jdk/pull/6250/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6250&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276629
  Stats: 44 lines in 28 files changed: 0 ins; 0 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6250/head:pull/6250

PR: https://git.openjdk.java.net/jdk/pull/6250

From prappo at openjdk.java.net  Thu Nov  4 11:35:15 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 4 Nov 2021 11:35:15 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <yrN2gpjokt-x9gdvzbcEaEjcLwzvUvgZJvm66XYdbQo=.3ea24fb8-5537-450b-b5ae-7f7f4053b269@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

I can see that this PR changes java.naming. Another bug to change java.naming, JDK-8276552, was filed yesterday. Please check with its reporter and coordinate this effort if necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From ihse at openjdk.java.net  Thu Nov  4 11:54:28 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 11:54:28 GMT
Subject: RFR: 8276635: Use blessed modifier order in compiler code
Message-ID: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>

I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

-------------

Commit messages:
 - 8276635: Use blessed modifier order in compiler code

Changes: https://git.openjdk.java.net/jdk/pull/6253/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6253&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276635
  Stats: 45 lines in 24 files changed: 0 ins; 0 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6253/head:pull/6253

PR: https://git.openjdk.java.net/jdk/pull/6253

From dholmes at openjdk.java.net  Thu Nov  4 12:25:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Nov 2021 12:25:13 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <RY2hRD9O14oeUExaDfQqCZEvL8Ax0jjbSxALNvisIC0=.62429cef-6291-4ca9-a88a-614d313f0ac9@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Looks fine to me.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6250

From aefimov at openjdk.java.net  Thu Nov  4 12:34:20 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 4 Nov 2021 12:34:20 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <LA7r08xlaJBycza7MWwvCO7T6sf41czSC0pKzlf-gUA=.ef2dc854-9b17-4152-8393-632edf3b39ca@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by aefimov (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From aefimov at openjdk.java.net  Thu Nov  4 12:34:21 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 4 Nov 2021 12:34:21 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <yrN2gpjokt-x9gdvzbcEaEjcLwzvUvgZJvm66XYdbQo=.3ea24fb8-5537-450b-b5ae-7f7f4053b269@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
 <yrN2gpjokt-x9gdvzbcEaEjcLwzvUvgZJvm66XYdbQo=.3ea24fb8-5537-450b-b5ae-7f7f4053b269@github.com>
Message-ID: <ZxUoWnufN7qkOizXnpwBEetW7i7Lk4ytwUOOUcV6uVg=.d7a73622-c808-4abd-86e8-ca5a5bb1f445@github.com>

On Thu, 4 Nov 2021 11:31:50 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I can see that this PR changes java.naming. Another bug to change java.naming, JDK-8276552, was filed yesterday. Please check with its reporter and coordinate this effort if necessary.

@magicus I'm ok with having `java.naming` changes integrated as part of this PR.  I'll close `JDK-8276552` as duplicate. 
The changes looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From ihse at openjdk.java.net  Thu Nov  4 12:55:23 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 12:55:23 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <ZxUoWnufN7qkOizXnpwBEetW7i7Lk4ytwUOOUcV6uVg=.d7a73622-c808-4abd-86e8-ca5a5bb1f445@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
 <yrN2gpjokt-x9gdvzbcEaEjcLwzvUvgZJvm66XYdbQo=.3ea24fb8-5537-450b-b5ae-7f7f4053b269@github.com>
 <ZxUoWnufN7qkOizXnpwBEetW7i7Lk4ytwUOOUcV6uVg=.d7a73622-c808-4abd-86e8-ca5a5bb1f445@github.com>
Message-ID: <hrOeto44By25rLSkLOLkzp9gSf3BUDfNroDRBImc4I0=.5c582cd8-778c-4ec6-893d-7e724157e3b6@github.com>

On Thu, 4 Nov 2021 12:30:40 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> I can see that this PR changes java.naming. Another bug to change java.naming, JDK-8276552, was filed yesterday. Please check with its reporter and coordinate this effort if necessary.
>
>> I can see that this PR changes java.naming. Another bug to change java.naming, JDK-8276552, was filed yesterday. Please check with its reporter and coordinate this effort if necessary.
> 
> @magicus I'm ok with having `java.naming` changes integrated as part of this PR.  I'll close `JDK-8276552` as duplicate. 
> The changes looks fine to me.

@AlekseiEfimov Thanks! I tried to search for open PRs with blessed ordering, but I did not search open bugs...

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From mcimadamore at openjdk.java.net  Thu Nov  4 13:03:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 4 Nov 2021 13:03:14 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
Message-ID: <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>

On Tue, 2 Nov 2021 10:51:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The specification for pattern matching for switch (preview)[1] has been updated with two changes:
> -any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in `Attr.java`.)
> -for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:
> 
> sealed interface I<T> {}
> final class A implements I<String> {}
> final class B<T> implements I<T> {}
> ...
> I<Integer> i = ...;
> switch (i) {
>      case A a -> {} //case not allowed as I<Integer> is not castable to A
>      case B b -> {}
> }
> 
> 
> But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including `A`, are covered by the switch, which forced a `default` clause in place of `case A a` for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:
> 
> 
> I<Integer> i = ...;
> switch (i) {
>      case B b -> {}
> }
> 
> 
> compiles OK.
> (See the change in `Flow.java`.)
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html

Looks good. Left one comment about the logic in Flow.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 788:

> 786: 
> 787:         private boolean isTransitivelyCovered(Type seltype, Symbol sealed, Set<Symbol> covered) {
> 788:             DeferredCompletionFailureHandler.Handler prevHandler =

Why do we need to guard against completion failures here in Flow?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6209

From darcy at openjdk.java.net  Thu Nov  4 13:13:11 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 4 Nov 2021 13:13:11 GMT
Subject: RFR: 8276635: Use blessed modifier order in compiler code
In-Reply-To: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
References: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
Message-ID: <hTF1UCCJgA6D3C0Md0qtr4HRdUguB0lOV7fqljnQPoA=.267b5bd7-d512-4978-9881-c847ed30665a@github.com>

On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Looks fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6253

From shade at openjdk.java.net  Thu Nov  4 13:16:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 4 Nov 2021 13:16:20 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <Jv2GZoKFv2oR04uVtIIMQM1OKzTLO8fO4uaYDBiF4Fg=.8977eab3-61cb-4689-b1e2-22f054396090@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

@magicus, are you good with this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From jlahoda at openjdk.java.net  Thu Nov  4 13:19:10 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 4 Nov 2021 13:19:10 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
 <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
Message-ID: <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>

On Thu, 4 Nov 2021 12:59:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The specification for pattern matching for switch (preview)[1] has been updated with two changes:
>> -any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in `Attr.java`.)
>> -for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:
>> 
>> sealed interface I<T> {}
>> final class A implements I<String> {}
>> final class B<T> implements I<T> {}
>> ...
>> I<Integer> i = ...;
>> switch (i) {
>>      case A a -> {} //case not allowed as I<Integer> is not castable to A
>>      case B b -> {}
>> }
>> 
>> 
>> But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including `A`, are covered by the switch, which forced a `default` clause in place of `case A a` for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:
>> 
>> 
>> I<Integer> i = ...;
>> switch (i) {
>>      case B b -> {}
>> }
>> 
>> 
>> compiles OK.
>> (See the change in `Flow.java`.)
>> 
>> [1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 788:
> 
>> 786: 
>> 787:         private boolean isTransitivelyCovered(Type seltype, Symbol sealed, Set<Symbol> covered) {
>> 788:             DeferredCompletionFailureHandler.Handler prevHandler =
> 
> Why do we need to guard against completion failures here in Flow?

Consider a case like this:

sealed interface I permits A, B {}
//A and B defined
...
I i = null;
switch (i) {
     case A -> {}
}


This will produce an error, because the switch is not exhaustive. Now, consider, in addition, that `B` is missing. It feels a bit harsh to produce an error about the missing `B` permitted subclass (possibly producing that error instead of the exhaustiveness error), as it seems plausible permitted subclasses may be missing during compilation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From ihse at openjdk.java.net  Thu Nov  4 13:20:12 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 13:20:12 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <EDwJMBQP0KLUytfUwJKw_MJnkRCOUdQCzIRNQiUnzIk=.8603fb46-3150-4b4d-b0c0-f1f7632c03ab@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

Shoot!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From mcimadamore at openjdk.java.net  Thu Nov  4 13:58:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 4 Nov 2021 13:58:17 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
 <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
 <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>
Message-ID: <Aziv_nCKVgn3M7S-jBUhyS12YHaPoFZfXZ4ug9gx7bA=.c92f11de-3a4e-4470-b752-51a6cd3fe186@github.com>

On Thu, 4 Nov 2021 13:16:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 788:
>> 
>>> 786: 
>>> 787:         private boolean isTransitivelyCovered(Type seltype, Symbol sealed, Set<Symbol> covered) {
>>> 788:             DeferredCompletionFailureHandler.Handler prevHandler =
>> 
>> Why do we need to guard against completion failures here in Flow?
>
> Consider a case like this:
> 
> sealed interface I permits A, B {}
> //A and B defined
> ...
> I i = null;
> switch (i) {
>      case A -> {}
> }
> 
> 
> This will produce an error, because the switch is not exhaustive. Now, consider, in addition, that `B` is missing. It feels a bit harsh to produce an error about the missing `B` permitted subclass (possibly producing that error instead of the exhaustiveness error), as it seems plausible permitted subclasses may be missing during compilation.

Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From mcimadamore at openjdk.java.net  Thu Nov  4 14:04:08 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 4 Nov 2021 14:04:08 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <Aziv_nCKVgn3M7S-jBUhyS12YHaPoFZfXZ4ug9gx7bA=.c92f11de-3a4e-4470-b752-51a6cd3fe186@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
 <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
 <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>
 <Aziv_nCKVgn3M7S-jBUhyS12YHaPoFZfXZ4ug9gx7bA=.c92f11de-3a4e-4470-b752-51a6cd3fe186@github.com>
Message-ID: <0GUGS3zw05XeDrPu5372k2CJknO0PcLG2vE-DyHgSL4=.36eabae0-1301-4871-9635-d818a8d09f52@github.com>

On Thu, 4 Nov 2021 13:55:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)

Ok - maybe you are considering the case where `I` is used in a compilation unit which did not defined it. And which cannot (for some reason) see B.  Seems cornery, but what I'm mostly worried about is that it's not (I think) uniform with the rest of the javac code dealing with sealed classes. For instance, look at the cast conversion rules in `Types::areDisjoint` - in that case there's no protection against missing types.

I think the compiler code should be consistent in how we reason about sealed permitted types?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From dfuchs at openjdk.java.net  Thu Nov  4 14:46:15 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 4 Nov 2021 14:46:15 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <ESjFvLrFVHF7ixyL0pYTtWWZPpfkNoGGKizpY1J25Lw=.b1fb096d-e6e6-439c-beb2-86e63b6d6b1d@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From shade at openjdk.java.net  Thu Nov  4 15:35:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 4 Nov 2021 15:35:11 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <EDwJMBQP0KLUytfUwJKw_MJnkRCOUdQCzIRNQiUnzIk=.8603fb46-3150-4b4d-b0c0-f1f7632c03ab@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
 <EDwJMBQP0KLUytfUwJKw_MJnkRCOUdQCzIRNQiUnzIk=.8603fb46-3150-4b4d-b0c0-f1f7632c03ab@github.com>
Message-ID: <8dU5ePyO8YqN5kZDJrm6hTHfAagQZHMtrYL5Y8-X8nU=.1c8c93a4-7f18-429c-89ba-b7a6df30a9e1@github.com>

On Thu, 4 Nov 2021 13:17:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Shoot!

...as in "Approved"? :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From ihse at openjdk.java.net  Thu Nov  4 15:44:17 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 15:44:17 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <Falxt6rGhlc24F0hclkk8zeg5iIFEnuut-V_WlwaPXc=.a1649aef-64bd-48d2-a755-3ab2cb18a22f@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

Marked as reviewed by ihse (Reviewer).

Yes, sorry, I was only on the phone and the github app didn't let me approve the PR, or I was too stupid to figure out how to correctly fight their UI. This is kind of border-line build functionality, so I didn't know my approval was needed. :) But now you have it, anyway. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From shade at openjdk.java.net  Thu Nov  4 15:44:17 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 4 Nov 2021 15:44:17 GMT
Subject: RFR: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <-yKDa1gUy36WcvNLlEG4uxDy0aTX-2S_3tYB4tf63Sg=.d9a050f1-46d9-49bd-8a6e-ab29b961ae92@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

Good, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From shade at openjdk.java.net  Thu Nov  4 15:44:18 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 4 Nov 2021 15:44:18 GMT
Subject: Integrated: 8276550: Use SHA256 hash in build.tools.depend.Depend
In-Reply-To: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
References: <zO0WGEFRL5JdN6UlcducmnP_OzhWNkr-fKCJqZdBiz4=.6f9d0805-49b0-4a34-8b0b-ba433e24c166@github.com>
Message-ID: <5ZJwEiPjea4jhp2KOVlEjmvXNxC688zQoljf1XCicck=.9b72de1f-8fff-4dd6-8c29-b8ff284e6f98@github.com>

On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8182285](https://bugs.openjdk.java.net/browse/JDK-8182285) added the incremental build capabilities for modules, by hashing the APIs of each module.
> 
> The original change uses MD5, which is quite weak, and [JDK-8214483](https://bugs.openjdk.java.net/browse/JDK-8214483) allows `MessageDigest` to have no MD5 implementation. This is the cause of some build failures when using a FIPS-compliant boot JDK that has no MD5 implementation. I suggest we switch to the latest available hash instead.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug build completes
>  - [x] Linux x86_64 fastdebug build times do not regress

This pull request has now been integrated.

Changeset: afb502e2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8276550: Use SHA256 hash in build.tools.depend.Depend

Reviewed-by: adinn, aph, andrew, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/6231

From mchung at openjdk.java.net  Thu Nov  4 16:09:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 16:09:12 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <NO0_GKSuhoclaLuJSm5iSzet_Hx5QZRSUt146Yw3Ue0=.1e28a40a-5674-429c-9d6b-c05168805d54@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From jlahoda at openjdk.java.net  Thu Nov  4 16:16:11 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 4 Nov 2021 16:16:11 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <0GUGS3zw05XeDrPu5372k2CJknO0PcLG2vE-DyHgSL4=.36eabae0-1301-4871-9635-d818a8d09f52@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
 <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
 <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>
 <Aziv_nCKVgn3M7S-jBUhyS12YHaPoFZfXZ4ug9gx7bA=.c92f11de-3a4e-4470-b752-51a6cd3fe186@github.com>
 <0GUGS3zw05XeDrPu5372k2CJknO0PcLG2vE-DyHgSL4=.36eabae0-1301-4871-9635-d818a8d09f52@github.com>
Message-ID: <OqjHCWyt_1obXMGMv80mlhv0bIE4qgLg_Uwfq5Bkqho=.930e8f10-c07e-47fc-b2b4-59e5fadff763@github.com>

On Thu, 4 Nov 2021 14:01:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
>
>> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
> 
> Ok - maybe you are considering the case where `I` is used in a compilation unit which did not defined it. And which cannot (for some reason) see B.  Seems cornery, but what I'm mostly worried about is that it's not (I think) uniform with the rest of the javac code dealing with sealed classes. For instance, look at the cast conversion rules in `Types::areDisjoint` - in that case there's no protection against missing types.
> 
> I think the compiler code should be consistent in how we reason about sealed permitted types?

Right, the case is where the sealed class/interface is used from some other project. It is somewhat cornery, but might happen even for us - consider an sealed API interface in the JDK, which has permitted classes that are in an implementation package. The `--release` data normally do not include non-API packages, so when looking at the API interface, we may encounter a class that does not exist.

I didn't realize there is the same issue with `areDisjoint`, but you are right it suffers from the problem and that it should be consistent. I'll take a look at that, possibly separately, if that's OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From jjg at openjdk.java.net  Thu Nov  4 16:53:15 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 4 Nov 2021 16:53:15 GMT
Subject: RFR: 8272728: javac ignores any -J option in @argfiles silently
In-Reply-To: <YYENqjokKeg5xFUYaJLnuAFL3RsKjb4PqfXE37FgyhQ=.aee49177-40cf-48fe-81be-9ed99fa8a865@github.com>
References: <YYENqjokKeg5xFUYaJLnuAFL3RsKjb4PqfXE37FgyhQ=.aee49177-40cf-48fe-81be-9ed99fa8a865@github.com>
Message-ID: <_YpI_xTAFVMKjTzTI4TK0bxcjY8FjbUQIDKMjHxR1KI=.1838c40a-47f4-4484-a159-b8c0851a3d22@github.com>

On Mon, 11 Oct 2021 12:20:02 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them.

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5891

From itakiguchi at openjdk.java.net  Thu Nov  4 16:58:14 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 4 Nov 2021 16:58:14 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <P0AuXzsED_Qw17n6662lW0-pxK838w59qmuenfK24Qs=.af9e293a-1d22-4f35-bbc2-2d5254cdc41c@github.com>
Message-ID: <fjnb_N2nCTEUxdKa7zGhdRd6U3UVDDh87UKRquApv6k=.ffa3c221-2afb-4de5-ab8e-ab6b47744f4d@github.com>

On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - Langtools command's usage were grabled on Japanese Windows
>
> Firstly, please do NOT rebase your fix, as it will clobber the review history. Use merge instead.
> As to the fix, I am not sure consolidating the code into Log.java would be OK as it would introduce module dependency.

@naotoj 
I'm sorry about my bad operation.

@jonathan-gibbons 
I appreciate if you give me some suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From iris at openjdk.java.net  Thu Nov  4 17:05:23 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 4 Nov 2021 17:05:23 GMT
Subject: RFR: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <EEqbHO2GPxPgFUGhBVT5mTZXJGY9mHzUSXCA4_iRebw=.8d4d474a-2a49-4f20-bd91-272ca5dbb271@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From ihse at openjdk.java.net  Thu Nov  4 17:05:23 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:05:23 GMT
Subject: Integrated: 8276629: Use blessed modifier order in core-libs code
In-Reply-To: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
References: <UC2B15ReEGdyPjxGNLq5_3kQ6lLnB1snqEKJjWgdDYE=.c5ba393c-e850-4499-9092-cf9e06038650@github.com>
Message-ID: <QLgOC182fh3g_tBh4ek99503LSOHRZ9bAIar6duoM3Y=.5243c155-97cb-46aa-abff-0c675b99e41b@github.com>

On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: 1533b819
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1533b8191bed9d65ab4af03945584d8b2276d828
Stats:     44 lines in 28 files changed: 0 ins; 0 del; 44 mod

8276629: Use blessed modifier order in core-libs code

Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6250

From ihse at openjdk.java.net  Thu Nov  4 17:24:44 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:24:44 GMT
Subject: RFR: 8276635: Use blessed modifier order in compiler code [v2]
In-Reply-To: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
References: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
Message-ID: <pFmx_obaHkG8PIzcG1KWBvNUTUmBeeWr5Sy5P-c7c8k=.c4d55463-4598-4b0c-a26b-0c8b8baa6f82@github.com>

> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6253/files
  - new: https://git.openjdk.java.net/jdk/pull/6253/files/483213d3..b1e1b97f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6253&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6253&range=00-01

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6253/head:pull/6253

PR: https://git.openjdk.java.net/jdk/pull/6253

From mcimadamore at openjdk.java.net  Thu Nov  4 18:02:14 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 4 Nov 2021 18:02:14 GMT
Subject: RFR: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <OqjHCWyt_1obXMGMv80mlhv0bIE4qgLg_Uwfq5Bkqho=.930e8f10-c07e-47fc-b2b4-59e5fadff763@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
 <iH2mKTqJ2GxFrvvSiilApIJbawwS8QOmWtwNqb1mYYs=.3ebc649e-7288-4440-92e0-c226620cbe3f@github.com>
 <cCvC7zx4hoY6VHKLYowexo7OviQr50gbb2o6d-LZxHA=.00cb8c9f-dd70-4736-be23-b1b93ddf25fe@github.com>
 <Aziv_nCKVgn3M7S-jBUhyS12YHaPoFZfXZ4ug9gx7bA=.c92f11de-3a4e-4470-b752-51a6cd3fe186@github.com>
 <0GUGS3zw05XeDrPu5372k2CJknO0PcLG2vE-DyHgSL4=.36eabae0-1301-4871-9635-d818a8d09f52@github.com>
 <OqjHCWyt_1obXMGMv80mlhv0bIE4qgLg_Uwfq5Bkqho=.930e8f10-c07e-47fc-b2b4-59e5fadff763@github.com>
Message-ID: <B3zuA3Q1m5pNY-xfHCqkbGPmY-QyPq-LP1Yy_ToxzCQ=.29985403-bc86-4e90-8849-498a409d5aed@github.com>

On Thu, 4 Nov 2021 16:13:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> Uhm - I get what you say. But isn't sealing meant to be used within a single maintenance domain? If B is missing, how the heck did we get to Flow in the first place (since for sealed classes we check that permitted subclasses extend the sealed class being defined)
>> 
>> Ok - maybe you are considering the case where `I` is used in a compilation unit which did not defined it. And which cannot (for some reason) see B.  Seems cornery, but what I'm mostly worried about is that it's not (I think) uniform with the rest of the javac code dealing with sealed classes. For instance, look at the cast conversion rules in `Types::areDisjoint` - in that case there's no protection against missing types.
>> 
>> I think the compiler code should be consistent in how we reason about sealed permitted types?
>
> Right, the case is where the sealed class/interface is used from some other project. It is somewhat cornery, but might happen even for us - consider an sealed API interface in the JDK, which has permitted classes that are in an implementation package. The `--release` data normally do not include non-API packages, so when looking at the API interface, we may encounter a class that does not exist.
> 
> I didn't realize there is the same issue with `areDisjoint`, but you are right it suffers from the problem and that it should be consistent. I'll take a look at that, possibly separately, if that's OK.

Yep - fine to postpone!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From mchung at openjdk.java.net  Thu Nov  4 19:36:26 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 19:36:26 GMT
Subject: RFR: JDK-8276650: GenGraphs does not produce deterministic output
Message-ID: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>

The dot graph should print the edges in alphatical order.   A simple fix to sort the edges before printing them.

-------------

Commit messages:
 - JDK-8276650: GenGraphs does not produce deterministic output

Changes: https://git.openjdk.java.net/jdk/pull/6266/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6266&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276650
  Stats: 41 lines in 2 files changed: 2 ins; 1 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6266/head:pull/6266

PR: https://git.openjdk.java.net/jdk/pull/6266

From iris at openjdk.java.net  Thu Nov  4 20:17:10 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 4 Nov 2021 20:17:10 GMT
Subject: RFR: JDK-8276650: GenGraphs does not produce deterministic output
In-Reply-To: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
References: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
Message-ID: <OM54XVp2uO3synWtBSEewP9kft8ALb-VwactwKzE0NA=.74fe1501-0501-4796-9145-e9603c4d4108@github.com>

On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The dot graph should print the edges in alphatical order.   A simple fix to sort the edges before printing them.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6266

From aleonard at openjdk.java.net  Thu Nov  4 21:16:31 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 4 Nov 2021 21:16:31 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
Message-ID: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>

This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
It fixes the following keys issues relating to reproducibility:
- Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
  - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
- Jar and Jmod file content ordering was non-determinsitic
  - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
- openjdk image zip file generation used "zip" which is non-determinsitic
  - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Commit messages:
 - 8276400: openjdk image Jars, Zips and Jmods built from the same source are not reproducible

Changes: https://git.openjdk.java.net/jdk/pull/6268/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6268&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276400
  Stats: 818 lines in 11 files changed: 797 ins; 3 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6268.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6268/head:pull/6268

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Thu Nov  4 21:16:32 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 4 Nov 2021 21:16:32 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <7f3EDTxxB759aaBolckEm4yIHTGgkqWou-BHq6ghMQg=.6979cc3d-1043-4ae6-9695-c293c3528c7c@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@magicus fyi, please review if you have a moment, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From cushon at openjdk.java.net  Thu Nov  4 21:43:10 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 4 Nov 2021 21:43:10 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v3]
In-Reply-To: <MEiz58NV_v6AlY4AlkJkKcpauxb1typSr4HKUo4z964=.f5b43677-6cff-40f4-a0bc-2ea7ab78eedc@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <MEiz58NV_v6AlY4AlkJkKcpauxb1typSr4HKUo4z964=.f5b43677-6cff-40f4-a0bc-2ea7ab78eedc@github.com>
Message-ID: <xyoQhbbGr0Pcm2Kyy2TTboHIkVGOv8NKqtWZNCNGUX8=.ef399830-326a-44b0-9780-8fc98fe18be7@github.com>

On Mon, 11 Oct 2021 20:11:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

The CSR has been approved, I think this is ready for review. Is anyone interested in taking a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From duke at openjdk.java.net  Thu Nov  4 21:49:15 2021
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Thu, 4 Nov 2021 21:49:15 GMT
Subject: RFR: JDK-8276650: GenGraphs does not produce deterministic output
In-Reply-To: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
References: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
Message-ID: <dHVBejAXyBEqmeWI9Cwz6TWLWugx6GQMHlmxaNCS6hI=.1cdadf96-f567-43fd-86c5-bf89a291d2ac@github.com>

On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The dot graph should print the edges in alphatical order.   A simple fix to sort the edges before printing them.

src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336:

> 334:         private final String name;
> 335:         private final Graph<String> graph;
> 336:         private final TreeSet<ModuleDescriptor> descriptors = new TreeSet<>();

This change is unnecessary, isn't it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6266

From darcy at openjdk.java.net  Thu Nov  4 21:55:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 4 Nov 2021 21:55:12 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <rWRNOYJ5XQzSDF6ZsC2rHYmt-W6Ls_FRe5PEBHgD09c=.5819a6e6-5d14-4534-b5ba-85c1cec32436@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, etc. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Thu Nov  4 22:11:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 4 Nov 2021 22:11:10 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <rWRNOYJ5XQzSDF6ZsC2rHYmt-W6Ls_FRe5PEBHgD09c=.5819a6e6-5d14-4534-b5ba-85c1cec32436@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <rWRNOYJ5XQzSDF6ZsC2rHYmt-W6Ls_FRe5PEBHgD09c=.5819a6e6-5d14-4534-b5ba-85c1cec32436@github.com>
Message-ID: <qnfltg-Y_tHu4VOQq6rZe9QCOm4OM6hu_0Gt73_fC44=.bdd44888-712e-454d-8355-d0f6d2f23031@github.com>

On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, etc. Thanks.

@jddarcy thanks, I did wonder that, i'll start a CSR, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From mchung at openjdk.java.net  Thu Nov  4 22:20:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 22:20:11 GMT
Subject: RFR: JDK-8276650: GenGraphs does not produce deterministic output
In-Reply-To: <dHVBejAXyBEqmeWI9Cwz6TWLWugx6GQMHlmxaNCS6hI=.1cdadf96-f567-43fd-86c5-bf89a291d2ac@github.com>
References: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
 <dHVBejAXyBEqmeWI9Cwz6TWLWugx6GQMHlmxaNCS6hI=.1cdadf96-f567-43fd-86c5-bf89a291d2ac@github.com>
Message-ID: <6eGJZ6fovwnmnbynjmCewLgfif0wnY2k6Q7pn2Fer7E=.3aae32b0-b6ec-402d-aba8-dab10d88a81b@github.com>

On Thu, 4 Nov 2021 21:46:21 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

>> The dot graph should print the edges in alphatical order.   A simple fix to sort the edges before printing them.
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336:
> 
>> 334:         private final String name;
>> 335:         private final Graph<String> graph;
>> 336:         private final TreeSet<ModuleDescriptor> descriptors = new TreeSet<>();
> 
> This change is unnecessary, isn't it?

This will make it clear that this is sorted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6266

From aleonard at openjdk.java.net  Thu Nov  4 22:43:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 4 Nov 2021 22:43:07 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <rWRNOYJ5XQzSDF6ZsC2rHYmt-W6Ls_FRe5PEBHgD09c=.5819a6e6-5d14-4534-b5ba-85c1cec32436@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <rWRNOYJ5XQzSDF6ZsC2rHYmt-W6Ls_FRe5PEBHgD09c=.5819a6e6-5d14-4534-b5ba-85c1cec32436@github.com>
Message-ID: <_3m1Ajg1RnTqOz28MYiVIPW2CR6NqJWk8AWHKi-o22A=.b25869fd-f9ca-4a33-a510-509d88c6da10@github.com>

On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Please file a CSR for the behavioral change of recognizing SOURCE_DATE_EPOCH, etc. Thanks.

@jddarcy  CSR created: https://bugs.openjdk.java.net/browse/JDK-8276667

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From mchung at openjdk.java.net  Thu Nov  4 23:54:12 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 4 Nov 2021 23:54:12 GMT
Subject: Integrated: JDK-8276650: GenGraphs does not produce deterministic
 output
In-Reply-To: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
References: <coczFcG6BI-gCA8AqnpPoHje5QOHQGO4mfBI2IUPewQ=.69198f0d-0262-4e62-82c2-56e68d8278e0@github.com>
Message-ID: <XHUBVBFmhFHBjLtMxlHa8r98XLW8oBQwz_PeCe9HUZ8=.015c4b99-77cb-4c96-b6c7-088ea5323760@github.com>

On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The dot graph should print the edges in alphatical order.   A simple fix to sort the edges before printing them.

This pull request has now been integrated.

Changeset: e21b5c7b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e
Stats:     41 lines in 2 files changed: 2 ins; 1 del; 38 mod

8276650: GenGraphs does not produce deterministic output

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6266

From duke at openjdk.java.net  Fri Nov  5 01:46:10 2021
From: duke at openjdk.java.net (Michael Bien)
Date: Fri, 5 Nov 2021 01:46:10 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <XeJs1ws2QRLPo4iBpCYV4AZ58P-55HyuGAXPdObpqR8=.c34cf414-6402-4783-84d8-1ce1d70f0937@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

a few minor comments

make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 96:

> 94:                     ok = createOk;
> 95:                 }
> 96:                 out.close();

could be a try-with-resource block

make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 191:

> 189:         Iterator<Map.Entry<String, Path>> itr = filesToProcess.entrySet().iterator();
> 190:         while(itr.hasNext()) {
> 191:             Map.Entry<String, Path> entry = itr.next();

could be `for (Map.Entry<String, Path> entry : filesToProcess.entrySet())`

make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 262:

> 260:                 zos.write(buf, 0, len);
> 261:             }
> 262:             is.close();

try-with-resource candidate + in.transferTo(zos)

make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 291:

> 289:             newArgs.add(arg);
> 290:         }
> 291:         return newArgs.toArray(new String[newArgs.size()]);

something might be missing here. It just adds args to a list and makes it an array again + If the language level allows it toArray(String[]::new) could be used.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 106:

> 104:                         value = -1;
> 105:                     }
> 106:                     return new Long(value);

value can be returned here directly which will use auto-boxing. (new Long(long) is deprecated).

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 799:

> 797:             Iterator<Map.Entry<String, Path>> itr = filesToProcess.entrySet().iterator();
> 798:             while(itr.hasNext()) {
> 799:                 Map.Entry<String, Path> entry = itr.next();

another for-each candidate

test/jdk/java/util/zip/ZipSourceDateEpoch.java line 71:

> 69:             zos.close();
> 70:             os.close();
> 71:         }

try-with-resource

test/jdk/java/util/zip/ZipSourceDateEpoch.java line 97:

> 95:             zis.close();
> 96:             fis.close();
> 97:         }

try-with-resource

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From jpai at openjdk.java.net  Fri Nov  5 06:40:12 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 5 Nov 2021 06:40:12 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <3j98nPAewSZPIOKWUZoA8s0WcSmn2Jo7bnvjSFp7hcQ=.9e5f2017-f750-4fa7-94a4-e6f100a3c673@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

make/jdk/src/classes/build/tools/generatezip/GenerateZip.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2021, Oracle and/or its affiliates. All rights reserved.

Hello @andrew-m-leonard, for a new file, the year should just be stated once. So just `2021,`

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From Alan.Bateman at oracle.com  Fri Nov  5 07:23:40 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 5 Nov 2021 07:23:40 +0000
Subject: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the
 same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <b274d592-3d86-327e-bb73-5c538f2e60df@oracle.com>

On 04/11/2021 21:16, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>    - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>    - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>    - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>
I think this is going to require discussion, a PR may be too premature. 
Is your goal to get the JDK build and run-time images creates with jlink 
to use the SOURCE_DATE_EPOCH? Are you looking for project builds that 
use the jar/jmod/etc. tools to use it? Or are you looking to have every 
library and application that uses the java.util.zip APIs to read it? If 
it includes the latter, and the patch in the PR suggests you are, then 
it will require analysis to work through the API spec changes.

One suggestion is to look at JDK-8231640 and PR 5372 [1]. The original 
proposal was to use SOURCE_DATE_EPOCH. After a lengthy discussion we 
converged on the system property java.properties.date rather than the 
env variable. I suspect that much of that discussion applies here.

-Alan

[1] https://github.com/openjdk/jdk/pull/5372

From lancea at openjdk.java.net  Fri Nov  5 11:30:19 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 5 Nov 2021 11:30:19 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <tMoGwiaR8Mr5LMpRGqxVHQqx_1N8JPcEozOQuNTij1U=.3e663ae1-79f0-4aa5-beb2-6311b8d71bd3@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thank you for your contribution Andrew.

Thank you for your efforts here Andrew.

A few comments in addition to what have already been mentioned by others on a very quick scan.

For new tests, please consider using TestNG.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 795:

> 793:         // Ensure files list is sorted for reproducible jar content
> 794:         Arrays.sort(files);
> 795: 

Have you had a chance to measure the performance with a large number of Zip entries with this change?

test/jdk/java/util/zip/TestZipSourceDateEpoch.sh line 1:

> 1: #!/bin/sh

Unless there is a specific reason to use a shell script, it would be better to convert this to java.  We have been trying to reduce the usage of shell scripts

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Fri Nov  5 11:34:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 11:34:13 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <TIN4tNOuqwLZ24xKmYuQ3nMQBtWoGx2WWs5bBkzOyvY=.de708972-2a52-4e8f-96c3-95a6a479772f@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

> I think this is going to require discussion, a PR may be too premature. Is your goal to get the JDK build and run-time images creates with jlink to use the SOURCE_DATE_EPOCH? Are you looking for project builds that use the jar/jmod/etc. tools to use it? Or are you looking to have every library and application that uses the java.util.zip APIs to read it? If it includes the latter, and the patch in the PR suggests you are, then it will require analysis to work through the API spec changes.
> 
> One suggestion is to look at JDK-8231640 and PR 5372 [1]. The original proposal was to use SOURCE_DATE_EPOCH. After a lengthy discussion we converged on the system property java.properties.date rather than the env variable. I suspect that much of that discussion applies here.
> 
> -Alan
> 
> [1] https://github.com/[/pull/5372](https://github.com/openjdk/jdk/pull/5372)

@AlanBateman Hi Alan, thank you for the comments. So yes, totally agree this has a way to go, I thought creating a PR would kick things off...! So just to clarify the initial objectives which you raise above. My current aim is actually purely an OpenJDK JDK image perspective, building on the work @magicus has been doing with SOURCE_DATE_EPOCH in the build, hence my natural approach to this PR. So from that perspective, it's purely a "build" change. However, the openjdk build obviously uses openjdk Jar, Jmod tooling to build itself, hence the direction I took in this PR.

Magnus's PR #5372 is useful thank you, I had not discovered that change, as you say the direction there is similar to mine, and I understand the potential pitfalls of adding doPrivileged's etc. So that resolved to a new system property java.properties.date, which makes sense.

So with that in mind, and given the objective of JDK image reproducibility, this would imply presumably an approach of a new cmd line option to Jar and Jmod tools (eg.--source-date <date>), since these tools are cmds?

One of the key changes in this PR is to ZipOutputStream where it sets the ZipEntry.xdostime if not set, to the current time. Now I am thinking given the "objective", if we fix all upstream tooling to ensure they set ZipEntry times, using "--source-date" (or whatever mechanism), then we can then avoid changing ZipOutputStream I believe. JDK tools like jar, jmod generate/update extra files like Manifests, and in fact I think the current jmod implementation writes all its content using the current time.

So something along these lines:
    jar -cf myjar.jar --source-date "<date>" * 
    jmod create --source-date "<date>" ... my.jmod
The jar, jmod,.. tooling then ensure all ZipEntry times are set to "source-date".

I chose "source-date" name based on being synonymous with SOURCE_DATE_EPOCH, implying a similar "use case".

So taking this approach for JDK tooling should achieve the reproducible JDK image objective, without a java API behavior change I am hoping.
Thoughts?

Regards
Andrew

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From ihse at openjdk.java.net  Fri Nov  5 11:39:09 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 11:39:09 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <7gOYWLbtg-mpCeFFGgqfrQs4e1QBfuXb7sz7UNkSTws=.90227519-ead9-487b-9e94-6acc15335312@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I agree with Alan's comment above. First of all, to be absolutely clear, I think this is a very worthy goal, and much overdue. I'll do my best to help get this implemented. 

But.

This PR conflates two different issues. One of them is "changing the zip implementation in the JDK". This will affect all users of the JDK, and as Alan says, this will require a thorough discussion to get it right, including a proper CSR. Otoh, the benefit of doing this will affect *all* Java projects out there in the wild wanting to do reproducible builds, so this has actually a much higher leverage for the reproducible build community as a whole. 

And, also, it is a prerequisite for issue number two, which is "use the new zip implementation in the build system". Once the former is in place, this is more or less a no-brainer. Most will come automatically, but there are some things to fix. But these require just the approval of developers in the build team; no long discussions or CSRs. (Also, when we get to this point, I believe we should get rid of the "zip" utility and write our own in Java, rather than unzipping and then re-zipping. But we can take that discussion when we get there.)

In a way, Alan is right when saying a PR is premature for issue #1. OTOH, my personal opinion is that "working code" is a good start for any discussion, as long as one is prepared to throw it all out and start over, or rewrite it over and over again, like @jaikiran did in the Property storage PR. So my suggestion is that your break out these changes to the zip and jar implementation, open a new PR, and start a discussion around them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From ihse at openjdk.java.net  Fri Nov  5 11:45:17 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 11:45:17 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <TyR1iK35Zgp0lGm8BnonFyq_ouEguLJjp1Qb7KSwBG8=.6042896b-88f1-41ba-aa28-8c86d28f97f8@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

(And we can easily make sure that we do that from the JDK build)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From ihse at openjdk.java.net  Fri Nov  5 11:45:14 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 11:45:14 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <TIN4tNOuqwLZ24xKmYuQ3nMQBtWoGx2WWs5bBkzOyvY=.de708972-2a52-4e8f-96c3-95a6a479772f@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <TIN4tNOuqwLZ24xKmYuQ3nMQBtWoGx2WWs5bBkzOyvY=.de708972-2a52-4e8f-96c3-95a6a479772f@github.com>
Message-ID: <R14AHUIliEfNg-b8Mkj0OoTw0AGsLKb234b2oHz5_j4=.0ce2a041-6a56-4e76-8fc5-cf5503160796@github.com>

On Fri, 5 Nov 2021 11:31:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
>> I think this is going to require discussion, a PR may be too premature. Is your goal to get the JDK build and run-time images creates with jlink to use the SOURCE_DATE_EPOCH? Are you looking for project builds that use the jar/jmod/etc. tools to use it? Or are you looking to have every library and application that uses the java.util.zip APIs to read it? If it includes the latter, and the patch in the PR suggests you are, then it will require analysis to work through the API spec changes.
>> 
>> One suggestion is to look at JDK-8231640 and PR 5372 [1]. The original proposal was to use SOURCE_DATE_EPOCH. After a lengthy discussion we converged on the system property java.properties.date rather than the env variable. I suspect that much of that discussion applies here.
>> 
>> -Alan
>> 
>> [1] https://github.com/[/pull/5372](https://github.com/openjdk/jdk/pull/5372)
> 
> @AlanBateman Hi Alan, thank you for the comments. So yes, totally agree this has a way to go, I thought creating a PR would kick things off...! So just to clarify the initial objectives which you raise above. My current aim is actually purely an OpenJDK JDK image perspective, building on the work @magicus has been doing with SOURCE_DATE_EPOCH in the build, hence my natural approach to this PR. So from that perspective, it's purely a "build" change. However, the openjdk build obviously uses openjdk Jar, Jmod tooling to build itself, hence the direction I took in this PR.
> 
> Magnus's PR #5372 is useful thank you, I had not discovered that change, as you say the direction there is similar to mine, and I understand the potential pitfalls of adding doPrivileged's etc. So that resolved to a new system property java.properties.date, which makes sense.
> 
> So with that in mind, and given the objective of JDK image reproducibility, this would imply presumably an approach of a new cmd line option to Jar and Jmod tools (eg.--source-date <date>), since these tools are cmds?
> 
> One of the key changes in this PR is to ZipOutputStream where it sets the ZipEntry.xdostime if not set, to the current time. Now I am thinking given the "objective", if we fix all upstream tooling to ensure they set ZipEntry times, using "--source-date" (or whatever mechanism), then we can then avoid changing ZipOutputStream I believe. JDK tools like jar, jmod generate/update extra files like Manifests, and in fact I think the current jmod implementation writes all its content using the current time.
> 
> So something along these lines:
>     jar -cf myjar.jar --source-date "<date>" * 
>     jmod create --source-date "<date>" ... my.jmod
> The jar, jmod,.. tooling then ensure all ZipEntry times are set to "source-date".
> 
> I chose "source-date" name based on being synonymous with SOURCE_DATE_EPOCH, implying a similar "use case".
> 
> So taking this approach for JDK tooling should achieve the reproducible JDK image objective, without a java API behavior change I am hoping.
> Thoughts?
> 
> Regards
> Andrew

@andrew-m-leonard Just to be clear: changing arguments to the command line utilities is still an API change and will need a CSR. 

My gut feeling is that using a system property that affect all users of ZipStream is preferable. That way a user could run like `java -Djava.properties.date=$(SOURCE_DATE_EPOCH) -Djava.zipfile.date=$(SOURCE_DATE_EPOCH) ...` (or whatever) and get reproducible behavior in all their code, for places that could otherwise be hard to fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From ihse at openjdk.java.net  Fri Nov  5 12:08:21 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 12:08:21 GMT
Subject: Integrated: 8276635: Use blessed modifier order in compiler code
In-Reply-To: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
References: <H3gH-sASB9jw0d-FgTtY7tU5EFt8yk9no-SEwQtBNgE=.e0125e24-99f0-4226-a845-9779bb513588@github.com>
Message-ID: <9ParyBs5vc_laE8mdIOiwe93eIN263psa5SHvIpz100=.fac551db-5483-4e2b-ad9f-561fb2731744@github.com>

On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: 0616d868
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0616d868c7cd5010f017b315fa1cf6cc1617ce29
Stats:     43 lines in 19 files changed: 0 ins; 0 del; 43 mod

8276635: Use blessed modifier order in compiler code

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/6253

From aleonard at openjdk.java.net  Fri Nov  5 12:13:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 12:13:10 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <tMoGwiaR8Mr5LMpRGqxVHQqx_1N8JPcEozOQuNTij1U=.3e663ae1-79f0-4aa5-beb2-6311b8d71bd3@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <tMoGwiaR8Mr5LMpRGqxVHQqx_1N8JPcEozOQuNTij1U=.3e663ae1-79f0-4aa5-beb2-6311b8d71bd3@github.com>
Message-ID: <06lpIVfltXdvWVSiRgOywDz2YZl7HCGrDSZbYgQMDRw=.12a56f57-45e4-4fad-a1f7-a2692efde752@github.com>

On Fri, 5 Nov 2021 11:16:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 795:
> 
>> 793:         // Ensure files list is sorted for reproducible jar content
>> 794:         Arrays.sort(files);
>> 795: 
> 
> Have you had a chance to measure the performance with a large number of Zip entries with this change?

No I haven't, but my thoughts on this were assuming you had a zip with many 1000s of ZipEntries the file I/O would be far more significant. Also, you will note this is not sorting the whole set, just within each directory, so the sort won't be complex, unless you had 1000s of files in a single directory. The "non-determinism" comes from the File.list() implementation which uses OS file listing, whose order is non-deterministic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From Alan.Bateman at oracle.com  Fri Nov  5 12:19:45 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 5 Nov 2021 12:19:45 +0000
Subject: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the
 same source are not reproducible
In-Reply-To: <7gOYWLbtg-mpCeFFGgqfrQs4e1QBfuXb7sz7UNkSTws=.90227519-ead9-487b-9e94-6acc15335312@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <7gOYWLbtg-mpCeFFGgqfrQs4e1QBfuXb7sz7UNkSTws=.90227519-ead9-487b-9e94-6acc15335312@github.com>
Message-ID: <5e565027-20f6-e1c0-f42b-3c16cd47cf4b@oracle.com>

On 05/11/2021 11:39, Magnus Ihse Bursie wrote:
> :
> I agree with Alan's comment above. First of all, to be absolutely clear, I think this is a very worthy goal, and much overdue. I'll do my best to help get this implemented.
>
One suggestion is to separate out the issue of ordering of entries (in 
zip/JAR and JMOD) and whether it would be the default. There may be 
trade-offs to discuss, also whether it's limited to just new zip/JAR 
files or updates to existing zip/JARs files.

-Alan

From aleonard at openjdk.java.net  Fri Nov  5 12:27:09 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 12:27:09 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <TIN4tNOuqwLZ24xKmYuQ3nMQBtWoGx2WWs5bBkzOyvY=.de708972-2a52-4e8f-96c3-95a6a479772f@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <TIN4tNOuqwLZ24xKmYuQ3nMQBtWoGx2WWs5bBkzOyvY=.de708972-2a52-4e8f-96c3-95a6a479772f@github.com>
Message-ID: <7d_9gJtgcNEfYDH_VkkDrdj-aW6wQPphDNsBObc8e4k=.422c1bc2-c9ef-492c-a45c-55995a2b1965@github.com>

On Fri, 5 Nov 2021 11:31:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
>> I think this is going to require discussion, a PR may be too premature. Is your goal to get the JDK build and run-time images creates with jlink to use the SOURCE_DATE_EPOCH? Are you looking for project builds that use the jar/jmod/etc. tools to use it? Or are you looking to have every library and application that uses the java.util.zip APIs to read it? If it includes the latter, and the patch in the PR suggests you are, then it will require analysis to work through the API spec changes.
>> 
>> One suggestion is to look at JDK-8231640 and PR 5372 [1]. The original proposal was to use SOURCE_DATE_EPOCH. After a lengthy discussion we converged on the system property java.properties.date rather than the env variable. I suspect that much of that discussion applies here.
>> 
>> -Alan
>> 
>> [1] https://github.com/[/pull/5372](https://github.com/openjdk/jdk/pull/5372)
> 
> @AlanBateman Hi Alan, thank you for the comments. So yes, totally agree this has a way to go, I thought creating a PR would kick things off...! So just to clarify the initial objectives which you raise above. My current aim is actually purely an OpenJDK JDK image perspective, building on the work @magicus has been doing with SOURCE_DATE_EPOCH in the build, hence my natural approach to this PR. So from that perspective, it's purely a "build" change. However, the openjdk build obviously uses openjdk Jar, Jmod tooling to build itself, hence the direction I took in this PR.
> 
> Magnus's PR #5372 is useful thank you, I had not discovered that change, as you say the direction there is similar to mine, and I understand the potential pitfalls of adding doPrivileged's etc. So that resolved to a new system property java.properties.date, which makes sense.
> 
> So with that in mind, and given the objective of JDK image reproducibility, this would imply presumably an approach of a new cmd line option to Jar and Jmod tools (eg.--source-date <date>), since these tools are cmds?
> 
> One of the key changes in this PR is to ZipOutputStream where it sets the ZipEntry.xdostime if not set, to the current time. Now I am thinking given the "objective", if we fix all upstream tooling to ensure they set ZipEntry times, using "--source-date" (or whatever mechanism), then we can then avoid changing ZipOutputStream I believe. JDK tools like jar, jmod generate/update extra files like Manifests, and in fact I think the current jmod implementation writes all its content using the current time.
> 
> So something along these lines:
>     jar -cf myjar.jar --source-date "<date>" * 
>     jmod create --source-date "<date>" ... my.jmod
> The jar, jmod,.. tooling then ensure all ZipEntry times are set to "source-date".
> 
> I chose "source-date" name based on being synonymous with SOURCE_DATE_EPOCH, implying a similar "use case".
> 
> So taking this approach for JDK tooling should achieve the reproducible JDK image objective, without a java API behavior change I am hoping.
> Thoughts?
> 
> Regards
> Andrew

> @andrew-m-leonard Just to be clear: changing arguments to the command line utilities is still an API change and will need a CSR.
> 
> My gut feeling is that using a system property that affect all users of ZipStream is preferable. That way a user could run like `java -Djava.properties.date=$(SOURCE_DATE_EPOCH) -Djava.zipfile.date=$(SOURCE_DATE_EPOCH) ...` (or whatever) and get reproducible behavior in all their code, for places that could otherwise be hard to fix.

Thanks @magicus 
Yes, I understand a CSR is required, I was trying to state there would not be a java.util.zip API behavior change necessarily.

Just to state again, and although I need to check this, I think if all JDK tooling ensures ZipEntry's had date set to whatever <source-date> prior to calling ZipOutputStream.putNextEntry(e), then I think no change to ZipOutputStream would be needed (I think).
However, you do elude to the benefit to "others" of changing ZipOutputStream to use (say -Djava.zipfile.date), in that it makes it easier for consumers to make reproducible builds rather than tracking down all the code that calls it in their project.

GenerateZip as you say is slightly separate, and bespoke to the openjdk build. I did start by trying to create my own "zip", but that is actually quite involved due to how openjdk build makes zip files, and how it leverages zip functionality for things like --includes & --excludes. It is far easier actually to just construct the final deterministic zip file using this class at the end. But I agree, if someone could write a determinisitic "zip", that would be great please!
I will move GenerateZip to a separate PR, and make it take "timestamp" just like CreateSymbols already does.

Thanks again
Andrew

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Fri Nov  5 12:34:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 12:34:13 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <35zICVlvWHkfc0XXtfZ40b5y0DIruMeYwHXWniMe69A=.2c674398-8d22-457b-99a1-dd7ef2f6f5b7@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on [build-dev](mailto:build-dev at mail.openjdk.java.net):_
> 
> On 05/11/2021 11:39, Magnus Ihse Bursie wrote:
> 
> > :
> > I agree with Alan's comment above. First of all, to be absolutely clear, I think this is a very worthy goal, and much overdue. I'll do my best to help get this implemented.
> 
> One suggestion is to separate out the issue of ordering of entries (in zip/JAR and JMOD) and whether it would be the default. There may be trade-offs to discuss, also whether it's limited to just new zip/JAR files or updates to existing zip/JARs files.
> 
> -Alan

Yes, makes sense, @LanceAndersen already picked up on that for file sorting. We can discuss in a separate PR.

So picking up on what @magicus suggested as well, what I shall do is split this into 3:

1) GenerateZip openjdk build tool
2) Changes to Jar and Jmod main's to ensure file ordering
3) Jar, Jmod and/or ZipOutputStream changes to support a "source-date" specification

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Fri Nov  5 12:43:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 12:43:10 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <tMoGwiaR8Mr5LMpRGqxVHQqx_1N8JPcEozOQuNTij1U=.3e663ae1-79f0-4aa5-beb2-6311b8d71bd3@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <tMoGwiaR8Mr5LMpRGqxVHQqx_1N8JPcEozOQuNTij1U=.3e663ae1-79f0-4aa5-beb2-6311b8d71bd3@github.com>
Message-ID: <XVqSpxnBs4mlPeSA-p7XBPIvx1p1cKhMhmutXvWUpZc=.0e75af2d-1058-4fa5-a6f5-f655b657d84e@github.com>

On Fri, 5 Nov 2021 11:19:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
>> It fixes the following keys issues relating to reproducibility:
>> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
>> - Jar and Jmod file content ordering was non-determinsitic
>>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
>> - openjdk image zip file generation used "zip" which is non-determinsitic
>>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/java/util/zip/TestZipSourceDateEpoch.sh line 1:
> 
>> 1: #!/bin/sh
> 
> Unless there is a specific reason to use a shell script, it would be better to convert this to java.  We have been trying to reduce the usage of shell scripts

I had copied an existing example, I obviously chose a bad example! I can re-write with ProcessBuilder... cheers

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From jpai at openjdk.java.net  Fri Nov  5 13:20:55 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 5 Nov 2021 13:20:55 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v3]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <EeZdrIsx9-E9jG-kruzwqfQsbUCTdwlVH5wneVk-zGY=.c53c1dc4-8c7d-4389-b487-65d96dd22790@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - convert test to testng
 - Merge latest from master branch
 - Merge latest from master branch
 - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/d91f02a3..57e1753f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=01-02

  Stats: 919174 lines in 2444 files changed: 477708 ins; 430777 del; 10689 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From ihse at openjdk.java.net  Fri Nov  5 13:22:13 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 13:22:13 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <AIBd8FQsYMdoA6Q0SfIM4LuG4kZhg4zUvmAlq1yVV7M=.22bab5c0-580c-485d-99a6-738a7b0cde81@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Sounds like a good plan. As for the build part ("GenerateZip"), this is not as important in the build as it used to be. Back in the days, before Jigsaw, we had a huge rt.jar that needed updating each time an incremental build was done. Hence the elaborate system for updating existing zip files. (Because recompressing the entire rt.jar was prohibitively slow.)

Now we instead have jmod/jlink which do not support incremental updates and are almost as slow as before (that's a bit underprioritized, as well...) but due to the modularization, all modules except java.base are fairly quick to link anyway.

So the old zip generation is only used for src.zip, afaik. (We might be using it in closed Oracle code as well for some side artifacts, but that is not relevant to the OpenJDK story, and to be honest, I'm not sure anymore.) This has no need to be quick to update incrementally. If it turns out to be too slow, we can move it out of the normal "jdk-image" target and add a "image-srczip" or whatever. 

So, another way of stating this is that GenerateZip has as its main goal to facilitate creation of src.zip. And most of the logic in CreateZipArchive.gmk can basically just be thrown out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Fri Nov  5 13:39:08 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 13:39:08 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <7rbFC_bx2ucbe6pkZzoMbUj8AMQqS_2PF2o9bkFFTxM=.2969e668-2ff8-4bdd-a0f1-72f18425ae0e@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thanks Magnus,
You've just reminded me of why I gave up trying to write my own zip, I
achieved it, but realized it was slow damn slow, and how efficient and
optimized the off the shelf zip is...!
Hence, why I let zip still do it's inclusion/exclusion job it does so well,
and then just re-generate at the end. Takes about 2-3 seconds longer, so
not an issue really.
cheers

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From jpai at openjdk.java.net  Fri Nov  5 13:52:49 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 5 Nov 2021 13:52:49 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v4]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - use testng asserts
 - Remove "final" usage from test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/57e1753f..2c0246f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=02-03

  Stats: 35 lines in 1 file changed: 4 ins; 12 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From vromero at openjdk.java.net  Fri Nov  5 15:30:17 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 5 Nov 2021 15:30:17 GMT
Subject: RFR: 8273039: JShell crashes when naming variable or method
 "abstract" or "strictfp"
In-Reply-To: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
References: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
Message-ID: <szvH0xhMB7pncFGK2BB_66kwGca1vQ0fdMYYIe7sFH0=.e8dd0b4a-1dae-4bfc-812d-04f9ae96d45d@github.com>

On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:
> 
> package REPL;
> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
> class $JShell$DOESNOTMATTER {
>     public static Object do_it$() throws Throwable {
>         return int strictfp = 0;
>     }
> }
> 
> 
> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.
> 
> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101:

> 5099: 
> 5100:     @Override
> 5101:     public void visitModifiers(JCModifiers tree) {

question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though

-------------

PR: https://git.openjdk.java.net/jdk/pull/5897

From vromero at openjdk.java.net  Fri Nov  5 15:35:13 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 5 Nov 2021 15:35:13 GMT
Subject: RFR: 8275097: Wrong span of the 'default' tag
In-Reply-To: <Wn6RfUb9CMgvAJ07s_d555DJ8z-XqGBTGq5cOwBXXf4=.5b190033-0532-4fed-af0d-a7c00b3cf759@github.com>
References: <Wn6RfUb9CMgvAJ07s_d555DJ8z-XqGBTGq5cOwBXXf4=.5b190033-0532-4fed-af0d-a7c00b3cf759@github.com>
Message-ID: <vk_krpg4CTf5TwWbIG1wwMCEzhpjCbjWsWCXWiIigX4=.8f08e8f8-371e-4929-b6c0-d068bd603345@github.com>

On Tue, 12 Oct 2021 07:56:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The span of the 'default' case label AST node is wrong when `default:` is encountered. This patch fixes the positions to be reasonable (i.e. the span of the AST node should be the characters 'default').

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5905

From jlahoda at openjdk.java.net  Fri Nov  5 18:30:33 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 5 Nov 2021 18:30:33 GMT
Subject: RFR: 8273039: JShell crashes when naming variable or method
 "abstract" or "strictfp"
In-Reply-To: <szvH0xhMB7pncFGK2BB_66kwGca1vQ0fdMYYIe7sFH0=.e8dd0b4a-1dae-4bfc-812d-04f9ae96d45d@github.com>
References: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
 <szvH0xhMB7pncFGK2BB_66kwGca1vQ0fdMYYIe7sFH0=.e8dd0b4a-1dae-4bfc-812d-04f9ae96d45d@github.com>
Message-ID: <M4kOC7bT3bmXT28wnpnvvWDvQr7uaRxBK4fOhaLZKK4=.d4881109-b2ad-4750-b31d-380c36475e5a@github.com>

On Fri, 5 Nov 2021 15:27:32 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:
>> 
>> package REPL;
>> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
>> class $JShell$DOESNOTMATTER {
>>     public static Object do_it$() throws Throwable {
>>         return int strictfp = 0;
>>     }
>> }
>> 
>> 
>> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.
>> 
>> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101:
> 
>> 5099: 
>> 5100:     @Override
>> 5101:     public void visitModifiers(JCModifiers tree) {
> 
> question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though

Parser will report the error, and will wrap the (presumed) modifiers into an erroneous tree, so the AST is reasonable. But JShell runs javac with `--should-stop=at=FLOW`, so the error in parser will not stop the processing, and when `Attr` will look into the erroneous tree, it will fail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5897

From vromero at openjdk.java.net  Fri Nov  5 18:46:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 5 Nov 2021 18:46:38 GMT
Subject: RFR: 8273039: JShell crashes when naming variable or method
 "abstract" or "strictfp"
In-Reply-To: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
References: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
Message-ID: <3y9A3pWIrfBR6UA9oNepWCfLG2KzNn9fDbp3obxoAMY=.000409f3-035a-4760-b727-4c92ce01d4a5@github.com>

On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:
> 
> package REPL;
> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
> class $JShell$DOESNOTMATTER {
>     public static Object do_it$() throws Throwable {
>         return int strictfp = 0;
>     }
> }
> 
> 
> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.
> 
> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5897

From vromero at openjdk.java.net  Fri Nov  5 18:46:39 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 5 Nov 2021 18:46:39 GMT
Subject: RFR: 8273039: JShell crashes when naming variable or method
 "abstract" or "strictfp"
In-Reply-To: <M4kOC7bT3bmXT28wnpnvvWDvQr7uaRxBK4fOhaLZKK4=.d4881109-b2ad-4750-b31d-380c36475e5a@github.com>
References: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
 <szvH0xhMB7pncFGK2BB_66kwGca1vQ0fdMYYIe7sFH0=.e8dd0b4a-1dae-4bfc-812d-04f9ae96d45d@github.com>
 <M4kOC7bT3bmXT28wnpnvvWDvQr7uaRxBK4fOhaLZKK4=.d4881109-b2ad-4750-b31d-380c36475e5a@github.com>
Message-ID: <V3Av23WYVhZCLJlSWpX564NAiw2J67MInIIP5C5GTd8=.bb96274d-0070-4e4c-9c3e-6006d91327b7@github.com>

On Fri, 5 Nov 2021 18:27:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101:
>> 
>>> 5099: 
>>> 5100:     @Override
>>> 5101:     public void visitModifiers(JCModifiers tree) {
>> 
>> question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though
>
> Parser will report the error, and will wrap the (presumed) modifiers into an erroneous tree, so the AST is reasonable. But JShell runs javac with `--should-stop=at=FLOW`, so the error in parser will not stop the processing, and when `Attr` will look into the erroneous tree, it will fail.

I see, thanks for the clarification

-------------

PR: https://git.openjdk.java.net/jdk/pull/5897

From aleonard at openjdk.java.net  Fri Nov  5 19:15:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 19:15:43 GMT
Subject: RFR: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <t2k1KkQf48OASCSazSMJfWe70VOAd9yagv5p4W8w-vg=.1ecc3fd1-ceae-4e13-a902-795af700cc40@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@AlanBateman @magicus thank you both for your guidance. I have now split this bug into the 3 mentioned:
- GenerateZip: https://bugs.openjdk.java.net/browse/JDK-8276743
- Jar/Jmod content ordering: https://bugs.openjdk.java.net/browse/JDK-8276764
- Jar/Jmod/ZipOutputStream timestamp option: https://bugs.openjdk.java.net/browse/JDK-8276766 **(requires CSR)**

Closing this PR to be replaced with 3 new PRs for the above bugs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From aleonard at openjdk.java.net  Fri Nov  5 19:15:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 5 Nov 2021 19:15:43 GMT
Subject: Withdrawn: 8276400: openjdk image Jars,
 Zips and Jmods built from the same source are not reproducible
In-Reply-To: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
Message-ID: <nuj67SjvmK5uDaaMzz0mOVDarZSF9HfpppbZ-dpZ-rs=.6c34da63-e86e-42b2-8822-f4c733a30763@github.com>

On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> This PR enables reproducible Jars, Jmods and openjdk image zip files (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying ZipOutputStream's.
> It fixes the following keys issues relating to reproducibility:
> - Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
>   - Jar and ZipOutputStream now detect SOURCE_DATE_EPOCH environment setting
> - Jar and Jmod file content ordering was non-determinsitic
>   - Fixes to Jar and Jmod main's to ensure sorted classes content ordering
> - openjdk image zip file generation used "zip" which is non-determinsitic
>   - New openjdk build tool "GenerateZip" which produces the final determinsitic zip files as part of the build and also detects SOURCE_DATE_EPOCH
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6268

From darcy at openjdk.java.net  Fri Nov  5 23:57:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 5 Nov 2021 23:57:58 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs
Message-ID: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>

Pass over javax.lang.model docs for some minor cleanups and improvements.

Before pushing, I'll do any needed copyright updates and reflow paragraphs.

-------------

Commit messages:
 - JDK-8276772: Refine javax.lang.model docs

Changes: https://git.openjdk.java.net/jdk/pull/6286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6286&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276772
  Stats: 18 lines in 10 files changed: 12 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6286/head:pull/6286

PR: https://git.openjdk.java.net/jdk/pull/6286

From iris at openjdk.java.net  Sat Nov  6 03:23:36 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 6 Nov 2021 03:23:36 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <3v40NaIT0h43djOHmvs31UGHUh-BEpQ-TnVLJ6OEIT0=.e01ff51c-5898-4fef-bc9a-0fad381f05be@github.com>

On Fri, 5 Nov 2021 23:49:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From duke at openjdk.java.net  Sun Nov  7 03:26:37 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 7 Nov 2021 03:26:37 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <ISIl-2mxLYNYn3kLmbEOU59TQbmBPj4SXwa_2lEFOkg=.22f4d4a6-9633-4fcc-a18c-854656e32dea@github.com>

On Fri, 5 Nov 2021 23:49:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java line 65:

> 63:      * will by definition have an empty map.
> 64:      *
> 65:      * <p>To fill in default values, use {@link

Is this paragraph supposed to be part of the api notes as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From jlahoda at openjdk.java.net  Mon Nov  8 13:24:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 8 Nov 2021 13:24:43 GMT
Subject: Integrated: 8275097: Wrong span of the 'default' tag
In-Reply-To: <Wn6RfUb9CMgvAJ07s_d555DJ8z-XqGBTGq5cOwBXXf4=.5b190033-0532-4fed-af0d-a7c00b3cf759@github.com>
References: <Wn6RfUb9CMgvAJ07s_d555DJ8z-XqGBTGq5cOwBXXf4=.5b190033-0532-4fed-af0d-a7c00b3cf759@github.com>
Message-ID: <gUcoSmumV2c1qFsHdHlHtg0KjAuGb98S_qEPvvPsGmg=.e24cc609-7440-4708-8647-fede2c72bd02@github.com>

On Tue, 12 Oct 2021 07:56:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The span of the 'default' case label AST node is wrong when `default:` is encountered. This patch fixes the positions to be reasonable (i.e. the span of the AST node should be the characters 'default').

This pull request has now been integrated.

Changeset: 0c2d00bf
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c2d00bff7b96cca53820aadfdaf09c840a2a33a
Stats:     96 lines in 3 files changed: 89 ins; 3 del; 4 mod

8275097: Wrong span of the 'default' tag

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/5905

From Alan.Bateman at oracle.com  Mon Nov  8 13:51:08 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 8 Nov 2021 13:51:08 +0000
Subject: RFR: 8276400: openjdk image Jars, Zips and Jmods built from the
 same source are not reproducible
In-Reply-To: <t2k1KkQf48OASCSazSMJfWe70VOAd9yagv5p4W8w-vg=.1ecc3fd1-ceae-4e13-a902-795af700cc40@github.com>
References: <5UDNFhfUqwOsOgcV2wEBWHZKU84d5w6Cc5JZQ-XEITk=.e4431826-178a-4c33-8cf4-b5a6e83016e5@github.com>
 <t2k1KkQf48OASCSazSMJfWe70VOAd9yagv5p4W8w-vg=.1ecc3fd1-ceae-4e13-a902-795af700cc40@github.com>
Message-ID: <2ffd51f1-c0a4-6bf2-e191-2681292837b0@oracle.com>



On 05/11/2021 19:15, Andrew Leonard wrote:
> :
> @AlanBateman @magicus thank you both for your guidance. I have now split this bug into the 3 mentioned:
> - GenerateZip: https://bugs.openjdk.java.net/browse/JDK-8276743
> - Jar/Jmod content ordering: https://bugs.openjdk.java.net/browse/JDK-8276764
> - Jar/Jmod/ZipOutputStream timestamp option: https://bugs.openjdk.java.net/browse/JDK-8276766 **(requires CSR)**
>
> Closing this PR to be replaced with 3 new PRs for the above bugs.
>
Thanks this seems a reasonable plan. When you get the 3rd item then 
we'll need to discuss whether ZipOutputStream.putEntry overrides (or 
not) the time stamps of entries that have a modification time.

-Alan

From darcy at openjdk.java.net  Mon Nov  8 16:42:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Nov 2021 16:42:40 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs
In-Reply-To: <ISIl-2mxLYNYn3kLmbEOU59TQbmBPj4SXwa_2lEFOkg=.22f4d4a6-9633-4fcc-a18c-854656e32dea@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
 <ISIl-2mxLYNYn3kLmbEOU59TQbmBPj4SXwa_2lEFOkg=.22f4d4a6-9633-4fcc-a18c-854656e32dea@github.com>
Message-ID: <zf9LTzMiP6Lw9GLtAEildnguE-Epm8255AlhBzEiYCg=.1a0cd747-47a8-4e53-8a16-bfa03bc2225c@github.com>

On Sun, 7 Nov 2021 03:23:45 GMT, liach <duke at openjdk.java.net> wrote:

>> Pass over javax.lang.model docs for some minor cleanups and improvements.
>> 
>> Before pushing, I'll do any needed copyright updates and reflow paragraphs.
>
> src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java line 65:
> 
>> 63:      * will by definition have an empty map.
>> 64:      *
>> 65:      * <p>To fill in default values, use {@link
> 
> Is this paragraph supposed to be part of the api notes as well?

Yes; those are both intended to be part of the apiNote and both render as such.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From vromero at openjdk.java.net  Mon Nov  8 17:11:38 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 8 Nov 2021 17:11:38 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <-s2RXdDwOiMuIDlOYfoi5u2ubhL3UQWow87C_Ze9gYM=.83b5cb15-76e4-4d10-ba34-43b585573dbf@github.com>

On Fri, 5 Nov 2021 23:49:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 67:

> 65:      *  15: text blocks (records and pattern matching in preview again)
> 66:      *  16: records and pattern matching
> 67:      *  17: sealed classes, floating-point always strict

shouldn't it be mentioned that sealed classes are in preview in 17?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From itakiguchi at openjdk.java.net  Mon Nov  8 17:12:34 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 8 Nov 2021 17:12:34 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v3]
In-Reply-To: <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <mRlzrdNCfPrbdnOn0Rau3nPH88g4XPMNvXXD7LiX5XY=.6bd16408-a84a-4bfa-a635-505769270d59@github.com>
 <4rJtaiFtRYh-V2G3x2iCtQBtbD-lDGvqu5iVUQ_a-bA=.becf558e-ea95-4054-9f7d-3d5fe34c31c8@github.com>
Message-ID: <H9on_jHnBVjvsd8i_x8HmH0y9jtMv3vX5aVxWkSll84=.5710f743-2dc2-4ea5-bc53-9b877fbe1b86@github.com>

On Tue, 19 Oct 2021 01:26:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Ichiroh Takiguchi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> This is pretty ugly code to be replicating so many times.
> 
> What if the tools have been run in an environment where `System.out` and `System.err` have already been redirected in some manner, with `System.setOut` or `System.setErr`?  You should not assume that `System.out` and `System.err` will always refer to the console.

Hello @jonathan-gibbons .
I tested -Xstdout option for javac command on Linux and Windows platform.
Output file encoding was UTF-8.
I assume it's expected result.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From darcy at openjdk.java.net  Mon Nov  8 19:45:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Nov 2021 19:45:18 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs [v2]
In-Reply-To: <-s2RXdDwOiMuIDlOYfoi5u2ubhL3UQWow87C_Ze9gYM=.83b5cb15-76e4-4d10-ba34-43b585573dbf@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
 <-s2RXdDwOiMuIDlOYfoi5u2ubhL3UQWow87C_Ze9gYM=.83b5cb15-76e4-4d10-ba34-43b585573dbf@github.com>
Message-ID: <aA_p8lqWq-Cf9jqPEawIKENvCJRIOoT_e5S5mj0WrNw=.12060749-981d-4d1e-b39a-652d1a86698a@github.com>

On Mon, 8 Nov 2021 17:05:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Update history of preview feature.
>>  - Merge branch 'master' into JDK-8276772
>>  - Merge branch 'master' into JDK-8276772
>>  - JDK-8276772: Refine javax.lang.model docs
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 67:
> 
>> 65:      *  15: text blocks (records and pattern matching in preview again)
>> 66:      *  16: records and pattern matching
>> 67:      *  17: sealed classes, floating-point always strict
> 
> shouldn't it be mentioned that sealed classes are in preview in 17?

Pushed updated history of preview features.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From darcy at openjdk.java.net  Mon Nov  8 19:45:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Nov 2021 19:45:14 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs [v2]
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <n_35NbG44WCtst2QVgc79m3Zp3n2Sf_iSk7VoKP06J0=.d071b09c-6fab-4a48-8a7a-de2aab4350f8@github.com>

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Update history of preview feature.
 - Merge branch 'master' into JDK-8276772
 - Merge branch 'master' into JDK-8276772
 - JDK-8276772: Refine javax.lang.model docs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6286/files
  - new: https://git.openjdk.java.net/jdk/pull/6286/files/d455dce0..57b3982c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6286&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6286&range=00-01

  Stats: 586 lines in 23 files changed: 490 ins; 23 del; 73 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6286/head:pull/6286

PR: https://git.openjdk.java.net/jdk/pull/6286

From vromero at openjdk.java.net  Mon Nov  8 21:16:36 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 8 Nov 2021 21:16:36 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs [v2]
In-Reply-To: <n_35NbG44WCtst2QVgc79m3Zp3n2Sf_iSk7VoKP06J0=.d071b09c-6fab-4a48-8a7a-de2aab4350f8@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
 <n_35NbG44WCtst2QVgc79m3Zp3n2Sf_iSk7VoKP06J0=.d071b09c-6fab-4a48-8a7a-de2aab4350f8@github.com>
Message-ID: <PVhpNQttOdHf8NxoZXCk_VXRDgi8H1zld_NIk_my7sY=.73ee917f-3417-4be5-8c2f-44ce5d250161@github.com>

On Mon, 8 Nov 2021 19:45:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Pass over javax.lang.model docs for some minor cleanups and improvements.
>> 
>> Before pushing, I'll do any needed copyright updates and reflow paragraphs.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update history of preview feature.
>  - Merge branch 'master' into JDK-8276772
>  - Merge branch 'master' into JDK-8276772
>  - JDK-8276772: Refine javax.lang.model docs

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6286

From vromero at openjdk.java.net  Mon Nov  8 21:16:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 8 Nov 2021 21:16:37 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs [v2]
In-Reply-To: <aA_p8lqWq-Cf9jqPEawIKENvCJRIOoT_e5S5mj0WrNw=.12060749-981d-4d1e-b39a-652d1a86698a@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
 <-s2RXdDwOiMuIDlOYfoi5u2ubhL3UQWow87C_Ze9gYM=.83b5cb15-76e4-4d10-ba34-43b585573dbf@github.com>
 <aA_p8lqWq-Cf9jqPEawIKENvCJRIOoT_e5S5mj0WrNw=.12060749-981d-4d1e-b39a-652d1a86698a@github.com>
Message-ID: <lcApeZlTRzT8t8S7xBVeJQAOeNk1boIyAukvodp_WBg=.d17329dd-6318-41a0-838a-ce20fabb83f8@github.com>

On Mon, 8 Nov 2021 19:41:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 67:
>> 
>>> 65:      *  15: text blocks (records and pattern matching in preview again)
>>> 66:      *  16: records and pattern matching
>>> 67:      *  17: sealed classes, floating-point always strict
>> 
>> shouldn't it be mentioned that sealed classes are in preview in 17?
>
> Pushed updated history of preview features.

sorry my mistake

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From darcy at openjdk.java.net  Mon Nov  8 22:24:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Nov 2021 22:24:00 GMT
Subject: RFR: JDK-8276772: Refine javax.lang.model docs [v3]
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <ikoj5mJd-nT_vRl-hF7BBmljtUXfn1yhKnUtCcMJbx4=.e3084bf1-6391-494e-b8a2-a962608bd22c@github.com>

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Final cleanups, update copyright, etc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6286/files
  - new: https://git.openjdk.java.net/jdk/pull/6286/files/57b3982c..757353c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6286&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6286&range=01-02

  Stats: 13 lines in 8 files changed: 2 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6286.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6286/head:pull/6286

PR: https://git.openjdk.java.net/jdk/pull/6286

From darcy at openjdk.java.net  Mon Nov  8 22:24:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Nov 2021 22:24:00 GMT
Subject: Integrated: JDK-8276772: Refine javax.lang.model docs
In-Reply-To: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
References: <-BaexzRWRLtfitz2uPoyJVA5dTSjym4BEDY--SDj0_4=.4e05ac2e-9cd3-4a53-af38-5811bdf32216@github.com>
Message-ID: <DbDIN6us0hPq5E-hF6IkmbH4mI0zyj79-jC462lxD0I=.c43e3ff3-9bdc-4801-bab9-9cc2a896b98c@github.com>

On Fri, 5 Nov 2021 23:49:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Pass over javax.lang.model docs for some minor cleanups and improvements.
> 
> Before pushing, I'll do any needed copyright updates and reflow paragraphs.

This pull request has now been integrated.

Changeset: a7dedb5f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7dedb5f4761a7d0bc4db658d96d369b13b80620
Stats:     33 lines in 10 files changed: 17 ins; 0 del; 16 mod

8276772: Refine javax.lang.model docs

Reviewed-by: iris, vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/6286

From jjg at openjdk.java.net  Wed Nov 10 19:19:36 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 19:19:36 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

I strongly dislike this proposed changeset. In my opinion, the original change that has provoked the changes here is a bad/incompatible change, and should maybe be reconsidered. The fact that a change in the Java runtime has triggered the need for so many changes in application-style code is some sort of "canary in the coalmine".

Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

cc: @jddarcy with his CSR hat on, for the compatibility issues relating to the issue that caused the problems being addressed here.

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 19:44:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 19:44:42 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Informally, I suggest one of the following:

1.  `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.

2. or, add new overloads for  `PrintStream(PrintStream)` and `PrintStream(PrintStream, boolean)`  that are defined to use the character encoding from the `PrintStream` arg.


I note that `PrintStream` does not expose a "getter" for the encoding. That seems like a bug in itself, but even without fixing that, `PrintWriter` ought to be able to access the encoding "behind the scenes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From alanb at openjdk.java.net  Wed Nov 10 19:49:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 10 Nov 2021 19:49:45 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
Message-ID: <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>

On Wed, 10 Nov 2021 19:16:58 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Generally, the issue is related to the fact that we wrap a PrintStream in a PrintWriter ... and, if I understand correctly, the writer ends up with the wrong character encoding. Is it possible to change PrintWriter and/or PrintStream so that the correct underlying encoding used by the PrintStream is also used by the PrintWriter. That way, all existing uses where a PrintWriter wraps a PrintStream would continue to work without any modification.

JEP 400 has moved the JDK to using UTF-8 as the default charset, a long overdue change. So if you create a PrintStream or a PrintWriter without specifying the charset then it will default to UTF-8. The issue that I think we have with javac and a few other tools is that they are creating PrintWriters on PrintStreams where the underlying streams are stdout/stderr and so using the native encoding.  There was exploration into special casing this scenario during JEP 400 that was rejected because it complicates the spec and may not be feasible in cases where there are many layers in the onion. If there is resistance to fixing the tools then we might have to re-visit this. Naoto may have more to say on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From alanb at openjdk.java.net  Wed Nov 10 20:03:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 10 Nov 2021 20:03:38 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
Message-ID: <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>

On Wed, 10 Nov 2021 19:41:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.

I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From naoto at openjdk.java.net  Wed Nov 10 21:22:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Nov 2021 21:22:35 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 21:47:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 21:47:34 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <aoX5zvc_qr_UfKbdxRMivYoZvo7zHF-CmtpwvZDzVRc=.8c6b58ab-b4e4-4f29-8cd6-a784a61c9bc8@github.com>
 <yj5tQPFV9FTLJ1Muetf7awjcvN1Pey9UTFUsuwIPRl8=.35081123-9cf7-4290-9919-b8dc84725410@github.com>
Message-ID: <ElJGwUEHP-L5sxPuUE7GP89NICEi0cOQBtOMUO1V-Aw=.def3aad5-bedd-43de-b01b-6629e139946a@github.com>

On Wed, 10 Nov 2021 20:00:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > 1. `PrintStream(OutputStream)` and `PrintStream(OutputStream, boolean)`  should be redefined so that they internally check if the stream arg is a PrintStream, in which case they use the encoding from the `PrinStream` instead of the default.
> 
> I think you mean the PrintWriter constructors here. Yes, there is merit in that. PrintStream is a bit unusual in that it's an OutputStream but it has a charset because it prints text output.

Yes, sorry for the confusion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From jjg at openjdk.java.net  Wed Nov 10 21:55:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 10 Nov 2021 21:55:42 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <tr8S7mKC4ZKYhFEpybhnFGweOi0Z6wvspBs3W--udZA=.5f12aac8-255d-4c01-bc98-6cd165d4d201@github.com>
 <P0j7oEBawdHQfuKSBVkH_RDBz63_7KuVrKSEd0nqloY=.a674c502-2cbb-4287-9b15-60aae71e8bb6@github.com>
Message-ID: <8ugE0AF10_pPZDg1PoaezIIz1m-VG12m24NqmPcQHOA=.a437b180-fa0b-43f3-9c32-84179893a4dd@github.com>

On Wed, 10 Nov 2021 19:46:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  If there is resistance to fixing the tools then we might have to re-visit this.

It's not just the JDK tools that are an issue. I think that wrapping some PrintStream into a PrintWriter is a common enough idiom that it is not reasonable to fix all occurrences -- i.e. including those outside of JDK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From gli at openjdk.java.net  Thu Nov 11 13:54:05 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Thu, 11 Nov 2021 13:54:05 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
Message-ID: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>

Hi all,

The method `Gen#visitSwitchExpression` would switch code generation off by using the method `Code#markDead` when it meets the code like `throw new RuntimeException()`. Then the method `Gen#completeBinop` won't generate the expected code and wiil let the left operand stay in the stack without handling it.

This patch pops the left operand from the stack to solve this issue. And the corresponding test is added.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

-------------

Commit messages:
 - Error in javac caused by switch expression without result expressions: Internal error: stack sim error

Changes: https://git.openjdk.java.net/jdk/pull/6350/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6350&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276836
  Stats: 59 lines in 2 files changed: 59 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6350.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6350/head:pull/6350

PR: https://git.openjdk.java.net/jdk/pull/6350

From cushon at google.com  Fri Nov 12 18:32:07 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 12 Nov 2021 10:32:07 -0800
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes that
 don't use it
Message-ID: <CAL4Qsgsh_r5Asa8cW1vJcnHt_isxRmt+Z-j=zXrQ15hM2ErDNg@mail.gmail.com>

Hello,

Is anyone from the compiler group interested in reviewing the fix for
JDK-8271623?

There was some previous discussion about the change on amber-spec-experts
[1][2], I should have added compiler-dev@ sooner.

The idea is to omit the synthetic field that holds a reference to the
enclosing instance of an inner class if the inner class doesn't capture any
state from its enclosing instance. This avoids a potential memory leak, and
reduces the footprint of the inner class.

The optimization is currently implemented by adding logic to Lower to track
whether the symbol for the enclosing instance field is actually used when
generating code for the inner class, and generating the declaration and
initialization of the field only if it is used.

[1]
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-July/003061.html
[2]
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-August/003064.html

review: https://git.openjdk.java.net/jdk/pull/4966
bug: https://bugs.openjdk.java.net/browse/JDK-8271623
CSR: https://bugs.openjdk.java.net/browse/JDK-8271717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211112/5af216b4/attachment.htm>

From fweimer at openjdk.java.net  Fri Nov 12 20:06:40 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Fri, 12 Nov 2021 20:06:40 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v3]
In-Reply-To: <MEiz58NV_v6AlY4AlkJkKcpauxb1typSr4HKUo4z964=.f5b43677-6cff-40f4-a0bc-2ea7ab78eedc@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <MEiz58NV_v6AlY4AlkJkKcpauxb1typSr4HKUo4z964=.f5b43677-6cff-40f4-a0bc-2ea7ab78eedc@github.com>
Message-ID: <goMI8AMbiPcMpoISGcXMd5HWmA3AT9EU259bnE_ErBQ=.74f360a9-baf8-499b-83f8-b64754931dd3@github.com>

On Mon, 11 Oct 2021 20:11:30 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

Is it desirable to do this change for `Serializable` inner classes? If they do not define `serialVersionUID`, it won't be possible to deserialize existing data.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From itakiguchi at openjdk.java.net  Sun Nov 14 16:48:39 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 14 Nov 2021 16:48:39 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
Message-ID: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>

On Wed, 10 Nov 2021 21:19:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>>  - Langtools command's usage were grabled on Japanese Windows
>
> Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970

Hello @naotoj .
For PrintStream.getCharset(), following changes may be required.

+++ src/java.base/share/classes/java/io/OutputStreamWriter.java
+    Charset getCharset() {
+        return se.getCharset();
+    }

+++ src/java.base/share/classes/java/io/PrintStream.java
+    public Charset getCharset() {
+        return charOut.getCharset();
+    }

+++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
+    public Charset getCharset() {
+        return cs;
+    }

For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
We need to use reflection, like:

+++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
+    private static Charset getCharset(PrintStream ps) {
+        try {
+            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
+            return (Charset)getCharset.invoke(ps);
+        } catch (Exception e) {
+            return Charset.defaultCharset();
+        }
+    }

If we add following constructors against PrintWriter, we just change javap and jshell code.
But I cannot evaluate this code changes.

+++ src/java.base/share/classes/java/io/PrintWriter.java
+    public PrintWriter(PrintStream ps) {
+       this((OutputStream)ps, false, ps.getCharset());
+    }
+    public PrintWriter(PrintStream ps, boolean autoFlush) {
+       this((OutputStream)ps, autoFlush, ps.getCharset());
+    }

I really appreciate if you handle this kind of code change via JEP-400.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From duke at openjdk.java.net  Mon Nov 15 18:17:49 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Nov 2021 18:17:49 GMT
Subject: RFR: 8275242: Remove redundant stream() call before forEach in
 jdk.compiler [v2]
In-Reply-To: <TjQ3v84brXmOJmvQG9_0YEB5_ZiBGcakUlb5rq8EiF4=.5eef8583-2578-4e35-8ce9-fd001d4a4b08@github.com>
References: <oMhwkqQwoQLxnhy-Nfozx7IKGdTzQuxTUrHsk9MrEpM=.a119db21-1efb-42a2-97f2-1bd26d7c44aa@github.com>
 <TjQ3v84brXmOJmvQG9_0YEB5_ZiBGcakUlb5rq8EiF4=.5eef8583-2578-4e35-8ce9-fd001d4a4b08@github.com>
Message-ID: <FgMtCDCufTRDDeDQoV23kjQVxuWeAvuakHiF1ty1q30=.19927fd8-080b-4848-a6e7-3884b5441d92@github.com>

On Mon, 18 Oct 2021 08:45:12 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

>> There are several places in the jdk.compiler that use stream().forEach(...), these can be cleaned up.
>> Instead Collection.forEach or Map.forEach can be used directly.
>> This is continuation of
>> 1. [JDK-8273710](https://bugs.openjdk.java.net/browse/JDK-8273710) Remove redundant stream() call before forEach in jdk.jdeps
>> 2. [JDK-8273711](https://bugs.openjdk.java.net/browse/JDK-8273711) Remove redundant stream() call before forEach in jdk.jlink
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8275242: Remove redundant stream() call before forEach in jdk.compiler
>   expand start import

keep open

-------------

PR: https://git.openjdk.java.net/jdk/pull/5521

From duke at openjdk.java.net  Mon Nov 15 18:18:45 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Nov 2021 18:18:45 GMT
Subject: RFR: 8274161: Cleanup redundant casts in jdk.compiler
In-Reply-To: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
References: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
Message-ID: <yMbQDw5kKZwtBVTqfqcnODlGtGorKmOd8Xmfiq5dY8c=.bdbf37f8-ff9d-4997-b376-7fc1dae06fc2@github.com>

On Fri, 27 Aug 2021 18:30:31 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

keep open

-------------

PR: https://git.openjdk.java.net/jdk/pull/5283

From aleonard at openjdk.java.net  Mon Nov 15 18:56:51 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 15 Nov 2021 18:56:51 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar and
 Jmod
Message-ID: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>

Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Commit messages:
 - 8276764: Enable deterministic file content ordering for Jar and Jmod

Changes: https://git.openjdk.java.net/jdk/pull/6395/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276764
  Stats: 209 lines in 4 files changed: 199 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From jjg at openjdk.java.net  Mon Nov 15 20:00:44 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 15 Nov 2021 20:00:44 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <mTywmbEWG4IgwxClYs8_pT_vZkse_Ey46SYv8ed3yoc=.7970b43c-fb38-4013-a388-05b440cc08e7@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

Generally, I think it would be a good goal for JEP-400 to not require any source-code changes to any use-sites, at least for this common idiom of wrapping a `PrintStream` in a `PrintWriter`.  While we may have the ability to change JDK use-sites, we do not have the ability to change any usages outside of JDK, and we should try not to break those usages in the way that the JDK tools have been broken.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From cushon at openjdk.java.net  Mon Nov 15 20:18:06 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 15 Nov 2021 20:18:06 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
 - Enable enclosing instance optimization for --release 18 and newer
 - Add a test case with nested inner classes
 - 8271623: Omit enclosing instance fields from inner classes that don't use it

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4966/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=03
  Stats: 464 lines in 16 files changed: 425 ins; 12 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 15 20:18:07 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 15 Nov 2021 20:18:07 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v3]
In-Reply-To: <goMI8AMbiPcMpoISGcXMd5HWmA3AT9EU259bnE_ErBQ=.74f360a9-baf8-499b-83f8-b64754931dd3@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <MEiz58NV_v6AlY4AlkJkKcpauxb1typSr4HKUo4z964=.f5b43677-6cff-40f4-a0bc-2ea7ab78eedc@github.com>
 <goMI8AMbiPcMpoISGcXMd5HWmA3AT9EU259bnE_ErBQ=.74f360a9-baf8-499b-83f8-b64754931dd3@github.com>
Message-ID: <SP_v_QBXO-bDDKJnGkGUTwmuE6PiHL699P6Bro6phfk=.5927527b-78e2-4951-92e0-b50f6012c870@github.com>

On Fri, 12 Nov 2021 20:03:32 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Is it desirable to do this change for `Serializable` inner classes? If they do not define `serialVersionUID`, it won't be possible to deserialize existing data.

@fweimer-rh thanks, I added logic to disable the optimization for `Serializable` inner classes which do not define `serialVersionUID`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 15 20:48:38 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 15 Nov 2021 20:48:38 GMT
Subject: RFR: JDK-8273914: Indy string concat changes order of operations
 [v5]
In-Reply-To: <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
References: <iM42rUgZ1oVRCQTQ5-HcSSSxq8WPmNzMwLEivYMOjys=.9e5a2ed6-4877-4bb0-a250-75f4ae373c49@github.com>
 <mPchjrPQ83plRRl3Jbg_aG9WM3eAJiGCxun3P_B5IpU=.32a2242e-703a-45b3-90c4-8ee517719b15@github.com>
Message-ID: <Tmo9Nd-O9K1yeP7NuiQbwG6tPWuF4CYgxe9B8ErUdPc=.882c3a2c-26e7-4ebe-ba1f-f9c03010f71f@github.com>

On Thu, 14 Oct 2021 17:14:42 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change makes string concatenation call `toString` on the arguments eagerly, to preserve the correct evaluation order of the arguments and the calls to `toString`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename WellKnownTypes to WellKnownTypeSignatures
>   
>   and add more functional test coverage for string concat of well-known
>   types, covering all strategies.

> This pull request has been inactive for more than 4 weeks

The [CSR is still in progress](https://bugs.openjdk.java.net/browse/JDK-8274863?focusedCommentId=14458216&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14458216)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5844

From naoto at openjdk.java.net  Mon Nov 15 21:18:34 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 15 Nov 2021 21:18:34 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
Message-ID: <MSRlG2axHrLwJyzGDVFhYzuoenyO1WLsYpyJ9QhaaVw=.cc8352ba-9a4d-4b2d-ac19-8959c2061e1a@github.com>

On Mon, 1 Nov 2021 16:10:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
>> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
>> These commands use PrintWriter instead of standard out/err with PrintStream.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - 8274544: Langtools command's usage were garbled on Japanese Windows
>  - Langtools command's usage were grabled on Japanese Windows

The gist of the issue is that `PrintWriter` (w/o explicit charset) uses the default charset, ignoring `PrintStream`'s charset. So  it basically is irrelevant of JEP400, but apparently, JEP400 made it visible as it keeps the System.out/err encoding in `native.encoding` while changing the default to `UTF-8`.
I am now in the process of creating a PR for the issue JDK-8276970, and will submit it shortly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From darcy at openjdk.java.net  Tue Nov 16 08:00:30 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 16 Nov 2021 08:00:30 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v9]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <ewQ2ZcuJUyK_EiG4a0TNfFUhw2rBUFqVwkeHmIRQU40=.76c5f4fa-9e5f-4789-9362-7e2d409eaba5@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - Update spec for unnamed packages and modules.
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Ancillary improvements to the spec.
 - Merge branch 'master' into JDK-8224922
 - Merge branch 'master' into JDK-8224922
 - Appease jcheck.
 - ... and 16 more: https://git.openjdk.java.net/jdk/compare/74fcc8f7...1d2492d7

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/1599509b..1d2492d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=07-08

  Stats: 433903 lines in 959 files changed: 221227 ins; 199726 del; 12950 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From aleonard at openjdk.java.net  Tue Nov 16 14:34:34 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 16 Nov 2021 14:34:34 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <FWxPJDLpu8cW317k-x7bpxjLW6iQ8kfx5ijew-FP2XU=.896154f3-4a7e-4fb3-ae53-76d10b5ff652@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I have tried a couple of performance tests, running a jar of a significant size, repeatedly 100x, results show a 1% difference, although there was some variance on running this several times +/- 5 seconds.
For 100x jar creation of 16,000 files:
Previously : 499 seconds
With patch: 504 seconds

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From jlahoda at openjdk.java.net  Tue Nov 16 20:14:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 16 Nov 2021 20:14:08 GMT
Subject: RFR: 8277106: Cannot compile certain sources with --release
Message-ID: <odlB8AnorK8G0yObERVlte45rD4K5xWCkhB3Uwl26cc=.710db6d4-9d5b-423a-bf60-b82d7db39ab1@github.com>

While working on JDK-8277105[1], it turned out the historical data in `ct.sym` are not quite right in two directions:
a) some API classes extend classes from non-exported packages (often from the `java.base` module). Examples include `jdk.jfr.Event` which extends `jdk.internal.event.Event`. As the current `ct.sym` data do not keep classes from non-exported packages, compilation against these classes fails.
b) permitted subtypes may include classes from non-exported packages, and these are needed to properly determine validity of casts and pattern matching switches. But these classes are not kept in the `ct.sym`, and hence the behavior of the casts may be incorrect. (Although I am no aware of any cases where an actual problem would arise with the current APIs.)

The proposed solution is to keep a certain amount of classes from non-exported packages in the historical record, specifically classes that are either extended by a class in an exported package, or named as a permitted subclass in an exported package.

The first occurrence of a) I was able to find was in JDK 11, so this patch also fixes the historical record till JDK 11.

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

-------------

Commit messages:
 - 8277106: Cannot compile certain sources with --release

Changes: https://git.openjdk.java.net/jdk/pull/6417/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6417&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277106
  Stats: 1955 lines in 22 files changed: 1849 ins; 39 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6417.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6417/head:pull/6417

PR: https://git.openjdk.java.net/jdk/pull/6417

From jlahoda at openjdk.java.net  Tue Nov 16 20:30:01 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 16 Nov 2021 20:30:01 GMT
Subject: RFR: 8277105: Inconsistent handling of missing permitted subclasses
Message-ID: <SLldW8bNrWsFidWMjtwXXxKYd71xpHmRBzsXHrveYJc=.f9c22be4-c41f-49a7-be01-ef3689483ed2@github.com>

Consider a sealed interface, when one (or more) of the permitted subtypes is not available.:

public abstract sealed class Lib permits Impl1, Impl2 {}
final class Impl1 extends Lib {}
final class Impl2 extends Lib {}


When compiling against this `Lib`, consider that `Impl1` is missing. Then there is an inconsistency between cast and pattern switch in reported errors:

public class Test1 {
    public void test(Lib lib) {
        Runnable r = (Runnable) lib;
    }
}

$ javac -d out -classpath out --enable-preview -source 17 test/Test1.java
test/Test1.java:3: error: cannot access Impl1
        Runnable r = (Runnable) lib;
                     ^
  class file for Impl1 not found
1 error



public class Test2 {
    public void test(Lib lib) {
        switch (lib) {
            case Impl2 i -> {}
        }
    }
}

$ javac -d out -classpath out --enable-preview -source 17 test/Test2.java
test/Test2.java:3: error: the switch statement does not cover all possible input values
        switch (lib) {
        ^
Note: test/Test2.java uses preview features of Java SE 17.
Note: Recompile with -Xlint:preview for details.
1 error


The pattern matching switch tries to recover from the missing permitted subtype, but that is not right - it is generally not possible to determine reliably if a cast is valid, or a switch is exhaustive, when a permitted subtype is missing. So the "not found" error should be reported also for the pattern switch case.

The `CompletionFailure` still needs to be handled somehow in `Flow`, as there's nothing else that would catch the exception, and the compilation would fail with an exception if not handled.

-------------

Commit messages:
 - Fixing header years.
 - Removing debug info.
 - 8277105: Inconsistent handling of missing permitted subclasses

Changes: https://git.openjdk.java.net/jdk/pull/6418/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6418&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277105
  Stats: 315 lines in 3 files changed: 201 ins; 101 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6418.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6418/head:pull/6418

PR: https://git.openjdk.java.net/jdk/pull/6418

From serb at openjdk.java.net  Tue Nov 16 20:30:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Nov 2021 20:30:23 GMT
Subject: RFR: 8272358: Some tests may fail when executed with other locales
 than the US [v2]
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <VEKJDP_pYuMaHRH84-pMR-pe-wmzOmvmjN3sX-fVBpc=.f4c4c7b3-1468-4918-8aec-82ba6ee1c060@github.com>

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8272358
 - Initial fix of JDK-8272358

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5098/files
  - new: https://git.openjdk.java.net/jdk/pull/5098/files/1254951a..4860557e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5098&range=00-01

  Stats: 994174 lines in 4051 files changed: 529940 ins; 443625 del; 20609 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5098.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5098/head:pull/5098

PR: https://git.openjdk.java.net/jdk/pull/5098

From lancea at openjdk.java.net  Tue Nov 16 21:25:38 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 16 Nov 2021 21:25:38 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v4]
In-Reply-To: <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
Message-ID: <yYGarG8ud_l3mX1wOe59F9ZgL40FYuhveUgGiQgbtEQ=.42f2a438-24f8-4c30-852c-8692ee390308@github.com>

On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use testng asserts
>  - Remove "final" usage from test

Hi Jaikiran,

Thank you for your efforts on this.  I think the changes look good overall. I want to make one more pass this week, but nothing  obvious has jumped out as a concern.

I have also made a couple of mach5 runs without any regressions.

Best
Lance

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From darcy at openjdk.java.net  Tue Nov 16 23:27:13 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 16 Nov 2021 23:27:13 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v10]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <WsZ2IOX4Lropv51br7qIxNnu3mvHBgiJj1VhEB7hqfs=.66c5c5a9-f1b1-453d-8b2a-d5f84bce8659@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Refine spec.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/1d2492d7..bc9b6b12

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=08-09

  Stats: 42 lines in 2 files changed: 32 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Wed Nov 17 01:15:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 01:15:59 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v11]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <qhRRdWWGTCYcD7elWfsLXzVVa5UqAuj2yyPezNSivK0=.04b8a6d6-f386-424d-9019-c8ac04d81ee4@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Refine spec.
 - Add explicit spec coverage of auxillary types in package-info files.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/bc9b6b12..8cdbf525

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=09-10

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Wed Nov 17 02:06:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 02:06:14 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v12]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <YZCmtva5hg5P58Ov3GxbQf87jjbVlWvTzetI5-f_igI=.f1c4f83a-839d-4bfb-905b-fb316a2a3c6c@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add spec for automatic modules.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/8cdbf525..1f5e548f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=10-11

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From jpai at openjdk.java.net  Wed Nov 17 03:47:32 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 17 Nov 2021 03:47:32 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v4]
In-Reply-To: <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
Message-ID: <q3FhPrOrnyEIAb-1q-pu71XzHtBZEZ42Ww6m9PLEu10=.505b2f8f-6522-44fd-9521-fe02e0c0bdd9@github.com>

On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use testng asserts
>  - Remove "final" usage from test

Thank you for running the tests Lance. I'll wait for you to complete the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From darcy at openjdk.java.net  Wed Nov 17 08:15:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 08:15:51 GMT
Subject: RFR: JDK-8277303: Terminology mismatch between JLS17-3.9 and SE17's
 javax.lang.model.SourceVersion method specs
Message-ID: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>

Please review this simple terminology update along with the corresponding CSR:

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

-------------

Commit messages:
 - JDK-8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs

Changes: https://git.openjdk.java.net/jdk/pull/6425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6425&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277303
  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6425/head:pull/6425

PR: https://git.openjdk.java.net/jdk/pull/6425

From aleonard at openjdk.java.net  Wed Nov 17 16:50:37 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 17 Nov 2021 16:50:37 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <dgLhkA_Zj1YUgIj-jSr3boRHAhyt-fjvT_ZCP_jHWRQ=.5de293e0-99d3-48dd-8d5f-f279b41519ba@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@AlanBateman @magicus fyi, if you're able to take a look please, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Wed Nov 17 19:19:56 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 17 Nov 2021 19:19:56 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Wed Nov 17 19:25:45 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 17 Nov 2021 19:25:45 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Overall I think the change looks sane. A 1% performance penalty for tens of thousands of files in a single directory might be acceptable, since that is unusual.

Alan or someone else have to say if this needs a CSR, and/or a implNote.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 828:

> 826:                     String[] dirFiles = f.list();
> 827:                     // Ensure files list is sorted for reproducible jar content
> 828:                     if (dirFiles != null)

Style issue. I strongly dislike multi-line if statements without braces. I don't know if that style is followed in the rest of the code, but if it seems to fit in I strongly recommend using braces.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From iris at openjdk.java.net  Wed Nov 17 19:30:55 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 17 Nov 2021 19:30:55 GMT
Subject: RFR: JDK-8277303: Terminology mismatch between JLS17-3.9 and
 SE17's javax.lang.model.SourceVersion method specs
In-Reply-To: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
References: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
Message-ID: <3PRc7pJwQ3lfAQ6882t4sZFZgxlEoZ4ZHaWXIKnxkrA=.9bc367df-a27b-4490-be37-71a219fa2098@github.com>

On Wed, 17 Nov 2021 08:08:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple terminology update along with the corresponding CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8277325

Associated CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6425

From jjg at openjdk.java.net  Wed Nov 17 19:36:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 17 Nov 2021 19:36:42 GMT
Subject: RFR: JDK-8277303: Terminology mismatch between JLS17-3.9 and
 SE17's javax.lang.model.SourceVersion method specs
In-Reply-To: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
References: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
Message-ID: <KnAxtXeLoMOPACGt5w6HvajkrPv81SmcyGMgcJYOCCk=.14bde7d8-429f-4a16-8bf8-bfca08780515@github.com>

On Wed, 17 Nov 2021 08:08:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple terminology update along with the corresponding CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8277325

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6425

From lancea at openjdk.java.net  Wed Nov 17 20:24:43 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 17 Nov 2021 20:24:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <Allng8uGg53v_7fqBThgWq6A94oZPgeFtDYsx8v4diw=.148b5b4c-2d26-4427-a5db-c9d50aa87c9c@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

It would be good to consider adding a benchmark as part of this PR.  I realize you did your own testing.

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Wed Nov 17 20:24:44 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 17 Nov 2021 20:24:44 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>
Message-ID: <Fx2MkwlV-jY-nZkHHtNn-KHAIHKO3EOW6BYREOk70KQ=.acc8a114-23bc-45f0-aa86-e1ebbb09fdab@github.com>

On Wed, 17 Nov 2021 19:18:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 828:
> 
>> 826:                     String[] dirFiles = f.list();
>> 827:                     // Ensure files list is sorted for reproducible jar content
>> 828:                     if (dirFiles != null)
> 
> Style issue. I strongly dislike multi-line if statements without braces. I don't know if that style is followed in the rest of the code, but if it seems to fit in I strongly recommend using braces.

I agree, we should change this to include braces with the if statement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From darcy at openjdk.java.net  Wed Nov 17 20:26:48 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 20:26:48 GMT
Subject: Integrated: JDK-8277303: Terminology mismatch between JLS17-3.9 and
 SE17's javax.lang.model.SourceVersion method specs
In-Reply-To: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
References: <WJMy9DVXJ_9AYAvO8X2CrjoTJ6ZPKNf_7AVLLFWxViI=.93586d8e-1213-404a-a098-0d01195850b1@github.com>
Message-ID: <B4RBOI9fuoyeaUkwlYZcP0hJfaQDsZLe8KN0FlfvKC8=.af76f050-78b2-488e-bc7e-e5797467f25a@github.com>

On Wed, 17 Nov 2021 08:08:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review this simple terminology update along with the corresponding CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8277325

This pull request has now been integrated.

Changeset: 007ad7c7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/007ad7c77c6277ce733386b4402b787d81dd41cf
Stats:     10 lines in 1 file changed: 0 ins; 0 del; 10 mod

8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs

Reviewed-by: iris, jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/6425

From aleonard at openjdk.java.net  Wed Nov 17 21:27:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 17 Nov 2021 21:27:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Fx2MkwlV-jY-nZkHHtNn-KHAIHKO3EOW6BYREOk70KQ=.acc8a114-23bc-45f0-aa86-e1ebbb09fdab@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>
 <Fx2MkwlV-jY-nZkHHtNn-KHAIHKO3EOW6BYREOk70KQ=.acc8a114-23bc-45f0-aa86-e1ebbb09fdab@github.com>
Message-ID: <qtQf9F-K5OQu8QWesQp5FvXqh5FBt8NFIonf5GrDiKE=.dd9add5e-0551-4837-b8b7-fb91adebbc69@github.com>

On Wed, 17 Nov 2021 20:13:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 828:
>> 
>>> 826:                     String[] dirFiles = f.list();
>>> 827:                     // Ensure files list is sorted for reproducible jar content
>>> 828:                     if (dirFiles != null)
>> 
>> Style issue. I strongly dislike multi-line if statements without braces. I don't know if that style is followed in the rest of the code, but if it seems to fit in I strongly recommend using braces.
>
> I agree, we should change this to include braces with the if statement.

I agree, I always use {}, I was being consistent with the rest of the expand() method, but I will add {} as I prefer that too, better to set a good example!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From darcy at openjdk.java.net  Wed Nov 17 21:31:28 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 21:31:28 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v13]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <HGuUpZHGobDcB8ccFdQvVs4VwjLOBSeNhLsYYRetIno=.5c703557-729b-47a5-9d45-d25428a65c3e@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with three additional commits since the last revision:

 - Merge pull request #5 from lahodaj/JDK-8224922-3
   
   Adding tests for unnamed module/package and automatic modules.
 - Using a specific class file as the source.
 - Adjusting to the specification requiring returning of the outtermost class' FileObject, adding tests for unnamed module/package and automatic modules.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/1f5e548f..be167698

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=11-12

  Stats: 281 lines in 2 files changed: 277 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From lancea at openjdk.java.net  Wed Nov 17 21:31:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 17 Nov 2021 21:31:41 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <qtQf9F-K5OQu8QWesQp5FvXqh5FBt8NFIonf5GrDiKE=.dd9add5e-0551-4837-b8b7-fb91adebbc69@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>
 <Fx2MkwlV-jY-nZkHHtNn-KHAIHKO3EOW6BYREOk70KQ=.acc8a114-23bc-45f0-aa86-e1ebbb09fdab@github.com>
 <qtQf9F-K5OQu8QWesQp5FvXqh5FBt8NFIonf5GrDiKE=.dd9add5e-0551-4837-b8b7-fb91adebbc69@github.com>
Message-ID: <UUcWzJRjYM2FpPVUb80RIWlP31U5EpqoR9nZG6WCb04=.7f345774-30ec-4af2-ae78-1c136918c4a6@github.com>

On Wed, 17 Nov 2021 21:24:40 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> I agree, we should change this to include braces with the if statement.
>
> I agree, I always use {}, I was being consistent with the rest of the expand() method, but I will add {} as I prefer that too, better to set a good example!

Feel free to clean those up as well :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From mchung at openjdk.java.net  Wed Nov 17 21:52:44 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Nov 2021 21:52:44 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 131:

> 129:     // There's also a files array per version
> 130:     // Use a LinkedHashMap to keep original insertion ordering
> 131:     Map<Integer,String[]> filesMap = new LinkedHashMap<>();

The entries of `filesMap` is sorted by the version.   Is the value of each entry already sorted?  Does that matter?   It's unclear to me since `expand` is called for each entry's value:


    private void expand() throws IOException {
        for (int version : filesMap.keySet()) {
            String[] files = filesMap.get(version);
            expand(null, files, pathsMap.get(version), version);
        }
    }

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 803:

> 801:                     out.writeEntry(in, section, name);
> 802:                 }
> 803:             }

jmod change is okay.

test/jdk/tools/jar/ContentOrder.java line 79:

> 77:     @Test
> 78:     public void test1() throws IOException {
> 79:         mkdir("testjar/Ctest1 testjar/Btest2/subdir1 testjar/Atest3");

I suggest to make `mkdir` and `touch` to take a vararg of String or Path and the method body concatenates the input strings to build the command line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From darcy at openjdk.java.net  Wed Nov 17 22:09:36 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Nov 2021 22:09:36 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v14]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <g1Py4bXffj6iYg7G99BgMOX_UeIJ691CpcrHOgYxunE=.7ff679d9-e5c4-4a11-a90a-9d86c14806d9@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 37 additional commits since the last revision:

 - Reflow paragraphs.
 - Fix spec typo; update copyrights.
 - Merge branch 'JDK-8224922' of https://github.com/jddarcy/jdk into JDK-8224922
 - Merge pull request #5 from lahodaj/JDK-8224922-3
   
   Adding tests for unnamed module/package and automatic modules.
 - Using a specific class file as the source.
 - Adjusting to the specification requiring returning of the outtermost class' FileObject, adding tests for unnamed module/package and automatic modules.
 - Merge branch 'master' into JDK-8224922
 - Add spec for automatic modules.
 - Refine spec.
 - Add explicit spec coverage of auxillary types in package-info files.
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/c1dd8692...04e8ea4b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/be167698..04e8ea4b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=12-13

  Stats: 2800 lines in 110 files changed: 2021 ins; 441 del; 338 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From serb at openjdk.java.net  Wed Nov 17 22:24:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 17 Nov 2021 22:24:47 GMT
Subject: Integrated: 8272358: Some tests may fail when executed with other
 locales than the US
In-Reply-To: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
References: <94kSXUGkKtpqqyy_ys9eXPgl6A9UV2V-Jlac0iT_l9E=.b800f0df-5e3f-43ea-8928-01f955f0c4b8@github.com>
Message-ID: <c8HA2le_6SIG7yv7QyacWTxNTjou_89VK_K94O24zwc=.1be8f610-e38b-4803-ba0c-6e02efc5cbc5@github.com>

On Thu, 12 Aug 2021 08:46:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As mentioned in the bug report this issue was reported a few times, I have checked all tests in tier1/tier2/tier3 and found these four tests which fail because of non-US locale. The common issue is that the output depends on the locale(ex: 3.14 VS 3,14).

This pull request has now been integrated.

Changeset: 29e552c0
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29e552c03a2825f9526330072668a1d63ac68fd4
Stats:     9 lines in 4 files changed: 1 ins; 0 del; 8 mod

8272358: Some tests may fail when executed with other locales than the US

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/5098

From darcy at openjdk.java.net  Thu Nov 18 05:53:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 18 Nov 2021 05:53:07 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v15]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <3DPsYQBAEPAv8ov6l2xPMH853F-ReeEo3z1MlR2CPEU=.2bdef57a-b159-4236-8e0d-7a5fff7fe0d0@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #6 from lahodaj/JDK-8224922-4
   
   Adding forgotten file/fixing test.
 - Adding forgotten file/fixing test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/04e8ea4b..a62ff194

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=13-14

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From aleonard at openjdk.java.net  Thu Nov 18 09:13:38 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 18 Nov 2021 09:13:38 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
Message-ID: <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>

On Wed, 17 Nov 2021 21:44:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 131:
> 
>> 129:     // There's also a files array per version
>> 130:     // Use a LinkedHashMap to keep original insertion ordering
>> 131:     Map<Integer,String[]> filesMap = new LinkedHashMap<>();
> 
> The entries of `filesMap` is sorted by the version.   Is the value of each entry already sorted?  Does that matter?   It's unclear to me since `expand` is called for each entry's value:
> 
> 
>     private void expand() throws IOException {
>         for (int version : filesMap.keySet()) {
>             String[] files = filesMap.get(version);
>             expand(null, files, pathsMap.get(version), version);
>         }
>     }

@mlchung the way I looked at this was the filesMap is a HashMap, so the filesMap.keySet() iteration order is not defined (or necessarily deterministic), the expanded order of the file sets for each version could be ver1, ver2, ver3 or ver3, ver2, ver1... the next time you run it with the same parameters.
LinkedHashMap will ensure the iterated order is as inserted (or as specified in the jar args list..)

Although you say "filesMap is sorted by version", I don't see where that is done?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From duke at openjdk.java.net  Thu Nov 18 09:14:42 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 18 Nov 2021 09:14:42 GMT
Subject: Withdrawn: 8269121: Type inference bug with method references
In-Reply-To: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
References: <6uOcizX9XuJvqw-MJrUDIkwB2GQk2DGTJjrKfwI2uPY=.25ca8684-ffc3-4929-af89-24eedf5cfc90@github.com>
Message-ID: <SxHDz2pGT_dPdw1g1lHTtkpHTL10eUXbvNbQkusD_x0=.ead3f819-c09d-4904-ab17-06df946674c1@github.com>

On Wed, 8 Sep 2021 04:01:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is making a change to how javac generates the arguments for the lambda metafactory. There are cases like the one described in the JIRA bug entry for which the generated arguments won't be valid and the generated code will fail at execution. The problem arises when the erasure of the lambda method is incompatible with the erasure of the function descriptor. This can happen when at least one of the arguments of the lambda method has an intersection type, in case that the erasure of the intersection type is not compatible with the corresponding argument of the function descriptor. This fix's proposal is to analyze all the components of the intersection and select the first that is compatible with its corresponding argument in the function descriptor.
> 
> TIA

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5406

From aleonard at openjdk.java.net  Thu Nov 18 09:22:39 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 18 Nov 2021 09:22:39 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Allng8uGg53v_7fqBThgWq6A94oZPgeFtDYsx8v4diw=.148b5b4c-2d26-4427-a5db-c9d50aa87c9c@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <Allng8uGg53v_7fqBThgWq6A94oZPgeFtDYsx8v4diw=.148b5b4c-2d26-4427-a5db-c9d50aa87c9c@github.com>
Message-ID: <aRoDXKwpGrByL-VY0zpwWcxQK6DSSedUvrB22eVWoNU=.73404e70-b726-4144-90d6-29ed0751d1b5@github.com>

On Wed, 17 Nov 2021 20:21:09 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It would be good to consider adding a benchmark as part of this PR. I realize you did your own testing.

@LanceAndersen i'll add a simple benchmark test, eg.a 10,000 file jar x50 benchmark

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Thu Nov 18 09:35:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 18 Nov 2021 09:35:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
Message-ID: <xqr0MoMcjTY1UjQ8rNGfQWtD8uPozEGIoEybAGzJC-Y=.ece33de4-02b7-4f29-9f32-35d53aaca6d8@github.com>

On Wed, 17 Nov 2021 21:45:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 803:
> 
>> 801:                     out.writeEntry(in, section, name);
>> 802:                 }
>> 803:             }
> 
> jmod change is okay.

thanks

> test/jdk/tools/jar/ContentOrder.java line 79:
> 
>> 77:     @Test
>> 78:     public void test1() throws IOException {
>> 79:         mkdir("testjar/Ctest1 testjar/Btest2/subdir1 testjar/Atest3");
> 
> I suggest to make `mkdir` and `touch` to take a vararg of String or Path and the method body concatenates the input strings to build the command line.

I copied this from another test, but your suggestion makes sense

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Thu Nov 18 10:05:46 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 18 Nov 2021 10:05:46 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
 <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>
Message-ID: <tlqZO83LiA0ijD0AXBqU8X9aZSTWCVgtaROl8HJ3rt4=.a8ac1c89-c8af-424f-95c1-c733faab6b6e@github.com>

On Thu, 18 Nov 2021 09:10:16 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 131:
>> 
>>> 129:     // There's also a files array per version
>>> 130:     // Use a LinkedHashMap to keep original insertion ordering
>>> 131:     Map<Integer,String[]> filesMap = new LinkedHashMap<>();
>> 
>> The entries of `filesMap` is sorted by the version.   Is the value of each entry already sorted?  Does that matter?   It's unclear to me since `expand` is called for each entry's value:
>> 
>> 
>>     private void expand() throws IOException {
>>         for (int version : filesMap.keySet()) {
>>             String[] files = filesMap.get(version);
>>             expand(null, files, pathsMap.get(version), version);
>>         }
>>     }
>
> @mlchung the way I looked at this was the filesMap is a HashMap, so the filesMap.keySet() iteration order is not defined (or necessarily deterministic), the expanded order of the file sets for each version could be ver1, ver2, ver3 or ver3, ver2, ver1... the next time you run it with the same parameters.
> LinkedHashMap will ensure the iterated order is as inserted (or as specified in the jar args list..)
> 
> Although you say "filesMap is sorted by version", I don't see where that is done?

I'm guessing Mandy asks not if the keys are sorted -- this is changed by your patch, but if the value retrieved -- the String[], is sorted. It's a valid question, I think. It's not apparent to me at least that this is the case. If it is not sorted when it is inserted it needs to be sorted when extracted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Thu Nov 18 11:08:41 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 18 Nov 2021 11:08:41 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <tlqZO83LiA0ijD0AXBqU8X9aZSTWCVgtaROl8HJ3rt4=.a8ac1c89-c8af-424f-95c1-c733faab6b6e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
 <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>
 <tlqZO83LiA0ijD0AXBqU8X9aZSTWCVgtaROl8HJ3rt4=.a8ac1c89-c8af-424f-95c1-c733faab6b6e@github.com>
Message-ID: <Un3fZWq7_u3DU6E_L1BBmewLlwYBeO7K6D0CLuEPw9s=.4f4f77bc-bea0-40e7-82cc-a855c07a73da@github.com>

On Thu, 18 Nov 2021 10:02:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @mlchung the way I looked at this was the filesMap is a HashMap, so the filesMap.keySet() iteration order is not defined (or necessarily deterministic), the expanded order of the file sets for each version could be ver1, ver2, ver3 or ver3, ver2, ver1... the next time you run it with the same parameters.
>> LinkedHashMap will ensure the iterated order is as inserted (or as specified in the jar args list..)
>> 
>> Although you say "filesMap is sorted by version", I don't see where that is done?
>
> I'm guessing Mandy asks not if the keys are sorted -- this is changed by your patch, but if the value retrieved -- the String[], is sorted. It's a valid question, I think. It's not apparent to me at least that this is the case. If it is not sorted when it is inserted it needs to be sorted when extracted.

@magicus 
ah right, got you.  So the order of each version's String[] is as ordered on the jar cmd line args:
https://github.com/openjdk/jdk/blob/3e87db19bb7e2359e4b1ceaac7c123542345ecb1/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L664

So for the same jar cmdline input, the output will be deterministic, as in the same order.
If we think we need to be deterministic for different jar cmdline input for the same set of files, I can add a sort, but that wasn't my aim. eg: both these produce the same order?
    jar --create --file my.jar --release 9 v9classesdir1 v9classesdir2
    jar --create --file my.jar --release 9 v9classesdir2 v9classesdir1 
My aim was same input == same output
?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Thu Nov 18 11:45:41 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 18 Nov 2021 11:45:41 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
Message-ID: <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>

On Wed, 17 Nov 2021 19:16:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?

@magicus so the first test I did was 16,000 files in multiple directories, as I thought that was more representative, and would involve multiple small sorts vs one large sort.
I have just re-run the tests again, for both 16000 multi-dir and 16000 single dir, and the results are similar:
16000 multi-dir x50:
Existing code: 291 seconds (variance: +/- 3 seconds)
New patch:  293 seconds (variance: +/- 3 seconds)
16000 single-dir x50:
Existing code: 235 seconds (variance: +/- 3 seconds)
New patch: 237 seconds (variance: +/- 3 seconds)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Thu Nov 18 11:45:41 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 18 Nov 2021 11:45:41 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
Message-ID: <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>

On Thu, 18 Nov 2021 11:38:08 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?
>
>> Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?
> 
> @magicus so the first test I did was 16,000 files in multiple directories, as I thought that was more representative, and would involve multiple small sorts vs one large sort.
> I have just re-run the tests again, for both 16000 multi-dir and 16000 single dir, and the results are similar:
> 16000 multi-dir x50:
> Existing code: 291 seconds (variance: +/- 3 seconds)
> New patch:  293 seconds (variance: +/- 3 seconds)
> 16000 single-dir x50:
> Existing code: 235 seconds (variance: +/- 3 seconds)
> New patch: 237 seconds (variance: +/- 3 seconds)

@andrew-m-leonard Thanks. I think that alleviates any fear of performance regression. Sounds like you are well within the span of normal variation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Thu Nov 18 11:45:41 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 18 Nov 2021 11:45:41 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Un3fZWq7_u3DU6E_L1BBmewLlwYBeO7K6D0CLuEPw9s=.4f4f77bc-bea0-40e7-82cc-a855c07a73da@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
 <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>
 <tlqZO83LiA0ijD0AXBqU8X9aZSTWCVgtaROl8HJ3rt4=.a8ac1c89-c8af-424f-95c1-c733faab6b6e@github.com>
 <Un3fZWq7_u3DU6E_L1BBmewLlwYBeO7K6D0CLuEPw9s=.4f4f77bc-bea0-40e7-82cc-a855c07a73da@github.com>
Message-ID: <DKRqFT4HKFk2G1hgoF7YJbrBoST2BGRbcDuBg9XKuYs=.122e9d1f-457f-46d6-948b-c41e565400ed@github.com>

On Thu, 18 Nov 2021 11:05:54 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> I'm guessing Mandy asks not if the keys are sorted -- this is changed by your patch, but if the value retrieved -- the String[], is sorted. It's a valid question, I think. It's not apparent to me at least that this is the case. If it is not sorted when it is inserted it needs to be sorted when extracted.
>
> @magicus 
> ah right, got you.  So the order of each version's String[] is as ordered on the jar cmd line args:
> https://github.com/openjdk/jdk/blob/3e87db19bb7e2359e4b1ceaac7c123542345ecb1/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L664
> 
> So for the same jar cmdline input, the output will be deterministic, as in the same order.
> If we think we need to be deterministic for different jar cmdline input for the same set of files, I can add a sort, but that wasn't my aim. eg: both these produce the same order?
>     jar --create --file my.jar --release 9 v9classesdir1 v9classesdir2
>     jar --create --file my.jar --release 9 v9classesdir2 v9classesdir1 
> My aim was same input == same output
> ?

Fair enough, that's a good answer. I did not know the origin of these values. If they are in command line order, I completely agree with you that this is the behavior we want.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From darcy at openjdk.java.net  Thu Nov 18 18:16:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 18 Nov 2021 18:16:21 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v16]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <TqBKK3mMVrnPAeYW7EylPiN22WUGRi4XypWna0GOaYo=.29cf8bcc-3afd-47e6-a823-6df2f485d74d@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #7 from lahodaj/JDK-8224922-5
   
   Fixing a test on Windows.
 - Attempting to fix a Windows test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/a62ff194..cd9f6bc5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From jjg at openjdk.java.net  Thu Nov 18 19:54:43 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Nov 2021 19:54:43 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v16]
In-Reply-To: <TqBKK3mMVrnPAeYW7EylPiN22WUGRi4XypWna0GOaYo=.29cf8bcc-3afd-47e6-a823-6df2f485d74d@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
 <TqBKK3mMVrnPAeYW7EylPiN22WUGRi4XypWna0GOaYo=.29cf8bcc-3afd-47e6-a823-6df2f485d74d@github.com>
Message-ID: <h0tab4mLfoNF6HSZQ_nhIFczIz89poXjAthJ6uww_H4=.55a9dd37-c746-4a20-ac81-807b95825414@github.com>

On Thu, 18 Nov 2021 18:16:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #7 from lahodaj/JDK-8224922-5
>    
>    Fixing a test on Windows.
>  - Attempting to fix a Windows test.

Nice to see at least partial cleanup of the `Symbol.classfile` field.

src/java.compiler/share/classes/javax/lang/model/element/package-info.java line 39:

> 37:  * anonymous classes.
> 38:  *
> 39:  * <p><a id="accurate_model">When used in the context of annotation processing, an accurate

It would be more correct to just put the id on the `<p>` tag and drop the `<a>`.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 798:

> 796:      * the creation of source or class files in that package.  An
> 797:      * {@linkplain PackageElement#isUnnamed unnamed package} will have
> 798:      * a null file since it cannot be declared in a compilation unit.

`{@code }` around  null ??

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 802:

> 800:      * <p>If it has a file object, the file object for a module will
> 801:      * be a {@code module-info} file.  An {@linkplain
> 802:      * ModuleElement#isUnnamed unnamed module} will have a null file

another null.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 805:

> 803:      * since it cannot be declared in a compilation unit.  An
> 804:      * {@linkplain #isAutomaticModule automatic module} will have a
> 805:      * null file since it is implicitly declared.

I guess you're consistent!

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5038

From vromero at openjdk.java.net  Thu Nov 18 20:49:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 18 Nov 2021 20:49:41 GMT
Subject: RFR: 8277105: Inconsistent handling of missing permitted
 subclasses
In-Reply-To: <SLldW8bNrWsFidWMjtwXXxKYd71xpHmRBzsXHrveYJc=.f9c22be4-c41f-49a7-be01-ef3689483ed2@github.com>
References: <SLldW8bNrWsFidWMjtwXXxKYd71xpHmRBzsXHrveYJc=.f9c22be4-c41f-49a7-be01-ef3689483ed2@github.com>
Message-ID: <pr683CANx6t6Hf_V5IGAsjy-S725ExfGJD1CHbTBQJs=.c71a41ab-0dbf-49ca-bbbd-e5f4b5bf96de@github.com>

On Tue, 16 Nov 2021 20:21:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a sealed interface, when one (or more) of the permitted subtypes is not available.:
> 
> public abstract sealed class Lib permits Impl1, Impl2 {}
> final class Impl1 extends Lib {}
> final class Impl2 extends Lib {}
> 
> 
> When compiling against this `Lib`, consider that `Impl1` is missing. Then there is an inconsistency between cast and pattern switch in reported errors:
> 
> public class Test1 {
>     public void test(Lib lib) {
>         Runnable r = (Runnable) lib;
>     }
> }
> 
> $ javac -d out -classpath out --enable-preview -source 17 test/Test1.java
> test/Test1.java:3: error: cannot access Impl1
>         Runnable r = (Runnable) lib;
>                      ^
>   class file for Impl1 not found
> 1 error
> 
> 
> 
> public class Test2 {
>     public void test(Lib lib) {
>         switch (lib) {
>             case Impl2 i -> {}
>         }
>     }
> }
> 
> $ javac -d out -classpath out --enable-preview -source 17 test/Test2.java
> test/Test2.java:3: error: the switch statement does not cover all possible input values
>         switch (lib) {
>         ^
> Note: test/Test2.java uses preview features of Java SE 17.
> Note: Recompile with -Xlint:preview for details.
> 1 error
> 
> 
> The pattern matching switch tries to recover from the missing permitted subtype, but that is not right - it is generally not possible to determine reliably if a cast is valid, or a switch is exhaustive, when a permitted subtype is missing. So the "not found" error should be reported also for the pattern switch case.
> 
> The `CompletionFailure` still needs to be handled somehow in `Flow`, as there's nothing else that would catch the exception, and the compilation would fail with an exception if not handled.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6418

From mchung at openjdk.java.net  Thu Nov 18 23:52:42 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 18 Nov 2021 23:52:42 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <ubChY4loh1wwMA5cEFksxc02Dvl-ZIuRKqKeYl69V7E=.61ed1b76-6290-4824-82ee-a33baf286ad9@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 130:

> 128: 
> 129:     // There's also a files array per version
> 130:     // Use a LinkedHashMap to keep original insertion ordering

Suggestion:

    // base version is the first entry and then follow with the version given
    // from the --release option in the command-line order.
    // The value of each entry is the files given in the command-line order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From mchung at openjdk.java.net  Thu Nov 18 23:52:43 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 18 Nov 2021 23:52:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <DKRqFT4HKFk2G1hgoF7YJbrBoST2BGRbcDuBg9XKuYs=.122e9d1f-457f-46d6-948b-c41e565400ed@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
 <_Pt66KDAWGAlsk4n6EXafvFVAOXBTFLpnX-WMxVUt18=.d109f270-4906-4460-b851-62898196aa5f@github.com>
 <tlqZO83LiA0ijD0AXBqU8X9aZSTWCVgtaROl8HJ3rt4=.a8ac1c89-c8af-424f-95c1-c733faab6b6e@github.com>
 <Un3fZWq7_u3DU6E_L1BBmewLlwYBeO7K6D0CLuEPw9s=.4f4f77bc-bea0-40e7-82cc-a855c07a73da@github.com>
 <DKRqFT4HKFk2G1hgoF7YJbrBoST2BGRbcDuBg9XKuYs=.122e9d1f-457f-46d6-948b-c41e565400ed@github.com>
Message-ID: <eOrbx4rZq0yPYo9Ot_A3NsJ3HnqoTAJZD-Kk6wHmdeE=.60bc59d8-400c-436c-9d81-88ad143223c3@github.com>

On Thu, 18 Nov 2021 11:40:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @magicus 
>> ah right, got you.  So the order of each version's String[] is as ordered on the jar cmd line args:
>> https://github.com/openjdk/jdk/blob/3e87db19bb7e2359e4b1ceaac7c123542345ecb1/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L664
>> 
>> So for the same jar cmdline input, the output will be deterministic, as in the same order.
>> If we think we need to be deterministic for different jar cmdline input for the same set of files, I can add a sort, but that wasn't my aim. eg: both these produce the same order?
>>     jar --create --file my.jar --release 9 v9classesdir1 v9classesdir2
>>     jar --create --file my.jar --release 9 v9classesdir2 v9classesdir1 
>> My aim was same input == same output
>> ?
>
> Fair enough, that's a good answer. I did not know the origin of these values. If they are in command line order, I completely agree with you that this is the behavior we want.

@magicus Thanks for clarifying for my question.

@andrew-m-leonard Keeping it as the command-line order is good.   I suggest to add a comment to describe the order of  entries of `filesMap` and the order of the values.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From itakiguchi at openjdk.java.net  Fri Nov 19 07:09:15 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 19 Nov 2021 07:09:15 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT
Message-ID: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>

ncoding name COMPAT was defined for operating system encoding by JEP-400.
https://openjdk.java.net/jeps/400
But java does not accept "-encoding COMPAT".

-------------

Commit messages:
 - 8277398: javac does not accept encoding name COMPAT

Changes: https://git.openjdk.java.net/jdk/pull/6475/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277398
  Stats: 109 lines in 3 files changed: 106 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6475/head:pull/6475

PR: https://git.openjdk.java.net/jdk/pull/6475

From jlahoda at openjdk.java.net  Fri Nov 19 07:53:47 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 19 Nov 2021 07:53:47 GMT
Subject: Integrated: 8273039: JShell crashes when naming variable or method
 "abstract" or "strictfp"
In-Reply-To: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
References: <GC6QbNiCxujC2ewCHMaoJhrWGdjIIEyl9iLZcuErYg0=.c9c4788f-f6c8-4dc6-9447-a77b88c64382@github.com>
Message-ID: <8eLsx73SXjQDxthT8DCVdGK9PgXmbK7jl0LjTP_ltwA=.c7ca0345-da68-48d9-9256-2fa3af62069c@github.com>

On Mon, 11 Oct 2021 16:48:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:
> 
> package REPL;
> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
> class $JShell$DOESNOTMATTER {
>     public static Object do_it$() throws Throwable {
>         return int strictfp = 0;
>     }
> }
> 
> 
> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.
> 
> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.

This pull request has now been integrated.

Changeset: 2f20b0d8
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236
Stats:     182 lines in 3 files changed: 181 ins; 0 del; 1 mod

8273039: JShell crashes when naming variable or method "abstract" or "strictfp"

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/5897

From aleonard at openjdk.java.net  Fri Nov 19 09:58:25 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 09:58:25 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v2]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <BM8II-lOy_nWbNVoG4Xp8L8xzy4udYGcsHrTfJzouks=.28906b23-d59f-4c49-a8b4-46d1cceb8b77@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:

 - 8276764: Enable deterministic file content ordering for Jar and Jmod
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276764: Enable deterministic file content ordering for Jar and Jmod
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/3e87db19..772b89a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=00-01

  Stats: 227 lines in 3 files changed: 201 ins; 1 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 09:58:28 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 09:58:28 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v2]
In-Reply-To: <ubChY4loh1wwMA5cEFksxc02Dvl-ZIuRKqKeYl69V7E=.61ed1b76-6290-4824-82ee-a33baf286ad9@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <ubChY4loh1wwMA5cEFksxc02Dvl-ZIuRKqKeYl69V7E=.61ed1b76-6290-4824-82ee-a33baf286ad9@github.com>
Message-ID: <gb4OkHliX4ZiY9u1j6Le5Wg7ssEYup9mncq6MO_G-Gg=.276c3ef3-dc04-43ed-9942-5e0bcc44e975@github.com>

On Thu, 18 Nov 2021 23:49:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8276764: Enable deterministic file content ordering for Jar and Jmod
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276764: Enable deterministic file content ordering for Jar and Jmod
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 130:
> 
>> 128: 
>> 129:     // There's also a files array per version
>> 130:     // Use a LinkedHashMap to keep original insertion ordering
> 
> Suggestion:
> 
>     // base version is the first entry and then follow with the version given
>     // from the --release option in the command-line order.
>     // The value of each entry is the files given in the command-line order.

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 09:58:30 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 09:58:30 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v2]
In-Reply-To: <UUcWzJRjYM2FpPVUb80RIWlP31U5EpqoR9nZG6WCb04=.7f345774-30ec-4af2-ae78-1c136918c4a6@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <FqXP21nkKbYHIVEJtYXYVtkLMurJ-VeDye_BpZ1RuMk=.dec78fde-2f25-4a5b-b3d9-46c644ba6e3c@github.com>
 <Fx2MkwlV-jY-nZkHHtNn-KHAIHKO3EOW6BYREOk70KQ=.acc8a114-23bc-45f0-aa86-e1ebbb09fdab@github.com>
 <qtQf9F-K5OQu8QWesQp5FvXqh5FBt8NFIonf5GrDiKE=.dd9add5e-0551-4837-b8b7-fb91adebbc69@github.com>
 <UUcWzJRjYM2FpPVUb80RIWlP31U5EpqoR9nZG6WCb04=.7f345774-30ec-4af2-ae78-1c136918c4a6@github.com>
Message-ID: <aZ5gETw3pUeTJq7WWCbAYTD_9HaCYdWDKDhca4aTMZ8=.99b81c96-7d9d-44b9-b450-cafe9caabbce@github.com>

On Wed, 17 Nov 2021 21:29:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I agree, I always use {}, I was being consistent with the rest of the expand() method, but I will add {} as I prefer that too, better to set a good example!
>
> Feel free to clean those up as well :-)

all fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 09:58:32 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 09:58:32 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v2]
In-Reply-To: <xqr0MoMcjTY1UjQ8rNGfQWtD8uPozEGIoEybAGzJC-Y=.ece33de4-02b7-4f29-9f32-35d53aaca6d8@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <3gsy0rQeWNB4zJJLB9uLlYOgMQpLHfR3fByESL4fWnA=.15b9f042-8d10-434e-8b20-374321159f8c@github.com>
 <xqr0MoMcjTY1UjQ8rNGfQWtD8uPozEGIoEybAGzJC-Y=.ece33de4-02b7-4f29-9f32-35d53aaca6d8@github.com>
Message-ID: <t3S8L5nebq31JQw3yDnqmDFTQhykk6I8gLOwbCPyMiY=.9aade9d2-f9ca-4ed5-9df5-6878cc8ac368@github.com>

On Thu, 18 Nov 2021 09:32:04 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> test/jdk/tools/jar/ContentOrder.java line 79:
>> 
>>> 77:     @Test
>>> 78:     public void test1() throws IOException {
>>> 79:         mkdir("testjar/Ctest1 testjar/Btest2/subdir1 testjar/Atest3");
>> 
>> I suggest to make `mkdir` and `touch` to take a vararg of String or Path and the method body concatenates the input strings to build the command line.
>
> I copied this from another test, but your suggestion makes sense

fixed as suggested

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 10:10:33 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 10:10:33 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276764: Enable deterministic file content ordering for Jar and Jmod
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/772b89a4..c8d6e90d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From alanb at openjdk.java.net  Fri Nov 19 12:14:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 19 Nov 2021 12:14:39 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 283:

> 281:                     if (enc != null) {
> 282:                         encodingName = enc;
> 283:                     }

If we updating javac and javadoc --encoding to support "COMPAT" then we should list this in JEP 400.

Does javadoc use doPriv already, I don't know how common it would be to run javadoc with a SM set. If the doPriv stays then you can avoid the cast by changing it to:
PrivilegedAction<String> pa = () -> System.getProperty("native.encoding");
return AccessController.doPrivileged(pa);

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From aleonard at openjdk.java.net  Fri Nov 19 14:46:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 14:46:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
Message-ID: <4Uz37kypc4q2fUKhPGLN5KevmJ6isA_QwpG1TPSj5p0=.667c95f9-f5d2-40e4-985e-e5f13dcb42fe@github.com>

On Thu, 18 Nov 2021 11:42:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?
>> 
>> @magicus so the first test I did was 16,000 files in multiple directories, as I thought that was more representative, and would involve multiple small sorts vs one large sort.
>> I have just re-run the tests again, for both 16000 multi-dir and 16000 single dir, and the results are similar:
>> 16000 multi-dir x50:
>> Existing code: 291 seconds (variance: +/- 3 seconds)
>> New patch:  293 seconds (variance: +/- 3 seconds)
>> 16000 single-dir x50:
>> Existing code: 235 seconds (variance: +/- 3 seconds)
>> New patch: 237 seconds (variance: +/- 3 seconds)
>
> @andrew-m-leonard Thanks. I think that alleviates any fear of performance regression. Sounds like you are well within the span of normal variation.

@magicus @mlchung @LanceAndersen ready for review again please, with all changes incorporated. thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From naoto at openjdk.java.net  Fri Nov 19 17:35:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Nov 2021 17:35:09 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
 <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
Message-ID: <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>

On Sun, 14 Nov 2021 16:45:07 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> Good suggestions. Filed a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8276970
>
> Hello @naotoj .
> For PrintStream.getCharset(), following changes may be required.
> 
> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java
> +    Charset getCharset() {
> +        return se.getCharset();
> +    }
> 
> +++ src/java.base/share/classes/java/io/PrintStream.java
> +    public Charset getCharset() {
> +        return charOut.getCharset();
> +    }
> 
> +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
> +    public Charset getCharset() {
> +        return cs;
> +    }
> 
> For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
> We need to use reflection, like:
> 
> +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
> +    private static Charset getCharset(PrintStream ps) {
> +        try {
> +            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
> +            return (Charset)getCharset.invoke(ps);
> +        } catch (Exception e) {
> +            return Charset.defaultCharset();
> +        }
> +    }
> 
> If we add following constructors against PrintWriter, we just change javap and jshell code.
> But I cannot evaluate this code changes.
> 
> +++ src/java.base/share/classes/java/io/PrintWriter.java
> +    public PrintWriter(PrintStream ps) {
> +       this((OutputStream)ps, false, ps.getCharset());
> +    }
> +    public PrintWriter(PrintStream ps, boolean autoFlush) {
> +       this((OutputStream)ps, autoFlush, ps.getCharset());
> +    }
> 
> I really appreciate if you handle this kind of code change via JEP-400.

I think this PR can now safely be withdrawn, as https://github.com/openjdk/jdk/pull/6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From mchung at openjdk.java.net  Fri Nov 19 17:35:29 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 17:35:29 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
Message-ID: <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>

On Fri, 19 Nov 2021 10:10:33 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The source change looks good.   I have a couple comments for the tests.

test/jdk/tools/jar/ContentOrder.java line 55:

> 53: import jdk.test.lib.util.FileUtils;
> 54: 
> 55: public class ContentOrder {

It'd be useful to include the test cases to verify the `--release` option with the specified files and directories as well.

test/jdk/tools/jar/ContentOrder.java line 89:

> 87:         jar("cf test.jar testjar");
> 88:         jar("tf test.jar");
> 89:         println();

Suggestion:

        System.out.println(new String(baos.toByteArray()));


You can simply print the output from `jar tf` command here and the `println` method isn't really needed.

test/jdk/tools/jar/CreateJarBenchmark.java line 56:

> 54: import jdk.test.lib.util.FileUtils;
> 55: 
> 56: public class CreateJarBenchmark {

This is a benchmark which should not be run as regression testing.   I wonder if we need this benchmark for future use.  If so I would suggest to convert it to JMH and place it under `test/micro/org/openjdk/bench/tools/jar` directory.   I'm okay with or without it in this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 18:17:11 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 18:17:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
Message-ID: <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>

On Fri, 19 Nov 2021 17:24:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276764: Enable deterministic file content ordering for Jar and Jmod
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/CreateJarBenchmark.java line 56:
> 
>> 54: import jdk.test.lib.util.FileUtils;
>> 55: 
>> 56: public class CreateJarBenchmark {
> 
> This is a benchmark which should not be run as regression testing.   I wonder if we need this benchmark for future use.  If so I would suggest to convert it to JMH and place it under `test/micro/org/openjdk/bench/tools/jar` directory.   I'm okay with or without it in this patch.

@LanceAndersen what's your opinion? I'm not totally sure of it's usefulness?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 18:19:32 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 18:19:32 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped
 content
Message-ID: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>

Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.

Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Commit messages:
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
 - 8276766: Enable jar and jmod to produce deterministic timestamped content

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276766
  Stats: 169 lines in 10 files changed: 141 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From lancea at openjdk.java.net  Fri Nov 19 18:29:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 18:29:11 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v4]
In-Reply-To: <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
Message-ID: <apg0cum_ymij31FybLDwPBaDxdMkd5jNxdIUUaWJQHs=.2fb4b75d-83e6-40b7-b730-53fa77b148f6@github.com>

On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use testng asserts
>  - Remove "final" usage from test

Hi Jaikiran,

I am OK with moving forward.  You might give it a couple more days before you push in the event we get additional feedback (realizing the PR has been open for a while)

Thank you for your efforts and patience on this.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5486

From lancea at openjdk.java.net  Fri Nov 19 18:36:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 18:36:09 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
Message-ID: <zYkrNiF3h8SUfpTzM8mjCgq5StBPEeSOladtVkFWERw=.189d6726-462e-462b-9e97-00ea3c2ba312@github.com>

On Fri, 19 Nov 2021 10:10:33 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The changes look OK. 

Have you run the JCK tests in addition to the Mach5 tests for the areas being changed to make sure we did not trip over a conformance test?

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Fri Nov 19 18:36:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 18:36:09 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <zYkrNiF3h8SUfpTzM8mjCgq5StBPEeSOladtVkFWERw=.189d6726-462e-462b-9e97-00ea3c2ba312@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <zYkrNiF3h8SUfpTzM8mjCgq5StBPEeSOladtVkFWERw=.189d6726-462e-462b-9e97-00ea3c2ba312@github.com>
Message-ID: <lu0hNi3fSJ7WO9Qy324uB1Wh3KA0MS1XKJXnZOGvA9w=.678a03e6-df88-4224-bac8-c259448626ba@github.com>

On Fri, 19 Nov 2021 18:30:17 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The changes look OK.
> 
> Have you run the JCK tests in addition to the Mach5 tests for the areas being changed to make sure we did not trip over a conformance test?

Sorry wrong PR window  please ignore this comment

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 18:36:11 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 18:36:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
 <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
Message-ID: <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>

On Fri, 19 Nov 2021 18:13:47 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> test/jdk/tools/jar/CreateJarBenchmark.java line 56:
>> 
>>> 54: import jdk.test.lib.util.FileUtils;
>>> 55: 
>>> 56: public class CreateJarBenchmark {
>> 
>> This is a benchmark which should not be run as regression testing.   I wonder if we need this benchmark for future use.  If so I would suggest to convert it to JMH and place it under `test/micro/org/openjdk/bench/tools/jar` directory.   I'm okay with or without it in this patch.
>
> @LanceAndersen what's your opinion? I'm not totally sure of it's usefulness?

My thought is to remove it from this PR, since we've already determined the change has little impact.
We can raise a new issue if we feel it's needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Fri Nov 19 18:36:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 18:36:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
 <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
 <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>
Message-ID: <HASEmQ8GHLa6JmAQd-zMMH3ZgKrF3O5ii4dJcqvygaM=.e84a1868-3664-4a59-a4e4-c9c96e4a6f86@github.com>

On Fri, 19 Nov 2021 18:30:37 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> @LanceAndersen what's your opinion? I'm not totally sure of it's usefulness?
>
> My thought is to remove it from this PR, since we've already determined the change has little impact.
> We can raise a new issue if we feel it's needed.

The benchmark should use JMH.  @cl4es, what are your thoughts here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From naoto at openjdk.java.net  Fri Nov 19 17:35:11 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Nov 2021 17:35:11 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <jTjoFY4oCoNDOgNM0rt_fpkqQY85C5b_0ICh2TgmE7Q=.b0a394df-7441-46bc-9580-2aeeb1cbdd98@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Do we want this option in `javac`/`javadoc`? Should `-J-Dfile.encoding=COMPAT` suffice the need?
I don't think `COMPAT` is an encoding name, but a valid value to the system property `file.encoding`. If we wanted to regard `COMPAT` as an encoding alias to the native encoding, I would expect `Charset.forName("COMPAT")` would have to be modified, but I don't think we would do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From lancea at openjdk.java.net  Fri Nov 19 18:41:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 18:41:09 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
Message-ID: <hQzAut9rSXIbz2mKRXKITvi8iLrV1cuiWZxgZRwz5Ck=.1d041707-e204-49fc-a643-b6d9efd2f54e@github.com>

On Fri, 19 Nov 2021 10:10:33 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

test/jdk/tools/jar/ContentOrder.java line 87:

> 85:         onCompletion = () -> rm("test.jar", "testjar");
> 86: 
> 87:         jar("cf test.jar testjar");

It might be worth testing with -C dir as well

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From mchung at openjdk.java.net  Fri Nov 19 18:59:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 18:59:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <HASEmQ8GHLa6JmAQd-zMMH3ZgKrF3O5ii4dJcqvygaM=.e84a1868-3664-4a59-a4e4-c9c96e4a6f86@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
 <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
 <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>
 <HASEmQ8GHLa6JmAQd-zMMH3ZgKrF3O5ii4dJcqvygaM=.e84a1868-3664-4a59-a4e4-c9c96e4a6f86@github.com>
Message-ID: <nbqEjgVO0j81848QjzyAulNUn-drKVNcOUUGcYhTHDg=.53272ec9-44b5-42c3-b9f7-07847cac42d0@github.com>

On Fri, 19 Nov 2021 18:33:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> My thought is to remove it from this PR, since we've already determined the change has little impact.
>> We can raise a new issue if we feel it's needed.
>
> The benchmark should use JMH.  @cl4es, what are your thoughts here?

> My thought is to remove it from this PR, since we've already determined the change has little impact.
We can raise a new issue if we feel it's needed.

This is fine with me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Fri Nov 19 19:13:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 19:13:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
Message-ID: <E0YP4wG4flsO19HiOC5gvFmg6tybtziFxQymyqbFmL4=.9ac14426-b7a2-4209-b8cd-a105115caa4d@github.com>

On Fri, 19 Nov 2021 10:10:33 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 812:

> 810:                     if (uflag) {
> 811:                         entryMap.put(name, e);
> 812:                     }

Thank you for cleaning up the if missing braces in this method.  Looks much better :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Fri Nov 19 19:13:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 19:13:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <nbqEjgVO0j81848QjzyAulNUn-drKVNcOUUGcYhTHDg=.53272ec9-44b5-42c3-b9f7-07847cac42d0@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
 <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
 <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>
 <HASEmQ8GHLa6JmAQd-zMMH3ZgKrF3O5ii4dJcqvygaM=.e84a1868-3664-4a59-a4e4-c9c96e4a6f86@github.com>
 <nbqEjgVO0j81848QjzyAulNUn-drKVNcOUUGcYhTHDg=.53272ec9-44b5-42c3-b9f7-07847cac42d0@github.com>
Message-ID: <AW2v8wJpjgQYRZuIp9VZ1mKFrq-DKxRxbrNs_6zosDU=.47b583bc-ec5b-4c7a-acf1-7d3d79ac3255@github.com>

On Fri, 19 Nov 2021 18:55:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The benchmark should use JMH.  @cl4es, what are your thoughts here?
>
>> My thought is to remove it from this PR, since we've already determined the change has little impact.
> We can raise a new issue if we feel it's needed.
> 
> This is fine with me.

I am Ok with separating this out as well but I think it would be nice to give Claes a chance to state his preference

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 20:15:54 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 20:15:54 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v4]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <V6ccpuEIlXTy61oSbXWPPJcL9hwFkqlRPuSjw_-SHj4=.94072531-6251-46f7-a287-f201350d12a2@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276764: Enable deterministic file content ordering for Jar and Jmod
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/c8d6e90d..23efb28c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=02-03

  Stats: 235 lines in 2 files changed: 40 ins; 193 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 20:15:57 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 20:15:57 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
Message-ID: <Rm-zInr6qypAPp_TCQ0ZeIrgmfyw9qcHhPWOuMzCoJQ=.d836f268-301d-487e-9941-654efe82ab05@github.com>

On Fri, 19 Nov 2021 17:27:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276764: Enable deterministic file content ordering for Jar and Jmod
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> The source change looks good.   I have a couple comments for the tests.

@mlchung Added -C and --release to tests, looks more complete now, thanks

> test/jdk/tools/jar/ContentOrder.java line 55:
> 
>> 53: import jdk.test.lib.util.FileUtils;
>> 54: 
>> 55: public class ContentOrder {
> 
> It'd be useful to include the test cases to verify the `--release` option with the specified files and directories as well.

added

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 20:16:02 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 20:16:02 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <hQzAut9rSXIbz2mKRXKITvi8iLrV1cuiWZxgZRwz5Ck=.1d041707-e204-49fc-a643-b6d9efd2f54e@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <hQzAut9rSXIbz2mKRXKITvi8iLrV1cuiWZxgZRwz5Ck=.1d041707-e204-49fc-a643-b6d9efd2f54e@github.com>
Message-ID: <gfWJqhXLoPKy4VpiXvwDrsiAOPGUvu5dkTFfVxvv-Kg=.11f3e64a-2729-487f-b767-47eeea76500e@github.com>

On Fri, 19 Nov 2021 18:38:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276764: Enable deterministic file content ordering for Jar and Jmod
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ContentOrder.java line 87:
> 
>> 85:         onCompletion = () -> rm("test.jar", "testjar");
>> 86: 
>> 87:         jar("cf test.jar testjar");
> 
> It might be worth testing with -C dir as well

added

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From lancea at openjdk.java.net  Fri Nov 19 20:29:11 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Nov 2021 20:29:11 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v4]
In-Reply-To: <V6ccpuEIlXTy61oSbXWPPJcL9hwFkqlRPuSjw_-SHj4=.94072531-6251-46f7-a287-f201350d12a2@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <V6ccpuEIlXTy61oSbXWPPJcL9hwFkqlRPuSjw_-SHj4=.94072531-6251-46f7-a287-f201350d12a2@github.com>
Message-ID: <WUsgi2lZRySIV8eEgiRO2tt4o5H_obLYYBX1PAvtDuk=.611e2dc9-3190-4d09-a26a-18bca9d4c9a1@github.com>

On Fri, 19 Nov 2021 20:15:54 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

The changes look good.

Could you please add a comment overviewing each test.  Thank you

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 20:30:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 20:30:12 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
Message-ID: <H-fnp3jxgvRE1nZyXeeywLrjkgYKey4-yRM0GnmDSp0=.17b8b3ef-5d71-4ef9-a803-5baad9d2c9a0@github.com>

On Fri, 19 Nov 2021 17:11:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276764: Enable deterministic file content ordering for Jar and Jmod
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/ContentOrder.java line 89:
> 
>> 87:         jar("cf test.jar testjar");
>> 88:         jar("tf test.jar");
>> 89:         println();
> 
> Suggestion:
> 
>         System.out.println(new String(baos.toByteArray()));
> 
> 
> You can simply print the output from `jar tf` command here and the `println` method isn't really needed.

done

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 20:30:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 20:30:12 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v3]
In-Reply-To: <AW2v8wJpjgQYRZuIp9VZ1mKFrq-DKxRxbrNs_6zosDU=.47b583bc-ec5b-4c7a-acf1-7d3d79ac3255@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <tY9eRxgBiwU5KOjMNkeY3qvHBB-hFoSGiqrPg9wk9HU=.12a24adc-a19d-4914-bd3f-cf0b6bd79f4e@github.com>
 <eYVtYW8-zdOEHzx5ka-HZiYyCRs_rL86gYuHlN-BnlE=.c9a1815b-6f65-4dec-a6f7-8987e647d61d@github.com>
 <uD1GBSM4_YjXtBdpkNeIapAy3ZhmXCqct0TdlgdrUoA=.f507fcfe-4ccc-4231-8bcc-c7892b06cbd2@github.com>
 <8ktxM8wSxDEhsI2lm2iz6jQJkA0E23eJuLWo6Xp76oc=.32a14bc7-7ba7-40ca-a257-f2716a125010@github.com>
 <HASEmQ8GHLa6JmAQd-zMMH3ZgKrF3O5ii4dJcqvygaM=.e84a1868-3664-4a59-a4e4-c9c96e4a6f86@github.com>
 <nbqEjgVO0j81848QjzyAulNUn-drKVNcOUUGcYhTHDg=.53272ec9-44b5-42c3-b9f7-07847cac42d0@github.com>
 <AW2v8wJpjgQYRZuIp9VZ1mKFrq-DKxRxbrNs_6zosDU=.47b583bc-ec5b-4c7a-acf1-7d3d79ac3255@github.com>
Message-ID: <hHN2Q3WXXgnssPM1foXw_DOqluTwI-0n20oeONQT59k=.5475505c-9084-406a-88e6-aa7db68673e4@github.com>

On Fri, 19 Nov 2021 19:08:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> My thought is to remove it from this PR, since we've already determined the change has little impact.
>> We can raise a new issue if we feel it's needed.
>> 
>> This is fine with me.
>
> I am Ok with separating this out as well but I think it would be nice to give Claes a chance to state his preference

Removed benchmark

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 21:25:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 21:25:43 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v5]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <xqd6yBAqTQkfh8nIzs4AB7QfyaakUmmkS_8f2yeaTOE=.447943fd-f945-4fe3-b87b-b8a30d780b96@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276764: Enable deterministic file content ordering for Jar and Jmod
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/23efb28c..18776eb3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=03-04

  Stats: 18 lines in 3 files changed: 18 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 21:25:44 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 21:25:44 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v4]
In-Reply-To: <WUsgi2lZRySIV8eEgiRO2tt4o5H_obLYYBX1PAvtDuk=.611e2dc9-3190-4d09-a26a-18bca9d4c9a1@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <V6ccpuEIlXTy61oSbXWPPJcL9hwFkqlRPuSjw_-SHj4=.94072531-6251-46f7-a287-f201350d12a2@github.com>
 <WUsgi2lZRySIV8eEgiRO2tt4o5H_obLYYBX1PAvtDuk=.611e2dc9-3190-4d09-a26a-18bca9d4c9a1@github.com>
Message-ID: <ITshxiNvjBkYZ-wmqq5XuNdjSoQKaIVW2su2x1Ii-8k=.32fd00f2-37f9-4d4c-b4e2-e8527388b266@github.com>

On Fri, 19 Nov 2021 20:25:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The changes look good.
> 
> Could you please add a comment overviewing each test. Thank you

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 21:25:45 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 21:25:45 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
Message-ID: <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>

On Thu, 18 Nov 2021 11:42:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> Just to verify, this test jar had 16000 files in a single directory? Since having 100 files in 160 directories would not have the same impact, right?
>> 
>> @magicus so the first test I did was 16,000 files in multiple directories, as I thought that was more representative, and would involve multiple small sorts vs one large sort.
>> I have just re-run the tests again, for both 16000 multi-dir and 16000 single dir, and the results are similar:
>> 16000 multi-dir x50:
>> Existing code: 291 seconds (variance: +/- 3 seconds)
>> New patch:  293 seconds (variance: +/- 3 seconds)
>> 16000 single-dir x50:
>> Existing code: 235 seconds (variance: +/- 3 seconds)
>> New patch: 237 seconds (variance: +/- 3 seconds)
>
> @andrew-m-leonard Thanks. I think that alleviates any fear of performance regression. Sounds like you are well within the span of normal variation.

@magicus I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From mchung at openjdk.java.net  Fri Nov 19 21:37:06 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 19 Nov 2021 21:37:06 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
 <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
Message-ID: <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>

On Fri, 19 Nov 2021 21:22:28 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>  I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?

The true source of the man pages are still kept in our closed repository.  The copy in the jdk repo is generated from our closed source and updated near the end of each release.    We should create a follow-up issue to update the man pages that perhaps Lance can help updating that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 21:59:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 21:59:10 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
 <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
 <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
Message-ID: <P8lLr8yJ3IZltjUrzclQTEgXj-UI59gQHpQHQasYoM8=.fda136c3-dc4d-4303-a308-960d26b36b37@github.com>

On Fri, 19 Nov 2021 21:33:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @magicus I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
>
>>  I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
> 
> The true source of the man pages are still kept in our closed repository.  The copy in the jdk repo is generated from our closed source and updated near the end of each release.    We should create a follow-up issue to update the man pages that perhaps Lance can help updating that.

@mlchung ah thanks Mandy, I didn't realize that. I'll remove from here and create a follow up once this is merged, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Fri Nov 19 22:04:47 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 19 Nov 2021 22:04:47 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v6]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276764: Enable deterministic file content ordering for Jar and Jmod
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/18776eb3..2a7668f1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=04-05

  Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From jpai at openjdk.java.net  Sat Nov 20 01:58:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 20 Nov 2021 01:58:54 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v5]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <bXA5CzmmBkUrtEe3R2v7xI-6BfzrcyZ_BaKbUdS0oi8=.2e86f5fe-32d4-4e94-b680-d5788c1dbc3d@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge latest from master branch
 - use testng asserts
 - Remove "final" usage from test
 - convert test to testng
 - Merge latest from master branch
 - Merge latest from master branch
 - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/2c0246f9..945fde6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=03-04

  Stats: 48509 lines in 1041 files changed: 34004 ins; 7147 del; 7358 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Sat Nov 20 01:58:56 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 20 Nov 2021 01:58:56 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v4]
In-Reply-To: <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <gIJ7qYv61DZJaoRs6s9wXQl49q8mjzTqb25UK2KC7NU=.85b2c1b3-c67e-465d-a1b6-9f78f015e16e@github.com>
Message-ID: <HM5BEqaKiQ3dZCt4m1ph-TgQeO9izMEfp6ruENEICt4=.662a197c-a163-4689-b18f-1060adbd4013@github.com>

On Fri, 5 Nov 2021 13:52:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use testng asserts
>  - Remove "final" usage from test

Hello Lance,

> Hi Jaikiran,
> 
> I am OK with moving forward. 

Thank you for the review.

> You might give it a couple more days before you push in the event we get additional feedback (realizing the PR has been open for a while)
> 
> Thank you for your efforts and patience on this.

Certainly. I won't integrate this until this next Tuesday. In the meantime, given that this has been open for a while now and new commits have made it to master, I will go ahead and merge the latest master changes just to be sure nothing surprisingly breaks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From darcy at openjdk.java.net  Sun Nov 21 20:21:10 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 21 Nov 2021 20:21:10 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v17]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <wGW7jmwR9jHOkOAhZOvEqQbI92F1w-DgVzqAg5ZrxX0=.bd44c91e-7210-4b6a-993b-85f095c70411@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 42 additional commits since the last revision:

 - Merge branch 'master' into JDK-8224922
 - Merge pull request #7 from lahodaj/JDK-8224922-5
   
   Fixing a test on Windows.
 - Attempting to fix a Windows test.
 - Merge pull request #6 from lahodaj/JDK-8224922-4
   
   Adding forgotten file/fixing test.
 - Adding forgotten file/fixing test.
 - Reflow paragraphs.
 - Fix spec typo; update copyrights.
 - Merge branch 'JDK-8224922' of https://github.com/jddarcy/jdk into JDK-8224922
 - Merge pull request #5 from lahodaj/JDK-8224922-3
   
   Adding tests for unnamed module/package and automatic modules.
 - Using a specific class file as the source.
 - ... and 32 more: https://git.openjdk.java.net/jdk/compare/63d998ea...55759b2f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/cd9f6bc5..55759b2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=15-16

  Stats: 6775 lines in 268 files changed: 5202 ins; 514 del; 1059 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Sun Nov 21 20:46:42 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 21 Nov 2021 20:46:42 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v18]
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <-2B4gSsM3so9CAUdruQfH2nAW45kzIOAvN9C5T8Hl1o=.ccdf9deb-050b-4e96-95c1-e52e331d37c3@github.com>

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5038/files
  - new: https://git.openjdk.java.net/jdk/pull/5038/files/55759b2f..ff1badbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5038&range=16-17

  Stats: 21 lines in 2 files changed: 2 ins; 1 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5038/head:pull/5038

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Sun Nov 21 20:46:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 21 Nov 2021 20:46:47 GMT
Subject: RFR: 8224922: Access JavaFileObject from Element(s) [v16]
In-Reply-To: <h0tab4mLfoNF6HSZQ_nhIFczIz89poXjAthJ6uww_H4=.55a9dd37-c746-4a20-ac81-807b95825414@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
 <TqBKK3mMVrnPAeYW7EylPiN22WUGRi4XypWna0GOaYo=.29cf8bcc-3afd-47e6-a823-6df2f485d74d@github.com>
 <h0tab4mLfoNF6HSZQ_nhIFczIz89poXjAthJ6uww_H4=.55a9dd37-c746-4a20-ac81-807b95825414@github.com>
Message-ID: <Zxgit91T0AhbaWJlky_RWdN28zAmYlmvrAK-wg-wJrk=.9d53d97e-4618-4c41-9b77-c1482a6bf133@github.com>

On Thu, 18 Nov 2021 19:28:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge pull request #7 from lahodaj/JDK-8224922-5
>>    
>>    Fixing a test on Windows.
>>  - Attempting to fix a Windows test.
>
> src/java.compiler/share/classes/javax/lang/model/element/package-info.java line 39:
> 
>> 37:  * anonymous classes.
>> 38:  *
>> 39:  * <p><a id="accurate_model">When used in the context of annotation processing, an accurate
> 
> It would be more correct to just put the id on the `<p>` tag and drop the `<a>`.

Fixed.

> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 798:
> 
>> 796:      * the creation of source or class files in that package.  An
>> 797:      * {@linkplain PackageElement#isUnnamed unnamed package} will have
>> 798:      * a null file since it cannot be declared in a compilation unit.
> 
> `{@code }` around  null ??

I'll fix these before pushing and do a follow-up pass over the API for consistent "null" vs "{@code null}" treatment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5038

From darcy at openjdk.java.net  Sun Nov 21 20:46:50 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 21 Nov 2021 20:46:50 GMT
Subject: Integrated: 8224922: Access JavaFileObject from Element(s)
In-Reply-To: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
References: <-2S0nPhqaIkkzWGXAHIEtC-N4iuSNTcP_cQuiIftg94=.0464d28b-413b-40ef-8871-15d5ef44f267@github.com>
Message-ID: <eOhoEVPlJkSbniHv8JujykZOgTgn200ydF_kMO-SES8=.b699e5bf-8b5d-4f88-b2e1-6b2ad7303fde@github.com>

On Fri, 6 Aug 2021 21:12:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Initial review to get some comments on the shape of the API. Tests are needed of course, as well as some tuning of the spec to better describe differences in behavior when class files rather than source files are the backing file type.

This pull request has now been integrated.

Changeset: 4ff43010
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ff43010bb3f92bd58f66be52a086b3d078b0cbb
Stats:     752 lines in 9 files changed: 730 ins; 0 del; 22 mod

8224922: Access JavaFileObject from Element(s)

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/5038

From jgneff at openjdk.java.net  Mon Nov 22 02:39:09 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Mon, 22 Nov 2021 02:39:09 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <CLFlvQzZlzZvNKKrmjAhRFRylqMrR5tXqypFJDhapEE=.39c98667-fe1e-4597-bff8-08d820063be4@github.com>

On Fri, 19 Nov 2021 16:52:36 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thank you for this timely pull request, Andrew! I need this pull request and also #6395 to [enable reproducible builds in JavaFX](https://github.com/openjdk/jfx/pull/446). I drove myself crazy this weekend with time zones, and if I understand your proposed changes correctly, it looks as if you're hitting the same problems as I did:

1. The [`SOURCE_DATE_EPOCH` environment variable](https://reproducible-builds.org/specs/source-date-epoch/) is defined as the number of **seconds** since the epoch of 1970-01-01T00:00:00Z, but the new command option is defined as the number of milliseconds. That makes it difficult to set `--source-date=$SOURCE_DATE_EPOCH` on the command line.

2. Calling the method `ZipEntry.setTime(long)` will not allow for reproducible builds when the builds run in different time zones.

For the second problem, run the included Java Time program as shown below:


$ javac Time.java 
$ echo $SOURCE_DATE_EPOCH
1637085342
$ date --date="@$SOURCE_DATE_EPOCH"
Tue 16 Nov 2021 09:55:42 AM PST
$ java Time
Build timestamp = 2021-11-16T17:55:42Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  FailsInNome.zip
  file last modified on (DOS date/time):          2021 Nov 16 08:55:42
Archive:  FailsInRome.zip
  file last modified on (DOS date/time):          2021 Nov 16 18:55:42
Archive:  WorksInNome.zip
  file last modified on (DOS date/time):          2021 Nov 16 17:55:42
Archive:  WorksInRome.zip
  file last modified on (DOS date/time):          2021 Nov 16 17:55:42


import java.io.FileOutputStream;
import java.io.IOException;
import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.temporal.ChronoUnit;
import java.util.TimeZone;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class Time {

    static void writeZipFile(String name, ZipEntry entry) throws IOException {
        var output = new ZipOutputStream(new FileOutputStream(name));
        output.putNextEntry(entry);
        output.closeEntry();
        output.close();
    }

    public static void main(String[] args) throws IOException {
        var instant = Instant.now().truncatedTo(ChronoUnit.SECONDS);
        var sourceDateEpoch = System.getenv("SOURCE_DATE_EPOCH");
        if (sourceDateEpoch != null) {
            long seconds = Long.parseLong(sourceDateEpoch);
            instant = Instant.ofEpochSecond(seconds);
        }
        System.out.println("Build timestamp = " + instant);

        var entry = new ZipEntry("Entry");

        long newTime = 1000 * instant.getEpochSecond();
        TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
        entry.setTime(newTime);
        writeZipFile("FailsInNome.zip", entry);
        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
        entry.setTime(newTime);
        writeZipFile("FailsInRome.zip", entry);

        var dosTime = LocalDateTime.ofInstant(instant, ZoneOffset.UTC);
        TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
        entry.setTimeLocal(dosTime);
        writeZipFile("WorksInNome.zip", entry);
        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
        entry.setTimeLocal(dosTime);
        writeZipFile("WorksInRome.zip", entry);
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From darcy at openjdk.java.net  Mon Nov 22 03:24:17 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 03:24:17 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19
Message-ID: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>

The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:

JDK-8277512: Add SourceVersion.RELEASE_19
https://bugs.openjdk.java.net/browse/JDK-8277512

JDK-8277514: Add source 19 and target 19 to javac
https://bugs.openjdk.java.net/browse/JDK-8277514

Clean local tier 1 test runs for langtools, jdk, and hotspot.

-------------

Commit messages:
 - Add --release 18 information. Good tier1 test results.
 - JDK-8273146: Start of release updates for JDK 19

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273146
  Stats: 3242 lines in 67 files changed: 3202 ins; 0 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From dholmes at openjdk.java.net  Mon Nov 22 04:21:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 22 Nov 2021 04:21:07 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <n0t8ZVyYoTEapIaMkBplDKzHUl4h5CdnWQ555tJc3vw=.b932037e-2fe3-429f-a395-ed6d437e658a@github.com>

On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Hi Joe,

I looked at all the non-sym file changes. Only one potential issue spotted.

Thanks,
David

test/langtools/tools/javac/versions/Versions.java line 91:

> 89:         SEVENTEEN(false, "61.0", "17", Versions::checksrc17),
> 90:         EIGHTEEN(false,  "62.0", "18", Versions::checksrc18),
> 91:         NINETEEN(false,  "63.0", "19", Versions::checksrc18);

checkSrc19?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From darcy at openjdk.java.net  Mon Nov 22 04:30:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 04:30:38 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/5052cd90..4da056ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From darcy at openjdk.java.net  Mon Nov 22 04:30:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 04:30:40 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <n0t8ZVyYoTEapIaMkBplDKzHUl4h5CdnWQ555tJc3vw=.b932037e-2fe3-429f-a395-ed6d437e658a@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <n0t8ZVyYoTEapIaMkBplDKzHUl4h5CdnWQ555tJc3vw=.b932037e-2fe3-429f-a395-ed6d437e658a@github.com>
Message-ID: <8ZLnKB6sQq4VRcomQVUkCk8QAD_w7dDk3REQYFEWiPk=.4d2b9116-3eab-48a9-bc94-f1df6d0becf2@github.com>

On Mon, 22 Nov 2021 04:17:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Joe,
> 
> I looked at all the non-sym file changes. Only one potential issue spotted.
> 
> Thanks, David

*sigh* Yep; cut and paste error -- corrected in next push. Well spotted!

Thanks David

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From dholmes at openjdk.java.net  Mon Nov 22 04:35:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 22 Nov 2021 04:35:06 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
Message-ID: <w1RgGQWNn6gWahGhN-X9nEMSq45I9xQgG-k7ocHhpUw=.986e3994-4b9f-406a-ae30-ccbc2b3d9d83@github.com>

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Update looks good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6493

From darcy at openjdk.java.net  Mon Nov 22 07:05:26 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 07:05:26 GMT
Subject: RFR: JDK-8277522: Make formatting of null consistent in Elements
Message-ID: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>

Simple formatting cleanup.

-------------

Commit messages:
 - JDK-8277522: Make formatting of null consistent in Elements

Changes: https://git.openjdk.java.net/jdk/pull/6494/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6494&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277522
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6494.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6494/head:pull/6494

PR: https://git.openjdk.java.net/jdk/pull/6494

From jlahoda at openjdk.java.net  Mon Nov 22 07:29:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 22 Nov 2021 07:29:08 GMT
Subject: RFR: JDK-8277522: Make formatting of null consistent in Elements
In-Reply-To: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
References: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
Message-ID: <hc2DUxEhtvwHNsrLoOQDv6PVzdHVS43S2kOBjlhgUZ0=.704c9701-cd1c-4211-8c77-f4d497be4ac4@github.com>

On Mon, 22 Nov 2021 06:59:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple formatting cleanup.

Looks good.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6494

From alanb at openjdk.java.net  Mon Nov 22 08:35:11 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 22 Nov 2021 08:35:11 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v5]
In-Reply-To: <bXA5CzmmBkUrtEe3R2v7xI-6BfzrcyZ_BaKbUdS0oi8=.2e86f5fe-32d4-4e94-b680-d5788c1dbc3d@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <bXA5CzmmBkUrtEe3R2v7xI-6BfzrcyZ_BaKbUdS0oi8=.2e86f5fe-32d4-4e94-b680-d5788c1dbc3d@github.com>
Message-ID: <ZnDceF5VRSU9DNw8V5AFqpEBNXxDPMczlWTGzA_zSII=.4a774a41-c938-46b8-88af-8dc3eccd5ee0@github.com>

On Sat, 20 Nov 2021 01:58:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - use testng asserts
>  - Remove "final" usage from test
>  - convert test to testng
>  - Merge latest from master branch
>  - Merge latest from master branch
>  - 8258117: jar tool sets the time stamp of module-info.class entries to the current time

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 806:

> 804:                     Long lastModified = f.lastModified() == 0 ? null : f.lastModified();
> 805:                     moduleInfos.putIfAbsent(name,
> 806:                             new StreamedModuleInfoEntry(name, Files.readAllBytes(f.toPath()), lastModified));

I'd prefer to see this split into two two statements as there is just too much going on one the one line.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1785:

> 1783:         private final String name;
> 1784:         private final byte[] bytes;
> 1785:         private final Long lastModifiedTime;

It might be better to use a FileTime here, otherwise we risk a NPE when unboxing.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2108:

> 2106:             byte[] extended = extendedInfoBytes(md, bytes, packages);
> 2107:             // replace the entry value with the extended bytes
> 2108:             e.setValue(new StreamedModuleInfoEntry(e.getValue().name(), extended, e.getValue().getLastModifiedTime()));

There are 3 calls to getValue and each one I need to remember that e.getValue is a ModuleInfoEntry. If you add ModuleInfo entry = e.getValue() then it might help the readability.

test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java line 60:

> 58:     private static final String UPDATED_MODULE_VERSION = "1.2.4";
> 59:     private static final String MAIN_CLASS = "jdk.test.foo.Foo";
> 60:     private static final Path MODULE_CLASSES_DIR = Paths.get("8258117-module-classes", MODULE_NAME).toAbsolutePath();

You can use Path.of here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From alanb at openjdk.java.net  Mon Nov 22 08:54:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 22 Nov 2021 08:54:10 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
Message-ID: <6sXuvGqJ3j3740KAGE51lv-ipw4SqQauMQxOFXeXabc=.617dd6c0-4bde-47ae-903d-859fd59c1339@github.com>

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

It's not possible to manual review the sym files but everything else looks okay. I searched the test tree for any additional tests that might need updating but didn't spot any.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6493

From jpai at openjdk.java.net  Mon Nov 22 09:13:43 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 22 Nov 2021 09:13:43 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v6]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <K2YhGyERMRE1Tkn5nHkm2Uimh_0Zukt-_AaXkjpqSkY=.7df422f1-c061-440a-8243-e9fe9702a16d@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - review suggestion - use FileTime instead of Long to prevent any potential NPEs during unboxing
 - review suggestion - split into multiple statements to make it easily readable
 - review suggestion - Use Path.of instead of Paths.get in testcase
 - review suggestion - store e.getValue() and reuse the stored value

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/945fde6f..8ff75835

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=04-05

  Stats: 21 lines in 2 files changed: 3 ins; 1 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Mon Nov 22 09:13:54 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 22 Nov 2021 09:13:54 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v5]
In-Reply-To: <ZnDceF5VRSU9DNw8V5AFqpEBNXxDPMczlWTGzA_zSII=.4a774a41-c938-46b8-88af-8dc3eccd5ee0@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <bXA5CzmmBkUrtEe3R2v7xI-6BfzrcyZ_BaKbUdS0oi8=.2e86f5fe-32d4-4e94-b680-d5788c1dbc3d@github.com>
 <ZnDceF5VRSU9DNw8V5AFqpEBNXxDPMczlWTGzA_zSII=.4a774a41-c938-46b8-88af-8dc3eccd5ee0@github.com>
Message-ID: <AvNZ3BhBe5tKgx89tYAIaG07IRGFXYh18RmGeVrwEGM=.6ca07505-614f-4e2a-bfbc-627c473da71b@github.com>

On Mon, 22 Nov 2021 08:25:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge latest from master branch
>>  - use testng asserts
>>  - Remove "final" usage from test
>>  - convert test to testng
>>  - Merge latest from master branch
>>  - Merge latest from master branch
>>  - 8258117: jar tool sets the time stamp of module-info.class entries to the current time
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 806:
> 
>> 804:                     Long lastModified = f.lastModified() == 0 ? null : f.lastModified();
>> 805:                     moduleInfos.putIfAbsent(name,
>> 806:                             new StreamedModuleInfoEntry(name, Files.readAllBytes(f.toPath()), lastModified));
> 
> I'd prefer to see this split into two two statements as there is just too much going on one the one line.

Done. I have updated the PR to split this line into more than 1 statement.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1785:
> 
>> 1783:         private final String name;
>> 1784:         private final byte[] bytes;
>> 1785:         private final Long lastModifiedTime;
> 
> It might be better to use a FileTime here, otherwise we risk a NPE when unboxing.

Sounds good. I've updated the PR to replace this to use `FileTime`.

> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2108:
> 
>> 2106:             byte[] extended = extendedInfoBytes(md, bytes, packages);
>> 2107:             // replace the entry value with the extended bytes
>> 2108:             e.setValue(new StreamedModuleInfoEntry(e.getValue().name(), extended, e.getValue().getLastModifiedTime()));
> 
> There are 3 calls to getValue and each one I need to remember that e.getValue is a ModuleInfoEntry. If you add ModuleInfo entry = e.getValue() then it might help the readability.

That makes sense. The updated PR now has this change.

> test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java line 60:
> 
>> 58:     private static final String UPDATED_MODULE_VERSION = "1.2.4";
>> 59:     private static final String MAIN_CLASS = "jdk.test.foo.Foo";
>> 60:     private static final Path MODULE_CLASSES_DIR = Paths.get("8258117-module-classes", MODULE_NAME).toAbsolutePath();
> 
> You can use Path.of here.

Done. Replaced this and one other place in this test to use `Path.of`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Mon Nov 22 09:13:56 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 22 Nov 2021 09:13:56 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v5]
In-Reply-To: <AvNZ3BhBe5tKgx89tYAIaG07IRGFXYh18RmGeVrwEGM=.6ca07505-614f-4e2a-bfbc-627c473da71b@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <bXA5CzmmBkUrtEe3R2v7xI-6BfzrcyZ_BaKbUdS0oi8=.2e86f5fe-32d4-4e94-b680-d5788c1dbc3d@github.com>
 <ZnDceF5VRSU9DNw8V5AFqpEBNXxDPMczlWTGzA_zSII=.4a774a41-c938-46b8-88af-8dc3eccd5ee0@github.com>
 <AvNZ3BhBe5tKgx89tYAIaG07IRGFXYh18RmGeVrwEGM=.6ca07505-614f-4e2a-bfbc-627c473da71b@github.com>
Message-ID: <twK8U3kWJFPiV6HfQYFa2QGXVgmHlp1aeelyIxHCtoM=.1757d430-99e9-4276-9645-7b5368315856@github.com>

On Mon, 22 Nov 2021 09:09:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java line 60:
>> 
>>> 58:     private static final String UPDATED_MODULE_VERSION = "1.2.4";
>>> 59:     private static final String MAIN_CLASS = "jdk.test.foo.Foo";
>>> 60:     private static final Path MODULE_CLASSES_DIR = Paths.get("8258117-module-classes", MODULE_NAME).toAbsolutePath();
>> 
>> You can use Path.of here.
>
> Done. Replaced this and one other place in this test to use `Path.of`.

Test continues to pass with all these new changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From jlahoda at openjdk.java.net  Mon Nov 22 10:13:23 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 22 Nov 2021 10:13:23 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v5]
In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
Message-ID: <Su8OEcEgzCwcszftLBKrohNvh1JGGk0aoFsPBbuVH_k=.5b01ff98-19ba-4d9f-aeb1-b895f3cda4bd@github.com>

> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.
> 
> Any feedback on this prototype would be welcome.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Test cleanup.
 - Merge branch 'ap-keep-originating-elements' into ap-keep-originating-elements-forwarding-tweak
 - Cleanup
 - Merge branch 'master' into ap-keep-originating-elements
 - Fixing test (need to exclude a private method from the test).
 - Fixing typo, as per review comments.
 - Fixing javadoc.
 - Cleanup.
 - Attempting to improve compatibility with existing subclasses of ForwardingJavaFileManager
 - Javadoc improvements.
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/ca31ed53...da4781a9

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5076/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=04
  Stats: 722 lines in 7 files changed: 712 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076

PR: https://git.openjdk.java.net/jdk/pull/5076

From lancea at openjdk.java.net  Mon Nov 22 13:51:22 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 22 Nov 2021 13:51:22 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v6]
In-Reply-To: <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>
Message-ID: <BrLfN7FAPKoL0dQrzOL6DL7tcw0s5A8zICLbl7ueSJg=.8cfdbeab-7fa1-4c97-958f-02abb204a6d9@github.com>

On Fri, 19 Nov 2021 22:04:47 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Changes look fine.

I can run the changes through mach5 tiers 1  - 3 for you.  Let me know

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From erikj at openjdk.java.net  Mon Nov 22 14:03:20 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 22 Nov 2021 14:03:20 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
Message-ID: <a7pr0fggKdN2YVIeMhCCOQP_0lysx0RhHUHjnV_d7so=.008f4eb6-722c-4c19-a1ed-f078d57b8524@github.com>

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From jpai at openjdk.java.net  Mon Nov 22 14:37:47 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 22 Nov 2021 14:37:47 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v7]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <ykusHnoW4aWR8SuDt4jdAqlgaAGoZYy3IxjU1P4F0jI=.44315c2e-f036-4911-be65-77853bbfaf4c@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use proper FileTime centric APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/8ff75835..9ab5ad8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=05-06

  Stats: 12 lines in 1 file changed: 1 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From dfuchs at openjdk.java.net  Mon Nov 22 15:00:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Nov 2021 15:00:32 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v6]
In-Reply-To: <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>
Message-ID: <d-FehcWQqOq1w_ZtjPVgcyhnz3hhvcTlhjOjOPVaxbA=.d36f230e-b9b9-4894-84d5-e20f37b02921@github.com>

On Fri, 19 Nov 2021 22:04:47 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 772:

> 770:             // Keep a sorted set of files to be processed, so that the jmod
> 771:             // content is reproducible as Files.walkFileTree order is not defined
> 772:             SortedMap<String, Path> filesToProcess  = new TreeMap<String, Path>();

Nit: there seems to be two whitespaces (instead of one) before the `=` sign on this line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From itakiguchi at openjdk.java.net  Mon Nov 22 16:16:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:16:26 GMT
Subject: RFR: 8274544: Langtools command's usage were garbled on Japanese
 Windows [v5]
In-Reply-To: <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
 <PsGdqvacmF-NFuCXS8PKK3jObMymr9rBevrLCsIASw0=.3618fd46-1ef2-45a6-9c7c-bbffb58bccf1@github.com>
 <9YgpGI3xitbwet8VhZ7g5HOW5jMqyUQFApYwqwGs9Wc=.ede84eb4-67ee-4503-9060-dcf4f1e622be@github.com>
 <3zQ6qYDHh9mxWcS86kifh5L2NwXUR-EKc5k6SnqkD5I=.b5f0ec9a-fe26-420d-96c1-d06032d37191@github.com>
 <7JYAnqIv4UFGDCnbFtovQrkFC-jUUmRPLrUfQsJn1po=.66ad8156-f70f-4ebe-8bc0-2a1ee8a6b1af@github.com>
Message-ID: <qtzbWJL3pfQnTa8FlearwmbutzMqsxIvTgpI4OnTyIw=.4bbca3e1-75f4-444e-b8a8-5475a57ba4a7@github.com>

On Fri, 19 Nov 2021 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> For PrintStream.getCharset(), following changes may be required.
>> 
>> +++ src/java.base/share/classes/java/io/OutputStreamWriter.java
>> +    Charset getCharset() {
>> +        return se.getCharset();
>> +    }
>> 
>> +++ src/java.base/share/classes/java/io/PrintStream.java
>> +    public Charset getCharset() {
>> +        return charOut.getCharset();
>> +    }
>> 
>> +++ src/java.base/share/classes/sun/nio/cs/StreamEncoder.java
>> +    public Charset getCharset() {
>> +        return cs;
>> +    }
>> 
>> For javac code, we may not use PrintStream.getCharset() directly because javac code is compiled by boot compiler.
>> We need to use reflection, like:
>> 
>> +++ src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java
>> +    private static Charset getCharset(PrintStream ps) {
>> +        try {
>> +            Method getCharset = PrintStream.class.getDeclaredMethod("getCharset");
>> +            return (Charset)getCharset.invoke(ps);
>> +        } catch (Exception e) {
>> +            return Charset.defaultCharset();
>> +        }
>> +    }
>> 
>> If we add following constructors against PrintWriter, we just change javap and jshell code.
>> But I cannot evaluate this code changes.
>> 
>> +++ src/java.base/share/classes/java/io/PrintWriter.java
>> +    public PrintWriter(PrintStream ps) {
>> +       this((OutputStream)ps, false, ps.getCharset());
>> +    }
>> +    public PrintWriter(PrintStream ps, boolean autoFlush) {
>> +       this((OutputStream)ps, autoFlush, ps.getCharset());
>> +    }
>> 
>> I really appreciate if you handle this kind of code change via JEP-400.
>
> I think this PR can now safely be withdrawn, as https://github.com/openjdk/jdk/pull/6401 is now integrated. @takiguc, if you do not mind, I will create a PR for the remaining jshell issue. Please let me know.

Thanks @naotoj .
I opened new pr via 8274784.
I'd like to close this pr since main issue was fixed by #6401.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From itakiguchi at openjdk.java.net  Mon Nov 22 16:16:26 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:16:26 GMT
Subject: Withdrawn: 8274544: Langtools command's usage were garbled on Japanese
 Windows
In-Reply-To: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
References: <C1RvS3vmY2hWJXeCpt5rgNUrKvf_tALIFjhDKVve8hY=.b0fbf30c-7d61-46d1-939c-ff67ab89f15d@github.com>
Message-ID: <kdA1hd2YKY1fqDH7n4kConX9tEu5do7J326l8JGIikk=.a4cfb71c-bf68-469b-9209-ebcfd6252777@github.com>

On Thu, 30 Sep 2021 09:36:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> JEP-400 (UTF-8 by Default) was eabled on JDK18-b13.
> After JDK18-b13, javac and some other langtool command's usage were garbled on Japanese Windows.
> These commands use PrintWriter instead of standard out/err with PrintStream.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5771

From itakiguchi at openjdk.java.net  Mon Nov 22 16:23:19 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 22 Nov 2021 16:23:19 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <IffFJlk85Md1HYFLR2PVepQZw9_Br4zKwMbKvBQzaIQ=.60fd962a-cc2a-43f0-943f-cf245f8a41b6@github.com>

On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Thanks @AlanBateman and @naotoj .
I appreciate your good suggestions.
My consideration was not enough.
I think this issue should be handle via Charset alias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From darcy at openjdk.java.net  Mon Nov 22 17:03:56 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 17:03:56 GMT
Subject: RFR: JDK-8277522: Make formatting of null consistent in Elements
 [v2]
In-Reply-To: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
References: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
Message-ID: <qSZLlDZQYDFOByLearJB-9oP53YLJWgrxBsik-dHIMw=.4fbcc532-e82e-44a6-aa90-890962c6553f@github.com>

> Simple formatting cleanup.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Reflow paragraphs.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6494/files
  - new: https://git.openjdk.java.net/jdk/pull/6494/files/b94c5095..929c63df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6494&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6494&range=00-01

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6494.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6494/head:pull/6494

PR: https://git.openjdk.java.net/jdk/pull/6494

From darcy at openjdk.java.net  Mon Nov 22 17:03:58 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 22 Nov 2021 17:03:58 GMT
Subject: Integrated: JDK-8277522: Make formatting of null consistent in
 Elements
In-Reply-To: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
References: <_D6Dswe8xjOBYJYWQtInq1qkg7MlSBBRA1O9FxaR-DU=.703e7566-e134-4513-8bf6-26010b60f999@github.com>
Message-ID: <2cFGiQyFZQDnAfqCYXg39-V1DXUZ7PSktn7jVRMNmj4=.0313ae79-8c36-4b2b-a65a-83e5843c36c8@github.com>

On Mon, 22 Nov 2021 06:59:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple formatting cleanup.

This pull request has now been integrated.

Changeset: 22f12ac4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22f12ac429fbbf134d182d9bf2a16a3d43bc71e1
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8277522: Make formatting of null consistent in Elements

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/6494

From iris at openjdk.java.net  Mon Nov 22 17:38:19 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 22 Nov 2021 17:38:19 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
Message-ID: <pbvOUyl7XjLoZiPOIW9aCROBkiyikAbPUfbsGpDBsd0=.297cb5f7-4631-4ffb-a075-c601dfbc6975@github.com>

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From cushon at google.com  Mon Nov 22 18:13:08 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 22 Nov 2021 10:13:08 -0800
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <CAL4Qsgsh_r5Asa8cW1vJcnHt_isxRmt+Z-j=zXrQ15hM2ErDNg@mail.gmail.com>
References: <CAL4Qsgsh_r5Asa8cW1vJcnHt_isxRmt+Z-j=zXrQ15hM2ErDNg@mail.gmail.com>
Message-ID: <CAL4Qsgs+az3fyoASZD7HnpKw0T0_apJjV6zP-3nOaNowYbs--A@mail.gmail.com>

>
> Is anyone from the compiler group interested in reviewing the fix for
> JDK-8271623?


Bump, is anyone interested in reviewing this patch?

On Fri, Nov 12, 2021 at 10:32 AM Liam Miller-Cushon <cushon at google.com>
wrote:

> Hello,
>
> Is anyone from the compiler group interested in reviewing the fix for
> JDK-8271623?
>
> There was some previous discussion about the change on amber-spec-experts
> [1][2], I should have added compiler-dev@ sooner.
>
> The idea is to omit the synthetic field that holds a reference to the
> enclosing instance of an inner class if the inner class doesn't capture any
> state from its enclosing instance. This avoids a potential memory leak, and
> reduces the footprint of the inner class.
>
> The optimization is currently implemented by adding logic to Lower to
> track whether the symbol for the enclosing instance field is actually used
> when generating code for the inner class, and generating the declaration
> and initialization of the field only if it is used.
>
> [1]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-July/003061.html
> [2]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-August/003064.html
>
> review: https://git.openjdk.java.net/jdk/pull/4966
> bug: https://bugs.openjdk.java.net/browse/JDK-8271623
> CSR: https://bugs.openjdk.java.net/browse/JDK-8271717
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211122/ba719fd7/attachment.htm>

From vromero at openjdk.java.net  Mon Nov 22 21:18:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 22 Nov 2021 21:18:07 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
Message-ID: <nmbOvSj6xZrr5haEIIdwXgl3rsNErzLkE-JQcXRztqs=.0769f4c7-462b-41ea-8db7-cb18e3128194@github.com>

On Mon, 15 Nov 2021 20:18:06 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java line 210:

> 208:      * instance state.
> 209:      */
> 210:     public boolean omitUnusedPrivateSyntheticEnclosingInstanceFields() {

nit: what about a shorter name for this one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From mikael at openjdk.java.net  Mon Nov 22 21:27:07 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Mon, 22 Nov 2021 21:27:07 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]
In-Reply-To: <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <zplAhNz-mw6ctIrtqDGPp0oOQHSjlmD6U9qBU8jQxVQ=.17c3a544-9ea1-4dc2-b217-9e4d507074fe@github.com>
Message-ID: <WEew0X240YNMoxrqN2nbiiw20V0Xiwy3InH0ZpfGZrQ=.222eb722-9a54-4a5e-babb-3726025c96f3@github.com>

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From vromero at openjdk.java.net  Mon Nov 22 21:50:19 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 22 Nov 2021 21:50:19 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
Message-ID: <k8IaZj2Q3_7jPxjlU3Xsu9j-sVbCgfBcyQes3KD9zXg=.b5bf0aee-d080-4dcf-8142-5f3c721b4470@github.com>

On Mon, 15 Nov 2021 20:18:06 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

made a first review of the code, looks good, still I would like to give another pass on it. Comment, do you still need to force the access to the outer class in all the test cases or does it make sense to provide a new golden file for some of them when applicable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 22 21:54:10 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 22 Nov 2021 21:54:10 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <nmbOvSj6xZrr5haEIIdwXgl3rsNErzLkE-JQcXRztqs=.0769f4c7-462b-41ea-8db7-cb18e3128194@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
 <nmbOvSj6xZrr5haEIIdwXgl3rsNErzLkE-JQcXRztqs=.0769f4c7-462b-41ea-8db7-cb18e3128194@github.com>
Message-ID: <pLATF7OM7P6UoZ-YgUyo1MyOQxvzEQmxP7_aE9H9Rqw=.4d05327e-69b0-48d5-acd5-add58d40fe5c@github.com>

On Mon, 22 Nov 2021 21:14:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>>  - Enable enclosing instance optimization for --release 18 and newer
>>  - Add a test case with nested inner classes
>>  - 8271623: Omit enclosing instance fields from inner classes that don't use it
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java line 210:
> 
>> 208:      * instance state.
>> 209:      */
>> 210:     public boolean omitUnusedPrivateSyntheticEnclosingInstanceFields() {
> 
> nit: what about a shorter name for this one?

SGTM, maybe `optimizeOuterThis`? I'm open to suggestions :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From jlahoda at openjdk.java.net  Mon Nov 22 22:01:16 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 22 Nov 2021 22:01:16 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
Message-ID: <RG4G2s5VKO3Mgfw8oAM9brSDKyzeFoRD0R3KMNFwEKU=.11cc020f-13c2-4f8a-8ae8-4613cc15869d@github.com>

On Mon, 15 Nov 2021 20:18:06 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

I think overall it seems sensible. Regarding compatibility impact, I'd suggest to make sure it is understood (e.g. in the release notes) the behavior may be altered by instances being GCed sooner. (While it typically may be desirable, it might cause issues for some.)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2251:

> 2249: 
> 2250:            for (JCTree def : tree.defs) {
> 2251:                 if (!TreeInfo.isInitialConstructor(def)) {

Nit: given the rest of the for loop is fairly short, I'd recommend to consider not using a negation, but rather doing the work inside the if. (Although, this may be a personal preference, so only for consideration.) I.e. something like:

          for (JCTree def : tree.defs) {
                if (TreeInfo.isInitialConstructor(def)) {
                    JCMethodDecl mdef = (JCMethodDecl) def;
                    mdef.body.stats = mdef.body.stats.prepend(
                        initOuterThis(mdef.body.pos, mdef.params.head.sym));
                }
            }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 22 22:33:48 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 22 Nov 2021 22:33:48 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v5]
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <d4F2pdzRGIoIt8GmByrv40steGqb9Uf6aHd6Nrz9f9k=.2bca3575-a9b4-4455-be34-8e70d1ee43ff@github.com>

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

Liam Miller-Cushon has updated the pull request incrementally with three additional commits since the last revision:

 - Negate condition inside loop
 - Clean up tests
 - Use a shorter name for Target setting

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4966/files
  - new: https://git.openjdk.java.net/jdk/pull/4966/files/f90c7560..0ebe65ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=03-04

  Stats: 83 lines in 11 files changed: 10 ins; 49 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 22 22:33:49 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 22 Nov 2021 22:33:49 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <k8IaZj2Q3_7jPxjlU3Xsu9j-sVbCgfBcyQes3KD9zXg=.b5bf0aee-d080-4dcf-8142-5f3c721b4470@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
 <k8IaZj2Q3_7jPxjlU3Xsu9j-sVbCgfBcyQes3KD9zXg=.b5bf0aee-d080-4dcf-8142-5f3c721b4470@github.com>
Message-ID: <ZyU6dL5NE79pxfm3rm5R4EkVU4AioQB6lHqferWYUJc=.5e5990d2-7b9e-4405-83d7-5c6574d4a7ec@github.com>

On Mon, 22 Nov 2021 21:47:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> do you still need to force the access to the outer class in all the test cases or does it make sense to provide a new golden file for some of them when applicable?

Thanks @vicente-romero-oracle for taking a first pass! For the tests that are about details of inner and outer classes, I wanted to make sure I didn't regress coverage for anything that was specifically testing `this$`. Taking another pass over the tests, I think for most of the `attributes/Synthetic` tests it makes more sense to just update the assertions. Let me know if you see any others where there's a better fix than adding an explicit enclosing instance reference, and I'm happy to update them also.

> I think overall it seems sensible. Regarding compatibility impact, I'd suggest to make sure it is understood (e.g. in the release notes) the behavior may be altered by instances being GCed sooner. (While it typically may be desirable, it might cause issues for some.)

@lahodaj Thanks! I created the sub-task for the release notes and added a note there as a reminder to mention that: https://bugs.openjdk.java.net/browse/JDK-8277604

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Mon Nov 22 22:33:57 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 22 Nov 2021 22:33:57 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v4]
In-Reply-To: <RG4G2s5VKO3Mgfw8oAM9brSDKyzeFoRD0R3KMNFwEKU=.11cc020f-13c2-4f8a-8ae8-4613cc15869d@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <b-hG86XzIDGCmYszd4VUcb_oSER0ZcAAxTFvlmeWS5E=.a61f4d76-ceee-46cf-b5e9-04197919b34e@github.com>
 <RG4G2s5VKO3Mgfw8oAM9brSDKyzeFoRD0R3KMNFwEKU=.11cc020f-13c2-4f8a-8ae8-4613cc15869d@github.com>
Message-ID: <lgIeompXNfuio83Li1R64yO61uNjfNbrm2seSL2HXCQ=.6afba979-8709-4dd1-83fc-bd8b664f5ba3@github.com>

On Mon, 22 Nov 2021 21:54:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>>  - Enable enclosing instance optimization for --release 18 and newer
>>  - Add a test case with nested inner classes
>>  - 8271623: Omit enclosing instance fields from inner classes that don't use it
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2251:
> 
>> 2249: 
>> 2250:            for (JCTree def : tree.defs) {
>> 2251:                 if (!TreeInfo.isInitialConstructor(def)) {
> 
> Nit: given the rest of the for loop is fairly short, I'd recommend to consider not using a negation, but rather doing the work inside the if. (Although, this may be a personal preference, so only for consideration.) I.e. something like:
> 
>           for (JCTree def : tree.defs) {
>                 if (TreeInfo.isInitialConstructor(def)) {
>                     JCMethodDecl mdef = (JCMethodDecl) def;
>                     mdef.body.stats = mdef.body.stats.prepend(
>                         initOuterThis(mdef.body.pos, mdef.params.head.sym));
>                 }
>             }

Done, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From darcy at openjdk.java.net  Tue Nov 23 05:37:13 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 23 Nov 2021 05:37:13 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v5]
In-Reply-To: <Su8OEcEgzCwcszftLBKrohNvh1JGGk0aoFsPBbuVH_k=.5b01ff98-19ba-4d9f-aeb1-b895f3cda4bd@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
 <Su8OEcEgzCwcszftLBKrohNvh1JGGk0aoFsPBbuVH_k=.5b01ff98-19ba-4d9f-aeb1-b895f3cda4bd@github.com>
Message-ID: <hfApY6A2sDwjhBGpyy5QMt7PKtQTodDe_roKx7PcVjo=.087f6da3-28c1-40b9-9534-da76c4c1deca@github.com>

On Mon, 22 Nov 2021 10:13:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.
>> 
>> Any feedback on this prototype would be welcome.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Test cleanup.
>  - Merge branch 'ap-keep-originating-elements' into ap-keep-originating-elements-forwarding-tweak
>  - Cleanup
>  - Merge branch 'master' into ap-keep-originating-elements
>  - Fixing test (need to exclude a private method from the test).
>  - Fixing typo, as per review comments.
>  - Fixing javadoc.
>  - Cleanup.
>  - Attempting to improve compatibility with existing subclasses of ForwardingJavaFileManager
>  - Javadoc improvements.
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/ca31ed53...da4781a9

src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 381:

> 379:                                         String className,
> 380:                                         Kind kind,
> 381:                                         FileObject... originatingFiles)

Perhaps explicitly state that null originatingFile or empty originatingFiles are no-ops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5076

From gli at openjdk.java.net  Tue Nov 23 06:30:08 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Tue, 23 Nov 2021 06:30:08 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
Message-ID: <lwysohUZ7WNs6pyXJPHsKuNJ4DX0WRw09kOC8bdp2Ak=.0e972dc1-1a6a-4e23-a0cf-4141122de196@github.com>

On Thu, 11 Nov 2021 13:47:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `Gen#visitSwitchExpression` would switch code generation off by using the method `Code#markDead` when it meets the code like `throw new RuntimeException()`. Then the method `Gen#completeBinop` won't generate the expected code and wiil let the left operand stay in the stack without handling it.
> 
> This patch pops the left operand from the stack to solve this issue. And the corresponding test is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Ping for review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6350

From aleonard at openjdk.java.net  Tue Nov 23 10:04:51 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 10:04:51 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v7]
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <CuJt1Pm9mR6N4ckPzRq9e-nWcgqq4H7cJvqfrxliImA=.8d65e75d-7ec8-4cf8-97f2-9cf55799e099@github.com>

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276764: Enable deterministic file content ordering for Jar and Jmod
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6395/files
  - new: https://git.openjdk.java.net/jdk/pull/6395/files/2a7668f1..58772b58

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6395&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6395.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6395/head:pull/6395

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Tue Nov 23 10:04:54 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 10:04:54 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v6]
In-Reply-To: <d-FehcWQqOq1w_ZtjPVgcyhnz3hhvcTlhjOjOPVaxbA=.d36f230e-b9b9-4894-84d5-e20f37b02921@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <AMxNi2I1y0uqN7m86M9NFV0swGZw6gNyFdCq_yzqhSU=.c276d05a-e9ee-42bc-a45e-fb6a945727de@github.com>
 <d-FehcWQqOq1w_ZtjPVgcyhnz3hhvcTlhjOjOPVaxbA=.d36f230e-b9b9-4894-84d5-e20f37b02921@github.com>
Message-ID: <deD8uTnOTo0ffSUlf5usfKSTmh_a5Q8DMQOUgvsvN44=.14f2b611-a01c-4092-8d31-3c69903c97dc@github.com>

On Mon, 22 Nov 2021 14:57:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8276764: Enable deterministic file content ordering for Jar and Jmod
>>   
>>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 772:
> 
>> 770:             // Keep a sorted set of files to be processed, so that the jmod
>> 771:             // content is reproducible as Files.walkFileTree order is not defined
>> 772:             SortedMap<String, Path> filesToProcess  = new TreeMap<String, Path>();
> 
> Nit: there seems to be two whitespaces (instead of one) before the `=` sign on this line.

thanks, fixed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Tue Nov 23 11:16:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 11:16:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content
In-Reply-To: <CLFlvQzZlzZvNKKrmjAhRFRylqMrR5tXqypFJDhapEE=.39c98667-fe1e-4597-bff8-08d820063be4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <CLFlvQzZlzZvNKKrmjAhRFRylqMrR5tXqypFJDhapEE=.39c98667-fe1e-4597-bff8-08d820063be4@github.com>
Message-ID: <hDTBU1nu_UM4J0cIiE9e1AnZdwOKNxuM5KLpRv8TZrg=.d0eea207-4e42-482d-a9c3-72b9a56cc8c7@github.com>

On Mon, 22 Nov 2021 02:36:00 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Thank you for this timely pull request, Andrew! I need this pull request and also #6395 to [enable reproducible builds in JavaFX](https://github.com/openjdk/jfx/pull/446). I drove myself crazy this weekend with time zones, and if I understand your proposed changes correctly, it looks as if you're hitting the same problems as I did:
> 
> 1. The [`SOURCE_DATE_EPOCH` environment variable](https://reproducible-builds.org/specs/source-date-epoch/) is defined as the number of **seconds** since the epoch of 1970-01-01T00:00:00Z, but the new command option is defined as the number of milliseconds. That makes it difficult to set `--source-date=$SOURCE_DATE_EPOCH` on the command line.
> 
> 2. Calling the method `ZipEntry.setTime(long)` will not allow for reproducible builds when the builds run in different time zones.
> 
> For the second problem, run the included Java Time program as shown below:
> 
> 
> $ javac Time.java 
> $ echo $SOURCE_DATE_EPOCH
> 1637085342
> $ date --date="@$SOURCE_DATE_EPOCH"
> Tue 16 Nov 2021 09:55:42 AM PST
> $ java Time
> Build timestamp = 2021-11-16T17:55:42Z
> $ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
> Archive:  FailsInNome.zip
>   file last modified on (DOS date/time):          2021 Nov 16 08:55:42
> Archive:  FailsInRome.zip
>   file last modified on (DOS date/time):          2021 Nov 16 18:55:42
> Archive:  WorksInNome.zip
>   file last modified on (DOS date/time):          2021 Nov 16 17:55:42
> Archive:  WorksInRome.zip
>   file last modified on (DOS date/time):          2021 Nov 16 17:55:42
> 
> 
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.time.Instant;
> import java.time.LocalDateTime;
> import java.time.ZoneOffset;
> import java.time.temporal.ChronoUnit;
> import java.util.TimeZone;
> import java.util.zip.ZipEntry;
> import java.util.zip.ZipOutputStream;
> 
> public class Time {
> 
>     static void writeZipFile(String name, ZipEntry entry) throws IOException {
>         var output = new ZipOutputStream(new FileOutputStream(name));
>         output.putNextEntry(entry);
>         output.closeEntry();
>         output.close();
>     }
> 
>     public static void main(String[] args) throws IOException {
>         var instant = Instant.now().truncatedTo(ChronoUnit.SECONDS);
>         var sourceDateEpoch = System.getenv("SOURCE_DATE_EPOCH");
>         if (sourceDateEpoch != null) {
>             long seconds = Long.parseLong(sourceDateEpoch);
>             instant = Instant.ofEpochSecond(seconds);
>         }
>         System.out.println("Build timestamp = " + instant);
> 
>         var entry = new ZipEntry("Entry");
> 
>         long newTime = 1000 * instant.getEpochSecond();
>         TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
>         entry.setTime(newTime);
>         writeZipFile("FailsInNome.zip", entry);
>         TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
>         entry.setTime(newTime);
>         writeZipFile("FailsInRome.zip", entry);
> 
>         var dosTime = LocalDateTime.ofInstant(instant, ZoneOffset.UTC);
>         TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
>         entry.setTimeLocal(dosTime);
>         writeZipFile("WorksInNome.zip", entry);
>         TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
>         entry.setTimeLocal(dosTime);
>         writeZipFile("WorksInRome.zip", entry);
>     }
> }

@jgneff Hi John, thanks for the comment, I hadn't realized that aspect, but sort of obvious when you look at the ZIP spec for dostime, which has no timezone info.
So with this in mind the --source-date=<timestamp> option I am looking to add for jar/jmod, will need to state the timestamp is an "Epoch timestamp", ie. seconds since Jan1 1970 in UTC, and that as such the jar/jmod dostime will represent UTC "local time", akin to the EPOCH_SOURCE_DATE spec: https://reproducible-builds.org/specs/source-date-epoch/
I will update my PR to to use this.
thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From duke at openjdk.java.net  Tue Nov 23 13:39:12 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 23 Nov 2021 13:39:12 GMT
Subject: Withdrawn: 8274425: Remove unused Modules.extraLimitMods
In-Reply-To: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>
References: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>
Message-ID: <22NQNzZ23OgbFmlmlW6lpEoD96cy_LA_AeixDMzzUNE=.15ac3e58-7c14-4616-b0c5-5ef19b9a8aee@github.com>

On Wed, 22 Sep 2021 07:09:29 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> HashSet `com.sun.tools.javac.comp.Modules.extraLimitMods` is always empty. Code only check its content, but no content added.
> There was a method `addExtraLimitModules`, but it was removed under [JDK-8175191](https://bugs.openjdk.java.net/browse/JDK-8175191) 253fdcd0b26
> Method `addExtraLimitModules` itself was added in ec9ca2997f4, but was never actually used .

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5628

From jlahoda at openjdk.java.net  Tue Nov 23 13:40:46 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 23 Nov 2021 13:40:46 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v6]
In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
Message-ID: <u6CD_o1aAnWkqk3FEwf1CmXQlFdbQO_xTbr3ySKQqZA=.e4b42543-264f-4525-b75d-c3051a43cd6f@github.com>

> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.
> 
> Any feedback on this prototype would be welcome.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Improving javadoc as suggested in the PR.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5076/files
  - new: https://git.openjdk.java.net/jdk/pull/5076/files/da4781a9..7c11f10d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=04-05

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076

PR: https://git.openjdk.java.net/jdk/pull/5076

From jlahoda at openjdk.java.net  Tue Nov 23 13:40:52 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 23 Nov 2021 13:40:52 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v5]
In-Reply-To: <hfApY6A2sDwjhBGpyy5QMt7PKtQTodDe_roKx7PcVjo=.087f6da3-28c1-40b9-9534-da76c4c1deca@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
 <Su8OEcEgzCwcszftLBKrohNvh1JGGk0aoFsPBbuVH_k=.5b01ff98-19ba-4d9f-aeb1-b895f3cda4bd@github.com>
 <hfApY6A2sDwjhBGpyy5QMt7PKtQTodDe_roKx7PcVjo=.087f6da3-28c1-40b9-9534-da76c4c1deca@github.com>
Message-ID: <2BbI-Qj82sompz39KkY2coUXA-3TUJg5mlCibh8aZYE=.2559ae00-4f97-448f-bbf1-564ae2f7ddf6@github.com>

On Tue, 23 Nov 2021 05:33:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Test cleanup.
>>  - Merge branch 'ap-keep-originating-elements' into ap-keep-originating-elements-forwarding-tweak
>>  - Cleanup
>>  - Merge branch 'master' into ap-keep-originating-elements
>>  - Fixing test (need to exclude a private method from the test).
>>  - Fixing typo, as per review comments.
>>  - Fixing javadoc.
>>  - Cleanup.
>>  - Attempting to improve compatibility with existing subclasses of ForwardingJavaFileManager
>>  - Javadoc improvements.
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/ca31ed53...da4781a9
>
> src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 381:
> 
>> 379:                                         String className,
>> 380:                                         Kind kind,
>> 381:                                         FileObject... originatingFiles)
> 
> Perhaps explicitly state that null originatingFile or empty originatingFiles are no-ops.

Thanks - how about the following?
https://github.com/openjdk/jdk/pull/5076/commits/7c11f10d9c2bce6a5841fcfc4580edc12692dde5

-------------

PR: https://git.openjdk.java.net/jdk/pull/5076

From ihse at openjdk.java.net  Tue Nov 23 14:29:12 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Nov 2021 14:29:12 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v7]
In-Reply-To: <CuJt1Pm9mR6N4ckPzRq9e-nWcgqq4H7cJvqfrxliImA=.8d65e75d-7ec8-4cf8-97f2-9cf55799e099@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <CuJt1Pm9mR6N4ckPzRq9e-nWcgqq4H7cJvqfrxliImA=.8d65e75d-7ec8-4cf8-97f2-9cf55799e099@github.com>
Message-ID: <tX358BoGeRe04eZC05W92Z6GdrrXErfnYUNGcakpZrI=.f69a3f37-a249-4928-98e2-210651c531d8@github.com>

On Tue, 23 Nov 2021 10:04:51 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Tue Nov 23 14:37:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 14:37:12 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
 <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
 <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
Message-ID: <Iq3QckTSFZI5nglB3aq8OOJ-tEdOzFg9Y_XOOduoyek=.8e8d236d-1977-4c94-917e-e5f50fb5c0b3@github.com>

On Fri, 19 Nov 2021 21:33:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @magicus I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
>
>>  I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
> 
> The true source of the man pages are still kept in our closed repository.  The copy in the jdk repo is generated from our closed source and updated near the end of each release.    We should create a follow-up issue to update the man pages that perhaps Lance can help updating that.

@mlchung hi Mandy, I just wanted to check with you that all your comments are addressed before I integrate this? thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From ihse at openjdk.java.net  Tue Nov 23 14:59:51 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Nov 2021 14:59:51 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Iq3QckTSFZI5nglB3aq8OOJ-tEdOzFg9Y_XOOduoyek=.8e8d236d-1977-4c94-917e-e5f50fb5c0b3@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
 <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
 <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
 <Iq3QckTSFZI5nglB3aq8OOJ-tEdOzFg9Y_XOOduoyek=.8e8d236d-1977-4c94-917e-e5f50fb5c0b3@github.com>
Message-ID: <QT93bLI7MmgFPKQvAEbahPpQ0Td_175O0nlmn0O_-is=.d9831239-f79e-4372-a301-9c21dac804f3@github.com>

On Tue, 23 Nov 2021 14:34:23 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>>>  I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
>> 
>> The true source of the man pages are still kept in our closed repository.  The copy in the jdk repo is generated from our closed source and updated near the end of each release.    We should create a follow-up issue to update the man pages that perhaps Lance can help updating that.
>
> @mlchung hi Mandy, I just wanted to check with you that all your comments are addressed before I integrate this? thanks

@andrew-m-leonard You might want to get more reviewers than me before integrating; at least someone from core-libs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From vromero at openjdk.java.net  Tue Nov 23 15:13:25 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 23 Nov 2021 15:13:25 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v5]
In-Reply-To: <d4F2pdzRGIoIt8GmByrv40steGqb9Uf6aHd6Nrz9f9k=.2bca3575-a9b4-4455-be34-8e70d1ee43ff@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <d4F2pdzRGIoIt8GmByrv40steGqb9Uf6aHd6Nrz9f9k=.2bca3575-a9b4-4455-be34-8e70d1ee43ff@github.com>
Message-ID: <Tq3Ix4RMe7ncmNeNzIG9i7KldWT2oNtxHNfGRPbPs-s=.514ea3bb-7227-4117-bcd6-43fbc0c911c1@github.com>

On Mon, 22 Nov 2021 22:33:48 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Negate condition inside loop
>  - Clean up tests
>  - Use a shorter name for Target setting

lgtm, thanks for fixing this!

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Tue Nov 23 15:29:39 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 23 Nov 2021 15:29:39 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v6]
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <F_ybektaEomCnXsXf8bfAvq_592kHU7JdNqeo6zQHu4=.6fa63ebf-8b32-4baa-bcd4-82042107e385@github.com>

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Restore accidentally removed flag from BridgeMethodsForLambdaTest
 - Negate condition inside loop
 - Clean up tests
 - Use a shorter name for Target setting
 - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
 - Enable enclosing instance optimization for --release 18 and newer
 - Add a test case with nested inner classes
 - 8271623: Omit enclosing instance fields from inner classes that don't use it

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4966/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4966&range=05
  Stats: 451 lines in 17 files changed: 396 ins; 22 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4966.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4966/head:pull/4966

PR: https://git.openjdk.java.net/jdk/pull/4966

From cushon at openjdk.java.net  Tue Nov 23 15:29:43 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 23 Nov 2021 15:29:43 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v5]
In-Reply-To: <Tq3Ix4RMe7ncmNeNzIG9i7KldWT2oNtxHNfGRPbPs-s=.514ea3bb-7227-4117-bcd6-43fbc0c911c1@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <d4F2pdzRGIoIt8GmByrv40steGqb9Uf6aHd6Nrz9f9k=.2bca3575-a9b4-4455-be34-8e70d1ee43ff@github.com>
 <Tq3Ix4RMe7ncmNeNzIG9i7KldWT2oNtxHNfGRPbPs-s=.514ea3bb-7227-4117-bcd6-43fbc0c911c1@github.com>
Message-ID: <hgSmA2esTTjqJZXPkMYJbd_fR3L3J-1Di4n7dbtYz2k=.3ce03506-c55a-40fa-9b84-5189a522634e@github.com>

On Tue, 23 Nov 2021 15:10:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> lgtm, thanks for fixing this!

@vicente-romero-oracle thanks for the review!

I rebased and pushed one more commit to `test/langtools/tools/javac/classfiles/attributes/Synthetic/BridgeMethodsForLambdaTest.java` to restore an `-XD` flag that was accidentally removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From jlahoda at openjdk.java.net  Tue Nov 23 15:35:28 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 23 Nov 2021 15:35:28 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v6]
In-Reply-To: <F_ybektaEomCnXsXf8bfAvq_592kHU7JdNqeo6zQHu4=.6fa63ebf-8b32-4baa-bcd4-82042107e385@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <F_ybektaEomCnXsXf8bfAvq_592kHU7JdNqeo6zQHu4=.6fa63ebf-8b32-4baa-bcd4-82042107e385@github.com>
Message-ID: <PsH3nQEYOyB520m15R_p6pwVPTjWL9d_IDs-60Wipxs=.7302468d-bf27-47db-bc53-009c1c7c6959@github.com>

On Tue, 23 Nov 2021 15:29:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Restore accidentally removed flag from BridgeMethodsForLambdaTest
>  - Negate condition inside loop
>  - Clean up tests
>  - Use a shorter name for Target setting
>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

Looks good to me.

Marked as reviewed by jlahoda (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From aleonard at openjdk.java.net  Tue Nov 23 15:38:08 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 15:38:08 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod
In-Reply-To: <Iq3QckTSFZI5nglB3aq8OOJ-tEdOzFg9Y_XOOduoyek=.8e8d236d-1977-4c94-917e-e5f50fb5c0b3@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <c_8pq1xQxLkTnjYR9GtXRnJ8jMAc4r0MV2sJs-7QvAU=.395f4d6d-9deb-45e9-88b4-23f24ad2bcd0@github.com>
 <a_NdsMvzyIccvsJmFFlJclWGj-ee476VH_LLNifwrAo=.e5e32f3d-fbff-496e-8d50-8beef4dc9e70@github.com>
 <GWYxZhIOJ4JcXaU9WU_3THrmlqbpgZx_dm_g7gT1LQs=.dc98575c-0a1b-4ff0-b88c-a222aac53160@github.com>
 <uIxh3vZb4e7DddYRpFlnhDiFCZAg--ebBJqSm3qWokE=.9bafea6a-a8b9-4a08-aa53-6ffc264cce08@github.com>
 <Yv6FCDE0wLK8oMEBCWOJhawiaRhk94hE31wWaUTdEtk=.7ab240fb-c8ac-4240-82ba-378d3fcf6cd2@github.com>
 <Iq3QckTSFZI5nglB3aq8OOJ-tEdOzFg9Y_XOOduoyek=.8e8d236d-1977-4c94-917e-e5f50fb5c0b3@github.com>
Message-ID: <IbL-XQCRv9hZMGU0DsRmyNH9aEeCxMp_gJNzmgKpovs=.d30e69d8-4416-48d8-9c38-ee5c6c81b02f@github.com>

On Tue, 23 Nov 2021 14:34:23 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>>>  I've added updates to the jar and jmod man pages, as "Notes" about ordering, does that sound reasonable?
>> 
>> The true source of the man pages are still kept in our closed repository.  The copy in the jdk repo is generated from our closed source and updated near the end of each release.    We should create a follow-up issue to update the man pages that perhaps Lance can help updating that.
>
> @mlchung hi Mandy, I just wanted to check with you that all your comments are addressed before I integrate this? thanks

> @andrew-m-leonard You might want to get more reviewers than me before integrating; at least someone from core-libs.

@magicus Yep, hence want Mandy's review, cheers

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Tue Nov 23 15:39:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 15:39:43 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v2]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <EPyW8YyWBt9bwW65YWGEAOGsHxTd2FDbdpe3ELgmCPk=.6329fdfa-d6e2-487a-b598-df9287d7492a@github.com>

> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/579fe77c..dec457fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=00-01

  Stats: 35 lines in 9 files changed: 7 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From vromero at openjdk.java.net  Tue Nov 23 15:40:19 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 23 Nov 2021 15:40:19 GMT
Subject: RFR: 8271623: Omit enclosing instance fields from inner classes
 that don't use it [v6]
In-Reply-To: <F_ybektaEomCnXsXf8bfAvq_592kHU7JdNqeo6zQHu4=.6fa63ebf-8b32-4baa-bcd4-82042107e385@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
 <F_ybektaEomCnXsXf8bfAvq_592kHU7JdNqeo6zQHu4=.6fa63ebf-8b32-4baa-bcd4-82042107e385@github.com>
Message-ID: <IaRfkQ3gaSrv1cjlC56wWPp1OdYrJ4RKXusKUDCvUKs=.db1d2f75-5dc7-4de7-a4cd-be7aecea40f2@github.com>

On Tue, 23 Nov 2021 15:29:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Restore accidentally removed flag from BridgeMethodsForLambdaTest
>  - Negate condition inside loop
>  - Clean up tests
>  - Use a shorter name for Target setting
>  - Don't remove enclosing instance fields from serializable classes without serialVersionUIDs
>  - Enable enclosing instance optimization for --release 18 and newer
>  - Add a test case with nested inner classes
>  - 8271623: Omit enclosing instance fields from inner classes that don't use it

Marked as reviewed by vromero (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From aleonard at openjdk.java.net  Tue Nov 23 15:45:52 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 15:45:52 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v3]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <RI4GfNBG9J43bezhpEew4Z_GyO85kn5m6PmSSEMB8Uw=.cb5ec26f-066c-4b6d-bb05-3d7ec0254b2c@github.com>

> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/dec457fd..f4694dc0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From cushon at openjdk.java.net  Tue Nov 23 18:18:10 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 23 Nov 2021 18:18:10 GMT
Subject: Integrated: 8271623: Omit enclosing instance fields from inner classes
 that don't use it
In-Reply-To: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
References: <-i5qZU_p-T4zzgb08QWqwDOoSPlDRZxAKR5m3wDSg9s=.e98021bb-fe9d-48a2-8518-b1ff88c2b993@github.com>
Message-ID: <F9OjXlHjWt98F5mV-QV7p4jcnE8W3X93ahwCaRAiC_Y=.3d9990f6-d899-4e6a-bccd-f136a55e0cb7@github.com>

On Tue, 3 Aug 2021 03:19:13 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change omits the synthetic `this$0` field from inner classes that do not access any enclosing instance state.

This pull request has now been integrated.

Changeset: ea85e01a
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea85e01a4c8db1bc48d590abc882dc6efe5b0f4a
Stats:     451 lines in 17 files changed: 396 ins; 22 del; 33 mod

8271623: Omit enclosing instance fields from inner classes that don't use it

Reviewed-by: vromero, jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/4966

From mchung at openjdk.java.net  Tue Nov 23 18:24:17 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 23 Nov 2021 18:24:17 GMT
Subject: RFR: 8276764: Enable deterministic file content ordering for Jar
 and Jmod [v7]
In-Reply-To: <CuJt1Pm9mR6N4ckPzRq9e-nWcgqq4H7cJvqfrxliImA=.8d65e75d-7ec8-4cf8-97f2-9cf55799e099@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
 <CuJt1Pm9mR6N4ckPzRq9e-nWcgqq4H7cJvqfrxliImA=.8d65e75d-7ec8-4cf8-97f2-9cf55799e099@github.com>
Message-ID: <bqvEbhNGgI2f5vZM4fWGI7LAWU8JYcy_wNTYlRRmbbw=.99565d3e-ed53-4341-b1d4-ba411b8df27f@github.com>

On Tue, 23 Nov 2021 10:04:51 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
>> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8276764: Enable deterministic file content ordering for Jar and Jmod
>   
>   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6395

From aleonard at openjdk.java.net  Tue Nov 23 18:32:19 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 18:32:19 GMT
Subject: Integrated: 8276764: Enable deterministic file content ordering for
 Jar and Jmod
In-Reply-To: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
References: <dZFc8WXc_mlHStI_aBBa2Glj3YJrq93j8U0tSj21KYU=.729fd1d9-582b-4ffa-80a9-09a03482646b@github.com>
Message-ID: <NiMzyZE6nuBhJ_qf_Sc1FzJEaceRFhBG-D0npOKtATY=.2c3b6f30-cd22-4f33-9d07-32a21194135b@github.com>

On Mon, 15 Nov 2021 18:47:34 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both jar and jmod utilise java.io file operations whose methods define no ordering of the return file lists, and in fact rely on OS query file ordering, which can differ by underlying OS architecture.
> This PR adds sort processing to the creation of such jar's and jmod's to enable a deterministic content ordering.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This pull request has now been integrated.

Changeset: 24e586a0
Author:    Andrew Leonard <aleonard at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/24e586a04368a76cd9f37aa783b974b9e0351d58
Stats:     265 lines in 4 files changed: 250 ins; 2 del; 13 mod

8276764: Enable deterministic file content ordering for Jar and Jmod

Reviewed-by: mchung, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/6395

From darcy at openjdk.java.net  Tue Nov 23 19:23:40 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 23 Nov 2021 19:23:40 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v3]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <NsoeSphaFHjJWvq-cj2gfwq-itERnEaJfQ0AGYm4Gxc=.488ce7ee-0cfe-487b-a905-95addb332d20@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - Add --release 18 information. Good tier1 test results.
 - JDK-8273146: Start of release updates for JDK 19

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/4da056ab..5fe55cbf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=01-02

  Stats: 1511 lines in 44 files changed: 1091 ins; 303 del; 117 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From jjg at openjdk.java.net  Tue Nov 23 20:10:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 23 Nov 2021 20:10:10 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT
In-Reply-To: <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <cfFe-LZYHTiECi-93Oy7XoVZmLtcla-yODnK4sMFRq8=.6cba0240-0687-484d-a60a-4e0864d9dcc9@github.com>
Message-ID: <x8S-Zg7EyWFyevwBsmF-U6tULcAey4teYgZdrHgyV9A=.f4fac962-692e-4429-b399-3cbc99ed85e2@github.com>

On Fri, 19 Nov 2021 12:11:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java line 283:
> 
>> 281:                     if (enc != null) {
>> 282:                         encodingName = enc;
>> 283:                     }
> 
> If we updating javac and javadoc --encoding to support "COMPAT" then we should list this in JEP 400.
> 
> Does javadoc use doPriv already, I don't know how common it would be to run javadoc with a SM set. If the doPriv stays then you can avoid the cast by changing it to:
> PrivilegedAction<String> pa = () -> System.getProperty("native.encoding");
> return AccessController.doPrivileged(pa);

javac and javadoc do not have privileged code. I am loathe to change that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From jjg at openjdk.java.net  Tue Nov 23 20:28:05 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 23 Nov 2021 20:28:05 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v6]
In-Reply-To: <u6CD_o1aAnWkqk3FEwf1CmXQlFdbQO_xTbr3ySKQqZA=.e4b42543-264f-4525-b75d-c3051a43cd6f@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
 <u6CD_o1aAnWkqk3FEwf1CmXQlFdbQO_xTbr3ySKQqZA=.e4b42543-264f-4525-b75d-c3051a43cd6f@github.com>
Message-ID: <HvIIec7gV61jhUf64QqmWb6t4E24icHnfpk70S_gK2k=.016df331-9ba4-4569-a051-988bd30e7f58@github.com>

On Tue, 23 Nov 2021 13:40:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.
>> 
>> Any feedback on this prototype would be welcome.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving javadoc as suggested in the PR.

src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 349:

> 347:      *
> 348:      * <p>The provided {@code originatingFiles} represent files that
> 349:      * were in, an unspecified way, used to create the content of

misplaced comma.  should be `were, in an unspecified way,`

src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 365:

> 363:      * @param originatingFiles the files which are contributing to this newly created file;
> 364:      *                         {@code null} is equivalent to empty {@code originatingFiles},
> 365:      *                         meaning no known originating files

(minor/white-space) inconsistent indentation of `@param` tags

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 531:

> 529:         }
> 530:         JavaFileObject[] originatingFiles = Arrays.asList(originatingElements)
> 531:                 .stream()

Why not start with `Stream.of(originatingElements)` ?

test/langtools/tools/javac/processing/filer/TestOriginatingElements.java line 24:

> 22:  */
> 23: 
> 24: /**

Should be `/*` not `/**`. This is not a documentation comment for javadoc.

test/langtools/tools/javac/processing/filer/TestOriginatingElements.java line 185:

> 183:                 List<String> options = List.of("-sourcepath", src.toString(),
> 184:                                                "-processor", "TestOriginatingElements$P",
> 185:                                                "-processorpath", System.getProperty("test.classes"),

This may be enough. but note there is also `test.class.path` .... one is just the output directory, the other is the full path.

test/langtools/tools/javac/processing/filer/TestOriginatingElements.java line 229:

> 227:                 PackageElement pack = processingEnv.getElementUtils().getPackageElement("p");
> 228:                 PackageElement lib1Pack = processingEnv.getElementUtils().getPackageElement("lib1");
> 229:                 PackageElement lib2Pack = processingEnv.getElementUtils().getPackageElement("lib2");

strongly suggest using a local variable for `processingEnv.getElementUtils()`

-------------

PR: https://git.openjdk.java.net/jdk/pull/5076

From aleonard at openjdk.java.net  Tue Nov 23 20:29:15 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 23 Nov 2021 20:29:15 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>

> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=03
  Stats: 173 lines in 10 files changed: 148 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From mchung at openjdk.java.net  Tue Nov 23 21:19:38 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 23 Nov 2021 21:19:38 GMT
Subject: RFR: 8277165: jdeps --multi-release --print-module-deps fails if
 module-info.class in different versioned directories
Message-ID: <BsM98YpTDyGBlsgSIuPQdU7L__D1Kdzj_KVwy6Fiu6Q=.a5bf3c21-26f6-4c88-937e-8f1e72707fd4@github.com>

jdeps intends to report an error if there are multiple versions of the same class being parsed.   module-info.class should be excluded from such detection.

This patch also fixes a data race in `VersionHelper::set` and also unwraps the `ExecutionException` when FutureTask of parsing the classes throws an exception to report `MultiReleaseException` properly.

-------------

Commit messages:
 - add comment to the test
 - JDK-8277165: jdeps cannot handle 2 jars that put module-info.class in a different versioned directory

Changes: https://git.openjdk.java.net/jdk/pull/6530/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6530&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277165
  Stats: 301 lines in 11 files changed: 288 ins; 6 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6530.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6530/head:pull/6530

PR: https://git.openjdk.java.net/jdk/pull/6530

From jvernee at openjdk.java.net  Tue Nov 23 21:19:39 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 23 Nov 2021 21:19:39 GMT
Subject: RFR: 8277165: jdeps --multi-release --print-module-deps fails if
 module-info.class in different versioned directories
In-Reply-To: <BsM98YpTDyGBlsgSIuPQdU7L__D1Kdzj_KVwy6Fiu6Q=.a5bf3c21-26f6-4c88-937e-8f1e72707fd4@github.com>
References: <BsM98YpTDyGBlsgSIuPQdU7L__D1Kdzj_KVwy6Fiu6Q=.a5bf3c21-26f6-4c88-937e-8f1e72707fd4@github.com>
Message-ID: <GEc9d64oqig2TEg9fqqR0Tx9RxB3GDvgZGZaX1oAWzk=.bb1fae37-4b8d-43c0-8da2-87d063036cd8@github.com>

On Tue, 23 Nov 2021 20:54:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> jdeps intends to report an error if there are multiple versions of the same class being parsed.   module-info.class should be excluded from such detection.
> 
> This patch also fixes a data race in `VersionHelper::set` and also unwraps the `ExecutionException` when FutureTask of parsing the classes throws an exception to report `MultiReleaseException` properly.

LGTM. Thanks for fixing.

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6530

From itakiguchi at openjdk.java.net  Wed Nov 24 04:08:43 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 04:08:43 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
Message-ID: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>

> ncoding name COMPAT was defined for operating system encoding by JEP-400.
> https://openjdk.java.net/jeps/400
> But java does not accept "-encoding COMPAT".

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8277398: javac does not accept encoding name COMPAT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6475/files
  - new: https://git.openjdk.java.net/jdk/pull/6475/files/a1b329e2..94d0c2c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6475&range=00-01

  Stats: 192 lines in 6 files changed: 83 ins; 106 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6475.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6475/head:pull/6475

PR: https://git.openjdk.java.net/jdk/pull/6475

From dholmes at openjdk.java.net  Wed Nov 24 05:35:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 24 Nov 2021 05:35:04 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v3]
In-Reply-To: <NsoeSphaFHjJWvq-cj2gfwq-itERnEaJfQ0AGYm4Gxc=.488ce7ee-0cfe-487b-a905-95addb332d20@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <NsoeSphaFHjJWvq-cj2gfwq-itERnEaJfQ0AGYm4Gxc=.488ce7ee-0cfe-487b-a905-95addb332d20@github.com>
Message-ID: <xz_Bs-0dvyEGeQm-h8dw9fnehgJnZZ_a2ioygx2gY7w=.2baca426-c48d-4551-a543-7bec34662baa@github.com>

On Tue, 23 Nov 2021 19:23:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Remove SharedSpaces options from VMDeprecatedOptions.java.
>  - Merge branch 'master' into JDK-8273146
>  - Respond to review feedback.
>  - Add --release 18 information. Good tier1 test results.
>  - JDK-8273146: Start of release updates for JDK 19

Update is good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6493

From darcy at openjdk.java.net  Wed Nov 24 07:41:01 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 24 Nov 2021 07:41:01 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v5]
In-Reply-To: <2BbI-Qj82sompz39KkY2coUXA-3TUJg5mlCibh8aZYE=.2559ae00-4f97-448f-bbf1-564ae2f7ddf6@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
 <Su8OEcEgzCwcszftLBKrohNvh1JGGk0aoFsPBbuVH_k=.5b01ff98-19ba-4d9f-aeb1-b895f3cda4bd@github.com>
 <hfApY6A2sDwjhBGpyy5QMt7PKtQTodDe_roKx7PcVjo=.087f6da3-28c1-40b9-9534-da76c4c1deca@github.com>
 <2BbI-Qj82sompz39KkY2coUXA-3TUJg5mlCibh8aZYE=.2559ae00-4f97-448f-bbf1-564ae2f7ddf6@github.com>
Message-ID: <pguDJjjcAIVHDn-jzwbamAb8QeW_mHFKCsZNx9TGCOM=.f170de9f-f961-45ff-ba56-2be6b19f5b42@github.com>

On Tue, 23 Nov 2021 13:36:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/tools/JavaFileManager.java line 381:
>> 
>>> 379:                                         String className,
>>> 380:                                         Kind kind,
>>> 381:                                         FileObject... originatingFiles)
>> 
>> Perhaps explicitly state that null originatingFile or empty originatingFiles are no-ops.
>
> Thanks - how about the following?
> https://github.com/openjdk/jdk/pull/5076/commits/7c11f10d9c2bce6a5841fcfc4580edc12692dde5

Spec update looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5076

From alanb at openjdk.java.net  Wed Nov 24 08:51:10 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Nov 2021 08:51:10 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

I see this PR has been re-purposed to add "COMPAT" as a charset that can be specified to Charset.forName. I don't think we should do that.  "COMPAT" is a special value for the file.encoding property, it's not meant to be in the charset tables as proposed here. The system property "native.encoding" was added in Java 17 as a standard way to obtain the encoding, you can pass its value to Charset.forName. I think we need a clear summary as to what the issue is, is -J-Dfile.encoding=COMPAT working or not?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From jlahoda at openjdk.java.net  Wed Nov 24 10:11:12 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 24 Nov 2021 10:11:12 GMT
Subject: Integrated: 8273328: Compiler implementation for Pattern Matching for
 switch (Second Preview)
In-Reply-To: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
References: <_hUs5IQRMm-eJDvie67qbTMxaXyqWmWiqU82I1ix6N8=.33c811c5-9661-4a2a-a4ad-e6c3f810aceb@github.com>
Message-ID: <MGCffFVMZULwP0CLm7XEHL6k0nBSdmyKU33l7npAxbw=.42e41448-126c-47d4-b7ea-a9e29c0ddb19@github.com>

On Tue, 2 Nov 2021 10:51:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The specification for pattern matching for switch (preview)[1] has been updated with two changes:
> -any type of pattern (including guarded patterns) dominates constant cases. Dominance across pattern/non-constant cases is unchanged. (See the change in `Attr.java`.)
> -for sealed hierarchies, it may happen some of the subtypes are impossible (not castable) to the selector type. Like, for example:
> 
> sealed interface I<T> {}
> final class A implements I<String> {}
> final class B<T> implements I<T> {}
> ...
> I<Integer> i = ...;
> switch (i) {
>      case A a -> {} //case not allowed as I<Integer> is not castable to A
>      case B b -> {}
> }
> 
> 
> But, the exhaustiveness checks in JDK 17 required all the permitted subclasses, including `A`, are covered by the switch, which forced a `default` clause in place of `case A a` for cases like this. The updated specification excludes such impossible permitted subclasses from exhaustiveness checks, so the default is no longer needed and this:
> 
> 
> I<Integer> i = ...;
> switch (i) {
>      case B b -> {}
> }
> 
> 
> compiles OK.
> (See the change in `Flow.java`.)
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep420/jep420-20211020/specs/patterns-switch-jls.html

This pull request has now been integrated.

Changeset: d085c2b8
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d085c2b8a790a5ddfbb01a0ea4edd4051cfb704b
Stats:     223 lines in 9 files changed: 174 ins; 16 del; 33 mod

8273328: Compiler implementation for Pattern Matching for switch (Second Preview)

Reviewed-by: vromero, mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/6209

From ihse at openjdk.java.net  Wed Nov 24 10:40:10 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 24 Nov 2021 10:40:10 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v3]
In-Reply-To: <NsoeSphaFHjJWvq-cj2gfwq-itERnEaJfQ0AGYm4Gxc=.488ce7ee-0cfe-487b-a905-95addb332d20@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <NsoeSphaFHjJWvq-cj2gfwq-itERnEaJfQ0AGYm4Gxc=.488ce7ee-0cfe-487b-a905-95addb332d20@github.com>
Message-ID: <cVl3WOX5j_-MMHG5yV00vdbEN9WmZlPBVjfElApqKLY=.fcc8c5c2-91b8-4a68-8246-09127a56c83f@github.com>

On Tue, 23 Nov 2021 19:23:40 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Remove SharedSpaces options from VMDeprecatedOptions.java.
>  - Merge branch 'master' into JDK-8273146
>  - Respond to review feedback.
>  - Add --release 18 information. Good tier1 test results.
>  - JDK-8273146: Start of release updates for JDK 19

Build changes look good

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6493

From ihse at openjdk.java.net  Wed Nov 24 11:27:09 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 24 Nov 2021 11:27:09 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
Message-ID: <YsvTty0PfRfippxDaKoKKX-kfZuIZlqKm_6aVLcSM6I=.df1a32f8-400a-4e0e-961a-b288c4c1586e@github.com>

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch milliseconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Looks good to me, but you need more reviewers

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6481

From lancea at openjdk.java.net  Wed Nov 24 11:40:05 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Nov 2021 11:40:05 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v7]
In-Reply-To: <ykusHnoW4aWR8SuDt4jdAqlgaAGoZYy3IxjU1P4F0jI=.44315c2e-f036-4911-be65-77853bbfaf4c@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <ykusHnoW4aWR8SuDt4jdAqlgaAGoZYy3IxjU1P4F0jI=.44315c2e-f036-4911-be65-77853bbfaf4c@github.com>
Message-ID: <C_DmxSbINc5l1v3yK_8DBerzYt8YJ2LJZ-MdEX3eZgQ=.3c9cbc08-951b-4512-8e44-b78f62be86e4@github.com>

On Mon, 22 Nov 2021 14:37:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use proper FileTime centric APIs

I ran your latest run through Mach5 tier1 - tier3 without any failures.

Your latest updates seem OK to me.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5486

From asotona at openjdk.java.net  Wed Nov 24 13:45:16 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 24 Nov 2021 13:45:16 GMT
Subject: RFR: 8235876: Misleading warning message in java source-file mode
Message-ID: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>

Execution of  `java --source 7 Test.java` displays following warning: 
`warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.` 

However use of `-Xlint:-options` is not allowed and so it proposes an invalid suggestion.

This is yet another case of "too much information" provided to user in source-file mode. 
Target audience of source-file mode are Java beginners with very simple cases.
Many options are not available in source-file mode and so this patch disables also related options warnings.

The case is similar to JDK-8268869

Patch adds `-Xlint:-options` into the list of default javac options in source-file mode.
Relevant test is also provided.

Thanks,
Adam

-------------

Commit messages:
 - 8235876: Misleading warning message in java source-file mode

Changes: https://git.openjdk.java.net/jdk/pull/6537/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6537&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235876
  Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6537.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6537/head:pull/6537

PR: https://git.openjdk.java.net/jdk/pull/6537

From asotona at openjdk.java.net  Wed Nov 24 13:52:36 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 24 Nov 2021 13:52:36 GMT
Subject: RFR: 8235876: Misleading warning message in java source-file mode
 [v2]
In-Reply-To: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>
References: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>
Message-ID: <cH8lbmEiRCD4e2dFwuVzr5ct_FW_422_jE_vacEJRyg=.d19913d7-73b9-4143-86ab-408c8395c3b0@github.com>

> Execution of  `java --source 7 Test.java` displays following warning: 
> `warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.` 
> 
> However use of `-Xlint:-options` is not allowed and so it proposes an invalid suggestion.
> 
> This is yet another case of "too much information" provided to user in source-file mode. 
> Target audience of source-file mode are Java beginners with very simple cases.
> Many options are not available in source-file mode and so this patch disables also related options warnings.
> 
> The case is similar to JDK-8268869
> 
> Patch adds `-Xlint:-options` into the list of default javac options in source-file mode.
> Relevant test is also provided.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete part of the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6537/files
  - new: https://git.openjdk.java.net/jdk/pull/6537/files/ede3e33f..237ca7d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6537&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6537&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6537.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6537/head:pull/6537

PR: https://git.openjdk.java.net/jdk/pull/6537

From naoto at openjdk.java.net  Wed Nov 24 13:58:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 13:58:05 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <ZVFU4z2WX4tHRZx47ROiBc3b1iIlSd6e47VYT0eyXt0=.d6406a1c-4f2e-42f6-beee-44538d7f8640@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

Sorry if I didn't make myself clear, but I totally agree with Alan. `COMPAT` is meant for apps for their migration to JDK18, not something we would want to promote as a feature. `Charset.forName("COMPAT")` was an example we would not do, leading to my point that we should not add the proposed javac/javadoc compiler flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From ihse at openjdk.java.net  Wed Nov 24 14:06:32 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 24 Nov 2021 14:06:32 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v7]
In-Reply-To: <ykusHnoW4aWR8SuDt4jdAqlgaAGoZYy3IxjU1P4F0jI=.44315c2e-f036-4911-be65-77853bbfaf4c@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <ykusHnoW4aWR8SuDt4jdAqlgaAGoZYy3IxjU1P4F0jI=.44315c2e-f036-4911-be65-77853bbfaf4c@github.com>
Message-ID: <zcT2YwQqR83e1FSBSdEPYYSMrJ-gQSZmvK9KMFJMmVM=.a3cc94cb-dcba-49cd-8476-97a4b79b5323@github.com>

On Mon, 22 Nov 2021 14:37:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use proper FileTime centric APIs

Looks good to me.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Wed Nov 24 14:06:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 24 Nov 2021 14:06:29 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v8]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <jPDRGVfUs3YPSls3vVFkFyzKdvvrwkNaeBL-Tihm9yw=.7c751f5b-43c4-41f3-9a7c-efa224fc7f5d@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge latest from master branch
 - use proper FileTime centric APIs
 - review suggestion - use FileTime instead of Long to prevent any potential NPEs during unboxing
 - review suggestion - split into multiple statements to make it easily readable
 - review suggestion - Use Path.of instead of Paths.get in testcase
 - review suggestion - store e.getValue() and reuse the stored value
 - Merge latest from master branch
 - use testng asserts
 - Remove "final" usage from test
 - convert test to testng
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cf7adae6...6f1c1b62

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5486/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=07
  Stats: 278 lines in 2 files changed: 259 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Wed Nov 24 14:10:10 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 24 Nov 2021 14:10:10 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v8]
In-Reply-To: <jPDRGVfUs3YPSls3vVFkFyzKdvvrwkNaeBL-Tihm9yw=.7c751f5b-43c4-41f3-9a7c-efa224fc7f5d@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <jPDRGVfUs3YPSls3vVFkFyzKdvvrwkNaeBL-Tihm9yw=.7c751f5b-43c4-41f3-9a7c-efa224fc7f5d@github.com>
Message-ID: <LIHu-9FEHAEJq-TM8GQ4aA9IeK4InxXDXpo07asQakE=.adf197dc-e404-4f0e-9c21-3eda9b6c1dae@github.com>

On Wed, 24 Nov 2021 14:06:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge latest from master branch
>  - use proper FileTime centric APIs
>  - review suggestion - use FileTime instead of Long to prevent any potential NPEs during unboxing
>  - review suggestion - split into multiple statements to make it easily readable
>  - review suggestion - Use Path.of instead of Paths.get in testcase
>  - review suggestion - store e.getValue() and reuse the stored value
>  - Merge latest from master branch
>  - use testng asserts
>  - Remove "final" usage from test
>  - convert test to testng
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cf7adae6...6f1c1b62

Thank you Lance and Magnus for the latest reviews and the testing. A recent commit to master in this area meant that there was a merge conflict in this PR. I have now resolved that and pushed the merge to this PR (no other changes). The test continues to pass.
Alan, do these latest round of changes around `FileTime` usage that you requested, look fine?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From alanb at openjdk.java.net  Wed Nov 24 14:33:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Nov 2021 14:33:15 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v8]
In-Reply-To: <jPDRGVfUs3YPSls3vVFkFyzKdvvrwkNaeBL-Tihm9yw=.7c751f5b-43c4-41f3-9a7c-efa224fc7f5d@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <jPDRGVfUs3YPSls3vVFkFyzKdvvrwkNaeBL-Tihm9yw=.7c751f5b-43c4-41f3-9a7c-efa224fc7f5d@github.com>
Message-ID: <Yt6VHzQpJjNZlqapD0SRz1BqGooDfJA1oRbDdhcTArs=.98160e46-d39f-48f8-acd9-91ea0c7a50f3@github.com>

On Wed, 24 Nov 2021 14:06:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge latest from master branch
>  - use proper FileTime centric APIs
>  - review suggestion - use FileTime instead of Long to prevent any potential NPEs during unboxing
>  - review suggestion - split into multiple statements to make it easily readable
>  - review suggestion - Use Path.of instead of Paths.get in testcase
>  - review suggestion - store e.getValue() and reuse the stored value
>  - Merge latest from master branch
>  - use testng asserts
>  - Remove "final" usage from test
>  - convert test to testng
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cf7adae6...6f1c1b62

A few minor cleanups but otherwise I think this is good.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1057:

> 1055:             ZipEntry e = new ZipEntry(name);
> 1056:             FileTime lastModified = mie.getLastModifiedTime();
> 1057:             e.setLastModifiedTime(lastModified != null ? lastModified : FileTime.fromMillis(System.currentTimeMillis()));

I think this would be a bit more readable if it were if-then-else.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1768:

> 1766:                 return is.readAllBytes();
> 1767:             }
> 1768:        }

I think the comment would be clear if it says "the last modified time of the module-info.class".
Also would you mind changing ModuleInfoEntry to use 4-space rather than 2-space indentation?

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5486

From itakiguchi at openjdk.java.net  Wed Nov 24 14:39:07 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 14:39:07 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <6gCZ5DkejqB-BWoOfwm11qzMtxNxuETGBdVQZP3b50Q=.51c7b8ff-e1bd-49dd-8b8d-00159ffa9eee@github.com>
Message-ID: <ITcPgw0Bop1aUELJSN_-TZSNw30YyOJ15lO1QI1heiU=.9b6ec3f1-bdd8-4548-9b0f-bb63c64ee46b@github.com>

On Wed, 24 Nov 2021 08:47:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277398: javac does not accept encoding name COMPAT
>
> I see this PR has been re-purposed to add "COMPAT" as a charset that can be specified to Charset.forName. I don't think we should do that.  "COMPAT" is a special value for the file.encoding property, it's not meant to be in the charset tables as proposed here. The system property "native.encoding" was added in Java 17 as a standard way to obtain the encoding, you can pass its value to Charset.forName. I think we need a clear summary as to what the issue is, is -J-Dfile.encoding=COMPAT working or not?

Hello @AlanBateman and @naotoj .
I'd like to show some commands output.
As you told me, -J-Dfile.encoding=COMPAT works for compilation.
Hello.java is encoded by EUC-JP.

$ export LANG=ja_JP.eucjp
$ cat Hello.java
public class Hello {
  public static void main(String[] args) throws Exception {
    System.out.println("?????");
  }
}
$ xxd Hello.java
0000000: 7075 626c 6963 2063 6c61 7373 2048 656c  public class Hel
0000010: 6c6f 207b 0a20 2070 7562 6c69 6320 7374  lo {.  public st
0000020: 6174 6963 2076 6f69 6420 6d61 696e 2853  atic void main(S
0000030: 7472 696e 675b 5d20 6172 6773 2920 7468  tring[] args) th
0000040: 726f 7773 2045 7863 6570 7469 6f6e 207b  rows Exception {
0000050: 0a20 2020 2053 7973 7465 6d2e 6f75 742e  .    System.out.
0000060: 7072 696e 746c 6e28 22a4 b3a4 f3a4 cba4  println(".......
0000070: c1a4 cf22 293b 0a20 207d 0a7d 0a         ...");.  }.}.
$ build/linux-x86_64-server-release/images/jdk/bin/javac -J-Dfile.encoding=COMPAT Hello.java
$ build/linux-x86_64-server-release/images/jdk/bin/java Hello
?????
$ build/linux-x86_64-server-release/images/jdk/bin/javac -J-Dfile.encoding=COMPAT -verbose Hello.java 2>&1 | head
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[13??????????]
[/modules/jdk.internal.vm.compiler/module-info.class?????]
[/modules/jdk.incubator.foreign/module-info.class?????]
[/modules/jdk.xml.dom/module-info.class?????]
[/modules/jdk.jdwp.agent/module-info.class?????]
[/modules/jdk.editpad/module-info.class?????]
[/modules/jdk.crypto.ec/module-info.class?????]
[/modules/java.management.rmi/module-info.class?????]
[/modules/java.management/module-info.class?????]

When I use -Xstdout option for javac, javac's output is redirect to file.


$ build/linux-x86_64-server-release/images/jdk/bin/javac -Xstdout out.log -J-Dfile.encoding=COMPAT -verbose Hello.java

According to head command, out.log was encoded by EUC-JP.
But I'd like to get UTF-8 encoded out.log. 

$ head out.log
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[13??????????]
[/modules/jdk.nio.mapmode/module-info.class?????]
[/modules/jdk.security.auth/module-info.class?????]
[/modules/jdk.internal.vm.compiler.management/module-info.class?????]
[/modules/java.scripting/module-info.class?????]
[/modules/java.datatransfer/module-info.class?????]
[/modules/jdk.attach/module-info.class?????]
[/modules/jdk.management.agent/module-info.class?????]
[/modules/jdk.jdi/module-info.class?????]

If I use -encoding option against javac command, out.log was encoded by UTF-8.

$ build/linux-x86_64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep encoding
    file.encoding = UTF-8
    native.encoding = EUC-JP-LINUX
    sun.io.unicode.encoding = UnicodeLittle
    sun.jnu.encoding = EUC-JP-LINUX
$ build/linux-x86_64-server-release/images/jdk/bin/javac -Xstdout out.log -encoding EUC-JP-LINUX -verbose Hello.java
$ head out.log
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???
$ head out.log | iconv -f UTF-8 -t EUC-JP
[SimpleFileObject[/home/jdktest/openjdk/jdk/Hello.java]???????]
[12??????????]
[/modules/jdk.jdi/module-info.class?????]
[/modules/jdk.internal.jvmstat/module-info.class?????]
[/modules/jdk.jartool/module-info.class?????]
[/modules/jdk.compiler/module-info.class?????]
[/modules/jdk.unsupported.desktop/module-info.class?????]
[/modules/java.desktop/module-info.class?????]
[/modules/java.xml/module-info.class?????]
[/modules/jdk.jcmd/module-info.class?????]

I don't want to find out encoding name each locale or platform.
javac and javadoc should be support COMPAT encoding name or COMPAT charset should be supported.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From jpai at openjdk.java.net  Wed Nov 24 15:04:35 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 24 Nov 2021 15:04:35 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v9]
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - review suggestion - format code in ModuleInfoEntry to use 4 space indentation
 - review suggestion - change javadoc to mention module-info.class instead of module descriptor
 - review suggestion - use if/else instead of ternary operator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5486/files
  - new: https://git.openjdk.java.net/jdk/pull/5486/files/6f1c1b62..bdc741ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5486&range=07-08

  Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5486/head:pull/5486

PR: https://git.openjdk.java.net/jdk/pull/5486

From alanb at openjdk.java.net  Wed Nov 24 15:22:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 24 Nov 2021 15:22:07 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v9]
In-Reply-To: <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
Message-ID: <j9r6azHPrLoiTAx2dhCmM1GlnZ0SUy2vflAdqtUGobQ=.585fdec8-14fd-4dab-b78f-5861b8becd7b@github.com>

On Wed, 24 Nov 2021 15:04:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review suggestion - format code in ModuleInfoEntry to use 4 space indentation
>  - review suggestion - change javadoc to mention module-info.class instead of module descriptor
>  - review suggestion - use if/else instead of ternary operator

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From vromero at openjdk.java.net  Wed Nov 24 16:13:10 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 24 Nov 2021 16:13:10 GMT
Subject: RFR: 8235876: Misleading warning message in java source-file mode
 [v2]
In-Reply-To: <cH8lbmEiRCD4e2dFwuVzr5ct_FW_422_jE_vacEJRyg=.d19913d7-73b9-4143-86ab-408c8395c3b0@github.com>
References: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>
 <cH8lbmEiRCD4e2dFwuVzr5ct_FW_422_jE_vacEJRyg=.d19913d7-73b9-4143-86ab-408c8395c3b0@github.com>
Message-ID: <nDS5j6aFPWTs3bZCKvzpfEk4SCYypXesuq_7Ea331o0=.7caabd66-15cc-41c9-a4a2-56d57c415d0b@github.com>

On Wed, 24 Nov 2021 13:52:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Execution of  `java --source 7 Test.java` displays following warning: 
>> `warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.` 
>> 
>> However use of `-Xlint:-options` is not allowed and so it proposes an invalid suggestion.
>> 
>> This is yet another case of "too much information" provided to user in source-file mode. 
>> Target audience of source-file mode are Java beginners with very simple cases.
>> Many options are not available in source-file mode and so this patch disables also related options warnings.
>> 
>> The case is similar to JDK-8268869
>> 
>> Patch adds `-Xlint:-options` into the list of default javac options in source-file mode.
>> Relevant test is also provided.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete part of the test

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6537

From lancea at openjdk.java.net  Wed Nov 24 16:19:14 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Nov 2021 16:19:14 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v9]
In-Reply-To: <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
Message-ID: <z9tjlojgG95jEV2hVUDdZ9bOAAEba877LKTCNY1e5V0=.4a623ef5-febd-4fc1-bc8d-5142ae914ec3@github.com>

On Wed, 24 Nov 2021 15:04:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review suggestion - format code in ModuleInfoEntry to use 4 space indentation
>  - review suggestion - change javadoc to mention module-info.class instead of module descriptor
>  - review suggestion - use if/else instead of ternary operator

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From cstein at openjdk.java.net  Wed Nov 24 16:53:10 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Wed, 24 Nov 2021 16:53:10 GMT
Subject: Integrated: 8272728: javac ignores any -J option in @argfiles silently
In-Reply-To: <YYENqjokKeg5xFUYaJLnuAFL3RsKjb4PqfXE37FgyhQ=.aee49177-40cf-48fe-81be-9ed99fa8a865@github.com>
References: <YYENqjokKeg5xFUYaJLnuAFL3RsKjb4PqfXE37FgyhQ=.aee49177-40cf-48fe-81be-9ed99fa8a865@github.com>
Message-ID: <bg8I_BI9IlQcU2z6IPZG2tg8T6tBIYha9oRQgzn1fFg=.1f2f374b-d659-4b86-9a3a-e53e025bc409@github.com>

On Mon, 11 Oct 2021 12:20:02 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Make javac error on `-J` being present in `@argfiles` or other locations, where the launcher didn't process and remove them.

This pull request has now been integrated.

Changeset: 663e33de
Author:    Christian Stein <cstein at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/663e33de13788586fa49bd9816bd148e58ad1031
Stats:     20 lines in 2 files changed: 18 ins; 0 del; 2 mod

8272728: javac ignores any -J option in @argfiles silently

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/5891

From asotona at openjdk.java.net  Wed Nov 24 17:07:12 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 24 Nov 2021 17:07:12 GMT
Subject: Integrated: 8235876: Misleading warning message in java source-file
 mode
In-Reply-To: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>
References: <HKOgglDbhVlI8J5mqbjTEaq7vzaw_2wDsEB-prk-WbA=.be25e828-197c-45a2-a566-2ade4b55bea8@github.com>
Message-ID: <VYRZzKVQdE7V8P_UZ54eJHUpvZeAQyR7yS8MvW0EfTk=.1005699f-0947-4a40-8f4e-d259beae582f@github.com>

On Wed, 24 Nov 2021 13:37:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Execution of  `java --source 7 Test.java` displays following warning: 
> `warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.` 
> 
> However use of `-Xlint:-options` is not allowed and so it proposes an invalid suggestion.
> 
> This is yet another case of "too much information" provided to user in source-file mode. 
> Target audience of source-file mode are Java beginners with very simple cases.
> Many options are not available in source-file mode and so this patch disables also related options warnings.
> 
> The case is similar to JDK-8268869
> 
> Patch adds `-Xlint:-options` into the list of default javac options in source-file mode.
> Relevant test is also provided.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 951247c8
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/951247c8cb4ea898bf7c188bed8e143ca7417c83
Stats:     16 lines in 2 files changed: 15 ins; 0 del; 1 mod

8235876: Misleading warning message in java source-file mode

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/6537

From lancea at openjdk.java.net  Wed Nov 24 18:15:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Nov 2021 18:15:09 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
Message-ID: <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thank you for your efforts here.

I just happened to notice that you created a [CSR](https://bugs.openjdk.java.net/browse/JDK-8277755), which is great, thank you.

Please add an explanation as to why the compatibility risk is minimal as that field is currently empty to the CSR.

The current version of the PR looks reasonable.  Please see a few additional comments below

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2290:

> 2288:     private void setSourceDate(ZipEntry e, long origTime) {
> 2289:         if (sourceDate != -1) {
> 2290:           e.setTimeLocal(LocalDateTime.ofEpochSecond(sourceDate, 0, ZoneOffset.UTC));

The above could potentially throw a DateTimeException which may be OK but I would sanity check there are no issues

src/jdk.jartool/share/man/jar.1 line 1:

> 1: .\" Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.

The man pages are maintained in the close repository

test/jdk/tools/jar/JarEntryTime.java line 129:

> 127:         // Make a jar file from that directory structure with
> 128:         // --source-date set to epoch seconds 1647302400 (15/03/2022)
> 129:         long sourceDate = 1647302400L;

Please consider  adding a few before Epoch test values.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From naoto at openjdk.java.net  Wed Nov 24 18:39:16 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Nov 2021 18:39:16 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

Sorry, but I am kind of lost what you are expecting here. All the logs that you provided seem to be working exactly what is expected. Are you expecting `COMPAT` to auto-detect the source file (Hello.java) encoding?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From duke at openjdk.java.net  Wed Nov 24 18:51:12 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Wed, 24 Nov 2021 18:51:12 GMT
Subject: Integrated: 8274161: Cleanup redundant casts in jdk.compiler
In-Reply-To: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
References: <B_wp3ckM_aRapSVf7aomrpbKbuDoyJL1DU6FyrNsp5U=.d0ebd1d0-8028-4c2f-a496-b3dc6a3cfbca@github.com>
Message-ID: <LepQ8u3eg_f_n2ckCiAaEAzNY11N3D0bD4Xn8wx30GE=.37937941-0645-4cd9-91aa-d323b8a2269d@github.com>

On Fri, 27 Aug 2021 18:30:31 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Such casts are actually redundant, but they are inserted, because variable is declared with too weak type.

This pull request has now been integrated.

Changeset: 077b2de0
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/077b2de088665b907dbfc2b0522a1e109d1d2ca3
Stats:     22 lines in 5 files changed: 0 ins; 0 del; 22 mod

8274161: Cleanup redundant casts in jdk.compiler

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/5283

From mr at openjdk.java.net  Wed Nov 24 19:44:16 2021
From: mr at openjdk.java.net (Mark Reinhold)
Date: Wed, 24 Nov 2021 19:44:16 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
Message-ID: <G4iP2ovtlWo-0TKRqnEC9FqSXqriLEqMW6FHvdKAE9I=.ea4cbcb1-d44a-48c7-90b0-8816a27e8465@github.com>

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

A user who?s not familiar with the lingo of [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/) will be mystified by an option named `--source-date`.  A user who just wants to set the timestamp of new entries won?t be looking for an option whose name includes ?source.?

Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME). That would solve the general problem while also satisfying the requirement for reproducible builds. In the build it?s easy enough to convert the seconds-since epoch value of `SOURCE_DATE_EPOCH` to an ISO 8601 string (`date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From vromero at openjdk.java.net  Wed Nov 24 22:44:33 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 24 Nov 2021 22:44:33 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied to
 the anonymous class constructor
Message-ID: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>

Please review this PR which is about propagating constructor and parameter annotations to the anonymous class constructor. Currently we are propagating them to bridge methods which are synthetic. Propagating them to the anonymous class constructor seems sensible given that they are mandated by the spec. Please review also the related CSR,

TIA

-------------

Commit messages:
 - removing dead code
 - 8274617: constructor and parameter annotations are not copied to the anonymous class constructor

Changes: https://git.openjdk.java.net/jdk/pull/6548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6548&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274617
  Stats: 135 lines in 3 files changed: 134 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6548/head:pull/6548

PR: https://git.openjdk.java.net/jdk/pull/6548

From itakiguchi at openjdk.java.net  Wed Nov 24 22:49:03 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 24 Nov 2021 22:49:03 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <_QbaoDO0VE5FNiLn4P7MzcNmgmuQbEz91_4giSGKFkA=.0310a8b1-a171-4de5-a0a3-7ea8d3564188@github.com>
Message-ID: <VMSKOLxfyyIfUPFSz-aDNsowH9AN8c7aMZquVXHSLBo=.05938046-e2a5-4ed3-8faf-9dbc64e9b806@github.com>

On Wed, 24 Nov 2021 18:35:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8277398: javac does not accept encoding name COMPAT
>
> Sorry, but I am kind of lost what you are expecting here. All the logs that you provided seem to be working exactly what is expected. Are you expecting `COMPAT` to auto-detect the source file (Hello.java) encoding?

Hello @naotoj .
I'm sorry, my explanation was not enough.
I prefer to use `-encoding XXX` option for javac instead of `-J-Dfile.encoding=COMPAT` since working behavior is not same.
But I don't want to find out native encoding name `XXX` before compilation.
Native encoding name is not easy to find out without executing java,
Locale's charmap name was `EUC-JP`, but Java's encoding name was `EUC-JP-LINUX` in the above case.
I think another option is required to reference native encoding.
`-encoding COMPAT` is one example.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From duke at openjdk.java.net  Wed Nov 24 23:13:26 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Wed, 24 Nov 2021 23:13:26 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
Message-ID: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>

JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

-------------

Commit messages:
 - Fixed @code and @link in some javadoc for JDK-8276674

Changes: https://git.openjdk.java.net/jdk/pull/6443/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6443&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276674
  Stats: 14 lines in 9 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6443.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6443/head:pull/6443

PR: https://git.openjdk.java.net/jdk/pull/6443

From jjg at openjdk.java.net  Wed Nov 24 23:13:26 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 24 Nov 2021 23:13:26 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Remarkable to have not been noticed for so long!

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6443

From rriggs at openjdk.java.net  Wed Nov 24 23:13:27 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 24 Nov 2021 23:13:27 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <Sh7hlXG4_5FKRzt2ovXEJRel23t9Mn9FQBdLL2cs-Fw=.77f03a88-f0a8-490f-ab32-4b827fe8ad6d@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6443

From naoto at openjdk.java.net  Thu Nov 25 00:00:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Nov 2021 00:00:07 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <qnTF4Od1wHzZMF9Y7acPSs6jso_unZDuhMYHvl-J4lY=.54e1caee-1f36-4849-a45d-92c7ba167c48@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

If you give `-J-Dfile.encoding=COMPAT`, you don't need to know the native encoding name beforehand or at all, do you? All things are done in `EUC-JP` under the cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From prappo at openjdk.java.net  Thu Nov 25 00:24:04 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 25 Nov 2021 00:24:04 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
 <7aknHgeAhXZtiJENc3MIvUBIl6vtlYSixOXcdRVfpuk=.590d68a2-df34-44ba-a111-7673e47c7351@github.com>
Message-ID: <m_mNhXsfqcKnTMJ6ZvSj8aSvrPNncfmztMht5KMVP68=.3a93b434-4d41-4ee9-9655-6e21e46c808a@github.com>

On Thu, 18 Nov 2021 19:18:24 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Remarkable to have not been noticed for so long!

Remarkable, but not too surprising: the PR consists of source files and tests that are not part of the API Documentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6443

From prappo at openjdk.java.net  Thu Nov 25 00:36:09 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 25 Nov 2021 00:36:09 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
Message-ID: <cvm208-sAlohW4rYOW5aMfJ19zIWGTn_vkikI6OOQpA=.d4ee7ee9-afff-4825-8f33-98894d8a9fb8@github.com>

On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Looks good.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 63:

> 61:      * Helper class to generate stable positions for AST nodes occurring in diagnostic arguments.
> 62:      * If the AST node appears in the same line number as the main diagnostic, the line is information is omitted.
> 63:      * Otherwise both line and column information is included, using the format {@code line:col}".

Not a showstopper by any means. But while you are at it, maybe you could also fix this?

Suggestion:

     * If the AST node appears in the same line number as the main diagnostic, the line information is omitted.
     * Otherwise both line and column information is included, using the format {@code line:col}.

-------------

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6443

From itakiguchi at openjdk.java.net  Thu Nov 25 01:02:09 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 25 Nov 2021 01:02:09 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
Message-ID: <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>

On Wed, 24 Nov 2021 04:08:43 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> ncoding name COMPAT was defined for operating system encoding by JEP-400.
>> https://openjdk.java.net/jeps/400
>> But java does not accept "-encoding COMPAT".
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277398: javac does not accept encoding name COMPAT

As I explained before, output file encoding which is created by `-Xstdout` option is changed to native encoding instead of UTF-8 by `-J-Dfile.encoding=COMPAT`.
In case of Linux ja_JP.eucjp locale, your explanation may be acceptable.
But how  about Windows platform ?
How can user find encoding name without running java ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From jpai at openjdk.java.net  Thu Nov 25 02:16:12 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 25 Nov 2021 02:16:12 GMT
Subject: Integrated: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time
In-Reply-To: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
Message-ID: <KQKT_irPF-dhs_gzri5I5LV_6SmAvlg4JzLCBXAOyME=.a50a4d88-791d-4d85-9114-80356f18c058@github.com>

On Mon, 13 Sep 2021 05:35:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
> 
> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
> 
> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
> 
> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
> 
> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
> 
> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.

This pull request has now been integrated.

Changeset: a81e4fc0
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a81e4fc07b654a3cc954921981d9d3c0cfd8bcec
Stats:     285 lines in 2 files changed: 263 ins; 0 del; 22 mod

8258117: jar tool sets the time stamp of module-info.class entries to the current time

Reviewed-by: lancea, ihse, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From jpai at openjdk.java.net  Thu Nov 25 02:16:10 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 25 Nov 2021 02:16:10 GMT
Subject: RFR: 8258117: jar tool sets the time stamp of module-info.class
 entries to the current time [v9]
In-Reply-To: <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
References: <Porm6ao7GOo28wDuGkkzuSo-bvTPiuq-rfW8Q6--0Rg=.3f810032-cb23-49e5-b35b-d90581568df2@github.com>
 <OmNBA2Dr3nFPxTFD01QoOSmnzWDRXdpY8VPEhy95M-Y=.fa7b621a-2876-4893-bbe0-48d38e6dd174@github.com>
Message-ID: <5nhqPAriPCz_wK0bb8enatWrZwIELVaAo3jOKkINXu8=.2c699596-d640-4d83-a550-d6f8b9c446a2@github.com>

On Wed, 24 Nov 2021 15:04:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The commit here is a potential fix for the issue noted in https://bugs.openjdk.java.net/browse/JDK-8258117.
>> 
>> The change here repurposes an existing internal interface `ModuleInfoEntry` to keep track of the last modified timestamp of a `module-info.class` descriptor.
>> 
>> This commit uses the timestamp of the `module-info.class` on the filesystem to set the time on the `JarEntry`. There are a couple of cases to consider here:
>> 
>> 1. When creating a jar  (using `--create`), we use the source `module-info.class` from the filesystem and then add extended info to it (attributes like packages, module version etc...). In such cases, this patch will use the lastmodified timestamp from the filesystem of `module-info.class` even though we might end up updating/extending/modifying (for example by adding a module version) its content while storing it as a `JarEntry`. 
>> 
>> 2. When updating a jar (using `--update`), this patch will use the lastmodified timestamp of `module-info.class` either from the filesystem or from the source jar's entry (depending on whether a new `module-info.class` is being passed to the command). Here too, it's possible that we might end up changing/modifying/extending the `module-info.class` (for example, changing the module version to a new version) that gets written into the updated jar file, but this patch _won't_ use `System.currentTimeMillis()` even in such cases.
>> 
>> If we do have to track actual changes that might happen to `module-info.class` while extending its info (in `extendedInfoBytes()`) and then decide whether to use current system time as last modified time, then this will require a bigger change and also a discussion on what kind of extending of module-info.class content will require a change to the lastmodifiedtime of that entry.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review suggestion - format code in ModuleInfoEntry to use 4 space indentation
>  - review suggestion - change javadoc to mention module-info.class instead of module descriptor
>  - review suggestion - use if/else instead of ternary operator

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5486

From jgneff at openjdk.java.net  Thu Nov 25 03:41:06 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 25 Nov 2021 03:41:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
Message-ID: <LFPCGGOSxU1R62qSnmGCO9vBKO-9NkCVKu3rDQeza5o=.25add1e9-2fe6-4404-8d76-759f0503a6dc@github.com>

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I just tested this pull request by building [my JavaFX pull request][1] on six Linux architectures, and it works beautifully!

First I built this pull request branch of OpenJDK for Linux on the following hardware platforms: amd64 (x86_64), arm64 (aarch64), armhf (armv7l), i386 (i636), ppc64el (ppc64le), and s390x (s390x).

Then I added three lines of Groovy code to the JavaFX `build.gradle` file where it invokes the `jmod` tool:


    if (sourceDateEpoch != null) {
        args("--source-date", sourceDateEpoch)
    }


Then I built JavaFX twice for each of the architectures, with each build on a clean, isolated container created from scratch. The result is 6 architectures ? 4,360 files = 26,160 identical files between the two sets of builds. The JMOD archives were the last missing piece for JavaFX, so thank you, Andrew, for completing the puzzle.

By the way, my builds of OpenJDK did not include your `jarjmodorder` branch, yet the order for the entries in the JMOD archives are the same. In fact, I checked my old builds and the entry order has always been the same between builds for the JMOD archives. Only the entry timestamps were different. Is that expected? I mean, although the order is not deterministic, is it expected that they would end up in the same order when the archives are built in the same environment by the same build process?

[1]: https://github.com/openjdk/jfx/pull/446

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Thu Nov 25 08:37:17 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 08:37:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
Message-ID: <d782-ZKIoNOmWA5vkCdf6wqrKeW9_-_cx5TolVdPG2Y=.0fc0cd2a-f3b6-4b4d-ac21-324d2ebf12ac@github.com>

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

> I just tested this pull request by building [my JavaFX pull request](https://github.com/openjdk/jfx/pull/446) on six Linux architectures, and it works beautifully!
> 
> First I built this pull request branch of OpenJDK for Linux on the following hardware platforms: amd64 (x86_64), arm64 (aarch64), armhf (armv7l), i386 (i636), ppc64el (ppc64le), and s390x (s390x).
> 
> Then I added three lines of Groovy code to the JavaFX `build.gradle` file where it invokes the `jmod` tool:
> 
> ```groovy-gradle
>     if (sourceDateEpoch != null) {
>         args("--source-date", sourceDateEpoch)
>     }
> ```
> 
> Then I built JavaFX twice for each of the architectures, with each build on a clean, isolated container created from scratch. The result is 6 architectures ? 4,360 files = 26,160 identical files between the two sets of builds. The JMOD archives were the last missing piece for JavaFX, so thank you, Andrew, for completing the puzzle.
> 
> By the way, my builds of OpenJDK did not include your `jarjmodorder` branch, yet the order for the entries in the JMOD archives are the same. In fact, I checked my old builds and the entry order has always been the same between builds for the JMOD archives. Only the entry timestamps were different. Is that expected? I mean, although the order is not deterministic, is it expected that they would end up in the same order when the archives are built in the same environment by the same build process?

@jgneff thank you for testing, that's great news
on the "ordering" issue, it depends on your OS architecture among probably other things... for example try this:
- Build 1: on a Ubuntu 20.04 running on an Intel processor
- Build 2: on a Ubuntu 20.04 running on an AMD processor
I suspect you will find the order will differ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Thu Nov 25 09:41:09 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 09:41:09 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
Message-ID: <rwXPlIggUkgU5spV8XIW3KpsyR6zoNv5j-0e8wxHWqk=.6e0f2d5c-1a8b-43de-89c4-59659fa91f93@github.com>

On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/JarEntryTime.java line 129:
> 
>> 127:         // Make a jar file from that directory structure with
>> 128:         // --source-date set to epoch seconds 1647302400 (15/03/2022)
>> 129:         long sourceDate = 1647302400L;
> 
> Please consider  adding a few before Epoch test values.

@LanceAndersen can you clarify your meaning here please? Are you referring to negative sourceDate? I put in the CSR that it was seconds "since" epoch akin to SOURCE_DATE_EPOCH, which as far as I can tell does not support negative values, as some time implementations won't support that. 
But this does imply I should add some -ve validation checks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Thu Nov 25 10:05:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 10:05:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <rwXPlIggUkgU5spV8XIW3KpsyR6zoNv5j-0e8wxHWqk=.6e0f2d5c-1a8b-43de-89c4-59659fa91f93@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
 <rwXPlIggUkgU5spV8XIW3KpsyR6zoNv5j-0e8wxHWqk=.6e0f2d5c-1a8b-43de-89c4-59659fa91f93@github.com>
Message-ID: <8LenSAmqFgWnILeLaajVzTTStpY47_VJoCRBZEkW_Ps=.8bae52fe-39c8-4800-a209-71ad68f5c712@github.com>

On Thu, 25 Nov 2021 09:37:59 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> test/jdk/tools/jar/JarEntryTime.java line 129:
>> 
>>> 127:         // Make a jar file from that directory structure with
>>> 128:         // --source-date set to epoch seconds 1647302400 (15/03/2022)
>>> 129:         long sourceDate = 1647302400L;
>> 
>> Please consider  adding a few before Epoch test values.
>
> @LanceAndersen can you clarify your meaning here please? Are you referring to negative sourceDate? I put in the CSR that it was seconds "since" epoch akin to SOURCE_DATE_EPOCH, which as far as I can tell does not support negative values, as some time implementations won't support that. 
> But this does imply I should add some -ve validation checks.

I think we could support -ve values, though i'd need to alter a couple of things

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Thu Nov 25 10:16:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 10:16:10 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
Message-ID: <Oecc7g5ziPSU83nCT4AJTMt09DWg6HT8xft0ZtSDtmU=.5e1ee55c-e352-47e7-af9c-25f72221dcf2@github.com>

On Wed, 24 Nov 2021 16:48:42 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/man/jar.1 line 1:
> 
>> 1: .\" Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> The man pages are maintained in the close repository

I'll raise a separate bug to get that changed

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From duke at openjdk.java.net  Thu Nov 25 10:32:10 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 25 Nov 2021 10:32:10 GMT
Subject: Withdrawn: 8268312: Compilation error with nested generic functional
 interface
In-Reply-To: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
References: <DEIO0KG0-b3cxa0iS8U26nknAD4xeM40v_CY9c35rw8=.7c5720dc-1a07-4bee-afca-ade646e4e6cf@github.com>
Message-ID: <D7e8qraydGblYkeA7hHZgQUHFhoJVbfDmgATh3wTPzY=.ea687697-8df5-4161-a4dd-0a94f736b388@github.com>

On Mon, 20 Sep 2021 19:00:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR, which is my proposal to fix an existing regression. This code:
> 
> 
> import java.util.Optional;
> 
> class App {
>     public static void main(String[] args) {
>         Optional.of("").map(outer -> {
>             Optional.of("")
>                 .map(inner -> returnGeneric(outer))
>                 .ifPresent(String::toString);
>             return "";
>         });
>     }
> 
>     private static <RG> RG returnGeneric(RG generic) {
>         return generic;
>     }
> }
> 
> is not accepted by javac but if the user passes the `-Xdiags:verbose` option then the code compiles. I tracked down the reason for this puzzling difference and I found that it is due to our diagnostic rewriters which can generate more detailed positions for error messages but in cases like the one above can trick the compiler to generate an error message too early. The code deciding if an error message should be deferred or not, depending on the position, is at `DeferredDiagnosticHandler::report`. We decide to do the rewriting if we are in diagnostics compact mode, this is why the error doesn't occur with the `-Xdiags:verbose` option. This fix will made some diagnostics to appear at a slightly different position, but won't make the compiler reject correct code. Comments?
> 
> TIA

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5586

From aleonard at openjdk.java.net  Thu Nov 25 10:59:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 10:59:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <G4iP2ovtlWo-0TKRqnEC9FqSXqriLEqMW6FHvdKAE9I=.ea4cbcb1-d44a-48c7-90b0-8816a27e8465@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <G4iP2ovtlWo-0TKRqnEC9FqSXqriLEqMW6FHvdKAE9I=.ea4cbcb1-d44a-48c7-90b0-8816a27e8465@github.com>
Message-ID: <I2ygiWfFS8jrNef3g5OB661WEUnvmGAaW7DG9Gz_tis=.a8e7ff71-8df9-4e14-b5d2-2f3da8b4f74d@github.com>

On Wed, 24 Nov 2021 19:40:38 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> A user who?s not familiar with the lingo of [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/) will be mystified by an option named `--source-date`. A user who just wants to set the timestamp of new entries won?t be looking for an option whose name includes ?source.?
> 
> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME). That would solve the general problem while also satisfying the requirement for reproducible builds. In the build it?s easy enough to convert the seconds-since epoch value of `SOURCE_DATE_EPOCH` to an ISO 8601 string (`date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds`).

Thanks @mbreinhold , good point, i'll update to use --date=<iso-8601-date\>

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Thu Nov 25 18:00:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 25 Nov 2021 18:00:12 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
Message-ID: <pefodxVrx_3CbXxe1wc7FHhgErg-Nr40hj7SgmZGKeU=.d99435c5-5c6a-42fd-ac80-40ee1b9882d4@github.com>

On Wed, 24 Nov 2021 16:43:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> test/jdk/tools/jar/JarEntryTime.java line 129:
> 
>> 127:         // Make a jar file from that directory structure with
>> 128:         // --source-date set to epoch seconds 1647302400 (15/03/2022)
>> 129:         long sourceDate = 1647302400L;
> 
> Please consider  adding a few before Epoch test values.

@LanceAndersen java File times can't be before the epoch, but having a test before dostime 1980 would be useful

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Thu Nov 25 19:25:04 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 25 Nov 2021 19:25:04 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <I2ygiWfFS8jrNef3g5OB661WEUnvmGAaW7DG9Gz_tis=.a8e7ff71-8df9-4e14-b5d2-2f3da8b4f74d@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <G4iP2ovtlWo-0TKRqnEC9FqSXqriLEqMW6FHvdKAE9I=.ea4cbcb1-d44a-48c7-90b0-8816a27e8465@github.com>
 <I2ygiWfFS8jrNef3g5OB661WEUnvmGAaW7DG9Gz_tis=.a8e7ff71-8df9-4e14-b5d2-2f3da8b4f74d@github.com>
Message-ID: <dWajgHz0ucygFVptf10AQpaubDoK9biO-dRQP0r05E4=.594dd497-87b3-4ad5-bcbd-b93e94ef4c6c@github.com>

On Thu, 25 Nov 2021 10:55:45 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).

The `jar` and `jmod` tools will need to truncate, restrict, or convert the time zone and fractional seconds permitted by the ISO 8601 date and time format.

The only way I found to store a timestamp using the methods of `java.util.zip.ZipEntry` that was independent of the system's time zone was by passing a local date and time in UTC to `setTimeLocal(LocalDateTime)`, truncated to seconds.

You can store a zoned date and time indirectly (in seconds) by adding an extra extended timestamp field to each entry with `setLastModifiedTime(FileTime)`. Unfortunately, that method also stores the "MS-DOS date and time" as the local date and time in the default time zone of the JVM (the time zone of the build machine). Furthermore, the extra field added to each entry increases the size of the archive.

The beauty of the `SOURCE_DATE_EPOCH` value is that it avoids any confusion in its interpretation while providing a straightforward solution to the only users ever known to need it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From coffeys at openjdk.java.net  Fri Nov 26 12:27:07 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 26 Nov 2021 12:27:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
Message-ID: <4kOSu0L-IiTV9f76yffhWWxs5hdBroRU7hvpkBoGP58=.fb32c313-739e-413f-9f65-2ece3d69a2c3@github.com>

On Wed, 24 Nov 2021 16:56:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2290:
> 
>> 2288:     private void setSourceDate(ZipEntry e, long origTime) {
>> 2289:         if (sourceDate != -1) {
>> 2290:           e.setTimeLocal(LocalDateTime.ofEpochSecond(sourceDate, 0, ZoneOffset.UTC));
> 
> The above could potentially throw a DateTimeException which may be OK but I would sanity check there are no issues

For files with large number of entries, alot of LocalDateTime Objects are being created here. Would there be an efficiency gain by converting sourceDate variable to be of type LocalDateTime and simply pass it to the s.setTimeLocal call here. The LocalDateTime Object could be constructed at init time (may be null) and can be static etc. 

Same for jmod code ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jlahoda at openjdk.java.net  Fri Nov 26 14:35:27 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 26 Nov 2021 14:35:27 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v7]
In-Reply-To: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
Message-ID: <qQMZ4T6w1Okwfpxt5uClcgT6M3ahCYQRnOG5pjG3Kok=.cce9dfdd-edd7-427e-b20e-a7bc9597c305@github.com>

> This is a first prototype of a patch that propagates originating elements from `Filer` (`createSourceFile`/`createClassFile`/`createResource`) to the corresponding methods in `JavaFileManager`. As file managers generally don't know about `Element`s, the `Element`s are first converted to their corresponding `FileObject`s (if any). As the currently existing methods only take one `FileObject` as a sibling of the newly created file, a new set of methods is proposed that take multiple originating files.
> 
> Any feedback on this prototype would be welcome.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge branch 'master' into ap-keep-originating-elements
 - Applying changes as suggested on the review.
 - Improving javadoc as suggested in the PR.
 - Test cleanup.
 - Merge branch 'ap-keep-originating-elements' into ap-keep-originating-elements-forwarding-tweak
 - Cleanup
 - Merge branch 'master' into ap-keep-originating-elements
 - Fixing test (need to exclude a private method from the test).
 - Fixing typo, as per review comments.
 - Fixing javadoc.
 - ... and 18 more: https://git.openjdk.java.net/jdk/compare/040b2c52...e191d936

-------------

Changes: https://git.openjdk.java.net/jdk/pull/5076/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5076&range=06
  Stats: 728 lines in 7 files changed: 718 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5076.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5076/head:pull/5076

PR: https://git.openjdk.java.net/jdk/pull/5076

From lancea at openjdk.java.net  Fri Nov 26 16:29:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 26 Nov 2021 16:29:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <4kOSu0L-IiTV9f76yffhWWxs5hdBroRU7hvpkBoGP58=.fb32c313-739e-413f-9f65-2ece3d69a2c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
 <4kOSu0L-IiTV9f76yffhWWxs5hdBroRU7hvpkBoGP58=.fb32c313-739e-413f-9f65-2ece3d69a2c3@github.com>
Message-ID: <0EZdECmKFHRhnfDk7zwWAZ75rwWDPOPRKeGwY-DbY_c=.db2bfb76-4fc5-45be-a035-fb27bda426fc@github.com>

On Fri, 26 Nov 2021 12:23:41 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2290:
>> 
>>> 2288:     private void setSourceDate(ZipEntry e, long origTime) {
>>> 2289:         if (sourceDate != -1) {
>>> 2290:           e.setTimeLocal(LocalDateTime.ofEpochSecond(sourceDate, 0, ZoneOffset.UTC));
>> 
>> The above could potentially throw a DateTimeException which may be OK but I would sanity check there are no issues
>
> For files with large number of entries, alot of LocalDateTime Objects are being created here. Would there be an efficiency gain by converting sourceDate variable to be of type LocalDateTime and simply pass it to the s.setTimeLocal call here. The LocalDateTime Object could be constructed at init time (may be null) and can be static etc. 
> 
> Same for jmod code ?

> 

I think that is a reasonable suggestion

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From lancea at openjdk.java.net  Fri Nov 26 16:29:07 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 26 Nov 2021 16:29:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <pefodxVrx_3CbXxe1wc7FHhgErg-Nr40hj7SgmZGKeU=.d99435c5-5c6a-42fd-ac80-40ee1b9882d4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
 <pefodxVrx_3CbXxe1wc7FHhgErg-Nr40hj7SgmZGKeU=.d99435c5-5c6a-42fd-ac80-40ee1b9882d4@github.com>
Message-ID: <LrX97UarMfwJ0Uf9cyasPPpW3ExPYCcwgSX9H-4Y7FM=.838c8230-3c10-4f5c-8648-667fd62ed571@github.com>

On Thu, 25 Nov 2021 17:57:20 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> test/jdk/tools/jar/JarEntryTime.java line 129:
>> 
>>> 127:         // Make a jar file from that directory structure with
>>> 128:         // --source-date set to epoch seconds 1647302400 (15/03/2022)
>>> 129:         long sourceDate = 1647302400L;
>> 
>> Please consider  adding a few before Epoch test values.
>
> @LanceAndersen java File times can't be before the epoch, but having a test before dostime 1980 would be useful

> 

The change to sun/tools/jar/GNUStyleOptions.java does not prevent a negative value which can be set via ZipEntry similar to:

    public void testOfEpochSecond() {
        var ze = new ZipEntry("test");
        for(var i =  0; i < 100; i++) {
            var time = LocalDateTime.ofEpochSecond(-i, 0, ZoneOffset.UTC);
            ze.setTimeLocal(time);
            System.out.printf(
                    "time= %s, Zip Entry time= %s%n", time, ze.getTimeLocal());
        }
    }

If the intent is to not support dates prior to the Epoch then GNUStyleOptions should throw an Exception in this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From darcy at openjdk.java.net  Mon Nov 29 07:14:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Nov 2021 07:14:37 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v4]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <qfLKkCTWly1jWnzEtzjtwolkAIsVgmX1tCvdNJ6iS54=.97b61c55-a9a3-4bd3-9845-aef5969839de@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - Add --release 18 information. Good tier1 test results.
 - JDK-8273146: Start of release updates for JDK 19

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/5fe55cbf..5c36a2ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=02-03

  Stats: 21630 lines in 395 files changed: 12529 ins; 5912 del; 3189 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From aleonard at openjdk.java.net  Mon Nov 29 11:13:49 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 11:13:49 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v5]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <vPXFz2-WBvvN3_ZN1GXMLFnZGSbdzsOUN_UbuAGZKco=.02d7997a-f931-402e-8672-35ce3b335e2e@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/6d372436..3768810f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=03-04

  Stats: 359 lines in 12 files changed: 280 ins; 14 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 11:18:42 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 11:18:42 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v6]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <ZUn5dPKU2j7OiRmQvji8eZ1kUwt8GNr_kOPB7TQiLSc=.977deec2-6a0b-46dc-afcd-37e1cf0490c4@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/3768810f..7f24db78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=04-05

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:04:31 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:04:31 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v7]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <y3w40fyyVpyt-VeJLICqNrIgQK-zMeYloO2AAtonvAY=.62ebb543-a35d-4678-bc60-b9324499be95@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=06
  Stats: 544 lines in 11 files changed: 515 ins; 0 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:13:34 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:13:34 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v8]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <4bhhLstqQbHlW3EOMkPTFFH7GbxABfFPJ9bqlG2_lpU=.66ed350d-f140-483b-bc3e-c796c57a1e8b@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/4deb80ea..c7928bfe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=06-07

  Stats: 50 lines in 3 files changed: 40 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From alanb at openjdk.java.net  Mon Nov 29 16:22:33 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 29 Nov 2021 16:22:33 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>

On Mon, 29 Nov 2021 16:19:01 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

@andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.

-------------

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:22:30 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:22:30 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/c7928bfe..6206c1ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=07-08

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:22:34 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:22:34 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <0EZdECmKFHRhnfDk7zwWAZ75rwWDPOPRKeGwY-DbY_c=.db2bfb76-4fc5-45be-a035-fb27bda426fc@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
 <4kOSu0L-IiTV9f76yffhWWxs5hdBroRU7hvpkBoGP58=.fb32c313-739e-413f-9f65-2ece3d69a2c3@github.com>
 <0EZdECmKFHRhnfDk7zwWAZ75rwWDPOPRKeGwY-DbY_c=.db2bfb76-4fc5-45be-a035-fb27bda426fc@github.com>
Message-ID: <yFyF2W1YhS1mdXlcl6MYf96xJo389HTGoU2LCWV-nwk=.c54314e4-b0f8-4536-814a-7cb8d88c942a@github.com>

On Fri, 26 Nov 2021 16:25:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> For files with large number of entries, alot of LocalDateTime Objects are being created here. Would there be an efficiency gain by converting sourceDate variable to be of type LocalDateTime and simply pass it to the s.setTimeLocal call here. The LocalDateTime Object could be constructed at init time (may be null) and can be static etc. 
>> 
>> Same for jmod code ?
>
>> 
> 
> I think that is a reasonable suggestion

The ZonedDateTime is now resolved during parsing of the options.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:22:36 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:22:36 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <LrX97UarMfwJ0Uf9cyasPPpW3ExPYCcwgSX9H-4Y7FM=.838c8230-3c10-4f5c-8648-667fd62ed571@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <hbOxZ-V1hIzMJqMWv0HqNxr94lVs2Or6ob1GI-thXeg=.e7f16c7f-cbbb-48d9-b756-4ab8814ebc22@github.com>
 <pefodxVrx_3CbXxe1wc7FHhgErg-Nr40hj7SgmZGKeU=.d99435c5-5c6a-42fd-ac80-40ee1b9882d4@github.com>
 <LrX97UarMfwJ0Uf9cyasPPpW3ExPYCcwgSX9H-4Y7FM=.838c8230-3c10-4f5c-8648-667fd62ed571@github.com>
Message-ID: <WojrH5dZB466e7NVKD4xFCzauz_XW9_nyUzqu1ohNcA=.9b768d12-3229-4304-936a-7114a66f2f04@github.com>

On Fri, 26 Nov 2021 16:24:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> @LanceAndersen java File times can't be before the epoch, but having a test before dostime 1980 would be useful
>
>> 
> 
> The change to sun/tools/jar/GNUStyleOptions.java does not prevent a negative value which can be set via ZipEntry similar to:
> 
>     public void testOfEpochSecond() {
>         var ze = new ZipEntry("test");
>         for(var i =  0; i < 100; i++) {
>             var time = LocalDateTime.ofEpochSecond(-i, 0, ZoneOffset.UTC);
>             ze.setTimeLocal(time);
>             System.out.printf(
>                     "time= %s, Zip Entry time= %s%n", time, ze.getTimeLocal());
>         }
>     }
> 
> If the intent is to not support dates prior to the Epoch then GNUStyleOptions should throw an Exception in this case.

Added more tests, and negative check

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:29:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:29:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v4]
In-Reply-To: <dWajgHz0ucygFVptf10AQpaubDoK9biO-dRQP0r05E4=.594dd497-87b3-4ad5-bcbd-b93e94ef4c6c@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <09-iIeNkg3QfjrCS5V0zRXr3nKA0HZEb6vHb6kLzEsw=.a0f870b3-c02b-4982-8542-2c36a96ca5c3@github.com>
 <G4iP2ovtlWo-0TKRqnEC9FqSXqriLEqMW6FHvdKAE9I=.ea4cbcb1-d44a-48c7-90b0-8816a27e8465@github.com>
 <I2ygiWfFS8jrNef3g5OB661WEUnvmGAaW7DG9Gz_tis=.a8e7ff71-8df9-4e14-b5d2-2f3da8b4f74d@github.com>
 <dWajgHz0ucygFVptf10AQpaubDoK9biO-dRQP0r05E4=.594dd497-87b3-4ad5-bcbd-b93e94ef4c6c@github.com>
Message-ID: <vfQSg9EQRNXlb93Khu0cyIwBlMB6CLu8xbW0KkOajCI=.e7ed5aec-0328-47b1-8bc9-2ae0f66d558c@github.com>

On Thu, 25 Nov 2021 19:21:36 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> A user who?s not familiar with the lingo of [reproducible builds](https://reproducible-builds.org/docs/source-date-epoch/) will be mystified by an option named `--source-date`. A user who just wants to set the timestamp of new entries won?t be looking for an option whose name includes ?source.?
>>> 
>>> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME). That would solve the general problem while also satisfying the requirement for reproducible builds. In the build it?s easy enough to convert the seconds-since epoch value of `SOURCE_DATE_EPOCH` to an ISO 8601 string (`date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds`).
>> 
>> Thanks @mbreinhold , good point, i'll update to use --date=<iso-8601-date\>
>
>> Please consider providing a more general option, say `--date`, which takes an [ISO 8601 date/time string](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/format/DateTimeFormatter.html#ISO_DATE_TIME).
> 
> The `jar` and `jmod` tools will need to truncate, restrict, or convert the time zone and fractional seconds permitted by the ISO 8601 date and time format.
> 
> The only way I found to store a timestamp using the methods of `java.util.zip.ZipEntry` that was independent of the system's time zone was by passing a local date and time in UTC to `setTimeLocal(LocalDateTime)`, truncated to seconds.
> 
> You can store a zoned date and time indirectly (in seconds) by adding an extra extended timestamp field to each entry with `setLastModifiedTime(FileTime)`. Unfortunately, that method also stores the "MS-DOS date and time" as the local date and time in the default time zone of the JVM (the time zone of the build machine). Furthermore, the extra field added to each entry increases the size of the archive.
> 
> The beauty of the `SOURCE_DATE_EPOCH` value is that it avoids any confusion in its interpretation while providing a straightforward solution to the only users ever known to need it.

@jgneff @LanceAndersen As John has pointed out there is a fundamental issue with the current ZipEntry API, in that for the conversion to/from (setTime()/getTime()) MS-DOS dostime it has to infer the time-zone from the current JVM default, so it can then workout the millis since epoch. Using set/getLocalDateTime() is only a half solution, that will only work as long as there isn't an extended FileTime being stored in the ZipEntry, which will occur for years  <1980 or >2106.

My updated PR proposes an extension to the ZipEntry API (and thus the CSR) to handle Zoned times for set/get, with the addition of the following API extensions to ZipEntry:
void setTimeZoned(ZonedDateTime)
ZonedDateTime getTimeZoned(ZoneId)
ZipEntry setLastModifiedTimeZoned(FileTime, ZoneId)
FileTime getLastModifiedTimeZoned(ZoneId)

Your thoughts are appreciated please?
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Mon Nov 29 16:34:06 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 16:34:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
Message-ID: <F6StKBZnCMbNP961y6imz1oPcUzvbg1SSO3zXV3SyQY=.65154219-6ed5-43a6-8f73-5c8df58290e5@github.com>

On Mon, 29 Nov 2021 16:18:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.

@AlanBateman yes, see above comment, thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From alanb at openjdk.java.net  Mon Nov 29 17:11:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 29 Nov 2021 17:11:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
Message-ID: <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>

On Mon, 29 Nov 2021 16:18:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>>    
>>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.

> @AlanBateman yes, see above comment, thanks

This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Mon Nov 29 17:14:08 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Mon, 29 Nov 2021 17:14:08 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <B_Bn4UGyDr_de6BryCG-i0_giIc0_tgcw9qR68l8EtY=.dfc1981a-0276-4e8b-8ba6-f6487612ef67@github.com>

On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

This is just a quick comment on the epoch date and time string. I'm testing your updates on the JavaFX builds now and will follow up with the results and more comments later today. Thanks, Andrew.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 88:

> 86:         date {0} is not a valid ISO 8601 date and time
> 87: error.date.before.epoch=\
> 88:         date {0} is before Epoch 1970-01-01T00:00:00

The epoch in Java is a [zoned date and time][1] (1970-01-01T00:00:00Z).

[1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/Instant.html#EPOCH

-------------

Changes requested by jgneff (no project role).

PR: https://git.openjdk.java.net/jdk/pull/6481

From naoto at openjdk.java.net  Mon Nov 29 17:32:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 29 Nov 2021 17:32:08 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
References: <b4099hHPqu8afnfH1oUlHKnApcG_T3ofseEqnn7_n2M=.4e78e037-1cd3-45a8-b0ba-0f09f48c4d93@github.com>
 <ywsfi6rzioH3hLVWl4h8RdE89KUiXFIJFgEH7Fen9yA=.4d008de5-369b-4092-bf48-329e209da8a7@github.com>
 <g3AdVBtrEbFzpNNmMp9CRTHMzKqKyqBinLLbZTCYoX4=.79dc25e3-f737-4a67-8786-e25cf4c42796@github.com>
Message-ID: <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>

On Thu, 25 Nov 2021 00:58:47 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> But how about Windows platform ?

If the user specifies `-J-Dfile.encoding=COMPAT`, all operations are done in `MS932` on Japanese Windows.

> How can user find encoding name without running java ?

I still don't get why the user needs to know the encoding if they specifies `COMPAT` property.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6475

From darcy at openjdk.java.net  Mon Nov 29 18:38:35 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Nov 2021 18:38:35 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v5]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <f2da2hwwbr9G7d2pV-HCEZuG4xOjKKLvHFml_HW3q3M=.c2c51c02-1532-4a74-9c57-62b0ed9019f9@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update symbol information for JDK 18 b25.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/5c36a2ef..53e46dec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=03-04

  Stats: 85 lines in 5 files changed: 62 ins; 22 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From jlahoda at openjdk.java.net  Mon Nov 29 18:46:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 29 Nov 2021 18:46:08 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
Message-ID: <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>

On Thu, 11 Nov 2021 13:47:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> The method `Gen#visitSwitchExpression` would switch code generation off by using the method `Code#markDead` when it meets the code like `throw new RuntimeException()`. Then the method `Gen#completeBinop` won't generate the expected code and wiil let the left operand stay in the stack without handling it.
> 
> This patch pops the left operand from the stack to solve this issue. And the corresponding test is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Thanks for looking into this and sorry for trouble.

One possible alternative that might work would be to put this only into `doHandleSwitchExpression`:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
index 9ef735e1543..f5d6430eecb 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
@@ -1237,6 +1237,9 @@ public class Gen extends JCTree.Visitor {
             try {
                 handleSwitch(tree, tree.selector, tree.cases, tree.patternSwitch);
             } finally {
+                if (!code.isAlive()) {
+                    code.state.pop(code.state.stacksize);
+                }
                 code.setLetExprStackPos(prevLetExprStart);
             }
         } finally {


But I am not sure offhand if it would not have some problems.

But, I wonder if we need to fix the simulated stack at all (as it won't be completely sensible in anyway). Maybe all we need is to disable the assertion?

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
index 9ef735e1543..08b075822c6 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
@@ -971,7 +971,7 @@ public class Gen extends JCTree.Visitor {
                     genStat(tree.body, env);
                 }
 
-                if (code.state.stacksize != 0) {
+                if (code.state.stacksize != 0 && code.isAlive()) {
                     log.error(tree.body.pos(), Errors.StackSimError(tree.sym));
                     throw new AssertionError();
                 }


In general, I am afraid there needs to be more testing:

- tests for compound assignments, roughly the same as for binary operators
- longer chains on binary operators - e.g. `4 + switch () {...} + 5`, `4 + switch () {...} + switch () {...}`, etc. (three operands would probably be enough)
- various other operand types - method invocations, array dereferences
- tests that employ boolean conditions (inside an `if` condition, for example)
- the tests should not only compile the code - they should also run it, and verify the resulting behavior
- possibly use such switch that does not return 

I can help with writing some tests, if needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6350

From lancea at openjdk.java.net  Mon Nov 29 19:12:09 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 29 Nov 2021 19:12:09 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
Message-ID: <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@github.com>

On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman yes, see above comment, thanks
> 
> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.

I agree with Alan.  We are too close to RDP 1 to consider this type of change for JDK 18 as we need more time to discuss, update the CSR, test (and we will need additional tests for this), and give it time to bake.  IMHO this will need to go into JDK 19 assuming we move forward with changes similar to the latest commit

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From vromero at openjdk.java.net  Mon Nov 29 19:13:29 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 29 Nov 2021 19:13:29 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean operations in
 jdk.compiler and langtools
Message-ID: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>

Hi,

Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.

TIA

-------------

Commit messages:
 - 8275771: JDK source code contains redundant boolean operations in jdk.compiler and langtools

Changes: https://git.openjdk.java.net/jdk/pull/6599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275771
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6599/head:pull/6599

PR: https://git.openjdk.java.net/jdk/pull/6599

From aleonard at openjdk.java.net  Mon Nov 29 19:31:06 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 29 Nov 2021 19:31:06 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
Message-ID: <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>

On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @andrew-m-leonard I see you've add several APIs to ZipEntry in this PR. I think this part will require discussion as it's not immediately clear that we should over burden the ZipEntry API as proposed.
>
>> @AlanBateman yes, see above comment, thanks
> 
> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.

> > > @AlanBateman yes, see above comment, thanks
> > 
> > 
> > This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.
> 
> I agree with Alan. We are too close to RDP 1 to consider this type of change for JDK 18 as we need more time to discuss, update the CSR, test (and we will need additional tests for this), and give it time to bake. IMHO this will need to go into JDK 19 assuming we move forward with changes similar to the latest commit

Thanks @LanceAndersen , @AlanBateman, i've just posted a discussion thread here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/084150.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From iris at openjdk.java.net  Mon Nov 29 19:53:10 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 29 Nov 2021 19:53:10 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v5]
In-Reply-To: <f2da2hwwbr9G7d2pV-HCEZuG4xOjKKLvHFml_HW3q3M=.c2c51c02-1532-4a74-9c57-62b0ed9019f9@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
 <f2da2hwwbr9G7d2pV-HCEZuG4xOjKKLvHFml_HW3q3M=.c2c51c02-1532-4a74-9c57-62b0ed9019f9@github.com>
Message-ID: <3IitEJDF2bwb41CY8BDHGMwrAAcU3ZfZKxOpYfOTiGQ=.89646199-abb3-4550-a4c6-edda6df8c32c@github.com>

On Mon, 29 Nov 2021 18:38:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
>> 
>> JDK-8277512: Add SourceVersion.RELEASE_19
>> https://bugs.openjdk.java.net/browse/JDK-8277512
>> 
>> JDK-8277514: Add source 19 and target 19 to javac
>> https://bugs.openjdk.java.net/browse/JDK-8277514
>> 
>> Clean local tier 1 test runs for langtools, jdk, and hotspot.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update symbol information for JDK 18 b25.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6493

From jlahoda at openjdk.java.net  Mon Nov 29 19:56:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 29 Nov 2021 19:56:08 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor
In-Reply-To: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
Message-ID: <zSKlGwba79rh2Uv7Olusq8D8uE2ImBybJZfDJ2alpik=.e026703c-acfe-404e-ae6b-6cf7e6c42bbe@github.com>

On Wed, 24 Nov 2021 22:34:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is about propagating constructor and parameter annotations to the anonymous class constructor. Currently we are propagating them to bridge methods which are synthetic. Propagating them to the anonymous class constructor seems sensible given that they are mandated by the spec. Please review also the related CSR,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1341:

> 1339:         public MethodSymbol constructorSymbol() {
> 1340:             // we should do this only once
> 1341:             boolean copyConstAnnos = constructorSymbol == null;

Question: can we avoid repeating this method completely if `constructorSymbol != null`? Seems a bit weird to not copy the annotation again (which I understand), but redo all the rest again.

test/langtools/tools/javac/annos_not_copied_anonymous_ctr/AnnosNotCopiedToAnonymousCtrTest.java line 116:

> 114:         @VisibleCtrAnnotation
> 115:         @InvisibleCtrAnnotation
> 116:         public Test(String firstParam, @VisibleParamAnnotation String secondParam, @InvisibleParamAnnotation String thirdParam) {}

How about type annotations of the parameter types? Should these be copied? (And tested?)

test/langtools/tools/jdeps/listdeps/ListModuleDeps.java line 98:

> 96:                                 "java.base/jdk.internal.jmod",
> 97:                                 "java.base/jdk.internal.misc",
> 98:                                 "java.base/jdk.internal.vm.annotation",

This looks a bit suspicious to me - why the new entry? Do we know why it was necessary? (I would expect that any change here would be caused by a change in dependencies among modules, but I don't seem to see that change.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6548

From darcy at openjdk.java.net  Mon Nov 29 19:57:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Nov 2021 19:57:08 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools
In-Reply-To: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
References: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
Message-ID: <nzpHPl7hG30bmy0AxgNHemIlEti6Mt-S58gU5ESQw64=.95e5d47e-104b-419a-bae7-9e4dac4d3b1f@github.com>

On Mon, 29 Nov 2021 19:05:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.
> 
> TIA

make/langtools/tools/compileproperties/CompileProperties.java line 187:

> 185:                 }
> 186:                 if ( ok && contents != null ) {
> 187:                     String tokens[] = (new String(contents)).split("\\s+");

So the intended composite predicate here is thought to be
ok == true && contents != null
which is equivalent to
ok && contents != null.
The semantics of the current code are equivalent to just
contents != null
right?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1316:

> 1314:                 public void visitReference(JCMemberReference tree) {
> 1315:                     if (sRet.hasTag(VOID)) {
> 1316:                         result = true;

Isn't the equivalent statement to
result &= true
just
result
?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6599

From vromero at openjdk.java.net  Mon Nov 29 20:13:07 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 29 Nov 2021 20:13:07 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor
In-Reply-To: <zSKlGwba79rh2Uv7Olusq8D8uE2ImBybJZfDJ2alpik=.e026703c-acfe-404e-ae6b-6cf7e6c42bbe@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
 <zSKlGwba79rh2Uv7Olusq8D8uE2ImBybJZfDJ2alpik=.e026703c-acfe-404e-ae6b-6cf7e6c42bbe@github.com>
Message-ID: <4bXnEOKbW2CuEqqRmO9XCYqhWHxcuX9dvfJiHW_s-wQ=.479b9912-8b25-4557-bc19-fae69e81a8ea@github.com>

On Mon, 29 Nov 2021 19:47:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Please review this PR which is about propagating constructor and parameter annotations to the anonymous class constructor. Currently we are propagating them to bridge methods which are synthetic. Propagating them to the anonymous class constructor seems sensible given that they are mandated by the spec. Please review also the related CSR,
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1341:
> 
>> 1339:         public MethodSymbol constructorSymbol() {
>> 1340:             // we should do this only once
>> 1341:             boolean copyConstAnnos = constructorSymbol == null;
> 
> Question: can we avoid repeating this method completely if `constructorSymbol != null`? Seems a bit weird to not copy the annotation again (which I understand), but redo all the rest again.

yep good point

> test/langtools/tools/javac/annos_not_copied_anonymous_ctr/AnnosNotCopiedToAnonymousCtrTest.java line 116:
> 
>> 114:         @VisibleCtrAnnotation
>> 115:         @InvisibleCtrAnnotation
>> 116:         public Test(String firstParam, @VisibleParamAnnotation String secondParam, @InvisibleParamAnnotation String thirdParam) {}
> 
> How about type annotations of the parameter types? Should these be copied? (And tested?)

yep I should add a test for type annotations, good point

> test/langtools/tools/jdeps/listdeps/ListModuleDeps.java line 98:
> 
>> 96:                                 "java.base/jdk.internal.jmod",
>> 97:                                 "java.base/jdk.internal.misc",
>> 98:                                 "java.base/jdk.internal.vm.annotation",
> 
> This looks a bit suspicious to me - why the new entry? Do we know why it was necessary? (I would expect that any change here would be caused by a change in dependencies among modules, but I don't seem to see that change.)

tbh I'm not sure why this new dependency appeared there is no new import, I will do some research

-------------

PR: https://git.openjdk.java.net/jdk/pull/6548

From jjg at openjdk.java.net  Mon Nov 29 23:33:21 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 29 Nov 2021 23:33:21 GMT
Subject: RFR: JDK-8276683: Malformed Javadoc inline tags in JDK source in
 com/sun/tools/javac/util/RawDiagnosticFormatter.java
Message-ID: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>

Please review a trivial patch to fix up some minor issues in doc comments in internal API.

-------------

Commit messages:
 - JDK-8276683: Malformed Javadoc inline tags in JDK source in com/sun/tools/javac/util/RawDiagnosticFormatter.java

Changes: https://git.openjdk.java.net/jdk/pull/6602/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6602&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276683
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6602/head:pull/6602

PR: https://git.openjdk.java.net/jdk/pull/6602

From duke at openjdk.java.net  Tue Nov 30 00:12:09 2021
From: duke at openjdk.java.net (PROgrm_JARvis)
Date: Tue, 30 Nov 2021 00:12:09 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools
In-Reply-To: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
References: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
Message-ID: <qeW0uxUksbVRQGc2sKviYve96fBz0cNqyx-z1uQpLYQ=.0baa72db-a1a1-44a5-9f2b-2372049580c5@github.com>

On Mon, 29 Nov 2021 19:05:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.
> 
> TIA

Changes requested by JarvisCraft at github.com (no known OpenJDK username).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1338:

> 1336:                 public void visitLambda(JCLambda tree) {
> 1337:                     if (sRet.hasTag(VOID)) {
> 1338:                         result = true;

Same as above, the change is changing the semantics:
original code keeps the value of `result` while the new one sets it to `true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6599

From duke at openjdk.java.net  Tue Nov 30 00:12:11 2021
From: duke at openjdk.java.net (PROgrm_JARvis)
Date: Tue, 30 Nov 2021 00:12:11 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools
In-Reply-To: <nzpHPl7hG30bmy0AxgNHemIlEti6Mt-S58gU5ESQw64=.95e5d47e-104b-419a-bae7-9e4dac4d3b1f@github.com>
References: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
 <nzpHPl7hG30bmy0AxgNHemIlEti6Mt-S58gU5ESQw64=.95e5d47e-104b-419a-bae7-9e4dac4d3b1f@github.com>
Message-ID: <boWmwADzBpfQesIPOBIpSl1rOTCeF9bXDpYw7qmAwQA=.81151fb9-ab66-489c-b913-a2577f25be16@github.com>

On Mon, 29 Nov 2021 19:54:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.
>> 
>> TIA
>
> make/langtools/tools/compileproperties/CompileProperties.java line 187:
> 
>> 185:                 }
>> 186:                 if ( ok && contents != null ) {
>> 187:                     String tokens[] = (new String(contents)).split("\\s+");
> 
> So the intended composite predicate here is thought to be
> ok == true && contents != null
> which is equivalent to
> ok && contents != null.
> The semantics of the current code are equivalent to just
> contents != null
> right?

The semantics is definitely changed (considering the first branch was always true originally) but it may be the original implementation being incorrect,

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1316:
> 
>> 1314:                 public void visitReference(JCMemberReference tree) {
>> 1315:                     if (sRet.hasTag(VOID)) {
>> 1316:                         result = true;
> 
> Isn't the equivalent statement to
> result &= true
> just
> result
> ?

Agreeing with jddarcy:
`a & true === a`
so current code just keeps the value of `result` while the new one sets `result` to `true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6599

From cushon at openjdk.java.net  Tue Nov 30 02:08:17 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 30 Nov 2021 02:08:17 GMT
Subject: RFR: 8277965: Enclosing instance optimization affects serialization
Message-ID: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>

This change disables the optimization introduced in [JDK-8271623](https://bugs.openjdk.java.net/browse/JDK-8277965) for all serializable classes, to avoid potential serialization compatibility issues.

As discussed in [JDK-8277965](https://bugs.openjdk.java.net/browse/JDK-8277965) the serialization spec notes that serializing inner classes is 'strongly discouraged' and that the 'synthetic fields generated by javac ... to implement inner classes are implementation dependent and may vary between compilers', which may allow the new behaviour.

This change is intended as an expedient way to restore the previous behaviour and provide more time to discuss the compatibility impact of this part of the change.

-------------

Commit messages:
 - 8277965: Enclosing instance optimization affects serialization

Changes: https://git.openjdk.java.net/jdk/pull/6604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6604&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277965
  Stats: 20 lines in 2 files changed: 0 ins; 17 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6604/head:pull/6604

PR: https://git.openjdk.java.net/jdk/pull/6604

From jgneff at openjdk.java.net  Tue Nov 30 08:35:04 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 08:35:04 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
Message-ID: <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>

On Mon, 29 Nov 2021 19:27:57 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>>> @AlanBateman yes, see above comment, thanks
>> 
>> This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.
>
>> > > @AlanBateman yes, see above comment, thanks
>> > 
>> > 
>> > This is a significant change to the ZipEntry API that will require discussion and agreement. Can you start a discussion on core-libs-dev about the topic? You could start with a summary of the problem and the API and non-API options that have been explored.
>> 
>> I agree with Alan. We are too close to RDP 1 to consider this type of change for JDK 18 as we need more time to discuss, update the CSR, test (and we will need additional tests for this), and give it time to bake. IMHO this will need to go into JDK 19 assuming we move forward with changes similar to the latest commit
> 
> Thanks @LanceAndersen , @AlanBateman, i've just posted a discussion thread here: https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/084150.html

@andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's request -- one that even solves the problem with the current `ZipEntry` API!

Would you be willing to consider a minor change to your implementation?

As I mentioned earlier, if we are going to allow an ISO 8601 zoned date and time, we need either to **truncate, restrict, or convert** its value. The current implementation **truncates,** discarding the time zone information. The better option might be to **convert.** That is, parse the ISO 8601 string with `Instant.parse`, get the seconds since the epoch with `getEpochSecond`, and then proceed as before. Treat the value of `--date` as an instant on the time line, just like `SOURCE_DATE_EPOCH`, and always store its value in UTC.

This also solves the problem of storing dates before 1980 as a local date and time in UTC while storing those after 1980 as a local date and time with a discarded time zone. By converting instead of truncating, the value is always stored as the local date and time in UTC regardless of whether or not it's within the range of the "MS-DOS date and time" field.

Those of us using the timestamp of the last commit can still get the value directly from `git`.

For `SOURCE_DATE_EPOCH`, run:


$ git log -1 --pretty=%ct
1638207366


For the `--date` option of the `jar` and `jmod` tools, run:


$ git log -1 --pretty=%cI
2021-11-29T09:36:06-08:00


Specifically, that `git` ISO 8601 string, and even the sample `date` command that Mark shows in his comment, are what break the current implementation by creating archives that depend on the time zone of the build machine again.

By the way, the `jar` utility displays a time zone in the output of its `--list` and `--verbose` options even when there is no time zone information in the file. (In other words, it lies, or at least embellishes.) Use the verbose output of `zipinfo` to see the true values of the timestamps in an archive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Tue Nov 30 08:56:08 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 08:56:08 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
Message-ID: <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>

On Tue, 30 Nov 2021 08:31:54 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> Would you be willing to consider a minor change to your implementation?

Just to be clear, this change should let us postpone any additions to the `ZipEntry` API for another day, if at all, and maybe even get this pull request integrated for JDK 18.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From asotona at openjdk.java.net  Tue Nov 30 11:03:25 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 30 Nov 2021 11:03:25 GMT
Subject: RFR: 8264485: build.tools.depend.Depend.toString(byte[]) creates
 malformed hex strings
Message-ID: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>

make/jdk/src/classes/build/tools/depend/Depend.java method toString(byte[]) constructs hex string out of the given byte array.
Actual implementation is using custom conversion code, which does not pad byte values <16 with leading zero.
Resulting hex string is invalid and for example sequence of bytes 1 and 0 generates the same hex string as a single byte 16.

Proposed patch is delegating hex conversion to java.util.HexFormat instead.

Thanks,
Adam

-------------

Commit messages:
 - 8264485: build.tools.depend.Depend.toString(byte[]) creates malformed hex strings

Changes: https://git.openjdk.java.net/jdk/pull/6610/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6610&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264485
  Stats: 8 lines in 1 file changed: 1 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6610/head:pull/6610

PR: https://git.openjdk.java.net/jdk/pull/6610

From aleonard at openjdk.java.net  Tue Nov 30 12:05:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 12:05:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
Message-ID: <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>

On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's request -- one that even solves the problem with the current `ZipEntry` API!
>> 
>> Would you be willing to consider a minor change to your implementation?
>> 
>> As I mentioned earlier, if we are going to allow an ISO 8601 zoned date and time, we need either to **truncate, restrict, or convert** its value. The current implementation **truncates,** discarding the time zone information. The better option might be to **convert.** That is, parse the ISO 8601 string with `Instant.parse`, get the seconds since the epoch with `getEpochSecond`, and then proceed as before. Treat the value of `--date` as an instant on the time line, just like `SOURCE_DATE_EPOCH`, and always store its value in UTC.
>> 
>> This also solves the problem of storing dates before 1980 as a local date and time in UTC while storing those after 1980 as a local date and time with a discarded time zone. By converting instead of truncating, the value is always stored as the local date and time in UTC regardless of whether or not it's within the range of the "MS-DOS date and time" field.
>> 
>> Those of us using the timestamp of the last commit can still get the value directly from `git`.
>> 
>> For `SOURCE_DATE_EPOCH`, run:
>> 
>> 
>> $ git log -1 --pretty=%ct
>> 1638207366
>> 
>> 
>> For the `--date` option of the `jar` and `jmod` tools, run:
>> 
>> 
>> $ git log -1 --pretty=%cI
>> 2021-11-29T09:36:06-08:00
>> 
>> 
>> Specifically, that `git` ISO 8601 string, and even the sample `date` command that Mark shows in his comment, are what break the current implementation by creating archives that depend on the time zone of the build machine again.
>> 
>> By the way, the `jar` utility displays a time zone in the output of its `--list` and `--verbose` options even when there is no time zone information in the file. (In other words, it lies, or at least embellishes.) Use the verbose output of `zipinfo` to see the true values of the timestamps in an archive.
>
>> Would you be willing to consider a minor change to your implementation?
> 
> Just to be clear, this change should let us postpone any additions to the `ZipEntry` API for another day, if at all, and maybe even get this pull request integrated for JDK 18.

@jgneff Hi John, many thanks for the suggestions

So what you suggest sounds reasonable, although it would be a "behaviour change" in that whereas now if the date is between 1980->2106 only a xdostime is stored, we would now always be storing the additional "mtime" field which is a FileTime persisted as an int("seconds from epoch") in the zip file. I was trying to not change the binary semantics, but I actually think your suggestion makes sense.

I've done a bit of digging as to why the extended mtime is only stored outside the xdos date range, and found this bug: https://bugs.openjdk.java.net/browse/JDK-8073497
Which basically I think changed ZipEntry so it did not construct Date() objects from ZipEntries loaded during JVM startup, which it "implies" (although I can't see the evidence) improves startup performance.
There is an interesting comment here: https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/util/zip/ZipEntry.java#L83

     * This establish an approximate high-bound value for DOS times in
     * milliseconds since epoch, used to enable an efficient but
     * sufficient bounds check to avoid generating extended last modified
     * time entries.
     *
     * Calculating the exact number is locale dependent, would require loading
     * TimeZone data eagerly, and would make little practical sense. Since DOS
     * times theoretically go to 2107 - with compatibility not guaranteed
     * after 2099 - setting this to a time that is before but near 2099
     * should be sufficient.

So if we were to always set the extended mtime field, then FileTime.from(long) would potentially cause the impact JDK-8073497 was trying to avoid...?
However, with this bug we seem to have not thought about deterministic behavior..."Calculating the exact number is locale dependent, would require loading TimeZone data eagerly, and would make little practical sense"

Thoughts?

@AlanBateman @LanceAndersen fyi

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 12:15:15 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 12:15:15 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <6uP7zRc-lQ2wm8iIKJankYdCYGyh_3tw0ElzqJQ6Smc=.107c07cc-a4e8-4ce5-bff6-44915c88089e@github.com>

On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I see maybe 2 ways forward:
1) We either prove always setting an mtime(FileTime) has no impact in JVM startup, and is an acceptable behavior change
2) We implement the original fix in 2 stages:
a) jdk-18: setTimeLocal() change, which provides deterministic behavior over years 1980-2106 (which is in keeping with the theme of JDK-8073497 !)
b) jdk-19+: provide ZipEntry Zoned time setting support

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jlahoda at openjdk.java.net  Tue Nov 30 12:50:15 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 30 Nov 2021 12:50:15 GMT
Subject: RFR: 8264485: build.tools.depend.Depend.toString(byte[]) creates
 malformed hex strings
In-Reply-To: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
References: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
Message-ID: <5ynIrkuIk6LVgozR72777LTQy56GECHCRg_ZBwtENTM=.dd687d32-859c-4395-9404-9f28211856d3@github.com>

On Tue, 30 Nov 2021 10:46:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> make/jdk/src/classes/build/tools/depend/Depend.java method toString(byte[]) constructs hex string out of the given byte array.
> Actual implementation is using custom conversion code, which does not pad byte values <16 with leading zero.
> Resulting hex string is invalid and for example sequence of bytes 1 and 0 generates the same hex string as a single byte 16.
> 
> Proposed patch is delegating hex conversion to java.util.HexFormat instead.
> 
> Thanks,
> Adam

Looks OK.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6610

From asotona at openjdk.java.net  Tue Nov 30 13:00:16 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 30 Nov 2021 13:00:16 GMT
Subject: Integrated: 8264485: build.tools.depend.Depend.toString(byte[])
 creates malformed hex strings
In-Reply-To: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
References: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
Message-ID: <mVkJDK4nr7RLWcwxC8ZBUkQsrwDk02elymW-_q-ojjg=.37049759-6c1e-41c4-8829-03a253f99a12@github.com>

On Tue, 30 Nov 2021 10:46:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> make/jdk/src/classes/build/tools/depend/Depend.java method toString(byte[]) constructs hex string out of the given byte array.
> Actual implementation is using custom conversion code, which does not pad byte values <16 with leading zero.
> Resulting hex string is invalid and for example sequence of bytes 1 and 0 generates the same hex string as a single byte 16.
> 
> Proposed patch is delegating hex conversion to java.util.HexFormat instead.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 69f56a0e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69f56a0ea0c2d551b660909deb89f0051540f9d0
Stats:     8 lines in 1 file changed: 1 ins; 6 del; 1 mod

8264485: build.tools.depend.Depend.toString(byte[]) creates malformed hex strings

Reviewed-by: jlahoda

-------------

PR: https://git.openjdk.java.net/jdk/pull/6610

From shade at openjdk.java.net  Tue Nov 30 13:05:16 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 13:05:16 GMT
Subject: RFR: 8264485: build.tools.depend.Depend.toString(byte[]) creates
 malformed hex strings
In-Reply-To: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
References: <pNfi2C8GMRPdZJoCU3PZEPW6GJiJwJr21FUUoWboW_4=.53d54549-1506-4fa8-b45f-f5b9f0a1c6dd@github.com>
Message-ID: <JNnaSHZgONWxYeFuWvk7Du1P02-qp3nceF9nZYelzfc=.48ccf1d2-0e43-4b4f-b935-c11c94841024@github.com>

On Tue, 30 Nov 2021 10:46:12 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> make/jdk/src/classes/build/tools/depend/Depend.java method toString(byte[]) constructs hex string out of the given byte array.
> Actual implementation is using custom conversion code, which does not pad byte values <16 with leading zero.
> Resulting hex string is invalid and for example sequence of bytes 1 and 0 generates the same hex string as a single byte 16.
> 
> Proposed patch is delegating hex conversion to java.util.HexFormat instead.
> 
> Thanks,
> Adam

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6610

From aleonard at openjdk.java.net  Tue Nov 30 14:02:19 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 14:02:19 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <vBonT-VS3gwwuauuzbn6vyhpNs_G4cqxWi5g8enJsZg=.2bdb3fc9-800f-49b8-81a3-ea520eddabfb@github.com>

On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

However, it looks like this behavior to not set extended mtime within the xdostime range has just been changed by a recent PR: https://github.com/openjdk/jdk/pull/5486/files which has changed jartool.Main using zipEntry.setTime(time) to use zipEntry.setLastModifiedTime(time), the later sets mtime always regardless of xdostime.
The implications of https://bugs.openjdk.java.net/browse/JDK-8073497 might also apply to FileTime unnecessary initialization slowing VM startup, however if FileTime is already regularly referenced during startup, then it wont.. If this is the case then way forward (1) would be ok...
@AlanBateman was that an intentional change? @jaikiran

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jai.forums2013 at gmail.com  Tue Nov 30 15:00:22 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 30 Nov 2021 20:30:22 +0530
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <vBonT-VS3gwwuauuzbn6vyhpNs_G4cqxWi5g8enJsZg=.2bdb3fc9-800f-49b8-81a3-ea520eddabfb@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <vBonT-VS3gwwuauuzbn6vyhpNs_G4cqxWi5g8enJsZg=.2bdb3fc9-800f-49b8-81a3-ea520eddabfb@github.com>
Message-ID: <bf4ec4e4-db3c-ebfc-c244-c2b5d2d4f2de@gmail.com>

Hello Andrew,

On 30/11/21 7:32 pm, Andrew Leonard wrote:
> On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:
>
>>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>>>
>>>
> However, it looks like this behavior to not set extended mtime within the xdostime range has just been changed by a recent PR: https://github.com/openjdk/jdk/pull/5486/files which has changed jartool.Main using zipEntry.setTime(time) to use zipEntry.setLastModifiedTime(time), the later sets mtime always regardless of xdostime.

When I changed the implementation in sun.tools.jar.Main to use 
setLastModifiedTime(FileTime) instead of the previous setTime(long), I 
hadn't paid close attention to the implementation of these methods in 
java.util.zip.ZipEntry. Now that you brought this up, I had a more 
closer look at their implementation.

So it looks like the implementation of setTime(long) conditionally sets 
the extended timestamp fields in optional extra data of the zip entry. 
That condition checks to see if the time value being set is before 1980 
or after 2099 and if it passes this condition, it goes and sets the 
extended timestamp fields. So in practice, for jar creation/updation in 
sun.tools.jar.Main, the previous code using setTime(long) wouldn't have 
set the extended timestamp fields, because the current year(s) aren't 
before 1980 or after 2099. The implementation of 
java.util.zip.ZipEntry.setLastModifiedTime(FileTime) on the other hand 
has no such conditional checks and (as noted in the javadoc of that 
method) goes ahead and sets the time value in the extended timestamp 
fields of that zip entry.

So yes, the change that went in to 
https://github.com/openjdk/jdk/pull/5486 did introduce this subtle 
change in the generated zip/jar entries. Having said that, the 
setTime(long) on java.util.zip.ZipEntry makes no mention of these 
conditional checks. It currently states:

 ???? * Sets the last modification time of the entry.
 ???? *
 ???? * <p> If the entry is output to a ZIP file or ZIP file formatted
 ???? * output stream the last modification time set by this method will
 ???? * be stored into the {@code date and time fields} of the zip file
 ???? * entry and encoded in standard {@code MS-DOS date and time format}.
 ???? * The {@link java.util.TimeZone#getDefault() default TimeZone} is
 ???? * used to convert the epoch time to the MS-DOS data and time.

So it doesn't even make a mention of setting extended timestamp fields, 
let along setting them on a particular condition. So I'm unsure whether 
switching to setLastModifiedTime(FileTime) instead of setTime(long) was 
a bad thing.

> The implications of https://bugs.openjdk.java.net/browse/JDK-8073497 might also apply to FileTime unnecessary initialization slowing VM startup, however if FileTime is already regularly referenced during startup, then it wont.. If this is the case then way forward (1) would be ok...
> @AlanBateman was that an intentional change? @jaikiran

I had a look at that JBS issue now. From what I understand in its 
description and goal, the idea was to prevent initialization of 
java.util.Date utilities very early on during the startup. I had a quick 
look at the code in ZipEntry and how it behaves when it constructs a 
ZipEntry instance out of the zip file data. With the change in 
https://github.com/openjdk/jdk/pull/5486, the "mtime" (which represents 
extended timestamp field) will be set in the zip file entry, so there 
would be an attempt to create a FileTime out of it. The call that does 
that appears to be "unixTimeToFileTime" in ZipEntry and as far as I can 
see it doesn't end up using any java.util.Date classes. Of course, I 
haven't yet looked or experimented to verify and be absolutely sure 
about it, but from a cursory check it doesn't look like this would 
contribute to pulling in java.util.Date utilities.

-Jaikiran


From aleonard at openjdk.java.net  Tue Nov 30 15:02:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 15:02:13 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
Message-ID: <Dr8g5QO2TjtOf1yd48xX1OFFreGkcE7Gy8U4G8A60PA=.e537c497-6493-40e2-b404-7f4a2b9ab55d@github.com>

On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's request -- one that even solves the problem with the current `ZipEntry` API!
>> 
>> Would you be willing to consider a minor change to your implementation?
>> 
>> As I mentioned earlier, if we are going to allow an ISO 8601 zoned date and time, we need either to **truncate, restrict, or convert** its value. The current implementation **truncates,** discarding the time zone information. The better option might be to **convert.** That is, parse the ISO 8601 string with `Instant.parse`, get the seconds since the epoch with `getEpochSecond`, and then proceed as before. Treat the value of `--date` as an instant on the time line, just like `SOURCE_DATE_EPOCH`, and always store its value in UTC.
>> 
>> This also solves the problem of storing dates before 1980 as a local date and time in UTC while storing those after 1980 as a local date and time with a discarded time zone. By converting instead of truncating, the value is always stored as the local date and time in UTC regardless of whether or not it's within the range of the "MS-DOS date and time" field.
>> 
>> Those of us using the timestamp of the last commit can still get the value directly from `git`.
>> 
>> For `SOURCE_DATE_EPOCH`, run:
>> 
>> 
>> $ git log -1 --pretty=%ct
>> 1638207366
>> 
>> 
>> For the `--date` option of the `jar` and `jmod` tools, run:
>> 
>> 
>> $ git log -1 --pretty=%cI
>> 2021-11-29T09:36:06-08:00
>> 
>> 
>> Specifically, that `git` ISO 8601 string, and even the sample `date` command that Mark shows in his comment, are what break the current implementation by creating archives that depend on the time zone of the build machine again.
>> 
>> By the way, the `jar` utility displays a time zone in the output of its `--list` and `--verbose` options even when there is no time zone information in the file. (In other words, it lies, or at least embellishes.) Use the verbose output of `zipinfo` to see the true values of the timestamps in an archive.
>
>> Would you be willing to consider a minor change to your implementation?
> 
> Just to be clear, this change should let us postpone any additions to the `ZipEntry` API for another day, if at all, and maybe even get this pull request integrated for JDK 18.

@jgneff John, i'm going to update this PR to use the LocalDateTime setting option and restrict --date to 1980->2099, thus ensuring xdostime is always only used. This I believe we should be able to get into jdk-18.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 15:23:14 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 15:23:14 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <V8wZ8-Jyr0zi5nKSFKm-937ARk3DjXPo1Pd6mZLgXMQ=.5de40fb7-d39f-47ca-b759-ee901b11b6f9@github.com>

On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Thanks for taking a look Jaikiran,
I concur with the above. I'm currently looking to make the rest of jar/jmod
deterministic as there
are several currentTimeMillis() used... i'll probably update this to be at
least consistent
with the others.
Thanks
Andrew


On Tue, Nov 30, 2021 at 3:02 PM mlbridge[bot] ***@***.***>
wrote:

> *Mailing list message from Jaikiran Pai ***@***.***> on
> core-libs-dev ***@***.***>:*
>
> Hello Andrew,
>
> On 30/11/21 7:32 pm, Andrew Leonard wrote:
>
> On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org>
> wrote:
>
> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod
> to allow specification of time to use for created/updated jar/jmod entries.
> This then allows the ability to make the content deterministic.
>
> However, it looks like this behavior to not set extended mtime within the
> xdostime range has just been changed by a recent PR: https://github.com/
> /pull/5486 <https://github.com/openjdk/jdk/pull/5486>/files which has
> changed jartool.Main using zipEntry.setTime(time) to use
> zipEntry.setLastModifiedTime(time), the later sets mtime always regardless
> of xdostime.
>
> When I changed the implementation in sun.tools.jar.Main to use
> setLastModifiedTime(FileTime) instead of the previous setTime(long), I
> hadn't paid close attention to the implementation of these methods in
> java.util.zip.ZipEntry. Now that you brought this up, I had a more
> closer look at their implementation.
>
> So it looks like the implementation of setTime(long) conditionally sets
> the extended timestamp fields in optional extra data of the zip entry.
> That condition checks to see if the time value being set is before 1980
> or after 2099 and if it passes this condition, it goes and sets the
> extended timestamp fields. So in practice, for jar creation/updation in
> sun.tools.jar.Main, the previous code using setTime(long) wouldn't have
> set the extended timestamp fields, because the current year(s) aren't
> before 1980 or after 2099. The implementation of
> java.util.zip.ZipEntry.setLastModifiedTime(FileTime) on the other hand
> has no such conditional checks and (as noted in the javadoc of that
> method) goes ahead and sets the time value in the extended timestamp
> fields of that zip entry.
>
> So yes, the change that went in to
> https://github.com//pull/5486 <https://github.com/openjdk/jdk/pull/5486>
> did introduce this subtle
> change in the generated zip/jar entries. Having said that, the
> setTime(long) on java.util.zip.ZipEntry makes no mention of these
> conditional checks. It currently states:
>
> ???? * Sets the last modification time of the entry.
> ???? *
> ???? * <p> If the entry is output to a ZIP file or ZIP file formatted
> ???? * output stream the last modification time set by this method will
> ???? * be stored into the ***@***.*** date and time fields} of the zip file
> ???? * entry and encoded in standard ***@***.*** MS-DOS date and time format}.
> ???? * The ***@***.*** java.util.TimeZone#getDefault() default TimeZone} is
> ???? * used to convert the epoch time to the MS-DOS data and time.
>
> So it doesn't even make a mention of setting extended timestamp fields,
> let along setting them on a particular condition. So I'm unsure whether
> switching to setLastModifiedTime(FileTime) instead of setTime(long) was
> a bad thing.
>
> The implications of https://bugs.openjdk.java.net/browse/JDK-8073497
> might also apply to FileTime unnecessary initialization slowing VM startup,
> however if FileTime is already regularly referenced during startup, then it
> wont.. If this is the case then way forward (1) would be ok...
> @AlanBateman was that an intentional change? @jaikiran
>
> I had a look at that JBS issue now. From what I understand in its
> description and goal, the idea was to prevent initialization of
> java.util.Date utilities very early on during the startup. I had a quick
> look at the code in ZipEntry and how it behaves when it constructs a
> ZipEntry instance out of the zip file data. With the change in
> https://github.com//pull/5486 <https://github.com/openjdk/jdk/pull/5486>,
> the "mtime" (which represents
> extended timestamp field) will be set in the zip file entry, so there
> would be an attempt to create a FileTime out of it. The call that does
> that appears to be "unixTimeToFileTime" in ZipEntry and as far as I can
> see it doesn't end up using any java.util.Date classes. Of course, I
> haven't yet looked or experimented to verify and be absolutely sure
> about it, but from a cursory check it doesn't look like this would
> contribute to pulling in java.util.Date utilities.
>
> -Jaikiran
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/6481#issuecomment-982719481>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHQDDN7UQMX4PV46ZZCALE3UOTRRJANCNFSM5IMSJY4Q>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Tue Nov 30 16:29:07 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 16:29:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
Message-ID: <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>

On Tue, 30 Nov 2021 12:00:59 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> So what you suggest sounds reasonable, although it would be a "behaviour change" in that whereas now if the date is between 1980->2106 only a xdostime is stored, we would now always be storing the additional "mtime" field ...

No, sorry, that is not at all what I suggested.

I am suggesting to immediately convert the value of the `--date` command-line option to an `Instant`. Once you have an `Instant` object, it's just like before when you had the value of `SOURCE_DATE_EPOCH` (which is in fact an instant on the time line), so you can revert to using your prior revision that handled that situation just perfectly!

In fact, you always want to avoid storing the addition "extended timestamp" field when possible because it causes a rather surprising increase in the size of the archive.

I wanted to send this right away, because you're such a fast coder, and in a different time zone, but please give me some time to look over your and Jaikiran's comments in more detail this morning. Thanks! ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From darcy at openjdk.java.net  Tue Nov 30 18:22:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Nov 2021 18:22:07 GMT
Subject: RFR: JDK-8276683: Malformed Javadoc inline tags in JDK source in
 com/sun/tools/javac/util/RawDiagnosticFormatter.java
In-Reply-To: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
References: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
Message-ID: <dt1djBfsjAGc7ClM-Ew9kLw7FVPl54xLbbzYkWIxZ3c=.e9b18855-4530-4a93-9372-3f13ee0f4c68@github.com>

On Mon, 29 Nov 2021 23:25:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial patch to fix up some minor issues in doc comments in internal API.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6602

From jjg at openjdk.java.net  Tue Nov 30 18:47:27 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 30 Nov 2021 18:47:27 GMT
Subject: RFR: JDK-8276683: Malformed Javadoc inline tags in JDK source in
 com/sun/tools/javac/util/RawDiagnosticFormatter.java [v2]
In-Reply-To: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
References: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
Message-ID: <nNDZriZwMWps3Sgn1qxvwOaS8P19DqM28ZI67taV25U=.15602437-c73c-4b5c-a809-f17a9eb38d50@github.com>

> Please review a trivial patch to fix up some minor issues in doc comments in internal API.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  review feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6602/files
  - new: https://git.openjdk.java.net/jdk/pull/6602/files/9af2d503..dd9d58a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6602&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6602&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6602/head:pull/6602

PR: https://git.openjdk.java.net/jdk/pull/6602

From prappo at openjdk.java.net  Tue Nov 30 18:50:07 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 30 Nov 2021 18:50:07 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream
In-Reply-To: <cvm208-sAlohW4rYOW5aMfJ19zIWGTn_vkikI6OOQpA=.d4ee7ee9-afff-4825-8f33-98894d8a9fb8@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
 <cvm208-sAlohW4rYOW5aMfJ19zIWGTn_vkikI6OOQpA=.d4ee7ee9-afff-4825-8f33-98894d8a9fb8@github.com>
Message-ID: <tUlL1F5kvUeFhL7rZVCUXifraaIkbi-LhaeNG4F2Kg0=.a46a36b0-ef32-45b2-a335-ca968626ccf3@github.com>

On Thu, 25 Nov 2021 00:31:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 63:
> 
>> 61:      * Helper class to generate stable positions for AST nodes occurring in diagnostic arguments.
>> 62:      * If the AST node appears in the same line number as the main diagnostic, the line is information is omitted.
>> 63:      * Otherwise both line and column information is included, using the format {@code line:col}".
> 
> Not a showstopper by any means. But while you are at it, maybe you could also fix this?
> 
> Suggestion:
> 
>      * If the AST node appears in the same line number as the main diagnostic, the line information is omitted.
>      * Otherwise both line and column information is included, using the format {@code line:col}.

This part was recently integrated in https://github.com/openjdk/jdk/pull/6602. I assume there will be a trivial merge conflict to resolve.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6443

From aleonard at openjdk.java.net  Tue Nov 30 18:56:04 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 18:56:04 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
 <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
Message-ID: <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>

On Tue, 30 Nov 2021 16:26:28 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> > So what you suggest sounds reasonable, although it would be a "behaviour change" in that whereas now if the date is between 1980->2106 only a xdostime is stored, we would now always be storing the additional "mtime" field ...
> 
> No, sorry, that is not at all what I suggested.
> 
> I am suggesting to immediately convert the value of the `--date` command-line option to an `Instant`. Once you have an `Instant` object, it's just like before when you had the value of `SOURCE_DATE_EPOCH` (which is in fact an instant on the time line), so you can revert to using your prior revision that handled that situation just perfectly!
> 
> In fact, you always want to avoid storing the addition "extended timestamp" field when possible because it causes a rather surprising increase in the size of the archive.
> 
> I wanted to send this right away, because you're such a fast coder, and in a different time zone, but please give me some time to look over your and Jaikiran's comments in more detail this morning. Thanks! ??
@jgneff John, sorry got confused, but I see what you're saying now. So what you're saying is take the --date <iso8601>, work out a LocalDateTime for that "instant" but in UTC, then call e.setTimeLocal(localDateTime).
So I think i'm in fact just putting together a new commit for option (1) using setTimeLocal() similar to this, just very slightly different but efftecively doing the same thing, i'm converting the user input --date string to a ZonedDateTime, from which I get the LocalDateTime for calling setTimeLocal(zonedDateTime.toLocalDateTime()). That way when you unzip it the files have the same local date time.
eg.
--date="2022-03-15T14:36:00+06:00"

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 19:01:08 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 19:01:08 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
Message-ID: <pLgXRhMKP9FDo1spXmpIsWYzfnBAxLVHAChP_0F5gjc=.9582f5c6-fba3-4630-a195-2fc0eedff962@github.com>

On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
>> 
>> Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>
> Andrew Leonard has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>
>  - 8276766: Enable jar and jmod to produce deterministic timestamped content
>    
>    Signed-off-by: Andrew Leonard <anleonar at redhat.com>

I'm also adding --date validation of 1980->2099

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From prappo at openjdk.java.net  Tue Nov 30 19:11:08 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 30 Nov 2021 19:11:08 GMT
Subject: RFR: JDK-8276683: Malformed Javadoc inline tags in JDK source in
 com/sun/tools/javac/util/RawDiagnosticFormatter.java [v2]
In-Reply-To: <nNDZriZwMWps3Sgn1qxvwOaS8P19DqM28ZI67taV25U=.15602437-c73c-4b5c-a809-f17a9eb38d50@github.com>
References: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
 <nNDZriZwMWps3Sgn1qxvwOaS8P19DqM28ZI67taV25U=.15602437-c73c-4b5c-a809-f17a9eb38d50@github.com>
Message-ID: <satcUKOVPEMQTf0_j3K2237GJyjI5DnmQWnR8DBAHLo=.dcb03767-9613-4726-9a55-6740875849ef@github.com>

On Tue, 30 Nov 2021 18:47:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a trivial patch to fix up some minor issues in doc comments in internal API.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Marked as reviewed by prappo (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6602

From jgneff at openjdk.java.net  Tue Nov 30 19:35:08 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 19:35:08 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
 <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
 <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>
Message-ID: <mvAni5LCd0NdCV9EGENz00HTYVcuburEQZts47YJBCw=.f2ad79a8-ff69-4653-a8da-c238f603e245@github.com>

On Tue, 30 Nov 2021 18:52:56 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Both basically truncate the timezone.

There's a difference. The first option saves a DOS date and time that depends on the time zone of the build machine due to the ISO 8601 string returned by default from the `git` and `date` commands, which is what everyone will be using. Those commands return the local time zone offset by default, which is what breaks your current implementation.

The second option converts to a DOS date and time that is independent of the time zone of the build machine, as long as you stay withing the range of its values, as you discovered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Tue Nov 30 20:03:10 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 20:03:10 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <pLgXRhMKP9FDo1spXmpIsWYzfnBAxLVHAChP_0F5gjc=.9582f5c6-fba3-4630-a195-2fc0eedff962@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <pLgXRhMKP9FDo1spXmpIsWYzfnBAxLVHAChP_0F5gjc=.9582f5c6-fba3-4630-a195-2fc0eedff962@github.com>
Message-ID: <eUV_5kZhbtC6VABUfNUP8oEpPlPEHqCFCdsnvTwjmCs=.84632ea4-1017-4e9a-88df-403c1056d1b9@github.com>

On Tue, 30 Nov 2021 18:57:55 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> I'm also adding --date validation of 1980->2099

I am only now catching up with you on that issue. ??  I wrote a very short program that illustrates that problem (and all the other ones) very clearly for anyone to see. I'll post it shortly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 20:03:10 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 20:03:10 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <mvAni5LCd0NdCV9EGENz00HTYVcuburEQZts47YJBCw=.f2ad79a8-ff69-4653-a8da-c238f603e245@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
 <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
 <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>
 <mvAni5LCd0NdCV9EGENz00HTYVcuburEQZt
 s47YJBCw=.f2ad79a8-ff69-4653-a8da-c238f603e245@github.com>
Message-ID: <T6p0p1fRTciu-oUQJB9f49sQ-ex3OZrW4lqD91kiXX8=.cd5b8679-1908-4d7c-9177-1e968780475b@github.com>

On Tue, 30 Nov 2021 19:31:37 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> > Both basically truncate the timezone.
> 
> There's a difference. The first option saves a DOS date and time that depends on the time zone of the build machine due to the ISO 8601 string returned by default from the `git` and `date` commands, which is what everyone will be using. Those commands return the local time zone offset by default, which is what breaks your current implementation.

@jgneff I think you've lost me on this one so example may help me please..
Whichever we use, we have to use e.setTimeLocal(), so can't see what the difference is?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From jgneff at openjdk.java.net  Tue Nov 30 20:03:11 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Tue, 30 Nov 2021 20:03:11 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <T6p0p1fRTciu-oUQJB9f49sQ-ex3OZrW4lqD91kiXX8=.cd5b8679-1908-4d7c-9177-1e968780475b@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
 <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
 <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>
 <mvAni5LCd0NdCV9EGENz00HTYVcuburEQZt
 s47YJBCw=.f2ad79a8-ff69-4653-a8da-c238f603e245@github.com>
 <T6p0p1fRTciu-oUQJB9f49sQ-ex3OZrW4lqD91kiXX8=.cd5b8679-1908-4d7c-9177-1e968780475b@github.com>
Message-ID: <Sm9-fhOtERhbBlu4TRIh8vAJzfPI3BxTbqviAFO-8yk=.9f010fe0-fd6e-4e5b-a4d2-c9b6c241abf3@github.com>

On Tue, 30 Nov 2021 19:37:23 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> Whichever we use, we have to use e.setTimeLocal(), so can't see what the difference is?

Okay, here's a brief command-line example before posting the code example. In my experience, most people trying to set up a common, project-wide build timestamp use the formatted string in UTC:


$ date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds --utc
2021-11-29T17:36:06+00:00


In JavaFX, we're using the more concise Java version of that string: `2021-11-29T17:36:06Z`.

So here's what happens when you get that exact same instant in time from different sources on different machines:


$ TZ=America/Nome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
2021-11-29T08:36:06-09:00
$ TZ=Europe/Rome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
2021-11-29T18:36:06+01:00
$ git log -1 --pretty=%cI
2021-11-29T09:36:06-08:00


All of a sudden it makes a big difference when you're discarding the time zone. You end up with differences in the archive files depending on (a) the time zone of the build machine, and (b) the source you use to obtain an ISO 8601 string to represent that singular instant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 20:18:07 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 20:18:07 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v9]
In-Reply-To: <Sm9-fhOtERhbBlu4TRIh8vAJzfPI3BxTbqviAFO-8yk=.9f010fe0-fd6e-4e5b-a4d2-c9b6c241abf3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <miiMSuGhBq75B5G-ZQBi9h41CKGdbuYcFE77rMMHEEE=.e90b5836-c29c-4aa1-9fd3-22c6de8cc764@github.com>
 <X8DkVYmZoy6IcbOoT_gpcKpgBvYVCibt9fHFUd2QXpk=.6560d645-97b0-471b-b772-fb8a0e2cbd06@github.com>
 <W17wLWfxULwDu4K8TjxiEvOWFvoIPFE5v5pZI8VGx8Q=.f7cb126d-0f2d-4950-9e36-4401a15a6fec@github.com>
 <6R6Yhe5pvYU8N23kUdTSAB0PygpVWptXFsiB7O0FjkA=.ea96411a-85d3-435a-9a8f-6b4245292551@github.com>
 <LxlNUWpCipYN6GVlz7U2CEGM81TG_67CdDq15PQpkhw=.98f1c90e-3951-45f8-b828-46cdb736fb53@github.com>
 <xhKjLv7EV69f3aIvTaaEx_FH1SrgpaC5dhzBSRvvm44=.a8d53283-74d6-487e-8d64-856f89e51f80@github.com>
 <ddt9oKJf5wG7dkoPyw6WmwiN7JK53Ms6jym-FVY2-A8=.ffc0e1fb-5b5d-4e9d-9a49-fb407cf7993a@github.com>
 <BF1Awilse5V6yAlKThw90ed0N2muQvAN79-AhRZeTzs=.cde26b3a-b80e-4394-8b2d-daf5ed9ac522@github.com>
 <k-_VVX77Rj53tbzQWEQmO0I-kSrMWaoREal-QrOO1es=.bef09818-5e17-4d89-bc9a-3c6df0ac5111@github.com>
 <mvAni5LCd0NdCV9EGENz00HTYVcuburEQZt
 s47YJBCw=.f2ad79a8-ff69-4653-a8da-c238f603e245@github.com>
 <T6p0p1fRTciu-oUQJB9f49sQ-ex3OZrW4lqD91kiXX8=.cd5b8679-1908-4d7c-9177-1e968780475b@github.com>
 <Sm9-fhOtERhbBlu4TRIh8vAJzfPI3BxTbqviAFO-8yk=.9f010fe0-fd6e-4e5b-a4d2-c9b6c241abf3@github.com>
Message-ID: <zx-eZzdvYBEQrdr8KaiFpHc_MYbqvzR2XihiG4qhHfU=.161941f2-04a9-4846-bd73-cdf49c922ecb@github.com>

On Tue, 30 Nov 2021 20:00:19 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> > Whichever we use, we have to use e.setTimeLocal(), so can't see what the difference is?
> 
> Okay, here's a brief command-line example before posting the code example. In my experience, most people trying to set up a common, project-wide build timestamp use the formatted string in UTC:
> 
> ```
> $ date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds --utc
> 2021-11-29T17:36:06+00:00
> ```
> 
> In JavaFX, we're using the more concise Java version of that string: `2021-11-29T17:36:06Z`.
> 
> So here's what happens when you get that exact same instant in time from different sources on different machines:
> 
> ```
> $ TZ=America/Nome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
> 2021-11-29T08:36:06-09:00
> $ TZ=Europe/Rome date -d @$SOURCE_DATE_EPOCH --iso-8601=seconds
> 2021-11-29T18:36:06+01:00
> $ git log -1 --pretty=%cI
> 2021-11-29T09:36:06-08:00
> ```
> 
> All of a sudden it makes a big difference when you're discarding the time zone. You end up with differences in the archive files depending on (a) the time zone of the build machine, and (b) the source you use to obtain an ISO 8601 string to represent that singular instant.

AH! got ya, so I was looking at the requirement from a slightly different perspective, ie. reproducibility is same input == same output, so to my mind:
--date "2021-11-29T08:36:06-09:00"
is a different input to:
--date "2021-11-29T09:36:06-08:00"

ie. the String is different! but as you say, the use case is actually same input === "same INSTANT in TIME", my mind was totally not seeing that, thank you!
ok all makes sense now :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6481

From iris at openjdk.java.net  Tue Nov 30 20:25:11 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 30 Nov 2021 20:25:11 GMT
Subject: RFR: JDK-8276683: Malformed Javadoc inline tags in JDK source in
 com/sun/tools/javac/util/RawDiagnosticFormatter.java [v2]
In-Reply-To: <nNDZriZwMWps3Sgn1qxvwOaS8P19DqM28ZI67taV25U=.15602437-c73c-4b5c-a809-f17a9eb38d50@github.com>
References: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
 <nNDZriZwMWps3Sgn1qxvwOaS8P19DqM28ZI67taV25U=.15602437-c73c-4b5c-a809-f17a9eb38d50@github.com>
Message-ID: <hr3X-tPaMHQ-ErzuZAWLoRwj8I0aB88CkWL8APQiNgc=.abc036d1-1693-4e53-be41-d8eed279d549@github.com>

On Tue, 30 Nov 2021 18:47:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a trivial patch to fix up some minor issues in doc comments in internal API.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6602

From aleonard at openjdk.java.net  Tue Nov 30 21:41:27 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 21:41:27 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v10]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <PQjNXOs7FBmvFBHFjL3mJjUIl_Uaht4ue9VqqwPlOys=.0eb6dd43-1907-49fc-954f-68480759375d@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into jarjmodtimestamps
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/98a9f037...06aadf1e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=09
  Stats: 288 lines in 9 files changed: 260 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 21:48:36 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 21:48:36 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v11]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <GkA7vllsaIfuJBQu-0b7oas7ptWsxnNSkK75m4EM4VI=.b9f5f04f-44fc-4632-bc57-1c2ca7f31d2a@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/06aadf1e..62e2f7c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=09-10

  Stats: 21 lines in 1 file changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From aleonard at openjdk.java.net  Tue Nov 30 21:56:51 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 30 Nov 2021 21:56:51 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>

> Add a new --source-date <TIMESTAMP> (epoch seconds) option to jar and jmod to allow specification of time to use for created/updated jar/jmod entries. This then allows the ability to make the content deterministic.
> 
> Signed-off-by: Andrew Leonard <anleonar at redhat.com>

Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:

  8276766: Enable jar and jmod to produce deterministic timestamped content
  
  Signed-off-by: Andrew Leonard <anleonar at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/62e2f7c8..283e435a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=10-11

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6481/head:pull/6481

PR: https://git.openjdk.java.net/jdk/pull/6481

From darcy at openjdk.java.net  Tue Nov 30 22:02:28 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Nov 2021 22:02:28 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v6]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <nRXhcpE9GZ0V5RqJUECFW_h2VBW_MLlSGkKY0XyTwBg=.21b0acfa-24ae-41ef-a9ac-8add2e50313e@github.com>

> The time to get JDK 19 underway draws nigh, please review this usual set of start-of-release updates, including CSRs for the javac and javax.lang.model updates:
> 
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
> 
> JDK-8277514: Add source 19 and target 19 to javac
> https://bugs.openjdk.java.net/browse/JDK-8277514
> 
> Clean local tier 1 test runs for langtools, jdk, and hotspot.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Remove SharedSpaces options from VMDeprecatedOptions.java.
 - Merge branch 'master' into JDK-8273146
 - Respond to review feedback.
 - Add --release 18 information. Good tier1 test results.
 - JDK-8273146: Start of release updates for JDK 19

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=05
  Stats: 3286 lines in 68 files changed: 3242 ins; 4 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6493/head:pull/6493

PR: https://git.openjdk.java.net/jdk/pull/6493

From jjg at openjdk.java.net  Tue Nov 30 22:10:08 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 30 Nov 2021 22:10:08 GMT
Subject: Integrated: JDK-8276683: Malformed Javadoc inline tags in JDK source
 in com/sun/tools/javac/util/RawDiagnosticFormatter.java
In-Reply-To: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
References: <EeoS1UX-GqfUBZ8voVbhcHj1i-slNgShaXzzCxxmcxQ=.c3845c50-4940-4488-be51-3a8843cf897d@github.com>
Message-ID: <KNQxWHWEAL0jLfMxCuubDYSay5G9IICAtKn7WBC3NZk=.dbcadfee-03b3-4024-bb49-df98026b73e9@github.com>

On Mon, 29 Nov 2021 23:25:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial patch to fix up some minor issues in doc comments in internal API.

This pull request has now been integrated.

Changeset: 29426469
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2942646957537b2a4b078bc8cb0becab967c21e2
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8276683: Malformed Javadoc inline tags in JDK source in com/sun/tools/javac/util/RawDiagnosticFormatter.java

Reviewed-by: darcy, prappo, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/6602