From jgneff at openjdk.java.net  Wed Dec  1 01:13:34 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 01:13:34 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
Message-ID: <JQI9alrV07UylaqRy5EPntjy0A_xI6Xob9wsVIW1QD4=.61f927b8-3cb1-4779-a41e-af45748029e7@github.com>

On Tue, 30 Nov 2021 21:56:51 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 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>

Here is the 32-line Java program that I've been modifying to find problems and solutions:


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);
        if (args.length > 0) {
            instant = Instant.parse(args[0]);
        }
        System.out.println("Build timestamp = " + instant);

        var entry = new ZipEntry("Entry");
        var local = LocalDateTime.ofInstant(instant, ZoneOffset.UTC);

        TimeZone.setDefault(TimeZone.getTimeZone("America/Nome"));
        entry.setTimeLocal(local);
        writeZipFile("Zipped_in_Nome.zip", entry);

        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Rome"));
        entry.setTimeLocal(local);
        writeZipFile("Zipped_in_Rome.zip", entry);
    }
}


For example, first I pick up the timestamp of the last commit in my JavaFX fork:


$ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
$ date --date=@$SOURCE_DATE_EPOCH --iso-8601=seconds --utc
2021-11-22T05:00:22+00:00
$ git log -1 --pretty=%cI
2021-11-21T21:00:22-08:00


Then I can verify that the timestamp in the archive is unaffected by the default time zone of the JVM:


$ java Time 2021-11-21T21:00:22-08:00
Build timestamp = 2021-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22


Even when I create the ISO 8601 date and time string on a system in a different time zone than the two simulated build machines in Nome and Rome, it still works:


$ java Time 2021-11-22T08:00:22+03:00
Build timestamp = 2021-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          2021 Nov 22 05:00:22


But it all falls apart when we venture outside the permitted DOS date and time range:


$ java Time 1975-11-22T05:00:22+00:00
Build timestamp = 1975-11-22T05:00:22Z
$ for f in *.zip; do zipinfo -v $f | grep -e Archive -e modified; done
Archive:  Zipped_in_Nome.zip
  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1975 Nov 22 08:00:22 local
  file last modified on (UT extra field modtime): 1975 Nov 22 16:00:22 UTC
Archive:  Zipped_in_Rome.zip
  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1975 Nov 21 20:00:22 local
  file last modified on (UT extra field modtime): 1975 Nov 22 04:00:22 UTC

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

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

From jgneff at openjdk.java.net  Wed Dec  1 01:41:32 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 01:41:32 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
Message-ID: <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>

On Tue, 30 Nov 2021 21:56:51 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 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>

I found it helpful to look at what others have done.

The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.

Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.

The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.

@andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.

[1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
[2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
[3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

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

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

From itakiguchi at openjdk.java.net  Wed Dec  1 08:52:31 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 1 Dec 2021 08:52:31 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@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>
 <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>
Message-ID: <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@github.com>

On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

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

Hello @naotoj .
I discussed this issue with my colleagues.
With `-J-Dfile.encoding=COMPAT` option, the working behavior is the same as JDK17, so there is no disadvantage.
However, `-Xstdout` output file cannot be UTF8 encoded and we will not benefit from JEP-400 enhancements.
I expected that garbled character related issues could be solved easily by JEP-400 if javac command output is encoded by UTF8.
By using `-encoding` option with encoding name, javac command output can be UTF8 encoded.
But it's not easy to pick up right locale/platform encoding name except for well known users.
Anyway, when I find actual issue with `-J-Dfile.encoding=COMPAT` option for javac command, I will open new one.

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

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

From itakiguchi at openjdk.java.net  Wed Dec  1 08:52:31 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 1 Dec 2021 08:52:31 GMT
Subject: Withdrawn: 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: <Q_l9sNF3g6W_O36J9PJtTfgNdWOzFhXeDWpS0tEj4hs=.e6ebb13f-0490-4b4c-b9c0-b0e54600ba03@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".

This pull request has been closed without being integrated.

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

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

From xxinliu at amazon.com  Wed Dec  1 10:17:26 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 1 Dec 2021 02:17:26 -0800
Subject: Is bytecode invokeinterface correct when resolved method from Object?
Message-ID: <a4d1e47a-1d15-76d9-5631-5e26076ebde5@amazon.com>

Hello,

In Java programming language, I think it's legal to invoke
java.lang.Object's methods via any interface. All classes must be the
subclass of j.l.Object. Here is my example. Even though the interface
'I' doesn't have the symbol getClass, it will certainly resolve it in
runtime.


public class InvokeInterfaceTest {
    interface I {}
    static class Base {
        public static int bar() {
            return 0;
        }
    }
    static class C extends Base implements I {};

    public static boolean foo(I o) {
        return o.getClass() == C.class;
    }

    // javac compiler-error
    //public static int bar(I o) {
    //    return o.bar();
    //}

    public static void main(String args[]) {
        I o = new C();
        foo(o);
    }
}


For InvokeInterfaceTest::foo(I o), I didn't make it up. I have seen the
code like this in ArrayList.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L183

Until jdk17, javac generates 'invokevirtual' in InvokeInterfaceTest::foo.

  public static boolean foo(InvokeInterfaceTest$I);
    Code:
       0: aload_0
       1: invokevirtual #7                  // Method
java/lang/Object.getClass:()Ljava/lang/Class;
       4: ldc           #11                 // class InvokeInterfaceTest$C
       6: if_acmpne     13
       9: iconst_1
      10: goto          14
      13: iconst_0
      14: ireturn


The tip of JDK now replaces 'invokevirtual' with invokeinterface, as
follows.

  public static boolean foo(InvokeInterfaceTest$I);
    Code:
       0: aload_0
       1: invokeinterface #7,  1            // InterfaceMethod
InvokeInterfaceTest$I.getClass:()Ljava/lang/Class;
       6: ldc           #13                 // class InvokeInterfaceTest$C
...


Not only each call takes 2 more bytes, I feel it doesn't comply with JVM
spec. JVMS says that 'invokeinterface' resolves an 'interface method'.
j.l.Object.getClass() is not an interface method, is it?
https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokeinterface

Is it an intentional change of javac? My concern is that this ambiguity
makes HotSpot more complex. Further, if it does violate JVMS, it will
make javac implementation-dependent.

thanks,
--lx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB9D934C61E047B0D.asc
Type: application/pgp-keys
Size: 3674 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211201/c6fd1c3b/OpenPGP_0xB9D934C61E047B0D.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211201/c6fd1c3b/OpenPGP_signature.bin>

From aleonard at openjdk.java.net  Wed Dec  1 11:06:12 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 11:06:12 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@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/283e435a..c84bc5ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=11-12

  Stats: 58 lines in 1 file changed: 50 ins; 0 del; 8 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  Wed Dec  1 11:06:13 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 11:06:13 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v12]
In-Reply-To: <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <Rrtfa0Vqk9fZuiwf5E3jvKqxXOjIwqOAUes9JComGxs=.4e69c2e3-6779-4f14-b109-be5769b59d46@github.com>
 <cirAeZ0LGlPA9RW6KqKYw18e6s6aQ_Kr_WlL8hxdnkI=.cf9a995e-f073-4ea4-9c24-62bb2b802d23@github.com>
Message-ID: <9Q9BgKB7M_k_ldtqDALrT6LP6G7OPxkthTvHpbC2jJE=.94897652-9e7a-4706-96be-47b883272e93@github.com>

On Wed, 1 Dec 2021 01:37:55 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> 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>
>
> I found it helpful to look at what others have done.
> 
> The Debian `strip-nondeterminism` tool clamps the low end of the date to `1980-01-01T12:01:00`. All other dates are permitted no matter the consequence. That tool is written in Perl and is able to access all of the timestamp fields individually. See the [`zip.pm` file][1] for details.
> 
> Gradle decided that the only permissible date is `1980-02-01T00:00:00` in the default time zone of the JVM. Period. End of story. No customization at all. [They use a trick][2] with the old `GregorianCalendar` class to counteract the effect in `ZipEntry.setTime` of the default time zone. They use the `org.apache.tools.zip.ZipEntry` subclass of `java.util.zip.ZipEntry`, but many methods pass through to the super class. See the [`ZipCopyAction.java` file][3] for details.
> 
> The crux of our problem, as Andrew made more clear to me, is that the methods of `ZipEntry` do not allow for independent access to the two fields: the "DOS date/time" field and the "UT extra field modtime". When trying to set either one of them, the `ZipEntry` class can overwrite the other using the default time zone of the JVM.
> 
> @andrew-m-leonard So I agree. Either document that the archives are reproducible only within a certain range of dates, or disallow the dates that are out of range. Then we should be good for at least the next 78 years.
> 
> [1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/-/blob/master/lib/File/StripNondeterminism/handlers/zip.pm#L40
> [2]: https://github.com/gradle/gradle/issues/12895#issuecomment-618850095
> [3]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John for you test program, i've been using your previous version which is similar.
So please can you review the latest commit, it basically follows the same method of your test program using a ZonedDateTime instant from the input --date converted to a LocalDateTime of the same Instant in UTC, and then passed to e.setTimeLocal(ldt)
It also only allows --date in the local date range of 1980->2099

Here's a manual test from 2 timezones of this latest commit:

~/workspace/repbuild$ sudo timedatectl set-timezone GMT
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar1.jar Time.*
~/workspace/repbuild$ sudo timedatectl set-timezone EST
~/workspace/repbuild$ jar --create --date="2021-01-06T14:36:00+02:00" --file=myjar2.jar Time.*
~/workspace/repbuild$ zipinfo -v myjar1.jar | grep -e Archive -e modified
Archive:  myjar1.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
~/workspace/repbuild$ zipinfo -v myjar2.jar | grep -e Archive -e modified
Archive:  myjar2.jar
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00
  file last modified on (DOS date/time):          2021 Jan 6 12:36:00


I have also added reproducible jar tests across timezones.
thanks

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

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

From phedlin at openjdk.java.net  Wed Dec  1 12:37:41 2021
From: phedlin at openjdk.java.net (Patric Hedlin)
Date: Wed, 1 Dec 2021 12:37:41 GMT
Subject: RFR: 8251216: Implement MD5 intrinsics on AArch64
Message-ID: <UA4HwO5jBFQl8y6qCtKlLprSBgUdoC_wgsBQdXOaoqg=.9241674d-4c2d-471f-9484-01aedd71bcce@github.com>

Implementation of MD5 intrinsic support for AArch64.

Contributed by Ludovic Henry (@luhenry).

Speedup measured (in Aurora running Ampere Altra) as follows:

openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:1048576-provider:...29.39%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:2047-provider:.........28.91%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:2048-provider:.........28.81%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:1023-provider:.........28.43%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:1024-provider:.........28.32%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:511-provider:...........27.78%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:512-provider:...........27.62%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:255-provider:...........26.52%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:256-provider:...........26.38%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:127-provider:...........25.41%
openjdk.bench.javax.crypto.full.MessageDigestBench.digest-algorithm:MD5-dataSize:128-provider:...........24.66%

Testing tier1-7.

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

Commit messages:
 - 8251216: Implement MD5 intrinsics on AArch64

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

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

From gli at openjdk.java.net  Wed Dec  1 13:04:21 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 1 Dec 2021 13:04:21 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
 <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
Message-ID: <q7V0J9GSBOZZo4wBlOvGdAUUUKMxpCsy96_sT6TeMe8=.bed38563-93b3-4734-8410-cf059bc79a28@github.com>

On Mon, 29 Nov 2021 18:43:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> One possible alternative that might work would be to put this only into doHandleSwitchExpression

I don't think that putting the code into `doHandleSwitchExpression` can solve this issue. Because the issue is caused by the right operand of the binary operation but not the switch expression. If the switch expression is not the right operand of the binary operation, even though `!code.isAlive()` is true, it don't need to pop the stack element. You can see the comment `Complete generating code for operation, with left operand already on stack.` in the method `Gen#completeBinop`. Only when the left operand is already on the stack should we pop the stack element to resolve the mistake.

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

We can't disable the assertion when `code.isAlive()` is false, because there are many situations which can make `code.isAlive()` as false. The condition `code.state.stacksize != 0` is enough. When we simulate the stack opration to the end of the method, the stack always need to be empty which is same as the jvm(the actual stack opration). If the stack is not empty, it means the code generation step has the bug which is like this issue.

> In general, I am afraid there needs to be more testing

I will submit more tests as needed.

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

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

From prappo at openjdk.java.net  Wed Dec  1 13:40:21 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 1 Dec 2021 13:40:21 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: <r-dd6didFJ8p6RLL4EPWmS6JKC5L4HcdJMBUdPZKufY=.585d5650-23cf-4899-9ef8-70ab869c085b@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

Given that this PR affects files that aren't rooted under java/util/stream, I would either rename the PR or exclude the unrelated files. If this PR is going to sit there for some more time, I would prefer the latter. This is because the PR has already conflicted with a few other issues related to malformed javadoc tags (e.g. JDK-8276683 and JDK-8276684).

So either rename and integrate soon, or exclude the unrelated files.

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

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

From aleonard at openjdk.java.net  Wed Dec  1 14:02:29 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 14:02:29 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
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: <fZu6gZ7vmx-cJ6IgnaRjolIABdA_In6Ufyudz84846o=.20bd6dd5-5757-4525-bd7a-06107ffb6518@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 @LanceAndersen @jgneff The new update based on our discussions is now ready for review please. I have also updated the CSR: https://bugs.openjdk.java.net/browse/JDK-8277755 which is review ready as well.
thank you
Andrew

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

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

From ihse at openjdk.java.net  Wed Dec  1 14:15:31 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 1 Dec 2021 14:15:31 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v13]
In-Reply-To: <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <aQgya92n7GIIPkyZ_EqVkFJrWg9Tm-7D_wSic3Qjg1Q=.ff3af676-e246-40bf-a899-41a40f56ff52@github.com>
Message-ID: <HudycLmJzUlaRInUw2Q1fkOsTbnOHEEnpJdg8Q1FB3w=.e84b5509-ed2a-4ba5-bec4-abdd9b96e0cb@github.com>

On Wed, 1 Dec 2021 11:06:12 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>

src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java line 65:

> 63: 
> 64:     private final ZipOutputStream zos;
> 65:     private final LocalDateTime   date;

Suggestion:

    private final LocalDateTime date;


No need for extra spaces.

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

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

From jjg at openjdk.java.net  Wed Dec  1 15:45:33 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 1 Dec 2021 15:45:33 GMT
Subject: RFR: 8272234: Pass originating elements from Filer to
 JavaFileManager [v7]
In-Reply-To: <qQMZ4T6w1Okwfpxt5uClcgT6M3ahCYQRnOG5pjG3Kok=.cce9dfdd-edd7-427e-b20e-a7bc9597c305@github.com>
References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com>
 <qQMZ4T6w1Okwfpxt5uClcgT6M3ahCYQRnOG5pjG3Kok=.cce9dfdd-edd7-427e-b20e-a7bc9597c305@github.com>
Message-ID: <fJptGIEKdvFYFqjni_MV5qW0rt31uK9YH5VuF_aAnWs=.5b18c634-1c8f-4e93-9850-cb38bd9723e1@github.com>

On Fri, 26 Nov 2021 14:35:27 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 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

The recent commits all look good.

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

Marked as reviewed by jjg (Reviewer).

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

From gli at openjdk.java.net  Wed Dec  1 16:16:27 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 1 Dec 2021 16:16:27 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
 <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
Message-ID: <M-8Q1Hef_H3eTDsRsw2FTI4nCOE1MuGLluqJSpaEzIQ=.c9a07cc5-65cf-459b-bec7-fd66e12f431d@github.com>

On Mon, 29 Nov 2021 18:43:02 GMT, Jan Lahoda <jlahoda 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.

@lahodaj When I write the tests, I find that my patch fails at the test `4 + switch () {...} + switch () {...}`.

When the compiler handles the first switch expression, it pops the stack element so that the stack becomes empty. When the compiler handles the second switch expression, it pops the stack element just like the first one. But the stack is empty and an ArrayOutOfBoundException will be reported.

My current patch can't solve the issue. I will continue to find a better way to fix this bug. And the patch should be targeted to JDK19 because it seems not easy to solve it.

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

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

From jlahoda at openjdk.java.net  Wed Dec  1 16:40:37 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 1 Dec 2021 16:40:37 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <M-8Q1Hef_H3eTDsRsw2FTI4nCOE1MuGLluqJSpaEzIQ=.c9a07cc5-65cf-459b-bec7-fd66e12f431d@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
 <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
 <M-8Q1Hef_H3eTDsRsw2FTI4nCOE1MuGLluqJSpaEzIQ=.c9a07cc5-65cf-459b-bec7-fd66e12f431d@github.com>
Message-ID: <_cwURlxQvtpRZxMA1t4UCTJ5Jtiv4XO_z09AsQyzhrA=.d70f4220-c155-4331-8828-2372fb83c5fe@github.com>

On Wed, 1 Dec 2021 16:13:30 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> 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.
>
> @lahodaj When I write the tests, I find that my patch fails at the test `4 + switch () {...} + switch () {...}`.
> 
> When the compiler handles the first switch expression, it pops the stack element so that the stack becomes empty. When the compiler handles the second switch expression, it pops the stack element just like the first one. But the stack is empty and an ArrayOutOfBoundException will be reported.
> 
> My current patch can't solve the issue. I will continue to find a better way to fix this bug. And the patch should be targeted to JDK19 because it seems not easy to solve it.

Thanks @lgxbslgx, yes, I think this will be fairly complex, unfortunately. One more example (which does not include binary operators):

public class M {
     private void m(int i, int j) {
         m(0, switch (j) { default: if (true) throw new RuntimeException(); yield 0;} );
     }
}


Regarding disabling the assertion, OK, maybe that was too much. But we may have to do something more general than only a tweak for binary operators, unfortunately.

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

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

From asotona at openjdk.java.net  Wed Dec  1 16:42:42 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Dec 2021 16:42:42 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor has
 been called
Message-ID: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>

Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
 error: cannot reference super before supertype constructor has been called 

For example following source fragment cannot be compiled since that: 

    class EnclClass { 
        class InnerClass extends Exception { 
            InnerClass() { 
                super(EnclClass.super.toString()); 
            } 
        } 
    } 


This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super

Plus it adds a new test.

Thanks,
Adam

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

Commit messages:
 - 8278078: cannot reference super before supertype constructor has been called

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

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

From mcimadamore at openjdk.java.net  Wed Dec  1 16:52:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 1 Dec 2021 16:52:25 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <e-D_vNtDvkOVFNVFovpC3ZCGzNZZbkQP23SYwZfTCLs=.d2110685-043b-45da-9585-03dc595a1cfd@github.com>

On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

Looks good. For a qualified `super` call there are basically two cases:
1. qualifier is an interface name
2. qualifier is a class name

And there are two possible contexts:

a. constructors (this/super calls)
b. static
c. non-static

(in the JLS,  (a) and (b) are the same, but javac deals with them differently).

Now, javac was correct with { b, c } x ( 1, 2 }, even before the problematic patch. It was also correct with (a, 2). But in the case of (a, 1) javac accepted the code even if that was, essentially, a reference to `this` before `super`.

The patch in 8261006 fixes this, but, while now javac rejects (a, 1), it also ends up rejecting (a, 2), which is a mistake.

Your patch seems to introduce a sharper distinction between handling of (1) and (2), so it looks good.

But I suggest that we test all possible combinations of { a, b, c } x { 1, 2 } - where for (a) we try both with super() and this() calls.

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

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

From gli at openjdk.java.net  Wed Dec  1 17:04:24 2021
From: gli at openjdk.java.net (Guoxiong Li)
Date: Wed, 1 Dec 2021 17:04:24 GMT
Subject: RFR: 8276836: Error in javac caused by switch expression without
 result expressions: Internal error: stack sim error
In-Reply-To: <_cwURlxQvtpRZxMA1t4UCTJ5Jtiv4XO_z09AsQyzhrA=.d70f4220-c155-4331-8828-2372fb83c5fe@github.com>
References: <QTTZWDHD_kM74NPEGEwAHUFVxXl4xQT-_sArJiODBlI=.62b1a747-eb1b-4271-b409-fa0a24330042@github.com>
 <qsr2aKTzlwKgJGuKWhZadyGcnTbYOrmKi0LEabn97PM=.2ebb6f2b-932c-4e39-9fdb-ece9ac2116db@github.com>
 <M-8Q1Hef_H3eTDsRsw2FTI4nCOE1MuGLluqJSpaEzIQ=.c9a07cc5-65cf-459b-bec7-fd66e12f431d@github.com>
 <_cwURlxQvtpRZxMA1t4UCTJ5Jtiv4XO_z09AsQyzhrA=.d70f4220-c155-4331-8828-2372fb83c5fe@github.com>
Message-ID: <MglbERPs3Vo73BP2S6bAkukjjSKfJkOI3ehWR-UhIuM=.fa8b4cf2-ec35-49fd-9d7f-79a5c46cd9e4@github.com>

On Wed, 1 Dec 2021 16:37:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> @lahodaj When I write the tests, I find that my patch fails at the test `4 + switch () {...} + switch () {...}`.
>> 
>> When the compiler handles the first switch expression, it pops the stack element so that the stack becomes empty. When the compiler handles the second switch expression, it pops the stack element just like the first one. But the stack is empty and an ArrayOutOfBoundException will be reported.
>> 
>> My current patch can't solve the issue. I will continue to find a better way to fix this bug. And the patch should be targeted to JDK19 because it seems not easy to solve it.
>
> Thanks @lgxbslgx, yes, I think this will be fairly complex, unfortunately. One more example (which does not include binary operators):
> 
> public class M {
>      private void m(int i, int j) {
>          m(0, switch (j) { default: if (true) throw new RuntimeException(); yield 0;} );
>      }
> }
> 
> 
> Regarding disabling the assertion, OK, maybe that was too much. But we may have to do something more general than only a tweak for binary operators, unfortunately.

@lahodaj would you like to take over this issue so that it can be solved as soon as possible (maybe JDK18)? I am glad to hand over it to you which can push the work.

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

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

From naoto at openjdk.java.net  Wed Dec  1 17:14:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Dec 2021 17:14:35 GMT
Subject: RFR: 8277398: javac does not accept encoding name COMPAT [v2]
In-Reply-To: <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@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>
 <i0js_aQnY9fcrtOR0sJg9D3E2CKiAaaWDusahpaptA8=.d453694e-e5f3-4232-a2ed-8c9d2efbd85b@github.com>
 <Kfy1u61urpo-QRDMToHuaVKfqRwVwZg5bcyQmwUA-7o=.3ebc32ad-a239-4e3f-9311-759f2186a2fe@github.com>
Message-ID: <I2TNn-94QQ1am6R53VE4rWr-Pkv_csz3SYPPWnaFFYI=.83d2b07c-6635-405a-8431-e625cbaea7df@github.com>

On Wed, 1 Dec 2021 08:49:09 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> But it's not easy to pick up right locale/platform encoding name except for well known users. 

JEP 400 has the example to get the encoding name as a one liner:

java -XshowSettings:properties -version 2>&1 | grep file.encoding

(replace `file.encoding` with `native.encoding`, if using JDK18)

I believe this is simple enough.

> Anyway, when I find actual issue with `-J-Dfile.encoding=COMPAT` option for javac command, I will open new one.

I appreciate it. Thanks.

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

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

From vromero at openjdk.java.net  Wed Dec  1 17:46:23 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 1 Dec 2021 17:46:23 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <6ty6T5AqRlRapXF5V5ugplxLdbJs8SpL4DjztK4v_jk=.f23fe84e-2870-4dc2-89cc-a4eff31a1561@github.com>

On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

test/langtools/tools/javac/8278078/EclosingSuperTest.java line 7:

> 5:  * @run compile EclosingSuperTest.java
> 6:  */
> 7: public class EclosingSuperTest {

nit typo: Enclosing

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

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

From vromero at openjdk.java.net  Wed Dec  1 17:49:24 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 1 Dec 2021 17:49:24 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <RWn6yLoC1yuYi6Y6jbxF_W-yaB9XbsTIJe2r1uUwuO8=.b8b15b52-9e9c-43f6-a672-b8d5edec104d@github.com>

On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

yep the patch looks very sensible, modulo the tests proposed by Maurizio which will complete it

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

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

From aleonard at openjdk.java.net  Wed Dec  1 18:02:05 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 18:02:05 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@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:

  Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
  
  Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6481/files
  - new: https://git.openjdk.java.net/jdk/pull/6481/files/c84bc5ad..2f3a7fc2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=12-13

  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 alex.buckley at oracle.com  Wed Dec  1 18:07:56 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 1 Dec 2021 10:07:56 -0800
Subject: Is bytecode invokeinterface correct when resolved method from
 Object?
In-Reply-To: <a4d1e47a-1d15-76d9-5631-5e26076ebde5@amazon.com>
References: <a4d1e47a-1d15-76d9-5631-5e26076ebde5@amazon.com>
Message-ID: <1ee75015-0205-6381-3605-f01a25ed1bbe@oracle.com>

On 12/1/2021 2:17 AM, Liu, Xin wrote:
> Not only each call takes 2 more bytes, I feel it doesn't comply with JVM
> spec. JVMS says that 'invokeinterface' resolves an 'interface method'.
> j.l.Object.getClass() is not an interface method, is it?
> https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokeinterface
> 
> Is it an intentional change of javac? My concern is that this ambiguity
> makes HotSpot more complex. Further, if it does violate JVMS, it will
> make javac implementation-dependent.

Emitting invokeinterface rather than invokevirtual in this scenario is 
legitimate, correct, desirable, and documented (CSR: JDK-8272715).

`o.getClass()` is a method invocation whose receiver, `o`, has a static 
type that is an interface, I. The compiler knows from JLS 9.2 that 
`getClass()` is a member of I, so it is proper for the compiler to treat 
`getClass()` as an interface method and thus emit an invokeinterface of 
I.getClass. When the invokeinterface instruction is executed, its first 
task is to resolve the interface method I.getClass -- happily, since the 
Java SE 8 Edition, JVMS 5.4.3.4 has aligned with JLS 9.2 by 
understanding that certain methods can be resolved in interfaces:

"Otherwise, if the class Object declares a method with the name and 
descriptor specified by the interface method reference, which has its 
ACC_PUBLIC flag set and does not have its ACC_STATIC flag set, method 
lookup succeeds."

Alex

From jgneff at openjdk.java.net  Wed Dec  1 18:24:28 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Wed, 1 Dec 2021 18:24:28 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
Message-ID: <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>

On Wed, 1 Dec 2021 18:02:05 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 one additional commit since the last revision:
> 
>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>   
>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

I'm testing it now. So far, it's working great!

I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:


  file last modified on (DOS date/time):          1980 Jan 1 00:00:00
  file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
  file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC


One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):


  file last modified on (DOS date/time):          1980 Jan 1 00:00:00

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

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

From xxinliu at amazon.com  Wed Dec  1 19:04:18 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 1 Dec 2021 11:04:18 -0800
Subject: Is bytecode invokeinterface correct when resolved method from
 Object?
In-Reply-To: <a4d1e47a-1d15-76d9-5631-5e26076ebde5@amazon.com>
References: <a4d1e47a-1d15-76d9-5631-5e26076ebde5@amazon.com>
Message-ID: <c382440c-339b-43bc-7229-7e5d12271e26@amazon.com>

hi, Alex,

Thanks for the explanation! Indeed, JVMS and JLS are aligned and they
cover Object's methods in the interface. I also understand why
InvokeInterfaceTest::bar() can't compile in my example.

thanks,
--lx



On 12/1/21 2:17 AM, Liu, Xin wrote:
> Hello,
> 
> In Java programming language, I think it's legal to invoke
> java.lang.Object's methods via any interface. All classes must be the
> subclass of j.l.Object. Here is my example. Even though the interface
> 'I' doesn't have the symbol getClass, it will certainly resolve it in
> runtime.
> 
> 
> public class InvokeInterfaceTest {
>     interface I {}
>     static class Base {
>         public static int bar() {
>             return 0;
>         }
>     }
>     static class C extends Base implements I {};
> 
>     public static boolean foo(I o) {
>         return o.getClass() == C.class;
>     }
> 
>     // javac compiler-error
>     //public static int bar(I o) {
>     //    return o.bar();
>     //}
> 
>     public static void main(String args[]) {
>         I o = new C();
>         foo(o);
>     }
> }
> 
> 
> For InvokeInterfaceTest::foo(I o), I didn't make it up. I have seen the
> code like this in ArrayList.
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ArrayList.java#L183
> 
> Until jdk17, javac generates 'invokevirtual' in InvokeInterfaceTest::foo.
> 
>   public static boolean foo(InvokeInterfaceTest$I);
>     Code:
>        0: aload_0
>        1: invokevirtual #7                  // Method
> java/lang/Object.getClass:()Ljava/lang/Class;
>        4: ldc           #11                 // class InvokeInterfaceTest$C
>        6: if_acmpne     13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: ireturn
> 
> 
> The tip of JDK now replaces 'invokevirtual' with invokeinterface, as
> follows.
> 
>   public static boolean foo(InvokeInterfaceTest$I);
>     Code:
>        0: aload_0
>        1: invokeinterface #7,  1            // InterfaceMethod
> InvokeInterfaceTest$I.getClass:()Ljava/lang/Class;
>        6: ldc           #13                 // class InvokeInterfaceTest$C
> ...
> 
> 
> Not only each call takes 2 more bytes, I feel it doesn't comply with JVM
> spec. JVMS says that 'invokeinterface' resolves an 'interface method'.
> j.l.Object.getClass() is not an interface method, is it?
> https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokeinterface
> 
> Is it an intentional change of javac? My concern is that this ambiguity
> makes HotSpot more complex. Further, if it does violate JVMS, it will
> make javac implementation-dependent.
> 
> thanks,
> --lx
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB9D934C61E047B0D.asc
Type: application/pgp-keys
Size: 3674 bytes
Desc: OpenPGP public key
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211201/b65dc25e/OpenPGP_0xB9D934C61E047B0D-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211201/b65dc25e/OpenPGP_signature-0001.bin>

From asotona at openjdk.java.net  Wed Dec  1 20:35:09 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Dec 2021 20:35:09 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <zCvF-0Yq9Sf-FM1OxALoQX9rYeuJm22cneDAx6WTicI=.495ea3d5-692c-4edc-806f-9c4a2b1be4cb@github.com>

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo in test name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6642/files
  - new: https://git.openjdk.java.net/jdk/pull/6642/files/f0242397..a3964667

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

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

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

From asotona at openjdk.java.net  Wed Dec  1 20:35:10 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Dec 2021 20:35:10 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <e-D_vNtDvkOVFNVFovpC3ZCGzNZZbkQP23SYwZfTCLs=.d2110685-043b-45da-9585-03dc595a1cfd@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <e-D_vNtDvkOVFNVFovpC3ZCGzNZZbkQP23SYwZfTCLs=.d2110685-043b-45da-9585-03dc595a1cfd@github.com>
Message-ID: <I_ALw_VlpVeMzRVVFp4kxpOW7wLezFa-4LXimPRLOGo=.12478388-fe42-47a2-b72c-7a178ff72706@github.com>

On Wed, 1 Dec 2021 16:49:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> And there are three possible contexts:
> 
> a. constructors (this/super calls) 
> b. static
> c. non-static

I'm actually not quite sure what the b. static and c. non-static contexts exactly mean in a context of this issue and how is it related with the bug subject "cannot reference super before supertype constructor has been called".

This only specifically failing case (constructor with super call to enclosing class) has been identified from the large regression compilation Corpus experiment.

I would prefer to track improvements in the actual test coverage as a separate issue, mainly to don't block this specific quick regression fix and have more time to design the test matrix more precisely.

Thanks,
Adam

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

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

From asotona at openjdk.java.net  Wed Dec  1 20:35:12 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 1 Dec 2021 20:35:12 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <6ty6T5AqRlRapXF5V5ugplxLdbJs8SpL4DjztK4v_jk=.f23fe84e-2870-4dc2-89cc-a4eff31a1561@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <6ty6T5AqRlRapXF5V5ugplxLdbJs8SpL4DjztK4v_jk=.f23fe84e-2870-4dc2-89cc-a4eff31a1561@github.com>
Message-ID: <EgVyzBvkzKowHes3eZE8e6yqW7_7_srLrSVF4FG68jE=.14f7a426-12f2-4935-9d0e-26235016faa8@github.com>

On Wed, 1 Dec 2021 17:43:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo in test name
>
> test/langtools/tools/javac/8278078/EclosingSuperTest.java line 7:
> 
>> 5:  * @run compile EclosingSuperTest.java
>> 6:  */
>> 7: public class EclosingSuperTest {
> 
> nit typo: Enclosing

fixed, thanks :)

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

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

From darcy at openjdk.java.net  Wed Dec  1 20:50:27 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 1 Dec 2021 20:50:27 GMT
Subject: RFR: 8277965: Enclosing instance optimization affects
 serialization
In-Reply-To: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
References: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
Message-ID: <kk6kBvvC9Eu3KqKpch6E1EOFvWExzD-m1SquCBnODXA=.2251ca0d-e85d-4027-9bb3-f582893c4f77@github.com>

On Tue, 30 Nov 2021 01:59:55 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

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

Marked as reviewed by darcy (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Wed Dec  1 21:17:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 1 Dec 2021 21:17:24 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <I_ALw_VlpVeMzRVVFp4kxpOW7wLezFa-4LXimPRLOGo=.12478388-fe42-47a2-b72c-7a178ff72706@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <e-D_vNtDvkOVFNVFovpC3ZCGzNZZbkQP23SYwZfTCLs=.d2110685-043b-45da-9585-03dc595a1cfd@github.com>
 <I_ALw_VlpVeMzRVVFp4kxpOW7wLezFa-4LXimPRLOGo=.12478388-fe42-47a2-b72c-7a178ff72706@github.com>
Message-ID: <0IzHgK-PQhvuVSF3QSGjl43RAoI__cxILZyLjVEcaiw=.af50e235-b881-46e9-8a5f-d7a7b544f964@github.com>

On Wed, 1 Dec 2021 20:29:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> > And there are three possible contexts:
> > a. constructors (this/super calls)
> > b. static
> > c. non-static
> 
> I'm actually not quite sure what the b. static and c. non-static contexts exactly mean in a context of this issue and how is it related with the bug subject "cannot reference super before supertype constructor has been called".
> 
> This only specifically failing case (constructor with super call to enclosing class) has been identified from the large regression compilation Corpus experiment.
> 
> I would prefer to track improvements in the actual test coverage as a separate issue, mainly to don't block this specific quick regression fix and have more time to design the test matrix more precisely.

It's ok to add more tests later. But at the very least I would like to see now a test which tries also `this(Foo.super.m())` - because the two forms are very related.

> 
> Thanks, Adam

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

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

From mcimadamore at openjdk.java.net  Wed Dec  1 21:30:36 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 1 Dec 2021 21:30:36 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <zCvF-0Yq9Sf-FM1OxALoQX9rYeuJm22cneDAx6WTicI=.495ea3d5-692c-4edc-806f-9c4a2b1be4cb@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <zCvF-0Yq9Sf-FM1OxALoQX9rYeuJm22cneDAx6WTicI=.495ea3d5-692c-4edc-806f-9c4a2b1be4cb@github.com>
Message-ID: <aB55RyiRSoAol6Ye8Gwb6NNKk8WjyiZrwi59NZUFBwg=.772a4957-06de-4a8d-865f-e0c422bb5991@github.com>

On Wed, 1 Dec 2021 20:35:09 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>>  error: cannot reference super before supertype constructor has been called 
>> 
>> For example following source fragment cannot be compiled since that: 
>> 
>>     class EnclClass { 
>>         class InnerClass extends Exception { 
>>             InnerClass() { 
>>                 super(EnclClass.super.toString()); 
>>             } 
>>         } 
>>     } 
>> 
>> 
>> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
>> 
>> Plus it adds a new test.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo in test name

test/langtools/tools/javac/8278078/EnclosingSuperTest.java line 7:

> 5:  * @run compile EclosingSuperTest.java
> 6:  */
> 7: public class EnclosingSuperTest {

My suggestion for another test is something like this:


public class EnclosingSuperTest2 {
    class InnerClass extends Exception {
        InnerClass() {
            this(EnclosingSuperTest2.super.toString());
        }
        
        InnerClass(String s) { }
    }
}


This test also pass before the problematic fix, and fails afterwards, so I think we should add it too.

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

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

From cushon at openjdk.java.net  Wed Dec  1 21:33:27 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 1 Dec 2021 21:33:27 GMT
Subject: RFR: 8277965: Enclosing instance optimization affects
 serialization
In-Reply-To: <kk6kBvvC9Eu3KqKpch6E1EOFvWExzD-m1SquCBnODXA=.2251ca0d-e85d-4027-9bb3-f582893c4f77@github.com>
References: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
 <kk6kBvvC9Eu3KqKpch6E1EOFvWExzD-m1SquCBnODXA=.2251ca0d-e85d-4027-9bb3-f582893c4f77@github.com>
Message-ID: <cluYvPQMdzosGtTXVtgqic9UAAdVB1kf5XqdHMvg8j8=.759e6f73-4c10-4f13-9d23-bacb6d20811a@github.com>

On Wed, 1 Dec 2021 20:47:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 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.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy thanks for the review!

To double-check before I integrate this, is anything still broken?

[JDK-8277718](https://bugs.openjdk.java.net/browse/JDK-8277718) mentions a decision to problem-list 3 JCK tests instead of backing this out, and in [JDK-8271717](https://bugs.openjdk.java.net/browse/JDK-8271717?focusedCommentId=14461616&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14461616) the issue with the JCK tests was described as a 'test bug'.

I'm happy back this out if, but I think it's worth considering keeping it (potentially after reverting it and having further discussion in a new CSR).

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

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

From aleonard at openjdk.java.net  Wed Dec  1 21:53:25 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Wed, 1 Dec 2021 21:53:25 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
Message-ID: <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>

On Wed, 1 Dec 2021 18:20:11 GMT, John Neffenger <jgneff at openjdk.org> wrote:

> I'm testing it now. So far, it's working great!
> 
> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
> 
> ```
>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
> ```
> 
> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
> 
> ```
>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
> ```

Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?

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

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

From jgneff at openjdk.java.net  Thu Dec  2 01:09:33 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 2 Dec 2021 01:09:33 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
Message-ID: <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>

On Wed, 1 Dec 2021 18:02:05 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 one additional commit since the last revision:
> 
>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>   
>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>

Mainly just two minor comments: (1) there's a better date and time parser, and (2) the current lower bound is a couple seconds off. I'll reply to your question about (2) separately.

The `DateTimeFormatter.ISO_ZONED_DATE_TIME` zoned date and time parser works better than the `ISO_DATE_TIME` local date and time parser when creating a `ZonedDateTime` instance. It catches the following error slightely earlier and provides a better error message.

Here's the current error using the local date and time parser:


$ jmod create --date 2011-12-03T10:15:30 ...
Error: --date 2011-12-03T10:15:30 is not a valid ISO 8601 date and time:
    Text '2011-12-03T10:15:30' could not be parsed:
    Unable to obtain ZonedDateTime from TemporalAccessor:
    {},ISO resolved to 2011-12-03T10:15:30 of type java.time.format.Parsed


Here's the same error using the zoned date and time parser:


$ jmod create --date 2011-12-03T10:15:30 ...
Error: --date 2011-12-03T10:15:30 is not a valid ISO 8601 date and time:
    Text '2021-11-29T09:36:06' could not be parsed at index 19

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 199:

> 197:                 void process(Main jartool, String opt, String arg) throws BadArgs {
> 198:                     try {
> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)

The `ISO_ZONED_DATE_TIME` parser works better here.

src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 201:

> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
> 200:                                            .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
> 201:                         if (jartool.date.getYear() < 1980 || jartool.date.getYear() > 2099) {

This `if` test actually compares down to the nanosecond, if present, but the wrong nanosecond. How about something like the following?


    ... ZonedDateTime TIME_MIN = ZonedDateTime.parse("1980-01-01T00:00:02Z");
    ... ZonedDateTime TIME_MAX = ZonedDateTime.parse("2099-12-31T23:59:59Z");
    ...
        var zoned = ZonedDateTime.parse(date, DateTimeFormatter.ISO_ZONED_DATE_TIME);
        if (zoned.isBefore(TIME_MIN) || zoned.isAfter(TIME_MAX)) {
            ....

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.out.of.range=\
> 88:         date {0} is not within the valid year range 1980->2099 

Maybe just define `date {0} is not within the valid range` and put the exact interval in the *man* pages and documentation?

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

> 1162:         public LocalDateTime convert(String value) {
> 1163:             try {
> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)

The `ISO_ZONED_DATE_TIME` parser works better here.

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

> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
> 1165:                                          .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
> 1166:                 if (date.getYear() < 1980 || date.getYear() > 2099) {

See previous comment for this line in the `jar` tool.

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:

> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
> 111: err.date.out.of.range=--date {0} is out of the valid year range 1980->2099

As before, perhaps refer to the exact range in the documentation? It's really an instant on the time line that is being compared and not the actual year digits that were provided in the command-line option.

test/jdk/tools/jar/JarEntryTime.java line 180:

> 178:                                 "2022-03-15T00:00:00+06:00",
> 179:                                 "2038-11-26T06:06:06+00:00",
> 180:                                 "2098-02-18T00:00:00-08:00"};

It would be great to test just inside the exact boundaries of the permitted interval here.

test/jdk/tools/jar/JarEntryTime.java line 251:

> 249:         // Negative Tests --date out of range source date
> 250:         String[] badSourceDates = {"1976-06-24T01:02:03+00:00",
> 251:                                    "2100-02-18T00:00:00-11:00"};

It would be great to test just outside the exact boundaries of the permitted interval here.

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

Changes requested by jgneff (no project role).

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

From jgneff at openjdk.java.net  Thu Dec  2 01:56:25 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Thu, 2 Dec 2021 01:56:25 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
Message-ID: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>

On Wed, 1 Dec 2021 21:50:46 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?

I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).

Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.

So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].

[1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

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

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

From duke at openjdk.java.net  Thu Dec  2 02:36:47 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 02:36:47 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source in
 java/util/stream [v2]
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: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>

> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8276674
 - 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=01
  Stats: 13 lines in 8 files changed: 0 ins; 0 del; 13 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 asotona at openjdk.java.net  Thu Dec  2 08:32:14 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Dec 2021 08:32:14 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v3]
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <VqxxmBzTD20XpIyxMgakQbUN00DAA7mleXlofwAGwfY=.8da379c7-89ed-4a9d-a597-d0c3fb267658@github.com>

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed handling of <self>.super
  extended set of compilation validation tests
  added set of negative tests that should result in compilation error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6642/files
  - new: https://git.openjdk.java.net/jdk/pull/6642/files/a3964667..1d09e71c

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

  Stats: 142 lines in 5 files changed: 128 ins; 13 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6642/head:pull/6642

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

From sadayapalam at openjdk.java.net  Thu Dec  2 08:34:04 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 2 Dec 2021 08:34:04 GMT
Subject: RFR: 8268575: Annotations not visible on model elements before they
 are generated
Message-ID: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>

As an inadvertant side effect of JDK-8206325, the model was failing to expose a missing annotation type. Address this.

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

Commit messages:
 - 8268575: Annotations not visible on model elements before they are generated

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

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

From asotona at openjdk.java.net  Thu Dec  2 08:35:29 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Dec 2021 08:35:29 GMT
Subject: RFR: 8278078: cannot reference super before supertype constructor
 has been called [v2]
In-Reply-To: <aB55RyiRSoAol6Ye8Gwb6NNKk8WjyiZrwi59NZUFBwg=.772a4957-06de-4a8d-865f-e0c422bb5991@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <zCvF-0Yq9Sf-FM1OxALoQX9rYeuJm22cneDAx6WTicI=.495ea3d5-692c-4edc-806f-9c4a2b1be4cb@github.com>
 <aB55RyiRSoAol6Ye8Gwb6NNKk8WjyiZrwi59NZUFBwg=.772a4957-06de-4a8d-865f-e0c422bb5991@github.com>
Message-ID: <hWlm9AlaxJQNAF8uvs8Nc1wxO4at8a6obKZLQnc3iU0=.1038c431-16f0-4e16-913e-61d3fc377c80@github.com>

On Wed, 1 Dec 2021 21:27:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo in test name
>
> test/langtools/tools/javac/8278078/EnclosingSuperTest.java line 7:
> 
>> 5:  * @run compile EclosingSuperTest.java
>> 6:  */
>> 7: public class EnclosingSuperTest {
> 
> My suggestion for another test is something like this:
> 
> 
> public class EnclosingSuperTest2 {
>     class InnerClass extends Exception {
>         InnerClass() {
>             this(EnclosingSuperTest2.super.toString());
>         }
>         
>         InnerClass(String s) { }
>     }
> }
> 
> 
> This test also pass before the problematic fix, and fails afterwards, so I think we should add it too.

Yes, now I understand.
I've extended set of "Valid" test cases and also added several "Invalid" test cases expecting to fail to compile.
During that work I found <self class>.super used in constructor arg is not failing compilation, so the Attr patch is also adjusted for that case.

However all the test cases here are still related to this and super in constructor args only, test matrix for other contexts should follow.

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

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

From sadayapalam at openjdk.java.net  Thu Dec  2 08:52:25 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 2 Dec 2021 08:52:25 GMT
Subject: RFR: 8268575: Annotations not visible on model elements before
 they are generated
In-Reply-To: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
References: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
Message-ID: <Vz4BdOIrDilYOLYwufCMxlIXs9ZTH3yLIBzSYIGEqbM=.ffca048d-730e-470d-b930-877f139077f4@github.com>

On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> As an inadvertant side effect of JDK-8206325, the model was failing to expose a missing annotation type. Address this.

The code chunk that "gathers up the annotations into a map" in the method Annotate.annotateNow got surrounded/enclosed  by a check 

if (a.type.tsym.isAnnotationType()) {
}

as part of the fix for JDK-8206325 - this check is tighter than it ought to be.

javax.lang.model spec requires that 

If a program refers to a missing class or interface Xyz, the returned model must contain no less information than if the declaration of class or interface Xyz were assumed to be "class Xyz {}", "interface Xyz {}", "enum Xyz {}", "@interface Xyz {}", or "record Xyz {}".


This goal would be defeated by the check above and hence the present fix which relaxes it so we tolerate missing types and expose them in the model.

(It is worth calling out that annotation processing would not kick in if there are errors that could not be recovered from by generation of code from the processor)

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

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

From aleonard at openjdk.java.net  Thu Dec  2 09:52:30 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 09:52:30 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <a6ZdfjhqfsJ-TYBbiXphB04AiiDREJVVwLbLMJjOGWw=.0a82c014-e911-4852-ba70-fb14d85990ae@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John, for a great review. The ZONED parser I believe achieves the same end goal, but I hadn't realized the error messages would be different, as you say it's more clear, i'll change to that.

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

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

From mcimadamore at openjdk.java.net  Thu Dec  2 12:00:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 12:00:41 GMT
Subject: RFR: 8261006: 'super' qualified method references cannot occur in
 a static context [v7]
In-Reply-To: <7WzcbTakN8P-wt64Fma6Ag-X8Zz782Nv238WHcF6hG4=.96187a6a-6958-463d-aca9-b55573dfda99@github.com>
References: <y2ns2VH2m07Kg4M4OQJf0eGSiWhIQreW1lCi2H-XlvM=.e9324ca9-b88f-4f3d-8d77-370223e9bcce@github.com>
 <7WzcbTakN8P-wt64Fma6Ag-X8Zz782Nv238WHcF6hG4=.96187a6a-6958-463d-aca9-b55573dfda99@github.com>
Message-ID: <9dw7N_prtolEW0exonhH8TiUZV6_lcv6bBilezrR4uQ=.5fa7772b-8f73-4d03-ab5b-1bee1ffcb3f1@github.com>

On Thu, 15 Jul 2021 03:20:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR, currently javac is accepting code like:
>> 
>> 
>> import java.util.function.Supplier;
>> 
>> public class MethodReferenceInConstructorInvocation {
>>     interface Bar {
>>         default String getString() { return ""; }
>>     }
>> 
>>     static class Foo implements Bar {
>>         public Foo() {  this(Bar.super::getString);  }
>>         public Foo(Supplier<String> sString) {}
>>     }
>> }
>> 
>> 
>> but the spec states in `15.13 Method Reference Expressions`:
>> 
>> If a method reference expression has the form super :: [TypeArguments] Identifier
>> or TypeName . super :: [TypeArguments] Identifier, it is a compile-time error if
>> the expression occurs in a static context (?8.1.3).
>> 
>> and a constructor invocation is a static context. So method references of this form, qualified by `super`, should be rejected by the compiler if they appear in a static context.
>> 
>> TIA
>
> Vicente Romero 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-8261006
>  - Merge branch 'master' into JDK-8261006
>  - addressing review comments
>  - updating comment
>  - addressing review comments
>  - Merge branch 'master' into JDK-8261006
>  - 8261006: fail to parse broken interface::method in lambda

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

> 4340: 
> 4341:         if (isType(sitesym)) {
> 4342:             if (sym.name == names._this || sym.name == names._super) {

I suggest to rewrite this as:


if (sym.name == names._this) {
   if (site.tsym == env.enclClass.sym) {
      // error
   }
} else if (sym.name == names._super) {
   if (sitesym.isInterface() || site.tsym == env.enclClass.sym) {
      // error
   }
}

As the compound expression is giving me headache :-)

Note that I've dropped the `constructorArgs` check, because I think this is set in Attr::visitApply, and can be assumed to be true if `isSelfCall` is set.

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

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

From aleonard at openjdk.java.net  Thu Dec  2 12:00:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:00:43 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v15]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <dN4BOng01bsio75VfS9Odqr7S7YQCNeFE9nzR-HRWNk=.e1b2ddb3-84ab-461d-8988-131caba5e87c@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 23 commits:

 - 8276766: Enable jar and jmod to produce deterministic timestamped content
   
   Signed-off-by: Andrew Leonard <anleonar at redhat.com>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - 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>
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/e002bfec...8e60bb77

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=14
  Stats: 330 lines in 8 files changed: 306 ins; 0 del; 24 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  Thu Dec  2 12:00:47 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 12:00:47 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <eOIKnc0kCSj5XB0qZGM7NIUk9cPJpfLWlxCCJyqG_hI=.54b0f3cc-0767-4c4a-bc01-4c5bd6d21f49@github.com>
Message-ID: <1TVeAXO1-tjT6C9SqhRYMfZeJ2eo-k0hGEL8pgy6qNM=.70576808-e0f1-41b2-9bd5-daa218f6b4c8@github.com>

On Thu, 2 Dec 2021 00:09:15 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>> Andrew Leonard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>>   
>>   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>
> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 199:
> 
>> 197:                 void process(Main jartool, String opt, String arg) throws BadArgs {
>> 198:                     try {
>> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
> 
> The `ISO_ZONED_DATE_TIME` parser works better here.

done

> src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java line 201:
> 
>> 199:                         jartool.date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_DATE_TIME)
>> 200:                                            .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
>> 201:                         if (jartool.date.getYear() < 1980 || jartool.date.getYear() > 2099) {
> 
> This `if` test can end up with consequences down to the millisecond of the instant provided, if present. (Try `1980-01-01T00:00:00.001Z` vs. `1980-01-01T00:00:00Z` and check for extended headers.) How about something like the following?
> 
> 
>     ... ZonedDateTime TIME_MIN = ZonedDateTime.parse("1980-01-01T00:00:02Z");
>     ... ZonedDateTime TIME_MAX = ZonedDateTime.parse("2099-12-31T23:59:59Z");
>     ...
>         var zoned = ZonedDateTime.parse(date, DateTimeFormatter.ISO_ZONED_DATE_TIME);
>         if (zoned.isBefore(TIME_MIN) || zoned.isAfter(TIME_MAX)) {
>             ....

done

> 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.out.of.range=\
>> 88:         date {0} is not within the valid year range 1980->2099 
> 
> Maybe just define `date {0} is not within the valid range` and put the exact interval in the *man* pages and documentation?

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1164:
> 
>> 1162:         public LocalDateTime convert(String value) {
>> 1163:             try {
>> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
> 
> The `ISO_ZONED_DATE_TIME` parser works better here.

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java line 1166:
> 
>> 1164:                 LocalDateTime date = ZonedDateTime.parse(value, DateTimeFormatter.ISO_DATE_TIME)
>> 1165:                                          .withZoneSameInstant(ZoneOffset.UTC).toLocalDateTime();
>> 1166:                 if (date.getYear() < 1980 || date.getYear() > 2099) {
> 
> See previous comment for this line in the `jar` tool.

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:
> 
>> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
>> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
>> 111: err.date.out.of.range=--date {0} is out of the valid year range 1980->2099
> 
> As before, perhaps refer to the exact range in the documentation? It's really an instant on the time line that is being compared and not the actual year digits that were provided in the command-line option.

done

> test/jdk/tools/jar/JarEntryTime.java line 180:
> 
>> 178:                                 "2022-03-15T00:00:00+06:00",
>> 179:                                 "2038-11-26T06:06:06+00:00",
>> 180:                                 "2098-02-18T00:00:00-08:00"};
> 
> It would be great to test just inside the exact boundaries of the permitted interval here. That is, test `1980-01-01T00:00:02+00:00` and `2099-12-31T23:59:59+00:00`.

done

> test/jdk/tools/jar/JarEntryTime.java line 251:
> 
>> 249:         // Negative Tests --date out of range source date
>> 250:         String[] badSourceDates = {"1976-06-24T01:02:03+00:00",
>> 251:                                    "2100-02-18T00:00:00-11:00"};
> 
> It would be great to test just outside the exact boundaries of the permitted interval here. That is, test `1980-01-01T00:00:01+00:00` and `2100-01-01T00:00:00+00:00`.

done

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

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

From mcimadamore at openjdk.java.net  Thu Dec  2 12:03:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 12:03:27 GMT
Subject: RFR: 8278078: Cannot reference super before supertype constructor
 has been called [v3]
In-Reply-To: <VqxxmBzTD20XpIyxMgakQbUN00DAA7mleXlofwAGwfY=.8da379c7-89ed-4a9d-a597-d0c3fb267658@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <VqxxmBzTD20XpIyxMgakQbUN00DAA7mleXlofwAGwfY=.8da379c7-89ed-4a9d-a597-d0c3fb267658@github.com>
Message-ID: <6xWxKJ-I2oHIlkzwFiymYmEM9l7iSR9wBi1kmRYQkw0=.a53d3f0b-84be-423e-931e-fae8a0e5ffc7@github.com>

On Thu, 2 Dec 2021 08:32:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>>  error: cannot reference super before supertype constructor has been called 
>> 
>> For example following source fragment cannot be compiled since that: 
>> 
>>     class EnclClass { 
>>         class InnerClass extends Exception { 
>>             InnerClass() { 
>>                 super(EnclClass.super.toString()); 
>>             } 
>>         } 
>>     } 
>> 
>> 
>> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
>> 
>> Plus it adds a new test.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed handling of <self>.super
>   extended set of compilation validation tests
>   added set of negative tests that should result in compilation error

test/langtools/tools/javac/8278078/InvalidThisAndSuperInConstructorArgTest.java line 22:

> 20:             super(InnerClass.super.toString());
> 21:         }
> 22:         InnerClass(int i) {

Should we write a similar test where, instead of InnerClass.super.toString(), we pass InnerClass.super::toString (e.g. a method ref) ? I think it would be useful that all these would fail, even in method reference mode.

test/langtools/tools/javac/8278078/ValidThisAndSuperInConstructorArgTest.java line 2:

> 1: /**
> 2:  * @test /nodynamiccopyright/

This is a positive test, so we typically add copyright in those.

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

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

From asotona at openjdk.java.net  Thu Dec  2 12:23:59 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Dec 2021 12:23:59 GMT
Subject: RFR: 8278078: Cannot reference super before supertype constructor
 has been called [v4]
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <_VfExHBkh85Xv-lBl1JVI7gPYd-f1nFmEFA0R_9A12Q=.f5245ac1-ef70-46a5-8771-a0630b7320dd@github.com>

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  aded copyright notice and method reference test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6642/files
  - new: https://git.openjdk.java.net/jdk/pull/6642/files/1d09e71c..4bd9503c

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

  Stats: 47 lines in 3 files changed: 33 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6642/head:pull/6642

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

From asotona at openjdk.java.net  Thu Dec  2 12:24:04 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Dec 2021 12:24:04 GMT
Subject: RFR: 8278078: Cannot reference super before supertype constructor
 has been called [v3]
In-Reply-To: <6xWxKJ-I2oHIlkzwFiymYmEM9l7iSR9wBi1kmRYQkw0=.a53d3f0b-84be-423e-931e-fae8a0e5ffc7@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <VqxxmBzTD20XpIyxMgakQbUN00DAA7mleXlofwAGwfY=.8da379c7-89ed-4a9d-a597-d0c3fb267658@github.com>
 <6xWxKJ-I2oHIlkzwFiymYmEM9l7iSR9wBi1kmRYQkw0=.a53d3f0b-84be-423e-931e-fae8a0e5ffc7@github.com>
Message-ID: <zpgjS6zkRvAs1Kr7fnbNmQ8bUaI51ALIKvFreECtzQY=.52fe1a97-0f8e-400c-9bcd-93ec4429c0d9@github.com>

On Thu, 2 Dec 2021 11:30:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed handling of <self>.super
>>   extended set of compilation validation tests
>>   added set of negative tests that should result in compilation error
>
> test/langtools/tools/javac/8278078/ValidThisAndSuperInConstructorArgTest.java line 2:
> 
>> 1: /**
>> 2:  * @test /nodynamiccopyright/
> 
> This is a positive test, so we typically add copyright in those.

done

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

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

From mcimadamore at openjdk.java.net  Thu Dec  2 12:57:26 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 12:57:26 GMT
Subject: RFR: 8278078: Cannot reference super before supertype constructor
 has been called [v4]
In-Reply-To: <_VfExHBkh85Xv-lBl1JVI7gPYd-f1nFmEFA0R_9A12Q=.f5245ac1-ef70-46a5-8771-a0630b7320dd@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
 <_VfExHBkh85Xv-lBl1JVI7gPYd-f1nFmEFA0R_9A12Q=.f5245ac1-ef70-46a5-8771-a0630b7320dd@github.com>
Message-ID: <lNz5AQPUcvSb7lkbvzVlVdyu7QdO0qG73v2LKU-vzos=.2ffd88e0-f666-474b-80a8-94da3e640486@github.com>

On Thu, 2 Dec 2021 12:23:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>>  error: cannot reference super before supertype constructor has been called 
>> 
>> For example following source fragment cannot be compiled since that: 
>> 
>>     class EnclClass { 
>>         class InnerClass extends Exception { 
>>             InnerClass() { 
>>                 super(EnclClass.super.toString()); 
>>             } 
>>         } 
>>     } 
>> 
>> 
>> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
>> 
>> Plus it adds a new test.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aded copyright notice and method reference test

Marked as reviewed by mcimadamore (Reviewer).

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

> 4349:                         ((sym.name == names._this &&
> 4350:                         site.tsym == env.enclClass.sym) ||
> 4351:                         sym.name == names._super && env.info.constructorArgs &&

Maybe for later - let's refactor this to:

if (sym.name == names._this) {
   if (site.tsym == env.enclClass.sym) {
      // error
   }
} else if (sym.name == names._super && env.info.constructorArgs) {
   if (sitesym.isInterface() || site.tsym == env.enclClass.sym) {
      // error
   }
}


The `isSelfCall` should imply that `env.info.constructorArgs` is true, probably no need to check twice.

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

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

From asotona at openjdk.java.net  Thu Dec  2 15:32:33 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 2 Dec 2021 15:32:33 GMT
Subject: Integrated: 8278078: Cannot reference super before supertype
 constructor has been called
In-Reply-To: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
References: <O7kvRe9h-EXX6y2AfuCGh6aRH1p_Z7MfSoam-jyXO28=.39fc4f5b-ae74-4be2-b2dc-229b6b3166c1@github.com>
Message-ID: <YBrl_oT8O5CDf55F3uHs-faH3X-bs2kNmtvDmljxk84=.8cbca6a7-38c5-4b4f-805c-a919391c1789@github.com>

On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using <enclosing class>.super pattern in their constructor argument to fail with: 
>  error: cannot reference super before supertype constructor has been called 
> 
> For example following source fragment cannot be compiled since that: 
> 
>     class EnclClass { 
>         class InnerClass extends Exception { 
>             InnerClass() { 
>                 super(EnclClass.super.toString()); 
>             } 
>         } 
>     } 
> 
> 
> This patch keeps throwing "cannot reference super" error for calls of <interface>.super and permits calls of <enclosing class>.super
> 
> Plus it adds a new test.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 8d9cb2ef
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8d9cb2efe655cc3945b3fe51a5e7d90f48b688e6
Stats:     162 lines in 4 files changed: 161 ins; 0 del; 1 mod

8278078: Cannot reference super before supertype constructor has been called

Reviewed-by: mcimadamore

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

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

From aleonard at openjdk.java.net  Thu Dec  2 15:35:40 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 2 Dec 2021 15:35:40 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v16]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@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 24 commits:

 - 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>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - 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>
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/8d9cb2ef...290a4903

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=15
  Stats: 330 lines in 8 files changed: 306 ins; 0 del; 24 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 mcimadamore at openjdk.java.net  Thu Dec  2 15:44:25 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 2 Dec 2021 15:44:25 GMT
Subject: RFR: 8268575: Annotations not visible on model elements before
 they are generated
In-Reply-To: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
References: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
Message-ID: <Hda1MRevciTwyH0x9M9sSDad64NfFebwCPLY90Xklbk=.1ac55666-0f1a-4eeb-9d2f-c0b21d58c3fe@github.com>

On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> As an inadvertant side effect of JDK-8206325, the model was failing to expose a missing annotation type. Address this.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From darcy at openjdk.java.net  Thu Dec  2 18:29:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 18:29:41 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v7]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <VyhYwb8d_zFqpeKiat7Gi4ooytJrD6Lb-NdvUkHFcrA=.d22c2f8c-8eda-409c-ab3b-35d7ba34c3ad@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 12 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - 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.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8b042d14...b1b4ae2b

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=06
  Stats: 3280 lines in 67 files changed: 3237 ins; 4 del; 39 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  Thu Dec  2 19:15:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 2 Dec 2021 19:15:19 GMT
Subject: RFR: 8277965: Enclosing instance optimization affects
 serialization
In-Reply-To: <cluYvPQMdzosGtTXVtgqic9UAAdVB1kf5XqdHMvg8j8=.759e6f73-4c10-4f13-9d23-bacb6d20811a@github.com>
References: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
 <kk6kBvvC9Eu3KqKpch6E1EOFvWExzD-m1SquCBnODXA=.2251ca0d-e85d-4027-9bb3-f582893c4f77@github.com>
 <cluYvPQMdzosGtTXVtgqic9UAAdVB1kf5XqdHMvg8j8=.759e6f73-4c10-4f13-9d23-bacb6d20811a@github.com>
Message-ID: <sGmrny7n3oamcHoqY0GYjFtm5FYgUjCss9zpIlBwQuU=.bc2d4a1f-c20d-45a6-ae35-55adb2a43d51@github.com>

On Wed, 1 Dec 2021 21:30:05 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Marked as reviewed by darcy (Reviewer).
>
> @jddarcy thanks for the review!
> 
> To double-check before I integrate this, is anything still broken?
> 
> [JDK-8277718](https://bugs.openjdk.java.net/browse/JDK-8277718) mentions a decision to problem-list 3 JCK tests instead of backing this out, and in [JDK-8271717](https://bugs.openjdk.java.net/browse/JDK-8271717?focusedCommentId=14461616&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14461616) the issue with the JCK tests was described as a 'test bug'.
> 
> I'm happy back this out if, but I think it's worth considering keeping it (potentially after reverting it and having further discussion in a new CSR).

@cushon , please integrate this PR and we'll make any needed updates to problem lists, etc. Longer term, I'd expect continued discussion on interactions with serialization.

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

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

From cushon at openjdk.java.net  Thu Dec  2 19:20:20 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 2 Dec 2021 19:20:20 GMT
Subject: Integrated: 8277965: Enclosing instance optimization affects
 serialization
In-Reply-To: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
References: <U7AeOoqnKOICuNyWOh0350MbDSMrY-_yrGji5Lf8PeM=.260df1d9-b4ac-4383-9c4f-7fb591103e8c@github.com>
Message-ID: <tppFQSZFy-6SJMgN3_e2O82ce3tut1fXhuOH4lCgQJ8=.bbd34c62-c601-4041-a86d-a961a0f65624@github.com>

On Tue, 30 Nov 2021 01:59:55 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 4f15be2c
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4f15be2cd41252d2e5a3f0832f07b98462e9076d
Stats:     20 lines in 2 files changed: 0 ins; 17 del; 3 mod

8277965: Enclosing instance optimization affects serialization

Reviewed-by: darcy

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

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

From bchristi at openjdk.java.net  Thu Dec  2 20:44:19 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 2 Dec 2021 20:44:19 GMT
Subject: RFR: JDK-8276674 : Malformed Javadoc inline tags in JDK source
 [v2]
In-Reply-To: <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
References: <NMEtofVxulh6JNDcOLF-zGYKB2gnLKUF-9Or07_oJ4k=.ecc5a86f-5d37-415b-a6b6-4104a12d8676@github.com>
 <TzkyN_WmuxVm2lVTwnD4-AmDckP5HA2HnpzLNxt3wzI=.3e6ca6e7-3d3c-4e68-846e-4e8698dbe1ac@github.com>
Message-ID: <0gXyEfJJNpaLR25-eBZpRR-Jn8dX0LCYxsEdBI3u5DA=.79af9dd2-895d-4f8c-b853-78a5d1ee2015@github.com>

On Thu, 2 Dec 2021 02:36:47 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> JDK-8276674 : Malformed Javadoc inline tags in JDK source
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8276674
>  - Fixed @code and @link in some javadoc for JDK-8276674

Looks good.  Thanks for renaming, per Pavel's suggestion.  I can sponsor this.

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

Marked as reviewed by bchristi (Reviewer).

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

From duke at openjdk.java.net  Thu Dec  2 20:52:18 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 20:52:18 GMT
Subject: Integrated: JDK-8276674 : Malformed Javadoc inline tags in JDK source
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: <TIDuuTFNp21jEDE1HwoI-nTiN8C2ePPoBZFDvmt2aUE=.cbbf6a77-afb1-49a9-bf90-8994656e8c8d@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

This pull request has now been integrated.

Changeset: 652b5f85
Author:    Tim Prinzing <tim at prinzing.net>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/652b5f8546d0453238166f8fcd0cd3d882886bb4
Stats:     13 lines in 8 files changed: 0 ins; 0 del; 13 mod

8276674: Malformed Javadoc inline tags in JDK source

Reviewed-by: jjg, rriggs, prappo, bchristi

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

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

From duke at openjdk.java.net  Thu Dec  2 21:02:40 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:02:40 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
Message-ID: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>

JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

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

Commit messages:
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

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

From lancea at openjdk.java.net  Thu Dec  2 21:08:17 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 2 Dec 2021 21:08:17 GMT
Subject: RFR: JDK-8276681: Malformed Javadoc inline tags in JDK source
 jdk/internal/net/http/ResponseSubscribers.java
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <BirNhh9Ja_VPIbBsvqXQE9qnyVxSyIi1FqufTfgDhR0=.20a63cea-3b4d-4d8f-9f23-8e060321eff0@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Malformed Javadoc inline tags in JDK source jdk/internal/net/http/ResponseSubscribers.java

Marked as reviewed by lancea (Reviewer).

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

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

From duke at openjdk.java.net  Thu Dec  2 21:25:53 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:53 GMT
Subject: RFR: JDK-8276681: Additional malformed Javadoc inline tags in JDK
 source [v2]
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <GbmF-XM7XVPim_elGvQ6JdprN0moW9rcXDFloSFV32g=.5df294e6-a3f0-4043-bd7b-aebef585ba87@github.com>

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

Tim Prinzing 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 three additional commits since the last revision:

 - Merge branch 'master' into JDK-8276681
 - Merge branch 'master' into JDK-8276681
 - Fix missing '@' in javadoc for JDK-8276681

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6486/files
  - new: https://git.openjdk.java.net/jdk/pull/6486/files/e8071197..8eaf05bc

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

  Stats: 29529 lines in 653 files changed: 17761 ins; 7341 del; 4427 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6486/head:pull/6486

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

From duke at openjdk.java.net  Thu Dec  2 21:25:54 2021
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 2 Dec 2021 21:25:54 GMT
Subject: Integrated: JDK-8276681: Additional malformed Javadoc inline tags in
 JDK source
In-Reply-To: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
References: <Xq13dh7dQkT3ZLbvFfFOzCVMf-2hJt6lqJaGc6k4RK0=.cb501327-88dd-440c-95ec-c0f8d50a6ce1@github.com>
Message-ID: <bWDNIhKSRZioOMEelJEP6XLFWIVlsL4db0dq8ci1uc8=.65ffd2fa-81ab-43c5-9b2e-f16adc02e97f@github.com>

On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> JDK-8276681: Additional malformed Javadoc inline tags in JDK source

This pull request has now been integrated.

Changeset: b8ac0d20
Author:    Tim Prinzing <tim.prinzing at oracle.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8ac0d20ceec26b3a1dd0b9577817fa6320ea9ef
Stats:     11 lines in 9 files changed: 0 ins; 0 del; 11 mod

8276681: Additional malformed Javadoc inline tags in JDK source

Reviewed-by: lancea

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

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

From jjg at openjdk.java.net  Fri Dec  3 00:24:30 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 00:24:30 GMT
Subject: RFR: JDK-8272944: Use snippets in jdk.javadoc documentation
Message-ID: <SjK8tSf-RRGxHZwmu3Y1QI-Hkbxo-rjm5jgEKdpMzpQ=.9634062c-cab7-4653-8b2a-4cd302b10a5f@github.com>

Please review a patch to convert an example in the `jdk.javadoc` documentation to use snippets instead of raw HTML and/or `{@code }`.  There are some minor tweaks to the text of the example, but no changes to the normative specification of the package.

Given that the example is in `package-info.java`, a minor change is required in `JavacElements` to ensure that the package symbol is completed (i.e. the `package-info.java` file has been read) when accessing the `PackageElement`.

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

Commit messages:
 - JDK-8272944: Use snippets in jdk.javadoc documentation

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

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

From jjg at openjdk.java.net  Fri Dec  3 00:35:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 3 Dec 2021 00:35:34 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
Message-ID: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>

Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.

One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

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

Commit messages:
 - JDK-8272945: Use snippets in java.compiler documentation

Changes: https://git.openjdk.java.net/jdk/pull/6686/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6686&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272945
  Stats: 123 lines in 7 files changed: 51 ins; 25 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6686/head:pull/6686

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

From ihse at openjdk.java.net  Fri Dec  3 00:44:16 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 3 Dec 2021 00:44:16 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>

On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

make/modules/java.compiler/Java.gmk line 30:

> 28: 
> 29: EXCLUDES += \
> 30:     javax/tools/snippet-files \

You can put this just on a single line :-). 

And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...

src/java.compiler/share/classes/javax/tools/snippet-files/JavaSourceFromString.java line 29:

> 27:         return code;
> 28:     }
> 29: }

Missing newline..?

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

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

From vromero at openjdk.java.net  Fri Dec  3 04:15:49 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Dec 2021 04:15:49 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v2]
In-Reply-To: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
Message-ID: <Kt8w4jAN9yRnju5_cCVdD18uqN7_4_S2HyjvmCU1AdA=.1f7068aa-b136-4636-ad4c-b96e6c194088@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

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - adding support for type annotations
 - addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6548/files
  - new: https://git.openjdk.java.net/jdk/pull/6548/files/7d95951c..2ed4c22d

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

  Stats: 172 lines in 3 files changed: 129 ins; 12 del; 31 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 darcy at openjdk.java.net  Fri Dec  3 06:45:45 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 3 Dec 2021 06:45:45 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v8]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <iVjwPPaqi-iB1ndHo7Qjil89hrQang7YS_MmMYyWK0g=.9f7e829b-e635-4ad5-a13b-ed369c0a231e@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 files to JDK 18 b26.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6493/files
  - new: https://git.openjdk.java.net/jdk/pull/6493/files/b1b4ae2b..88273596

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

  Stats: 610 lines in 3 files changed: 593 ins; 3 del; 14 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 jgneff at openjdk.java.net  Fri Dec  3 06:47:24 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Fri, 3 Dec 2021 06:47:24 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v16]
In-Reply-To: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com>
Message-ID: <NE7s1-HDJ1w0Zi2khE-ZXBSbrOX_CM-Sr8pvHcPLdxk=.9a110fd9-8588-4087-9034-bed0282628a6@github.com>

On Thu, 2 Dec 2021 15:35:40 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 24 commits:
> 
>  - 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>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - 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>
>  - ... and 14 more: https://git.openjdk.java.net/jdk/compare/8d9cb2ef...290a4903

I can't think of any more ways to break this. I tested pairs of JavaFX builds again on all six Linux architectures, from 32-bit ARM to IBM mainframe. I tested some of my own Java and JavaFX projects. All builds created identical artifacts: JAR files (classes, sources, and Javadoc), JMOD archives, and even all the files under the `jlink` output directory.

The `jpackage` tool fails to create reproducible Debian packages, but that seems to be nothing more than some inconsistent symbolic links under `lib/runtime/legal`.

Good job, Andrew!

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

Marked as reviewed by jgneff (no project role).

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

From jlahoda at openjdk.java.net  Fri Dec  3 07:44:26 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Dec 2021 07:44:26 GMT
Subject: Integrated: 8272234: Pass originating elements from Filer to
 JavaFileManager
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: <R6LmGea1kE-qhGqIoqRezU-dblc5AeGgZj_gJstaR3w=.2bf71c88-0200-42d1-a281-c61ce4c935df@github.com>

On Tue, 10 Aug 2021 20:46:32 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.

This pull request has now been integrated.

Changeset: 89070032
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/890700320a379c2712fe420017f7b84a8904c0c3
Stats:     728 lines in 7 files changed: 718 ins; 1 del; 9 mod

8272234: Pass originating elements from Filer to JavaFileManager

Reviewed-by: jjg

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

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

From alanb at openjdk.java.net  Fri Dec  3 08:02:13 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Dec 2021 08:02:13 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <qwL7_OXVZICHrqhEdI2CsLfRSaRKykeSwqyE58IpTxA=.4fd139e9-a339-4402-b2d6-939df0eb79d4@github.com>

On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

src/java.compiler/share/classes/javax/tools/JavaCompiler.java line 189:

> 187:  *     source code stored in a string:
> 188:  *
> 189:  *     {@snippet id=fileObject class=JavaSourceFromString }

JEP 413 uses the "file" attribute for external snippets, so using "class" here is new (to me anyway). Maybe the JEP should include an example that uses it.

Is this the first use of an external snippet in the src tree? I suspect files in the snippet-files directory will need a copyright header (downstream builders will report issues on this). It's not clear to me how that works if @replace region replacement="" isn't the first line of the external file.

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

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

From jlahoda at openjdk.java.net  Fri Dec  3 08:40:34 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 3 Dec 2021 08:40:34 GMT
Subject: RFR: 8277864: Compilation error thrown while doing a boxing conversion
 on selector expression
Message-ID: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>

Consider a switch whose selector type is a primitive type (e.g. an integer). This may still be a pattern matching switch, if it has a case with a pattern label. But, as the selector type is primitive, TransPatterns must not attempt to generate a null check, so this patch avoids it.

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

Commit messages:
 - 8277864: Compilation error thrown while doing a boxing conversion on selector expression

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

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

From aleonard at openjdk.java.net  Fri Dec  3 10:05:43 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 10:05:43 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@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 25 commits:

 - Merge jdk:master
   
   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>
 - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
 - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
   
   Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
 - 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>
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

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

Changes: https://git.openjdk.java.net/jdk/pull/6481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=16
  Stats: 329 lines in 8 files changed: 306 ins; 0 del; 23 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 jboes at openjdk.java.net  Fri Dec  3 10:40:18 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Fri, 3 Dec 2021 10:40:18 GMT
Subject: RFR: JDK-8272944: Use snippets in jdk.javadoc documentation
In-Reply-To: <SjK8tSf-RRGxHZwmu3Y1QI-Hkbxo-rjm5jgEKdpMzpQ=.9634062c-cab7-4653-8b2a-4cd302b10a5f@github.com>
References: <SjK8tSf-RRGxHZwmu3Y1QI-Hkbxo-rjm5jgEKdpMzpQ=.9634062c-cab7-4653-8b2a-4cd302b10a5f@github.com>
Message-ID: <D933kr-bhoOCs6e25KyRMFTNkD3jJT7UFMjE8QZxzzo=.06d6fced-7f40-4a1d-ac7a-ca7ed4a0389b@github.com>

On Fri, 3 Dec 2021 00:18:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a patch to convert an example in the `jdk.javadoc` documentation to use snippets instead of raw HTML and/or `{@code }`.  There are some minor tweaks to the text of the example, but no changes to the normative specification of the package.
> 
> Given that the example is in `package-info.java`, a minor change is required in `JavacElements` to ensure that the package symbol is completed (i.e. the `package-info.java` file has been read) when accessing the `PackageElement`.

src/jdk.javadoc/share/classes/jdk/javadoc/doclet/package-info.java line 54:

> 52:  * -- the {@link jdk.javadoc.doclet.Doclet#run(DocletEnvironment) run} interface
> 53:  * method, defines the entry point.
> 54:  * {@snippet id="entry-point" type=java :

What does the `type` attribute do? It's not mentioned in the JEP.

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

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

From jlaskey at openjdk.java.net  Fri Dec  3 12:49:15 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 3 Dec 2021 12:49:15 GMT
Subject: RFR: 8277864: Compilation error thrown while doing a boxing
 conversion on selector expression
In-Reply-To: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
References: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
Message-ID: <IPI7MjRyr-Fcci3RQU4iryQwRpPLEVZNLSQzGXcttVE=.bef10539-096c-42b6-a012-9f05e84ebf3a@github.com>

On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a switch whose selector type is a primitive type (e.g. an integer). This may still be a pattern matching switch, if it has a case with a pattern label. But, as the selector type is primitive, TransPatterns must not attempt to generate a null check, so this patch avoids it.

LGTM

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

Marked as reviewed by jlaskey (Reviewer).

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

From aleonard at openjdk.java.net  Fri Dec  3 13:44:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 13:44:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <MiWcaJhqMh9CbBVG8plCkgPtyTVKoAjYFQCnPz9SaBA=.0acfc66d-2138-487f-9f1f-dc4fce51af2f@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

@jgneff thank you John, for your help with this as well, your platform testing has been most useful as well.
I've Proposed the CSR now (https://bugs.openjdk.java.net/browse/JDK-8277755), so that should go through the approval process..
@AlanBateman @LanceAndersen i'd also like to get your final reviews as well please?
Many thanks
Andrew

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

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

From erikj at openjdk.java.net  Fri Dec  3 13:50:14 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 3 Dec 2021 13:50:14 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
Message-ID: <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>

On Fri, 3 Dec 2021 00:41:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> make/modules/java.compiler/Java.gmk line 30:
> 
>> 28: 
>> 29: EXCLUDES += \
>> 30:     javax/tools/snippet-files \
> 
> You can put this just on a single line :-). 
> 
> And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...

As long as the next line is empty, it works, but it's not a good idea. That's why we came up with the terminating # in our 1 element per line lists. In this case, I would prefer a single line assignment without any backslashes.

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

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

From alanb at openjdk.java.net  Fri Dec  3 13:53:18 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Dec 2021 13:53:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
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: <FGUZr5Te5YtPUKpsXj3_Uu3Z7Lm1pbkgbCusoGWASmo=.0b663170-2720-4040-8c88-7353c7d19e1d@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 @LanceAndersen i'd also like to get your final reviews as well please?

I plan to review this in the coming days.

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

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

From vromero at openjdk.java.net  Fri Dec  3 17:32:12 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Dec 2021 17:32:12 GMT
Subject: RFR: 8277864: Compilation error thrown while doing a boxing
 conversion on selector expression
In-Reply-To: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
References: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
Message-ID: <vhFwk9X_OLDl0tQgsOhhTzv7mcxTdjA4vGtXMmAuDCc=.8cb1d2ee-b276-4959-9f6f-bc5e7cb3e5ec@github.com>

On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a switch whose selector type is a primitive type (e.g. an integer). This may still be a pattern matching switch, if it has a case with a pattern label. But, as the selector type is primitive, TransPatterns must not attempt to generate a null check, so this patch avoids it.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From jgneff at openjdk.java.net  Fri Dec  3 17:42:28 2021
From: jgneff at openjdk.java.net (John Neffenger)
Date: Fri, 3 Dec 2021 17:42:28 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v14]
In-Reply-To: <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com>
 <SKki0kvxdUHBdGx_8q5ZhidvVE73yGzUSzeSgePsitA=.4c12b279-6c60-411b-81d1-b6c08a7e67c3@github.com>
 <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com>
 <TMNeeIoAkacLQvVmhkJSW415kWa5Owysn8MHQR8w67k=.02679217-f5c6-4ffc-b126-3ab02551ea1a@github.com>
Message-ID: <od9xwOLsOaRVk4u8h1PBkTKz0nPxitpConZSDvNmG7s=.607eac3d-41d2-409a-8d76-04b28008eb57@github.com>

On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger <jgneff at openjdk.org> wrote:

>>> I'm testing it now. So far, it's working great!
>>> 
>>> I found one boundary problem. The magic instant of `1980-01-01T00:00:00Z` triggers an extended header with the wrong time:
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 00:00:00 local
>>>   file last modified on (UT extra field modtime): 1980 Jan 1 08:00:00 UTC
>>> ```
>>> 
>>> One second later `1980-01-01T00:00:01Z` works fine (considering the rounding down to even seconds):
>>> 
>>> ```
>>>   file last modified on (DOS date/time):          1980 Jan 1 00:00:00
>>> ```
>> 
>> Thanks John. The 1980-01-01T00:00:00Z is a known issue because the zip xdostime format uses that value as the "marker" for date before-1980. I can adjust the --date value validation to be >  1980-01-01T00:00:00Z ?
>
>> I can adjust the --date value validation to be > 1980-01-01T00:00:00Z ?
> 
> I know, nit picky, right? ?? I'll take no offense if you ignore it. The thing is, everyone else implementing this feature gave that specific instant a wide margin. (See my previous comment about Debian and Gradle.) Debian adds 12 hours 1 minute just to avoid it (`1980-01-01T12:01:00Z`), while Gradle even skips to the next month (`1980-02-01T00:00:00`).
> 
> Because developers looking into this discover the magic earliest date, some may think it's a great choice for a default deterministic value and use it! Then this current implementation breaks with no warning. If you add one second, the `ZipEntry` method rounds down, and you get the exact same "DOS date and time" in the output (1980 Jan 1 00:00:00), but now it works. Kind of confusing.
> 
> So my latest recommendation is to define the earliest permitted instant at `1980-01-01T00:00:02Z` to avoid any possibility of setting the magic local date and time at all. The Gradle folks might explain it better in [their comment here][1].
> 
> [1]: https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/file/archive/ZipCopyAction.java#L42-L56

> @jgneff thank you John, for your help with this as well, your platform testing has been most useful as well.

You're welcome. I did not test on *x64* macOS or Windows, by the way. I'll test JavaFX builds on those platforms as soon as this enhancement is included in an [early-access build][1].

[1]: https://jdk.java.net/18/

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

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

From aleonard at openjdk.java.net  Fri Dec  3 18:04:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Fri, 3 Dec 2021 18:04:23 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <JmxOUHcJHVEn-h9tY_EvKkkYakgcBwlHSl-DWwaJUgw=.570e8abd-a281-4218-a67b-2cdae97ee55a@github.com>

On Fri, 3 Dec 2021 10:05:43 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 25 commits:
> 
>  - Merge jdk:master
>    
>    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>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - 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>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

I've got a mac so can test that, a little tricking building, but i'll do that this evening

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

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

From vromero at openjdk.java.net  Fri Dec  3 20:46:14 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 3 Dec 2021 20:46:14 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools
In-Reply-To: <boWmwADzBpfQesIPOBIpSl1rOTCeF9bXDpYw7qmAwQA=.81151fb9-ab66-489c-b913-a2577f25be16@github.com>
References: <V9PL8lCur0Lmm-vv5q8ilwyYVjui_wOksrd403EAwaM=.11659aaa-2d3d-402d-a801-38bacd4c6338@github.com>
 <nzpHPl7hG30bmy0AxgNHemIlEti6Mt-S58gU5ESQw64=.95e5d47e-104b-419a-bae7-9e4dac4d3b1f@github.com>
 <boWmwADzBpfQesIPOBIpSl1rOTCeF9bXDpYw7qmAwQA=.81151fb9-ab66-489c-b913-a2577f25be16@github.com>
Message-ID: <OYolfvMtob2RJQI4WlVQzA1xfe1mGojWRrGDyfELjgc=.83b7b0d3-5d81-4d61-8d17-dca881f63d38@github.com>

On Tue, 30 Nov 2021 00:09:23 GMT, PROgrm_JARvis <duke at openjdk.java.net> wrote:

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

well not assigning `true` to `ok` also breaks the semantics as `ok` is used in boolean expressions below this point. So if we want to keep the semantics 100% we will have to either let the code as it was or do:

ok = true;
if (contents != null) {
   ...

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

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

From duke at openjdk.java.net  Sat Dec  4 20:48:23 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Sat, 4 Dec 2021 20:48:23 GMT
Subject: RFR: 8274881: Update jdk.compiler classes to use
 try-with-resources
In-Reply-To: <KZ7glwO6LNrfX3h2zys05htd7bn80cc51Th9xAG7AlY=.187e2e56-fb8c-4d7d-8a6d-682f12622b8d@github.com>
References: <KZ7glwO6LNrfX3h2zys05htd7bn80cc51Th9xAG7AlY=.187e2e56-fb8c-4d7d-8a6d-682f12622b8d@github.com>
Message-ID: <NFlZqK-IbW3Ws1SixCeqUXakKbJW9MsE65Rpqa6TtMA=.5ec13036-06ed-44bf-a352-5b3415932ea4@github.com>

On Tue, 5 Oct 2021 07:52:40 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8274881: Update jdk.compiler classes to use try-with-resources

not yet bot

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

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

From alanb at openjdk.java.net  Sun Dec  5 18:40:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 5 Dec 2021 18:40:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <dpsfeZ0Nef4LRbl-LW8GH_1wKTuJJFDUfwjJnPWqFZk=.1887e108-f5a7-4a33-b5b7-888eb07b6331@github.com>

On Fri, 3 Dec 2021 10:05:43 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 25 commits:
> 
>  - Merge jdk:master
>    
>    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>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - 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>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

I looked at the latest patch (06863697) and I think you've got it to a good place (and thank you to John Neffenger for all the help).

One comment on the usage message is that it might be a bit clearer to say "for the timestamps of entries" rather than "for entry timestamps". I'm also wondering if it would be useful to include an example of an ISO 8601 in the usage message.

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

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

From lancea at openjdk.java.net  Mon Dec  6 01:53:19 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Dec 2021 01:53:19 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>

On Fri, 3 Dec 2021 10:05:43 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 25 commits:
> 
>  - Merge jdk:master
>    
>    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>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - 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>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

Overall the latest update looks good

a few minor comments below 

the CSR needs some updates and I will look to provide comments tomorrow

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 86:

> 84:         unexpected versioned entry {0} for release {1}
> 85: error.date.notvalid=\
> 86:         date {0} is not a valid ISO 8601 date and time

Please rephrase to use wording similar to what is in the Javadoc date-time with offset and zone

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.out.of.range=\
> 88:         date {0} is not within the valid range

Please  include the range in the message

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 298:

> 296: \  -0, --no-compress          Store only; use no ZIP compression
> 297: main.help.opt.create.update.index.date=\
> 298: \      --date=TIMESTAMP       The timestamp in ISO 8601 format to use\n\

Same comment as above perhaps show the syntax

src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:

> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
> 111: err.date.out.of.range=--date {0} is out of the valid range

Same comments as above

test/jdk/tools/jar/JarEntryTime.java line 191:

> 189:                                 "2038-11-26T06:06:06+00:00",
> 190:                                 "2098-02-18T00:00:00-08:00",
> 191:                                 "2099-12-31T23:59:59+00:00"};

I believe the parsing format you are using supports formats such as '2011-12-03T10:15:30', '2011-12-03T10:15:30+01:00' and'2011-12-03T10:15:30+01:00[Europe/Paris]'.

please add a few extra values to the above

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

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

From sadayapalam at openjdk.java.net  Mon Dec  6 06:30:19 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 6 Dec 2021 06:30:19 GMT
Subject: Integrated: 8268575: Annotations not visible on model elements before
 they are generated
In-Reply-To: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
References: <RpDKoVoWJAIpqe9-3tEnYRCfwG33b3YNG-eUwh4xXg4=.30fd8bfd-8a6c-445b-8945-f5222d1f16fd@github.com>
Message-ID: <GFWRAMaP-ekIJ4Lby3FYphkbbqPYYMCc0gJvGZraTwQ=.bc3ca491-03db-41bf-a8e7-8da8f770aba4@github.com>

On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> As an inadvertant side effect of JDK-8206325, the model was failing to expose a missing annotation type. Address this.

This pull request has now been integrated.

Changeset: 104aa1f7
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/104aa1f7f9f212318113e304e16e185a6acbec6c
Stats:     114 lines in 3 files changed: 113 ins; 0 del; 1 mod

8268575: Annotations not visible on model elements before they are generated

Reviewed-by: mcimadamore

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

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

From jlahoda at openjdk.java.net  Mon Dec  6 08:46:21 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Dec 2021 08:46:21 GMT
Subject: Integrated: 8277864: Compilation error thrown while doing a boxing
 conversion on selector expression
In-Reply-To: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
References: <AK5bBw-XrOX1LVDvnADuAF5E2N3cOHgDwoLcvqraDwc=.4d1fc07f-b3c2-4451-a35f-082f6a6c8632@github.com>
Message-ID: <-9ssbXq65tUHosgSJDcziTtkueh6eX4FQFwl8fZZRgk=.9c4018dc-82fa-4b8e-bac8-37d16cb9edce@github.com>

On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider a switch whose selector type is a primitive type (e.g. an integer). This may still be a pattern matching switch, if it has a case with a pattern label. But, as the selector type is primitive, TransPatterns must not attempt to generate a null check, so this patch avoids it.

This pull request has now been integrated.

Changeset: 194cdf4e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/194cdf4e28225133dcdf29cf1bf4e580f3fd9208
Stats:     15 lines in 2 files changed: 12 ins; 0 del; 3 mod

8277864: Compilation error thrown while doing a boxing conversion on selector expression

Reviewed-by: jlaskey, vromero

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

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

From jlahoda at openjdk.java.net  Mon Dec  6 10:45:37 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Dec 2021 10:45:37 GMT
Subject: RFR: 8277634: Incorrect method name in invokedynamic
Message-ID: <9_Tei0aV6BA_LPxV6xSkSSYVm5txU5d7vs47a9bayRI=.61845626-a486-4c7e-9082-9d82c3b37654@github.com>

An indy invocation (`CONSTANT_InvokeDynamic_info`) has a `NameAndType` entry. If several indy calls would be generated with the same bootstrap method and the same type, but with different names (which AFAIK does not happen currently, but it may in the future), javac won't generate different `NameAndType` entries for different invocations, because it does not take the name into account. As a consequence, the invocations will incorrectly share the same name.

The proposed with here ensures the name is taken into account when generating the `NameAndType`, while still ensuring that e.g. the bootstrap method entries are still properly de-duplicated.

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

Commit messages:
 - Fixing test.
 - Removing unnecessary empty line.
 - Fixing test.
 - 8277634: Incorrect method name in invokedynamic

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

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

From jlaskey at openjdk.java.net  Mon Dec  6 10:52:17 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 6 Dec 2021 10:52:17 GMT
Subject: RFR: 8277634: Incorrect method name in invokedynamic
In-Reply-To: <9_Tei0aV6BA_LPxV6xSkSSYVm5txU5d7vs47a9bayRI=.61845626-a486-4c7e-9082-9d82c3b37654@github.com>
References: <9_Tei0aV6BA_LPxV6xSkSSYVm5txU5d7vs47a9bayRI=.61845626-a486-4c7e-9082-9d82c3b37654@github.com>
Message-ID: <OE2UUXxLbh8Ph9BE-vHel6V0QF3HHG9Tn9kFmKYwfd4=.e4ebe27e-09e9-44da-b6e5-5f715c935c39@github.com>

On Mon, 6 Dec 2021 10:36:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> An indy invocation (`CONSTANT_InvokeDynamic_info`) has a `NameAndType` entry. If several indy calls would be generated with the same bootstrap method and the same type, but with different names (which AFAIK does not happen currently, but it may in the future), javac won't generate different `NameAndType` entries for different invocations, because it does not take the name into account. As a consequence, the invocations will incorrectly share the same name.
> 
> The proposed with here ensures the name is taken into account when generating the `NameAndType`, while still ensuring that e.g. the bootstrap method entries are still properly de-duplicated.

Marked as reviewed by jlaskey (Reviewer).

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

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

From aleonard at openjdk.java.net  Mon Dec  6 12:08:46 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:46 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v18]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <HUdSlcxc7Db4bvyCPazeMOVYuwS8G4xsbPm0rVVF-sk=.534d96c6-3b6e-40ec-a8f9-ee574eb6f4b9@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/06863697..2a2d781b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=16-17

  Stats: 18 lines in 3 files changed: 9 ins; 0 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 aleonard at openjdk.java.net  Mon Dec  6 12:08:50 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:50 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
Message-ID: <aVMTZPoS6tN2IPPZTIAh_f8gIlMKat_I0wYZKsiiQoM=.7fc26ccf-4f0d-421c-a261-8f6ce20f4fe7@github.com>

On Fri, 3 Dec 2021 10:05:43 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 25 commits:
> 
>  - Merge jdk:master
>    
>    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>
>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>    
>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>  - 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>
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697

> I looked at the latest patch ([0686369](https://github.com/openjdk/jdk/commit/068636971e833cb582790667171a67e40c823bb1)) and I think you've got it to a good place (and thank you to John Neffenger for all the help).
> 
> One comment on the usage message is that it might be a bit clearer to say "for the timestamps of entries" rather than "for entry timestamps". I'm also wondering if it would be useful to include an example of an ISO 8601 in the usage message.

@AlanBateman thanks. I've reworded, and added an example

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

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

From aleonard at openjdk.java.net  Mon Dec  6 12:08:57 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 12:08:57 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v17]
In-Reply-To: <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <cOWUPp_mDV6YksAsth_3X6mKOaDiz8qPrIIJgkUE25U=.eab1f150-1937-4379-b1a7-86a7a5c55c2f@github.com>
 <V8eR4MOIY5VTWpYWx2fbrQf5R-QAVLxd6-vcBZ0w51g=.28112e40-276d-4229-b53e-28e2766bded4@github.com>
Message-ID: <JgJbkkolGx0rZ6P4rFEt5UHLDBduiTilxHRpUjNB1ew=.232caeca-2185-4f44-a747-94be302f411e@github.com>

On Mon, 6 Dec 2021 00:15:13 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 25 commits:
>> 
>>  - Merge jdk:master
>>    
>>    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>
>>  - Merge branch 'jarjmodtimestamps' of github.com:andrew-m-leonard/jdk into jarjmodtimestamps
>>  - Update src/jdk.jlink/share/classes/jdk/tools/jmod/JmodOutputStream.java
>>    
>>    Co-authored-by: Magnus Ihse Bursie <mag at icus.se>
>>  - 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>
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/45da3aea...06863697
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 86:
> 
>> 84:         unexpected versioned entry {0} for release {1}
>> 85: error.date.notvalid=\
>> 86:         date {0} is not a valid ISO 8601 date and time
> 
> Please rephrase to use wording similar to what is in the Javadoc date-time with offset and zone

reworded

> 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.out.of.range=\
>> 88:         date {0} is not within the valid range
> 
> Please  include the range in the message

added range

> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 298:
> 
>> 296: \  -0, --no-compress          Store only; use no ZIP compression
>> 297: main.help.opt.create.update.index.date=\
>> 298: \      --date=TIMESTAMP       The timestamp in ISO 8601 format to use\n\
> 
> Same comment as above perhaps show the syntax

done

> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties line 111:
> 
>> 109: err.no.moduleToHash=No hashes recorded: no module matching {0} found to record hashes
>> 110: err.invalid.date=--date {0} is not a valid ISO 8601 date and time: {1} 
>> 111: err.date.out.of.range=--date {0} is out of the valid range
> 
> Same comments as above

done

> test/jdk/tools/jar/JarEntryTime.java line 191:
> 
>> 189:                                 "2038-11-26T06:06:06+00:00",
>> 190:                                 "2098-02-18T00:00:00-08:00",
>> 191:                                 "2099-12-31T23:59:59+00:00"};
> 
> I believe the parsing format you are using supports formats such as '2011-12-03T10:15:30', '2011-12-03T10:15:30+01:00' and'2011-12-03T10:15:30+01:00[Europe/Paris]'.
> 
> please add a few extra values to the above

added more tests
note '2011-12-03T10:15:30' is not valid as it needs a offset or Z, so it represents a reproducible "instant"

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

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

From jlahoda at openjdk.java.net  Mon Dec  6 13:14:33 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Dec 2021 13:14:33 GMT
Subject: RFR: 8277105: Inconsistent handling of missing permitted
 subclasses [v2]
In-Reply-To: <SLldW8bNrWsFidWMjtwXXxKYd71xpHmRBzsXHrveYJc=.f9c22be4-c41f-49a7-be01-ef3689483ed2@github.com>
References: <SLldW8bNrWsFidWMjtwXXxKYd71xpHmRBzsXHrveYJc=.f9c22be4-c41f-49a7-be01-ef3689483ed2@github.com>
Message-ID: <OYQlep8-pKfzpsxyEPqyHcoFcYSTyQOeJYrkQDtkrhg=.f7c9f4ff-11ee-46a8-91b7-ab9716e5c0ab@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.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merging master.
 - 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=01
  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 aleonard at openjdk.java.net  Mon Dec  6 13:57:48 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 13:57:48 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@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/2a2d781b..c5104305

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=17-18

  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 jlahoda at openjdk.java.net  Mon Dec  6 15:47:19 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 6 Dec 2021 15:47:19 GMT
Subject: Integrated: 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: <kxyFLigctBLunMm-EwD3cxDGm-Q55Zz_8-zz8ZkR94A=.144246fc-4b19-4a5b-b7ab-a0e118135ad9@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.

This pull request has now been integrated.

Changeset: ab781874
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab781874b27ee4fe1bc6b5fa2cd7997e451e2026
Stats:     315 lines in 3 files changed: 201 ins; 101 del; 13 mod

8277105: Inconsistent handling of missing permitted subclasses

Reviewed-by: vromero

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

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

From vromero at openjdk.java.net  Mon Dec  6 16:23:47 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 6 Dec 2021 16:23:47 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools [v2]
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: <gs9Tkmi5Z6k9aSAC1X5hmX2kM4A_ZFGvOPn2RFx7WBo=.133bff30-f335-49a3-a243-c7ddafab6e3e@github.com>

> Hi,
> 
> Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6599/files
  - new: https://git.openjdk.java.net/jdk/pull/6599/files/4fccdf40..012779d4

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

  Stats: 8 lines in 2 files changed: 1 ins; 4 del; 3 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 vromero at openjdk.java.net  Mon Dec  6 16:23:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 6 Dec 2021 16:23:48 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: <Hc91nc0Ro71gWxWbwG1Lamx0H4u22gy2-gFb8WJMUis=.c7985d83-65cc-4abf-a69a-cbbc583bbb77@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

submitted another iteration to the PR, thanks for the comment so far

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

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

From alanb at openjdk.java.net  Mon Dec  6 16:39:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 6 Dec 2021 16:39:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
Message-ID: <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>

On Mon, 6 Dec 2021 13:57:48 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 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>

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:

> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
> 299: \                             optional time-zone format, to use for the timestamps of\n\
> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"

The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".

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

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

From aleonard at openjdk.java.net  Mon Dec  6 19:11:45 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:45 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@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/c5104305..59617359

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=18-19

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 Dec  6 19:11:48 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:48 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
 <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
Message-ID: <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>

On Mon, 6 Dec 2021 16:36:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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>
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:
> 
>> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
>> 299: \                             optional time-zone format, to use for the timestamps of\n\
>> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"
> 
> The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".

ah yes, should have known that, and I did Latin at school !

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

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

From aleonard at openjdk.java.net  Mon Dec  6 19:11:50 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 19:11:50 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v19]
In-Reply-To: <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <wy1KwLLb0WTZQYW95hrwk_wQSCCOD912hoI3o0WbfNc=.f9eaf70a-26a4-484e-82bb-5633d7dca7ac@github.com>
 <RxxpADD4aDPA8UqhbDmy6vzd0m0KKtZvRdp7CVHxJUs=.ca5a6132-de02-4b54-9e28-d2916f5c4302@github.com>
 <bBTHRSFDOin5EIBPGfZj6G1lGCHvUWD4mLlhE567YAk=.e09254cc-aeff-4636-8b2e-adc07177bd71@github.com>
Message-ID: <3VHyKp-lqs2LwNAxotV1buStEUkcs6DkMvMAyXXa9gI=.950b3374-826b-4ff9-bfff-7e5677a5f3f3@github.com>

On Mon, 6 Dec 2021 19:04:06 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 300:
>> 
>>> 298: \      --date=TIMESTAMP       The timestamp in ISO-8601 extended offset date-time with\n\
>>> 299: \                             optional time-zone format, to use for the timestamps of\n\
>>> 300: \                             entries, eg. "2022-02-12T12:30:00-05:00"
>> 
>> The updated wording looks much better. Just a minor nit, it should be "e.g." rather than "eg.".
>
> ah yes, should have known that, and I did Latin at school !

fixed

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

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

From duke at openjdk.java.net  Mon Dec  6 19:14:18 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 6 Dec 2021 19:14:18 GMT
Subject: Withdrawn: 8274817: Allow JavacFiler subclasses and register them in
 Context
In-Reply-To: <o_8l88-X2hDySV58gkz3fbaRfyk1kEfzurE7Bzdabho=.7c74ac73-8f78-4a41-b505-3e7936c4630d@github.com>
References: <o_8l88-X2hDySV58gkz3fbaRfyk1kEfzurE7Bzdabho=.7c74ac73-8f78-4a41-b505-3e7936c4630d@github.com>
Message-ID: <pxyyFplka2egiQ5szv4jBXtlsb7eQPxkLCKPd_q-rco=.d68013a3-9ae7-41ca-ae7a-c01f937624f7@github.com>

On Wed, 6 Oct 2021 13:24:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> An alternative to https://github.com/openjdk/jdk/pull/5076 - this allows to subclass `JavacFiler` and install it to the `Context`. The subclass then can handle the originating elements as needed.

This pull request has been closed without being integrated.

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

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

From joe.darcy at oracle.com  Mon Dec  6 19:43:59 2021
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 6 Dec 2021 11:43:59 -0800
Subject: Preview of JSR 269 API changes for future maintenance review in Java
 SE 18
Message-ID: <2856340a-6703-a591-986c-cef094118696@oracle.com>

Hello,

As usual, a maintenance review of the JSR 269 APIs, packages 
javax.lang.model.* and javax.annotation.processing, is planned for Java 
SE 18. Changes to the JSR 269 API made in JDK 18 so far include:

JDK-8267631: Add SourceVersion.RELEASE_18
JDK-8273157: Add convenience methods to Messager
JDK-8275368: Correct statement of kinds of elements Processor.process 
operates over
JDK-8140442: Add getOutermostTypeElement to javax.lang.model utility class
JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion
JDK-8276772: Refine javax.lang.model docs
JDK-8224922: Access JavaFileObject from Element(s)
JDK-8277303: Terminology mismatch between JLS17-3.9 and SE17's 
javax.lang.model.SourceVersion method specs
JDK-8277522: Make formatting of null consistent in Elements

No other changes are currently planned for JDK 18. If there is some 
other change needed for 18, please raise it in the near future.

Thanks,

-Joe


From lancea at openjdk.java.net  Mon Dec  6 20:44:15 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Dec 2021 20:44:15 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <x-Jr9rzAV33O7lOJ1SlhFnkn0HFLb-jTHgA6irxBPOI=.9e72919e-5e02-42de-bef4-c22c36183af3@github.com>

On Mon, 6 Dec 2021 19:11:45 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 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>

The current revision looks good.

The CSR needs similar clean-up for consistency as you just did for the PR.  Do you want to make a pass through it?

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

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

From vromero at openjdk.java.net  Mon Dec  6 20:49:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 6 Dec 2021 20:49:41 GMT
Subject: RFR: 8275771: JDK source code contains redundant boolean
 operations in jdk.compiler and langtools [v3]
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: <-9o06SUwCVNwXXYzd_WdSJFs6yGtLV7vjDzqzyuksuI=.6cf86761-b350-42f0-9b10-52c769b1262f@github.com>

> Hi,
> 
> Please review this PR which is basically rewriting some redundant boolean expressions in the compiler.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6599/files
  - new: https://git.openjdk.java.net/jdk/pull/6599/files/012779d4..d009c43f

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

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 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 Dec  6 21:22:20 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Mon, 6 Dec 2021 21:22:20 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@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>
 <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@github.com>
Message-ID: <iDaP3c87Alx054qxYXrIVfTu_oJpU5HQy5LVtsgKXVU=.d90a68ea-aa7f-45c2-95b7-9fd68b115dd8@github.com>

On Mon, 29 Nov 2021 19:08:43 GMT, Lance Andersen <lancea 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

@LanceAndersen i've done a cleanup of the CSR, I think it looks consistent now: https://bugs.openjdk.java.net/browse/JDK-8277755
thanks

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

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

From darcy at openjdk.java.net  Mon Dec  6 21:52:37 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 6 Dec 2021 21:52:37 GMT
Subject: RFR: JDK-8273146: Start of release updates for JDK 19 [v9]
In-Reply-To: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
References: <PqnBjBW4HjKwmnKu1cjPkhEoE5fCxUkBCG3ea7na1kQ=.69d17045-d1f1-4d0c-aee8-221be386ce04@github.com>
Message-ID: <BEusjHE7fm_NEwQ_f8OXu9JsbamDJicDAIidVxJnHU8=.94cbc3cc-5e3e-447c-b86d-463e971bc506@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 17 commits:

 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol files to JDK 18 b26.
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Merge branch 'master' into JDK-8273146
 - Update symbol information for JDK 18 b25.
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...9f68398a

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

Changes: https://git.openjdk.java.net/jdk/pull/6493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6493&range=08
  Stats: 3870 lines in 67 files changed: 3827 ins; 4 del; 39 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 Dec  7 00:28:28 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 00:28:28 GMT
Subject: RFR: JDK-8278318: Create {@index} entries for key LangTools terms
Message-ID: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>

Please review a small update to the `jdk.compiler` and `java.compiler` module declarations, to index the names of some key compiler-related APIs.

There are no API changes, so no CSR is required.

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

Commit messages:
 - JDK-8278318: Create {@index} entries for key LangTools terms

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

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

From darcy at openjdk.java.net  Tue Dec  7 00:33:21 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 7 Dec 2021 00:33:21 GMT
Subject: RFR: JDK-8278318: Create {@index} entries for key LangTools terms
In-Reply-To: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
References: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
Message-ID: <hHXtcSdfMZTM6gbEyOk9NNFxLTuqE31i89EDZ-Rsr24=.c67694ba-c29b-48c6-b93f-7f84dc11b58c@github.com>

On Tue, 7 Dec 2021 00:19:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small update to the `jdk.compiler` and `java.compiler` module declarations, to index the names of some key compiler-related APIs.
> 
> There are no API changes, so no CSR is required.

Please update copyright years before pushing.

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

Marked as reviewed by darcy (Reviewer).

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

From jjg at openjdk.java.net  Tue Dec  7 00:45:43 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 00:45:43 GMT
Subject: RFR: JDK-8278318: Create {@index} entries for key LangTools terms
 [v2]
In-Reply-To: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
References: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
Message-ID: <peT7medDnkol9lWZ5qtwgeMsBJumN_NJ6t0Y98yFMSE=.a48aba99-875c-4deb-9ba5-e7b4056a1ce3@github.com>

> Please review a small update to the `jdk.compiler` and `java.compiler` module declarations, to index the names of some key compiler-related APIs.
> 
> There are no API changes, so no CSR is required.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update copyright years

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6729/files
  - new: https://git.openjdk.java.net/jdk/pull/6729/files/2cc1c3e4..3f9c9a40

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

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

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

From jjg at openjdk.java.net  Tue Dec  7 00:45:44 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 00:45:44 GMT
Subject: Integrated: JDK-8278318: Create {@index} entries for key LangTools
 terms
In-Reply-To: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
References: <oH6_KDOEZ1UkNnNoonjzAzqlro2fKWjb7hN1iUhN8ww=.9667f523-c914-4ae7-b534-eeba876738fd@github.com>
Message-ID: <ujg4p9nMjg1ir3RgibxKfG3pFwbhTqZkTDW_SGPJ3g8=.c58e2f72-ce35-475e-84f9-c2c9928760c2@github.com>

On Tue, 7 Dec 2021 00:19:45 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small update to the `jdk.compiler` and `java.compiler` module declarations, to index the names of some key compiler-related APIs.
> 
> There are no API changes, so no CSR is required.

This pull request has now been integrated.

Changeset: f148e3e4
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f148e3e4623c6d0270a10ba73140e0c37ca5398a
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8278318: Create {@index} entries for key LangTools terms

Reviewed-by: darcy

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

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

From jjg at openjdk.java.net  Tue Dec  7 02:57:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 02:57:10 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
Message-ID: <4YcA9pBfgNQpQ7UmFfKwwL7OOXmdsGgKpD-QSJb6pt4=.04ff3193-bc64-413d-aa96-f62aaa48c3b1@github.com>

On Fri, 3 Dec 2021 00:40:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> src/java.compiler/share/classes/javax/tools/snippet-files/JavaSourceFromString.java line 29:
> 
>> 27:         return code;
>> 28:     }
>> 29: }
> 
> Missing newline..?

Fixed

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

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

From jjg at openjdk.java.net  Tue Dec  7 02:57:10 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 02:57:10 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation
In-Reply-To: <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <eVOG2DP4JjdnmsgDJv1VsW0oTaow12ZGmF3GWR5eNSA=.ee9582fd-3614-4dcd-b519-2fbd72067979@github.com>
 <uo4yeuURIFG7XRaFewIpilv2KicNpj7FjTUZxEjTvQM=.c9c5a06b-c130-4bda-b84c-0237d6922426@github.com>
Message-ID: <ZEai3kb60xfUkUHDYyk4sPTCiUWOOBw8fAksBb1te2E=.5c6fa96f-d77d-4958-94a5-2c432c95cc6e@github.com>

On Fri, 3 Dec 2021 13:47:05 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/java.compiler/Java.gmk line 30:
>> 
>>> 28: 
>>> 29: EXCLUDES += \
>>> 30:     javax/tools/snippet-files \
>> 
>> You can put this just on a single line :-). 
>> 
>> And I'm frankly not sure if make is happy about having a trailing backslash but no additional line...
>
> As long as the next line is empty, it works, but it's not a good idea. That's why we came up with the terminating # in our 1 element per line lists. In this case, I would prefer a single line assignment without any backslashes.

Fixed to single line

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

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

From jjg at openjdk.java.net  Tue Dec  7 03:05:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 7 Dec 2021 03:05:41 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation [v2]
In-Reply-To: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
Message-ID: <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>

> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
> 
> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6686/files
  - new: https://git.openjdk.java.net/jdk/pull/6686/files/97cedc9a..27467bf2

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

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

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

From cushon at openjdk.java.net  Tue Dec  7 05:52:29 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 7 Dec 2021 05:52:29 GMT
Subject: RFR: 8275233: Incorrect line number reported in exception stack trace
 thrown from a lambda expression
Message-ID: <YUqiNX83kFfsheYjY_44OFbixVZiJ-e9BnsUefcJHLE=.a3a0ea61-161b-4327-ae96-2c09739373cf@github.com>

This change fixes a bug introduced in [JDK-8200301](https://bugs.openjdk.java.net/browse/JDK-8200301), which tries to check if line or variable debug info is generated, but fails to consider that line debug info is generated if no `-g` or `-g:` options are passed.

The new check is consistent with the handling of lines in e.g.

* https://github.com/openjdk/jdk/blob/17ceef97c3df2326d585b2a298e5daa5dcfe3d99/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#L421-L422
* https://github.com/openjdk/jdk/blob/fe89dd3b0d47807c7dbfe24d17f6aca152fc8908/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java#L118-L120

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

Commit messages:
 - 8275233:  Incorrect line number reported in exception stack trace thrown from a lambda expression

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

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

From alanb at openjdk.java.net  Tue Dec  7 09:28:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Dec 2021 09:28:14 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>

On Mon, 6 Dec 2021 19:11:45 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 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>

I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing.  I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.

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

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

From aleonard at openjdk.java.net  Tue Dec  7 09:36:21 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 09:36:21 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
Message-ID: <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>

On Tue, 7 Dec 2021 09:24:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing. I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.

@AlanBateman thank you Alan, yes that does look simpler, the alternate bit just confused things unnecessarily. Ah of course, -J-..
I'm good with the updates,
thanks
Andrew

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

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

From lancea at openjdk.java.net  Tue Dec  7 12:06:17 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 7 Dec 2021 12:06:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
 <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
Message-ID: <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>

On Tue, 7 Dec 2021 09:32:47 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> > I've edited the CSR to make the summary a bit simpler. I've also removed some of text from the Solution section as the discussion about SOURCE_DATE_EPOCH being an issue due to the security manager was confusing. I also removed the sentence about tools not supporting -Dname=value as it's not quite right as it can be done with -J-Dname=value. Please read over to make sure you are okay with the edits.
> 
> @AlanBateman thank you Alan, yes that does look simpler, the alternate bit just confused things unnecessarily. Ah of course, -J-.. I'm good with the updates, thanks Andrew

The latest CSR update looks good so I think you are in good shape now

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

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

From prappo at openjdk.java.net  Tue Dec  7 12:49:30 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 7 Dec 2021 12:49:30 GMT
Subject: RFR: 8273175: Add @since tags to the DocTree.Kind enum constants
Message-ID: <-YaIG6A2SjHXl2ZmrDDYXchNn_zaL2kric-HaE9a2vM=.ac9c8a18-747f-4639-a301-17683ff10272@github.com>

Please review this trivial change to update `@since` tags.

Here are the links that I used for comparison; you might also find them useful when reviewing:

  1. https://docs.oracle.com/javase/8/docs/api/index.html (DocTree.Kind was not documented in JDK 8)
  2. https://docs.oracle.com/javase/9/docs/api/com/sun/source/doctree/DocTree.Kind.html
  3. https://docs.oracle.com/javase/10/docs/api/com/sun/source/doctree/DocTree.Kind.html
  4. https://docs.oracle.com/en/java/javase/11/docs/api/jdk.compiler/com/sun/source/doctree/DocTree.Kind.html (for control, to ensure that nothing has changed since JDK 10)
  5. https://docs.oracle.com/en/java/javase/12/docs/api/jdk.compiler/com/sun/source/doctree/DocTree.Kind.html
  6. https://download.java.net/java/early_access/jdk18/docs/api/jdk.compiler/com/sun/source/doctree/DocTree.Kind.html

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

Commit messages:
 - Initial commit

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:14:16 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:14:16 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <H_a2jzlDo7-Ze_0Hzkq5OHkXxVGxnqhCdUy1DH5m1-E=.9f18f56e-fa50-4f86-9461-16fefdcf4758@github.com>
 <ZOCnUd0_ZVXxME9uL5ZILqORK5VTn7wsCH9sow4Puk8=.095549a3-09eb-4337-a536-385fb9bab1d0@github.com>
 <ObPAJ4oFtxuHKqRPWP-H2_zoxjxpm-rknzJRa0PfNRw=.b18d9fc2-4952-4e51-b2fa-0cae4b3859d6@github.com>
Message-ID: <j7reY7ihE07r7PR_RI_ELgPYthsw7iZWz7camV6P2EQ=.603da07e-b769-49e8-9edb-7ccb21636c97@github.com>

On Tue, 7 Dec 2021 12:03:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The latest CSR update looks good so I think you are in good shape now

@LanceAndersen thank you Lance

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:14:17 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:14:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>

On Mon, 6 Dec 2021 19:11:45 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 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>

@jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
thanks

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

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

From erikj at openjdk.java.net  Tue Dec  7 13:30:15 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 7 Dec 2021 13:30:15 GMT
Subject: RFR: JDK-8272945: Use snippets in java.compiler documentation [v2]
In-Reply-To: <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>
References: <uwUbyGT7kAUUgICPJAfzfFMDVr95EDZwgPHny5ceZRc=.27e499d1-ee36-41da-9361-cd5461d317f2@github.com>
 <iWmwew4LLM1HKRYe1qbwMDC5unpzk_VUmDb-h2pkB8w=.20ce25ff-0c1a-4c2e-913c-ae1d2143456b@github.com>
Message-ID: <322owcuKtMUGmQvVrIZC223CtXQrUxPswORBfLGZv0o=.617c1da6-b354-4578-86b0-addf79d7bd97@github.com>

On Tue, 7 Dec 2021 03:05:41 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to use snippets in the `java.compiler` documentation, instead of a mix of raw HTML and/or `{@code ...}`.  The change is just about the presentation of the code fragments; there are no changes to the normative specifications for the module.
>> 
>> One of the examples went to extraordinary lengths to include the character sequence `*/` within the example. That example has been replaced by an external snippet in a separate source file, which does not have any restriction on the use of `*/`. However, it does require that the file be excluded from standard compilation, and that is done by setting `EXCLUDES`, once for the "interim" compiler, and once again for the "product" compiler.    Going forward, a better solution might be to modify the `SetupJavaCompilation` macro to ignore all directories whose name is not a valid Java identifier (or, if easier, contains a `-`, such as `doc-files` or `snippet-files`.)
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Build changes look ok.

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

Marked as reviewed by erikj (Reviewer).

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

From alanb at openjdk.java.net  Tue Dec  7 13:31:17 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Dec 2021 13:31:17 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <tf1MFWgNDSNKM0BSW8-U-y-kScYYzouFjk3m_2SVN8c=.7a016b29-0492-40b4-9e86-bb0599ffbfed@github.com>
Message-ID: <QPzt4WMTT0tj-3ZnN_-w5sBB5--rBU85ruypu9tMAyo=.cbb1baaa-36c2-4a86-8823-3fd52efcdef6@github.com>

On Tue, 7 Dec 2021 13:10:53 GMT, Andrew Leonard <aleonard at openjdk.org> wrote:

> @jddarcy hi Joe, what's the next step with the CSR now? https://bugs.openjdk.java.net/browse/JDK-8277755
> thanks

For the CSR then you need to press "Finalize".

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

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

From aleonard at openjdk.java.net  Tue Dec  7 13:49:23 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Tue, 7 Dec 2021 13:49:23 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
Message-ID: <l8CsQJ1WwyqKris7jDJw_xTOk_wr5u81JrUwNqyLK4c=.25f95a47-137d-4806-8e11-f7f8b299949c@github.com>

On Mon, 6 Dec 2021 19:11:45 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 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>

Thanks, CSR now Finalized

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

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

From jlahoda at openjdk.java.net  Tue Dec  7 14:01:00 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 7 Dec 2021 14:01:00 GMT
Subject: RFR: 8277106: Cannot compile certain sources with --release [v2]
In-Reply-To: <odlB8AnorK8G0yObERVlte45rD4K5xWCkhB3Uwl26cc=.710db6d4-9d5b-423a-bf60-b82d7db39ab1@github.com>
References: <odlB8AnorK8G0yObERVlte45rD4K5xWCkhB3Uwl26cc=.710db6d4-9d5b-423a-bf60-b82d7db39ab1@github.com>
Message-ID: <MQVDBepdT7ERVh9Sm5J4zs_HWU8ML7ilXdGjuByQXkc=.0ab20f79-97e0-4c29-bf66-1e2541ef0a61@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

Jan Lahoda 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 three additional commits since the last revision:

 - Removing aspects related to sealed classes.
 - Merge branch 'master' into JDK-8277106
 - 8277106: Cannot compile certain sources with --release

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6417/files
  - new: https://git.openjdk.java.net/jdk/pull/6417/files/5388078d..1acbe84e

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

  Stats: 41846 lines in 1133 files changed: 26187 ins; 9349 del; 6310 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 darcy at openjdk.java.net  Thu Dec  9 17:07:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Dec 2021 17:07:18 GMT
Subject: Integrated: 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: <qJE3l7bbGSefMtF1mI5-Sd-2nDoul8oEzCgvQr4LMis=.1f8167ad-2d8f-4c84-b3a1-afa5493430e1@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.

This pull request has now been integrated.

Changeset: 09831e7a
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/09831e7aa47ebe41eab2f3014ebbacf338097ef6
Stats:     4252 lines in 67 files changed: 4206 ins; 7 del; 39 mod

8273146: Start of release updates for JDK 19
8277511: Add SourceVersion.RELEASE_19
8277513: Add source 19 and target 19 to javac

Reviewed-by: dholmes, alanb, erikj, iris, mikael, ihse

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

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

From aleonard at openjdk.java.net  Thu Dec  9 18:07:58 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:07:58 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
Message-ID: <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@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/59617359..436762f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6481&range=19-20

  Stats: 457 lines in 3 files changed: 296 ins; 147 del; 14 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  Thu Dec  9 18:08:03 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:08:03 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <l8VPJRM10FjI9eO-Q7DVZfq41tNNNbBBz6Ct3zxXqYo=.0cfb2f9f-5533-4300-8afc-a488661fff70@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <l8VPJRM10FjI9eO-Q7DVZfq41tNNNbBBz6Ct3zxXqYo=.0cfb2f9f-5533-4300-8afc-a488661fff70@github.com>
Message-ID: <QLWc-Hc1IuYZepb82LyMl-5KbVTOFyyglqzZhe1Kt4g=.cc363dac-0f34-4d90-9cbe-2da844ec1d7c@github.com>

On Wed, 8 Dec 2021 16:51:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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>
>
> src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 2339:
> 
>> 2337:         } else {
>> 2338:           e.setTime(origTime);
>> 2339:         }
> 
> I think the 8 usages would be a bit clearer if renamed setZipEntryTime. Minor nit in the 2-arg setDate is that it's using 2-space indent instead of 4.

thanks, fixed

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

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

From aleonard at openjdk.java.net  Thu Dec  9 18:09:37 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 18:09:37 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v20]
In-Reply-To: <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <IkJPwbd_JWkp7Tesr4lR5sYj85aRXE12lqpfoTbk_eE=.2b5e53cb-e7f8-4543-8bed-56c9234b9ca9@github.com>
 <utxFqkLHQPe4Um3NhzFOeqD26aIWWfi8I7nPcqbB4Jo=.fac1aa3a-569e-44b8-afaf-ef36a45394ab@github.com>
Message-ID: <BB7TzfyXAG-bIBlCDYR0jpA-cu-Ci76NOUAwzXa4he4=.b686676f-d66a-48ce-9314-fdbfc73a65fd@github.com>

On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> 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>
>
> Looks like the CSR has been approved.  I have a mach5 run that should hopefully finish sooner rather than later and if that remains happy, I will approve the PR

@LanceAndersen hi Lance, i've moved the new jar reproducible changes into a new test class in TestNG ReproducibleJar.java
and added the Unix 2038 XFS special case
Ready for your review please, if you're able to test on that mach5 machine again please?

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

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

From alanb at openjdk.java.net  Thu Dec  9 18:40:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 9 Dec 2021 18:40:20 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v2]
In-Reply-To: <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
Message-ID: <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>

On Thu, 9 Dec 2021 07:58:33 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clean up reproducer test case
>  - Keep helper in ZipFileSystem simple

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 211:

> 209: 
> 210:     private String getRealPath(byte[] resolvedPath) {
> 211:         byte[] path = zfs.lookupPath(resolvedPath);

Can getRealPath be changed to be no-arg method that calls getResolvedPath and then does the lookup. I think that would be a clearer than assuming the argument is a resolved path.

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

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

From jjg at openjdk.java.net  Thu Dec  9 21:14:33 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 9 Dec 2021 21:14:33 GMT
Subject: [jdk18] RFR: JDK-8278516: Typos in snippet for java.compiler
Message-ID: <zAK017kXjUQEulCzhfgPrmyavQQK2tdP5q8Azj3jVTo=.8216b25c-582a-455e-af43-86e65aa4628e@github.com>

Please review a trivial update to replace some instances of `toURI` with `toUri` that were accidentally introduced when converting some code to use snippets.

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

Commit messages:
 - JDK-8278516: Typos in snippet for java.compiler

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

PR: https://git.openjdk.java.net/jdk18/pull/2

From darcy at openjdk.java.net  Thu Dec  9 21:18:31 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 9 Dec 2021 21:18:31 GMT
Subject: [jdk18] RFR: JDK-8278516: Typos in snippet for java.compiler
In-Reply-To: <zAK017kXjUQEulCzhfgPrmyavQQK2tdP5q8Azj3jVTo=.8216b25c-582a-455e-af43-86e65aa4628e@github.com>
References: <zAK017kXjUQEulCzhfgPrmyavQQK2tdP5q8Azj3jVTo=.8216b25c-582a-455e-af43-86e65aa4628e@github.com>
Message-ID: <2et17tjQvi1-JDSPCD67bQMDOjp1Aw9TVeZ4kxliBTM=.a1c25693-e1e5-46c6-a2d3-c0d9e381a8e9@github.com>

On Thu, 9 Dec 2021 21:05:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to replace some instances of `toURI` with `toUri` that were accidentally introduced when converting some code to use snippets.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/2

From lancea at openjdk.java.net  Thu Dec  9 21:24:29 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 9 Dec 2021 21:24:29 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
Message-ID: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>

On Thu, 9 Dec 2021 18:07:58 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 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>

Hi Andrew,

Thank you for splitting out the test into its own file and addressing the test issues we found.

Overall looks good.  I have suggested some additional changes so the test is slightly more TestNG friendly and a few places where it would be useful to add comments

test/jdk/tools/jar/ReproducibleJar.java line 30:

> 28:  *          reproducible
> 29:  * @modules jdk.jartool
> 30:  * @run testng ReproducibleJar

Probably use othervm given you are toggling the TZ for extra safety

test/jdk/tools/jar/ReproducibleJar.java line 49:

> 47: import java.time.LocalDateTime;
> 48: import java.time.ZonedDateTime;
> 49: import java.time.ZoneId;

Duplicate import?  Perhaps get rid to the import of line 43

test/jdk/tools/jar/ReproducibleJar.java line 74:

> 72:     private static final File jarFileSourceDate1 = new File("JarEntryTimeSourceDate1.jar");
> 73:     private static final File jarFileSourceDate2 = new File("JarEntryTimeSourceDate2.jar");
> 74: 

Please consider using caps for your static final variable names

test/jdk/tools/jar/ReproducibleJar.java line 87:

> 85:                                 "2098-02-18T00:00:00-08:00",
> 86:                                 "2099-12-31T23:59:59+00:00"};
> 87: 

I would suggest converting to a DataProvider for the test.

test/jdk/tools/jar/ReproducibleJar.java line 95:

> 93:                                  "2006-04-06T12:38:00",
> 94:                                  "2012-08-24T16"};
> 95: 

Another good use of a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 102:

> 100:         jarFileSourceDate1.delete();
> 101:         jarFileSourceDate2.delete();
> 102:         TimeZone.setDefault(TZ);

I believe you could just call runAfter() from within this method

test/jdk/tools/jar/ReproducibleJar.java line 114:

> 112:     }
> 113: 
> 114:     @Test

Please add a comment introducing the intent of the test.  As mentioned above, please consider using a DataProvider vs. an array with the test.

test/jdk/tools/jar/ReproducibleJar.java line 120:

> 118:         // Test --date source date
> 119:         for (String sourceDate : sourceDates) {
> 120:             createOuterInnerDirs(dirOuter, dirInner);

If you use a DataProvider,  you could call this method from your runBeforeMethod

test/jdk/tools/jar/ReproducibleJar.java line 147:

> 145:             cleanup(dirInner);
> 146:             cleanup(dirOuter);
> 147:             jarFileSourceDate1.delete();

Is the above needed given your  `@AfterMethod`

test/jdk/tools/jar/ReproducibleJar.java line 152:

> 150: 
> 151:     @Test
> 152:     public void testInvalidSourceDate() throws Throwable {

Please add a basic comment of the intent of the method and consider using a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 165:

> 163: 
> 164:     @Test
> 165:     public void testJarsReproducible() throws Throwable {

Please add a basic comment of the intent of the method and consider using a DataProvider

test/jdk/tools/jar/ReproducibleJar.java line 193:

> 191: 
> 192:             // Check jars are identical
> 193:             checkSameContent(jarFileSourceDate1, jarFileSourceDate2);

You could if you choose use:

 Assert.assertEquals(Files.readAllBytes(jarFileSourceDate1.toPath(), Files.readAllBytes(jarFileSourceDate2.toPath()));

test/jdk/tools/jar/ReproducibleJar.java line 199:

> 197:             jarFileSourceDate1.delete();
> 198:             jarFileSourceDate2.delete();
> 199:         }

I believe your` @AfterMethod` will address this so the above is not needed

test/jdk/tools/jar/ReproducibleJar.java line 202:

> 200:     }
> 201: 
> 202:     static void createOuterInnerDirs(File dirOuter, File dirInner) throws Throwable {

I believe you are always passing in the same parameter values, so perhaps no need for the parameters?

test/jdk/tools/jar/ReproducibleJar.java line 208:

> 206:          *         foo.txt
> 207:          */
> 208:         Assert.assertTrue(dirOuter.mkdir());

Please move the  comment above the method

test/jdk/tools/jar/ReproducibleJar.java line 219:

> 217:     }
> 218: 
> 219:     static void checkFileTime(long now, long original) throws Throwable {

Please add a basic comment of the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 241:

> 239:     }
> 240: 
> 241:     static void checkSameContent(File f1, File f2) throws Throwable {

See comment above for consideration  regarding the use of Assert.assertEquals

test/jdk/tools/jar/ReproducibleJar.java line 249:

> 247:     }
> 248: 
> 249:     private static boolean isTimeSettingChanged() {

Please add a basic comment describing the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 260:

> 258:     }
> 259: 
> 260:     private static boolean isInTransition() {

Please add a basic comment of the intent of the method

test/jdk/tools/jar/ReproducibleJar.java line 278:

> 276:         File[] x = dir.listFiles();
> 277:         if (x != null) {
> 278:             for (int i = 0; i < x.length; i++) {

Could use enhanced for loop here if you desire

test/jdk/tools/jar/ReproducibleJar.java line 286:

> 284: 
> 285:     static void extractJar(File jarFile) throws Throwable {
> 286:         String javahome = System.getProperty("java.home");

Please add a basic comment of the intent of the method.

Any reason you chose not to use JAR_TOOL here?

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

Marked as reviewed by lancea (Reviewer).

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

From jjg at openjdk.java.net  Thu Dec  9 21:51:34 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 9 Dec 2021 21:51:34 GMT
Subject: [jdk18] Integrated: JDK-8278516: Typos in snippet for java.compiler
In-Reply-To: <zAK017kXjUQEulCzhfgPrmyavQQK2tdP5q8Azj3jVTo=.8216b25c-582a-455e-af43-86e65aa4628e@github.com>
References: <zAK017kXjUQEulCzhfgPrmyavQQK2tdP5q8Azj3jVTo=.8216b25c-582a-455e-af43-86e65aa4628e@github.com>
Message-ID: <iLceSVSiC3r-_marr9o8LsAYpB8hKZlF1LiPnsRwNUk=.11c75910-7061-4c35-88de-74dae152e95d@github.com>

On Thu, 9 Dec 2021 21:05:50 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to replace some instances of `toURI` with `toUri` that were accidentally introduced when converting some code to use snippets.

This pull request has now been integrated.

Changeset: 918b3505
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/918b3505e1cbbf5ac380cbcca43aae2829c18a2d
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8278516: Typos in snippet for java.compiler

Reviewed-by: darcy

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

PR: https://git.openjdk.java.net/jdk18/pull/2

From aleonard at openjdk.java.net  Thu Dec  9 22:15:18 2021
From: aleonard at openjdk.java.net (Andrew Leonard)
Date: Thu, 9 Dec 2021 22:15:18 GMT
Subject: RFR: 8276766: Enable jar and jmod to produce deterministic
 timestamped content [v21]
In-Reply-To: <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
References: <WR1n4cibLimKC_DzgLlibM91Co8O3YQt7WAiEnLs9Yc=.8529be36-dd4a-4d0f-884d-32d9c2546ad4@github.com>
 <hb0bjNtUCqjFyknUR-bnDFeH1fb7I7DOmIdqCGLApdw=.41e9739f-4a3e-40e0-8ac7-83981aea9a86@github.com>
 <Lg9YOp0KEz4T4zNFb3uSNHIMRPIWxoCAIO-9KpHhQTg=.700c69c0-5742-4655-ba72-defbc8f22545@github.com>
Message-ID: <VzPePmIUH5tmjcOBgh_FQadm-NkB3FHn7T-Uqu3jEvU=.2ff03ae8-68d2-4943-977a-f93516d69711@github.com>

On Thu, 9 Dec 2021 18:14:13 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> 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>
>
> test/jdk/tools/jar/ReproducibleJar.java line 87:
> 
>> 85:                                 "2098-02-18T00:00:00-08:00",
>> 86:                                 "2099-12-31T23:59:59+00:00"};
>> 87: 
> 
> I would suggest converting to a DataProvider for the test.

thanks, that's neat, not used a @DataProvider before

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

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

From jwilhelm at openjdk.java.net  Thu Dec  9 23:27:18 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 9 Dec 2021 23:27:18 GMT
Subject: Integrated: Merge jdk18
Message-ID: <44ZyKTpRjOWJNu84Qam-x86haLfdZ25nxf2Y03KGUaY=.5efaf2d7-466a-45ae-8191-0f2f424e2552@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8278185: Custom JRE cannot find non-ASCII named module inside
 - 8278421: G1: Remove unused HeapRegion::verify
 - 8278312: Update SimpleSSLContext keystore to use SANs for localhost IP addresses
 - 8253860: PPC: Relocation::pd_set_data_value conflates compressed oops and klasses
 - 8273146: Start of release updates for JDK 19

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/6787/files
  Stats: 4620 lines in 79 files changed: 4523 ins; 39 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6787/head:pull/6787

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

From jwilhelm at openjdk.java.net  Thu Dec  9 23:27:19 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 9 Dec 2021 23:27:19 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <44ZyKTpRjOWJNu84Qam-x86haLfdZ25nxf2Y03KGUaY=.5efaf2d7-466a-45ae-8191-0f2f424e2552@github.com>
References: <44ZyKTpRjOWJNu84Qam-x86haLfdZ25nxf2Y03KGUaY=.5efaf2d7-466a-45ae-8191-0f2f424e2552@github.com>
Message-ID: <4kKB9Gq6_33sJUODdR5KMvch96tufy1gjtwVZk9ite0=.be00aa08-8408-46eb-a946-cfc7bc5b2316@github.com>

On Thu, 9 Dec 2021 23:18:26 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: ec0a5ac8
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec0a5ac8fec75c5c3eda3d9909d2e65d610d9854
Stats:     5 lines in 2 files changed: 1 ins; 0 del; 4 mod

Merge

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

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

From jjg at openjdk.java.net  Fri Dec 10 01:56:54 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 01:56:54 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
Message-ID: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>

Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

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

Commit messages:
 - JDK-8273179: Update nroff pages in JDK 18 before RC

Changes: https://git.openjdk.java.net/jdk18/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=5&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273179
  Stats: 858 lines in 28 files changed: 448 ins; 146 del; 264 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/5/head:pull/5

PR: https://git.openjdk.java.net/jdk18/pull/5

From dholmes at openjdk.java.net  Fri Dec 10 02:15:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Dec 2021 02:15:33 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <XrztouvnRkkwistowUfWLgdBTgHP0fRisw3FZGuvalE=.413f903f-4421-4369-9da2-05853a6aaecb@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Hi Jon,

This all looks good - I'm familiar with many of the changes made to the sources but not yet generated.

We will have to be careful not to regress the copyright year or version if any subsequent updates are made before next year, or before the version loses the EA designator.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 02:53:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 02:53:14 GMT
Subject: [jdk18] Integrated: JDK-8273179: Update nroff pages in JDK 18 before
 RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <aUgePa-CZTl_8YUtExHfRcG35KchfIqrsFZfnblx5Cw=.16776a76-72c6-4eb0-bfd7-1a7d25843819@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

This pull request has now been integrated.

Changeset: ed5d53ae
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/ed5d53ae0eb0b12de11fb3d79ae0371c093ce434
Stats:     858 lines in 28 files changed: 448 ins; 146 del; 264 mod

8273179: Update nroff pages in JDK 18 before RC

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 02:53:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 02:53:14 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Hi David,

The copyright year will naturally sort itself out in a few weeks time ;-)  

When these changes make their way down from 18 to 19, we will probably want to regenerate these files with 19-EA.

-- Jon

We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period.

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From iris at openjdk.java.net  Fri Dec 10 03:12:20 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 10 Dec 2021 03:12:20 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <6aEQaagQdXw209dha2rqp32uSxtxze-f-1-j32dROQE=.53c0fcde-680f-40c6-bbc7-44a1e4635f11@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From dholmes at openjdk.java.net  Fri Dec 10 04:21:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Dec 2021 04:21:18 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
 <2BrCSwVuXVmMEZE2lncn2i0_-o3_nsjrmLEGqXnz9Sw=.efac0d59-093f-4b4a-a6e3-96935e40538d@github.com>
Message-ID: <qVuvwqe8lbBR-Web-A5nWUe6iY9w4VxcPcqZFqsmbqk=.f9daa291-cb0a-4c8f-ad0a-cde4ac1cf5ae@github.com>

On Fri, 10 Dec 2021 02:48:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.
>
> We will also want to regenerate any appropriate files if any more updates to the man pages are made during the ramp down period.

Hi @jonathan-gibbons ,

I have a couple of manpage related tasks for early in the 19 release cycle that will take care of updating the version number.

Unfortunately for this change it looks like whomever did the source uodate to the javadoc manpage did not know about the test:

test/langtools/jdk/javadoc/tool/CheckManPageOptions.java

which is now failing on all platforms. :( I will file a bug.

David

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From jjg at openjdk.java.net  Fri Dec 10 04:33:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 04:33:14 GMT
Subject: [jdk18] RFR: JDK-8273179: Update nroff pages in JDK 18 before RC
In-Reply-To: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
References: <6EIsBtepK0yhT-JqZ_-fI70ZInbEwn4TXW1EmzGh0rA=.2524dccb-596e-44d4-9e08-6f5875c11679@github.com>
Message-ID: <oP-JJ5AfuaU7KEDEmjWC-rZ0kVRFQy5KRAyWHyrukrg=.3670ffc5-0df7-41e6-afe6-66fbb8732685@github.com>

On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this semi-automatic update for the nroff man pages for JDK 18.  The changes update the version number, copyright year, and incorporate the changes from the latest upstream files.

hmmm, I thought we had taken care of that test. I will investigate

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

PR: https://git.openjdk.java.net/jdk18/pull/5

From cstein at openjdk.java.net  Fri Dec 10 08:16:46 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 10 Dec 2021 08:16:46 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Turn `getRealPath()` into a no-arg helper method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6768/files
  - new: https://git.openjdk.java.net/jdk/pull/6768/files/e62721a5..12e106c6

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

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

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

From cstein at openjdk.java.net  Fri Dec 10 08:16:51 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 10 Dec 2021 08:16:51 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v2]
In-Reply-To: <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <UE1Xy1VxH1UZuAfSLqBVmwOciz6Fo87tHmctfnKwLt0=.f8c0f646-fe84-42d8-82ab-47d55fa3a3f3@github.com>
 <VGIOu1zHH0LH5Ol69ZEM62dGHKIyAnpAmGvYtfYuNMw=.2c10db8e-4425-4761-b861-02f537b51c43@github.com>
Message-ID: <FZGnKR2-pTsFbFnVtfkQ8cB2uZkR-hlDSkWKY-CW5jw=.64d5ce0e-9a6b-481f-adea-a5ea0d9d4d97@github.com>

On Thu, 9 Dec 2021 18:37:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Clean up reproducer test case
>>  - Keep helper in ZipFileSystem simple
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java line 211:
> 
>> 209: 
>> 210:     private String getRealPath(byte[] resolvedPath) {
>> 211:         byte[] path = zfs.lookupPath(resolvedPath);
> 
> Can getRealPath be changed to be no-arg method that calls getResolvedPath and then does the lookup. I think that would be a clearer than assuming the argument is a resolved path.

Done via https://github.com/openjdk/jdk/pull/6768/commits/12e106c6e69449f1fbde9e5b6a5ff3305c5de547

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

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

From jlahoda at openjdk.java.net  Fri Dec 10 09:05:24 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 10 Dec 2021 09:05:24 GMT
Subject: Integrated: 8277634: Incorrect method name in invokedynamic
In-Reply-To: <9_Tei0aV6BA_LPxV6xSkSSYVm5txU5d7vs47a9bayRI=.61845626-a486-4c7e-9082-9d82c3b37654@github.com>
References: <9_Tei0aV6BA_LPxV6xSkSSYVm5txU5d7vs47a9bayRI=.61845626-a486-4c7e-9082-9d82c3b37654@github.com>
Message-ID: <335CzYJdXnYqf6fU3m2oTPbGjFGXj83DKoqQdsZPmUI=.6c76464b-5484-4f46-89b2-1073982ab021@github.com>

On Mon, 6 Dec 2021 10:36:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> An indy invocation (`CONSTANT_InvokeDynamic_info`) has a `NameAndType` entry. If several indy calls would be generated with the same bootstrap method and the same type, but with different names (which AFAIK does not happen currently, but it may in the future), javac won't generate different `NameAndType` entries for different invocations, because it does not take the name into account. As a consequence, the invocations will incorrectly share the same name.
> 
> The proposed with here ensures the name is taken into account when generating the `NameAndType`, while still ensuring that e.g. the bootstrap method entries are still properly de-duplicated.

This pull request has now been integrated.

Changeset: aed3ea20
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aed3ea2043e765bf4a9ac980da2515f19855c780
Stats:     289 lines in 3 files changed: 288 ins; 0 del; 1 mod

8277634: Incorrect method name in invokedynamic

Reviewed-by: jlaskey

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

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

From alanb at openjdk.java.net  Fri Dec 10 09:08:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 10 Dec 2021 09:08:14 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <4GBNHwF6NlDHsQlgt4HM7Gatr4SStsQdn833oZFBRRo=.30c50bd4-e4ff-4eed-a1c1-5dad3b896e3f@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

The changes to zipfs in the latest revision look good

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

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

From jjg at openjdk.java.net  Fri Dec 10 16:40:19 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 10 Dec 2021 16:40:19 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

javac changes look good. I suggest adding this bug number to the test to check that URIs are not double-encoded.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/PathFileObject.java line 183:

> 181:         @Override @DefinedBy(Api.COMPILER)
> 182:         public URI toUri() {
> 183:             // Work around bug JDK-8134451:

Nice to see the workaround go.  
Find the test that was added at the time of the workaround, and add this bug number (8271079) to the `@bug` line in that test, to mark that test as relevant to this issue.

test/langtools/tools/javac/T8271079.java line 39:

> 37: import java.util.*;
> 38: import java.util.jar.JarEntry;
> 39: import javax.tools.*;

You could add an explicit `import java.util.spi.ToolProvider;` to remove the need for qualified names in the code

test/langtools/tools/javac/T8271079.java line 58:

> 56:             testT8271079(mr);
> 57:         } finally {
> 58:             Files.deleteIfExists(mr);

If you generate files in the test's current directory, it's not wrong to delete them but there's no need either, and you might be deleting useful debug evidence if the test fails.

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

Marked as reviewed by jjg (Reviewer).

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

From jwilhelm at openjdk.java.net  Fri Dec 10 18:13:18 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 10 Dec 2021 18:13:18 GMT
Subject: RFR: Merge jdk18
Message-ID: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8277621: ARM32: multiple fastdebug failures with "bad AD file" after JDK-8276162
 - 8278538: Test langtools/jdk/javadoc/tool/CheckManPageOptions.java fails after the manpage was updated
 - 8273179: Update nroff pages in JDK 18 before RC

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/6802/files
  Stats: 1142 lines in 30 files changed: 688 ins; 155 del; 299 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6802/head:pull/6802

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

From jwilhelm at openjdk.java.net  Fri Dec 10 18:46:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 10 Dec 2021 18:46:17 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>
References: <NaqfEtc0QzHLCHXP3t87gEVkaqsHeJawyC5MvVPocOw=.6b092301-b363-4fbd-b52f-7edc2d0eafc7@github.com>
Message-ID: <kpQxjDOAP8oYJSlDDnHI_tQ-TqySIEgCecB0KZHOhlQ=.5b2f94bd-fbc6-4852-adbc-f0e5819b9f4a@github.com>

On Fri, 10 Dec 2021 17:51:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: 61736f81
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/61736f81fb4a20375c83d59e2b37a00aafb11107
Stats:     1142 lines in 30 files changed: 688 ins; 155 del; 299 mod

Merge

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

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

From lancea at openjdk.java.net  Fri Dec 10 19:43:10 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 10 Dec 2021 19:43:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
Message-ID: <UQGqcGXJ1oeevmfXCyYhpLF2BaKamhhfxM77M9gIwbw=.c278d9f1-ade9-4281-aee4-3d5758675a53@github.com>

On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn `getRealPath()` into a no-arg helper method

The changes look good.

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

Marked as reviewed by lancea (Reviewer).

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

From vromero at openjdk.java.net  Fri Dec 10 21:29:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 10 Dec 2021 21:29:02 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v4]
In-Reply-To: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
Message-ID: <M9JbD55YIM7T2bzVg20gfL8T_Fy7wHG9hAfEcTv__gw=.f00f0515-451e-4280-b363-3d6f96ea2891@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

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6548/files
  - new: https://git.openjdk.java.net/jdk/pull/6548/files/15f1417b..2e90dd15

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

  Stats: 32 lines in 2 files changed: 17 ins; 8 del; 7 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 cstein at openjdk.java.net  Sat Dec 11 11:03:10 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:03:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <G_aFz6mh1ayER5hBYHF0TfGIzbxsM5rWNLMXYVRiwh0=.454b37ff-61bc-44be-bb81-4f03ff34c587@github.com>

On Fri, 10 Dec 2021 16:30:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T8271079.java line 39:
> 
>> 37: import java.util.*;
>> 38: import java.util.jar.JarEntry;
>> 39: import javax.tools.*;
> 
> You could add an explicit `import java.util.spi.ToolProvider;` to remove the need for qualified names in the code

Such an import would break line 80: `ToolProvider.getSystemJavaCompiler()` as this one refers to `ToolProvider` in package `javax.tools`.

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:22:10 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:22:10 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <DAlY1wqdJT-CVVzzsNP_wd73KMkl4ARJf-wguUlxHM8=.47357498-551d-40cd-942a-2ed847a10abf@github.com>

On Fri, 10 Dec 2021 16:37:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> javac changes look good. I suggest adding this bug number to the test to check that URIs are not double-encoded.

I can't find [`8134451`](https://bugs.openjdk.java.net/browse/JDK-8134451) as noted in the now removed comment directly in an existing test, but [`8131067`](https://bugs.openjdk.java.net/browse/JDK-8131067) can be found in `ZipFSTester.java`: https://github.com/openjdk/jdk/blob/6eb6ec05fd4f80e11d0b052b58190bc8b53f4b11/test/jdk/jdk/nio/zipfs/ZipFSTester.java#L666

Thus, I'll add [`8271079`](https://bugs.openjdk.java.net/browse/JDK-8271079) to the already long list in `ZipFSTester.java`. https://github.com/openjdk/jdk/blob/6eb6ec05fd4f80e11d0b052b58190bc8b53f4b11/test/jdk/jdk/nio/zipfs/ZipFSTester.java#L74-L76

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:29:50 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:29:50 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add bug number `8271079` to ZipFS tester

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6768/files
  - new: https://git.openjdk.java.net/jdk/pull/6768/files/12e106c6..353cbd5d

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

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

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

From cstein at openjdk.java.net  Sat Dec 11 11:29:53 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Sat, 11 Dec 2021 11:29:53 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v3]
In-Reply-To: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <STlwnWyVFbdx1W9UnQ_obHmBRBNLpcAIPRrzjzRTClI=.930a71ba-d05d-430e-ba3f-837be836c9f4@github.com>
 <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com>
Message-ID: <-b8VPS5N4zJA2_uSs6f27yStd73jWoz3GE7aEOc3tVg=.c2a7273c-421e-44be-ac59-211039d9d9db@github.com>

On Fri, 10 Dec 2021 16:33:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Turn `getRealPath()` into a no-arg helper method
>
> test/langtools/tools/javac/T8271079.java line 58:
> 
>> 56:             testT8271079(mr);
>> 57:         } finally {
>> 58:             Files.deleteIfExists(mr);
> 
> If you generate files in the test's current directory, it's not wrong to delete them but there's no need either, and you might be deleting useful debug evidence if the test fails.

Understood.

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

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

From jjg at openjdk.java.net  Sat Dec 11 16:36:14 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 11 Dec 2021 16:36:14 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
Message-ID: <JhwlaigpD5wQf7JYJ773wooqu0aX2T8omC_pxDEzjlw=.06d74422-ed6a-4a22-8692-8a6246dcd3fc@github.com>

On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number `8271079` to ZipFS tester

Regarding the javac workaround, as best I can tell, the `createJarUri` code goes all the way back to the original file manager code in JDK 6.  The workaround comment appeared in JDK 9, as part of the general conversion from the old File-based file manager to the new Path-based file manager.  So yes, there does not appear to be a specific test for the workaround, and it's not clear it's worth bisecting the changes in the transition from JDK 8 to JDK 9 to investigate further.

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

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

From alanb at openjdk.java.net  Mon Dec 13 07:27:16 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 13 Dec 2021 07:27:16 GMT
Subject: RFR: 8271079: JavaFileObject#toUri and multi-release jars [v4]
In-Reply-To: <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
 <Z48LO2s78vHunpC5qD8kr7U19JhNUX-JMtoF9auD_AQ=.06d1a310-dc9a-48b2-a12e-b5550253f682@github.com>
Message-ID: <gh-ORVM4yjODPzU9L_n8GxzY98J7QR3PtHpm1BEhT0s=.83c1da98-8c34-4863-b42e-bced4edc5517@github.com>

On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
>> 
>> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
>> 
>> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
>> 
>> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug number `8271079` to ZipFS tester

I'll leave Jon or Lance to sponsor this.

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

Marked as reviewed by alanb (Reviewer).

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

From cstein at openjdk.java.net  Mon Dec 13 12:03:21 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 13 Dec 2021 12:03:21 GMT
Subject: Integrated: 8271079: JavaFileObject#toUri and multi-release jars
In-Reply-To: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
References: <px5TeFgakETfF4D7hybRN-EPZsfRw6Oq1eJ0U2nu5T4=.f0820fa4-e274-4ac8-ab96-b569348452d6@github.com>
Message-ID: <hgty71zmDQCH7Ew3uYzGuZcVfiP8MKNm2eSrdAlfpck=.e814995a-c860-4cfd-b56d-bf9e07bc96e4@github.com>

On Wed, 8 Dec 2021 15:26:23 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Prior to this PR, `toUri()` of class `ZipPath` in module `jdk.zipfs` and class `PathFileObject` in module `jdk.compiler` were always composed by base path names. Even for versioned entries of a multi-release JAR file.
> 
> Now, a `URI` for an entry is composed of its real path names using an existing lookup function in the associated zip file system object.
> 
> This PR also removes a superseded work around for [JDK-8134451](https://bugs.openjdk.java.net/browse/JDK-8134451).
> 
> Fixes https://bugs.openjdk.java.net/browse/JDK-8271079

This pull request has now been integrated.

Changeset: 23fd9f15
Author:    Christian Stein <cstein at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23fd9f15da40cef00231380766158bc0fa537c38
Stats:     198 lines in 6 files changed: 177 ins; 18 del; 3 mod

8271079: JavaFileObject#toUri and multi-release jars

Reviewed-by: jjg, lancea, alanb

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

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

From vromero at openjdk.java.net  Mon Dec 13 20:45:50 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 13 Dec 2021 20:45:50 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v5]
In-Reply-To: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
Message-ID: <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@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

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6548/files
  - new: https://git.openjdk.java.net/jdk/pull/6548/files/2e90dd15..c7799133

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

  Stats: 67 lines in 1 file changed: 52 ins; 8 del; 7 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 jjg at openjdk.java.net  Tue Dec 14 20:19:33 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 14 Dec 2021 20:19:33 GMT
Subject: RFR: JDK-8278795: Create test library and tests for langtools snippets
Message-ID: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>

Please review a test-only fix to provide a new test library for analyzing snippets, and two tests that use that library to test snippets in the `jdk.javadoc` and `jdk.compiler` modules.

It is expected that the library may evolve in future updates as we explore additional ways to analyze snippets.

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

Commit messages:
 - JDK-8278795: Create test library and tests for langtools snippets

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

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

From cushon at openjdk.java.net  Tue Dec 14 22:46:22 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Tue, 14 Dec 2021 22:46:22 GMT
Subject: RFR: 8278825: Unused variable for diagnostic in Resolve
Message-ID: <UM7hQg_TzagsYpEJlXxUgHINcSQVPMDSIP8XQcDNJWs=.3dcea199-2f30-457c-998a-bfb64eb30938@github.com>

The change removes an unused variable that was left over after [JDK-8067883](https://bugs.openjdk.java.net/browse/JDK-8067883).

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

Commit messages:
 - 8278825: Unused variable for diagnostic in Resolve

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

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

From vromero at openjdk.java.net  Wed Dec 15 00:07:56 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 15 Dec 2021 00:07:56 GMT
Subject: RFR: 8278825: Unused variable for diagnostic in Resolve
In-Reply-To: <UM7hQg_TzagsYpEJlXxUgHINcSQVPMDSIP8XQcDNJWs=.3dcea199-2f30-457c-998a-bfb64eb30938@github.com>
References: <UM7hQg_TzagsYpEJlXxUgHINcSQVPMDSIP8XQcDNJWs=.3dcea199-2f30-457c-998a-bfb64eb30938@github.com>
Message-ID: <TNCSf72UfmtCL5ZX2_prnLngCQavcJFBqYPFY2XdZGQ=.c1f7e1d6-864e-4181-ba48-2f9b43dff10d@github.com>

On Tue, 14 Dec 2021 22:39:32 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> The change removes an unused variable that was left over after [JDK-8067883](https://bugs.openjdk.java.net/browse/JDK-8067883).

lgtm

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

Marked as reviewed by vromero (Reviewer).

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

From cushon at openjdk.java.net  Wed Dec 15 00:30:02 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 15 Dec 2021 00:30:02 GMT
Subject: Integrated: 8278825: Unused variable for diagnostic in Resolve
In-Reply-To: <UM7hQg_TzagsYpEJlXxUgHINcSQVPMDSIP8XQcDNJWs=.3dcea199-2f30-457c-998a-bfb64eb30938@github.com>
References: <UM7hQg_TzagsYpEJlXxUgHINcSQVPMDSIP8XQcDNJWs=.3dcea199-2f30-457c-998a-bfb64eb30938@github.com>
Message-ID: <Me9v9BYPlVJvtb949zUXpmcn4cF-MW0tChATCcolZgk=.927ac93c-2c01-4fcc-9f38-8cb20540002a@github.com>

On Tue, 14 Dec 2021 22:39:32 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> The change removes an unused variable that was left over after [JDK-8067883](https://bugs.openjdk.java.net/browse/JDK-8067883).

This pull request has now been integrated.

Changeset: 068a4509
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/068a450954530d9a469db05d7cf2e7dcf1eddc8a
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8278825: Unused variable for diagnostic in Resolve

Reviewed-by: vromero

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

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

From hannesw at openjdk.java.net  Thu Dec 16 11:12:09 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 16 Dec 2021 11:12:09 GMT
Subject: [jdk18] RFR: JDK-8273452: DocTrees.getDocCommentTree should be
 specified as idempotent
Message-ID: <GhovZDzU7t6WkQLekF1CwPanpuN0newHN5TMPz2FZTs=.984b4252-2fa7-4de7-a33c-bc717e1bd413@github.com>

Please review a doc-only change to add implementation notes to the `DocTrees.getDocCommentTree` methods, some of which return the same `DocCommentTree` instance on repeated invocation and some don't. I decided to use `@implNote` instead of `@implSpec` as usually I wouldn't expect object identity to be part of a Java API specification.

I verified the described behavior using code analysis and enhancing existing tests. The latter are not included in the commit as this is a `noreg-doc` issue.

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

Commit messages:
 - JDK-8273452: DocTrees.getDocCommentTree should be specified as idempotent

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

PR: https://git.openjdk.java.net/jdk18/pull/36

From hannesw at openjdk.java.net  Thu Dec 16 16:10:02 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 16 Dec 2021 16:10:02 GMT
Subject: RFR: JDK-8278795: Create test library and tests for langtools
 snippets
In-Reply-To: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
References: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
Message-ID: <gD02RIX9x8E_cUn4C4OxaxN-apCO3STr9UQk3cT_7FE=.6c37fc12-981d-4e78-85a3-7d5d0bf20000@github.com>

On Tue, 14 Dec 2021 19:58:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a test-only fix to provide a new test library for analyzing snippets, and two tests that use that library to test snippets in the `jdk.javadoc` and `jdk.compiler` modules.
> 
> It is expected that the library may evolve in future updates as we explore additional ways to analyze snippets.

Very impressive how much functionality you managed to pack into this first version of SnippetUtils!

The snippet kind inferral code is (as is usual with regex-based solutions) not especially nice to look at but seems to solve the problem with very few lines.

test/langtools/tools/lib/snippets/SnippetUtils.java line 310:

> 308:             switch (ve.getKind()) {
> 309:                 case ENUM_CONSTANT, FIELD -> scanDocComment(ve, treeScanner);
> 310:                 default -> defaultAction(ve, treeScanner);

What kinds of elements are handled by the default branch?

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

Marked as reviewed by hannesw (Reviewer).

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

From duke at openjdk.java.net  Fri Dec 17 18:56:31 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Fri, 17 Dec 2021 18:56:31 GMT
Subject: Integrated: 8275242: Remove redundant stream() call before forEach in
 jdk.compiler
In-Reply-To: <oMhwkqQwoQLxnhy-Nfozx7IKGdTzQuxTUrHsk9MrEpM=.a119db21-1efb-42a2-97f2-1bd26d7c44aa@github.com>
References: <oMhwkqQwoQLxnhy-Nfozx7IKGdTzQuxTUrHsk9MrEpM=.a119db21-1efb-42a2-97f2-1bd26d7c44aa@github.com>
Message-ID: <_rSzQMFLz1p_r5YYveEPJCjveiTZCtWnrR1djA6BFzk=.fdd1c05a-46a0-40ac-b309-c363e16321de@github.com>

On Wed, 15 Sep 2021 07:24:35 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

This pull request has now been integrated.

Changeset: 022e4f0f
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/022e4f0f1c4862315b34595d6df228a49f67cb2e
Stats:     20 lines in 5 files changed: 10 ins; 4 del; 6 mod

8275242: Remove redundant stream() call before forEach in jdk.compiler

Reviewed-by: vromero

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

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

From vromero at openjdk.java.net  Fri Dec 17 21:42:56 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 17 Dec 2021 21:42:56 GMT
Subject: RFR: 8211004: javac is complaining about non-denotable types and
 refusing to generate the class file
Message-ID: <kvzpIy2xq2MHhZNdRNT1hEOgcGaP6BjR0FEYBn2rLj0=.b989188c-f35f-46ac-8f54-f249f16b381e@github.com>

Please review this fix which is checking if the enclosing class of an anonymous class is denotable or not. Currently javac is failing with an error at class writing time. All this fix is doing is failing during attribution and trying to issue a better error message so that the user knows better how to fix the issue and the position of the offending code,

TIA

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

Commit messages:
 - 8211004: javac is complaining about non-denotable types and refusing to generate the class file

Changes: https://git.openjdk.java.net/jdk/pull/6886/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6886&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8211004
  Stats: 21 lines in 8 files changed: 15 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6886.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6886/head:pull/6886

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

From duke at openjdk.java.net  Sun Dec 19 01:57:22 2021
From: duke at openjdk.java.net (liach)
Date: Sun, 19 Dec 2021 01:57:22 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v5]
In-Reply-To: <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
 <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@github.com>
Message-ID: <9t0HMccxqJkAc2Jt2e8IPGDK_zxbxLMX0CkpmA6PhpQ=.4eeafc83-0f9f-4b89-ae4e-b982c2731526@github.com>

On Mon, 13 Dec 2021 20:45:50 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
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

Can these annotations be detected properly by reflection at runtime (when, say, compiled with `-parameters` flag to avoid a few other existing issues)?

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

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

From vromero at openjdk.java.net  Mon Dec 20 14:32:26 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 20 Dec 2021 14:32:26 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v5]
In-Reply-To: <9t0HMccxqJkAc2Jt2e8IPGDK_zxbxLMX0CkpmA6PhpQ=.4eeafc83-0f9f-4b89-ae4e-b982c2731526@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
 <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@github.com>
 <9t0HMccxqJkAc2Jt2e8IPGDK_zxbxLMX0CkpmA6PhpQ=.4eeafc83-0f9f-4b89-ae4e-b982c2731526@github.com>
Message-ID: <HvvI7K0t_I78tnd9LO0QDZQodCUnMHSjNv_Rz-vI2KA=.91f34f6a-3612-4869-b251-c44e8b45ee9c@github.com>

On Sun, 19 Dec 2021 01:53:53 GMT, liach <duke at openjdk.java.net> wrote:

> Can these annotations be detected properly by reflection at runtime (when, say, compiled with `-parameters` flag to avoid a few other existing issues)?

sorry I'm not sure I'm following you, the `-parameters` option deals with the parameter names it has nothing to do with annotations

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

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

From vromero at openjdk.java.net  Mon Dec 20 19:56:52 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 20 Dec 2021 19:56:52 GMT
Subject: RFR: 8205187: javac/javadoc should not crash if no java.lang; crash
 message obsolete
Message-ID: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>

Please review this PR which is basically changing the error message the compiler shows if the package java.lang can't be found, the current message is obsolete,

TIA

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

Commit messages:
 - 8205187: javac/javadoc should not crash if no java.lang; crash message obsolete

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

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

From duke at openjdk.java.net  Wed Dec 22 00:07:17 2021
From: duke at openjdk.java.net (liach)
Date: Wed, 22 Dec 2021 00:07:17 GMT
Subject: RFR: 8274617: constructor and parameter annotations are not copied
 to the anonymous class constructor [v5]
In-Reply-To: <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
 <ZKIxXm0hh-X2pUVWvHac3GqpqAmeZURwVehab8lLUpQ=.b10fa258-3093-4538-b04f-7fe9fca2cb86@github.com>
Message-ID: <lbd72IwcRkuNiB2s2wZuuxP2MV6JcUxsd_LV5ZsxJi4=.ed85fb23-a428-4865-9ed8-43100acd89df@github.com>

On Mon, 13 Dec 2021 20:45:50 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
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional tests

Hmm, since both annotation and method signature attributes' recorded signature/annotations don't exactly correspond to the parameters in the descriptor, I thought they probably would share the same mechanism of determining the exact parameter mapping. Reflection uses `MethodParameters` attribute's modifiers to determine how signatures apply to parameters, while it handles annotation in a separate way.

This indeed doesn't matter as the extra local variables passed are in the end of parameter list, which doesn't impact the current way annotations are written to class files and read at runtime. Sorry for digressing here.

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

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

From jjg at openjdk.java.net  Wed Dec 22 16:12:16 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Dec 2021 16:12:16 GMT
Subject: RFR: 8205187: javac/javadoc should not crash if no java.lang;
 crash message obsolete
In-Reply-To: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
References: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
Message-ID: <RnzllTRLZ4Qn1curRSIFAySB4yYeygXo_ArkP9V0z4M=.6249b0d8-9f05-4662-aaf0-91fb9011da89@github.com>

On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is basically changing the error message the compiler shows if the package java.lang can't be found, the current message is obsolete,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 362:

> 360:                     log.error(Errors.NoJavaLang);
> 361:                     throw new Abort();
> 362:                 }

`Abort` seems to have different semantics to `FatalError`.
Unless there is a good reason for the change, it might be more advisable to stay with `FatalError` and just change the text of the message.

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

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

From jjg at openjdk.java.net  Wed Dec 22 16:20:21 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Dec 2021 16:20:21 GMT
Subject: RFR: 8205187: javac/javadoc should not crash if no java.lang;
 crash message obsolete
In-Reply-To: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
References: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
Message-ID: <9hhECtbsxZgbdhiX_APSdGs765RPnycULc204vzPE8k=.8d55e14b-9864-445e-92ff-bede55dcb593@github.com>

On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is basically changing the error message the compiler shows if the package java.lang can't be found, the current message is obsolete,
> 
> TIA

Marked as reviewed by jjg (Reviewer).

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

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

From jjg at openjdk.java.net  Wed Dec 22 16:20:22 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 22 Dec 2021 16:20:22 GMT
Subject: RFR: 8205187: javac/javadoc should not crash if no java.lang;
 crash message obsolete
In-Reply-To: <RnzllTRLZ4Qn1curRSIFAySB4yYeygXo_ArkP9V0z4M=.6249b0d8-9f05-4662-aaf0-91fb9011da89@github.com>
References: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
 <RnzllTRLZ4Qn1curRSIFAySB4yYeygXo_ArkP9V0z4M=.6249b0d8-9f05-4662-aaf0-91fb9011da89@github.com>
Message-ID: <Qb3VUcHvl7SSA9SNMeuJHy6pB47SodFww8FkcH544HY=.aef84dbd-82d2-4536-af11-d35fed6bbbc9@github.com>

On Wed, 22 Dec 2021 16:08:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this PR which is basically changing the error message the compiler shows if the package java.lang can't be found, the current message is obsolete,
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 362:
> 
>> 360:                     log.error(Errors.NoJavaLang);
>> 361:                     throw new Abort();
>> 362:                 }
> 
> `Abort` seems to have different semantics to `FatalError`.
> Unless there is a good reason for the change, it might be more advisable to stay with `FatalError` and just change the text of the message.

"no java.lang" seems similar to a completion error, which is normally handled with `Abort`, so that might be a good reason for the change.

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

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

From cushon at google.com  Thu Dec 23 16:50:55 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 23 Dec 2021 11:50:55 -0500
Subject: Backporting JDK-8225559: assertion error at TransTypes.visitApply
Message-ID: <CAL4Qsgv=bz75g4jrXcbGf6mbR-sNjoqVEUnUsJqiL=Swicy7MA@mail.gmail.com>

Hello,

I'd like to backport JDK-8225559: assertion error at TransTypes.visitApply
to 17u and 11u.

I've seen it cause a handful of crashes recently. The scenario is that some
IDEs will suggest removing an inferrable type parameter from an anonymous
class definition on Java >= 11, and then the bug causes a crash during type
inference.

Does anyone have concerns with backporting that fix, and if not, is anyone
interested in sponsoring the PR?

https://git.openjdk.java.net/jdk17u-dev/pull/17

Thanks,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20211223/ee268e52/attachment.htm>

From vromero at openjdk.java.net  Thu Dec 23 19:16:17 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 23 Dec 2021 19:16:17 GMT
Subject: Integrated: 8205187: javac/javadoc should not crash if no java.lang; 
 crash message obsolete
In-Reply-To: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
References: <AMoAvwuC7hIKVvXao3xMrNrPnlEwaKWcwcQGEU6wYyA=.2a50793e-414f-4c11-af02-acc272435ad3@github.com>
Message-ID: <9jgldUFioVg3480JEn0FHW0gh2U0cnSqeK8kiBxCGw8=.383c07c1-2d57-4b4a-9704-c5e30abfb785@github.com>

On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is basically changing the error message the compiler shows if the package java.lang can't be found, the current message is obsolete,
> 
> TIA

This pull request has now been integrated.

Changeset: ff2ca4f2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff2ca4f21b7bd9d5afc6c74d8d369b3a0b8a4f19
Stats:     23 lines in 4 files changed: 8 ins; 6 del; 9 mod

8205187: javac/javadoc should not crash if no java.lang; crash message obsolete

Reviewed-by: jjg

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

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

From jjg at openjdk.java.net  Thu Dec 23 21:10:17 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 23 Dec 2021 21:10:17 GMT
Subject: RFR: JDK-8278795: Create test library and tests for langtools
 snippets
In-Reply-To: <gD02RIX9x8E_cUn4C4OxaxN-apCO3STr9UQk3cT_7FE=.6c37fc12-981d-4e78-85a3-7d5d0bf20000@github.com>
References: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
 <gD02RIX9x8E_cUn4C4OxaxN-apCO3STr9UQk3cT_7FE=.6c37fc12-981d-4e78-85a3-7d5d0bf20000@github.com>
Message-ID: <XQjYajbdqUFyI8QFeARsCSEy2AIWLmgeRlPgkIhU71E=.97ea2070-62d0-4839-b360-1ba38f13a41a@github.com>

On Thu, 16 Dec 2021 14:14:44 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a test-only fix to provide a new test library for analyzing snippets, and two tests that use that library to test snippets in the `jdk.javadoc` and `jdk.compiler` modules.
>> 
>> It is expected that the library may evolve in future updates as we explore additional ways to analyze snippets.
>
> test/langtools/tools/lib/snippets/SnippetUtils.java line 310:
> 
>> 308:             switch (ve.getKind()) {
>> 309:                 case ENUM_CONSTANT, FIELD -> scanDocComment(ve, treeScanner);
>> 310:                 default -> defaultAction(ve, treeScanner);
> 
> What kinds of elements are handled by the default branch?

It's there as a default to catch "anything else" that may come along, but that being said, IIRC I believe record components will come this way.

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

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

From jjg at openjdk.java.net  Thu Dec 23 21:16:15 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 23 Dec 2021 21:16:15 GMT
Subject: RFR: JDK-8278795: Create test library and tests for langtools
 snippets
In-Reply-To: <gD02RIX9x8E_cUn4C4OxaxN-apCO3STr9UQk3cT_7FE=.6c37fc12-981d-4e78-85a3-7d5d0bf20000@github.com>
References: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
 <gD02RIX9x8E_cUn4C4OxaxN-apCO3STr9UQk3cT_7FE=.6c37fc12-981d-4e78-85a3-7d5d0bf20000@github.com>
Message-ID: <rKPiTySoEh0feieOIdtLwdBAahMfkP_8wJWgVZ581e8=.9b91f3a4-cff0-4cca-a351-92661b6352c2@github.com>

On Thu, 16 Dec 2021 16:07:07 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Very impressive how much functionality you managed to pack into this first version of SnippetUtils!

Thanks; yeah, it helped to have some interesting snippets that I wanted to test.

> 
> The snippet kind inferral code is (as is usual with regex-based solutions) not especially nice to look at but seems to solve the problem with very few lines.

The regex code is not entirely new, since there is similar code in `ToolBox.writeJavaFiles`.  That being said, it would be an interesting (separate) exercise to try and use the javac lever to infer the kind. But, there is currently no public API for anything like that, so for now, regex will have to do. And, the philosophy is somewhat "if it works for you, use it; if it doesn't: you can explicitly specify the snippet kind in other overloads of the `parse` method.

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

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

From jjg at openjdk.java.net  Thu Dec 23 21:19:18 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 23 Dec 2021 21:19:18 GMT
Subject: Integrated: JDK-8278795: Create test library and tests for langtools
 snippets
In-Reply-To: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
References: <PljzBRiLNAQyGeDluDjJEhTzZ5QkLFRz-hx1Q1vf_TU=.9226964c-4466-4084-a4ac-2ca26ff699a8@github.com>
Message-ID: <_E99Y5yFGYaqqLpCD3yLyU9RIy01N1KoyCIU2e6MIc8=.28093152-b702-4205-8818-96b4c91de912@github.com>

On Tue, 14 Dec 2021 19:58:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a test-only fix to provide a new test library for analyzing snippets, and two tests that use that library to test snippets in the `jdk.javadoc` and `jdk.compiler` modules.
> 
> It is expected that the library may evolve in future updates as we explore additional ways to analyze snippets.

This pull request has now been integrated.

Changeset: 9df200f7
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9df200f749e6326f1d4a22cca770284f38c2de8c
Stats:     804 lines in 3 files changed: 804 ins; 0 del; 0 mod

8278795: Create test library and tests for langtools snippets

Reviewed-by: hannesw

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

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

From vromero at openjdk.java.net  Thu Dec 23 21:30:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 23 Dec 2021 21:30:41 GMT
Subject: Integrated: 8279244: test accompaning fix for JDK-8205187 is failing
 in Windows
Message-ID: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>

Fix for JDK-8205187 broke a Windows test. This patch is fixing that issue by avoiding to use a expected output containing a new line character,

TIA

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

Commit messages:
 - 8279244: test accompaning fix for JDK-8205187 is failing in Windows

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

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

From dcubed at openjdk.java.net  Thu Dec 23 21:30:42 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Dec 2021 21:30:42 GMT
Subject: Integrated: 8279244: test accompaning fix for JDK-8205187 is
 failing in Windows
In-Reply-To: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
References: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
Message-ID: <lBTSk4tv_ObP8lcraeK76ZrU9hUyrDivRjDVv1g5JKE=.54460d00-a4bd-436d-b3bc-b6feb1de62f4@github.com>

On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Fix for JDK-8205187 broke a Windows test. This patch is fixing that issue by avoiding to use a expected output containing a new line character,
> 
> TIA

Thumbs up. This looks like a trivial fix to me.

The fixed location matches the reported error location in the test.

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

Marked as reviewed by dcubed (Reviewer).

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

From mikael at openjdk.java.net  Thu Dec 23 21:30:43 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 23 Dec 2021 21:30:43 GMT
Subject: Integrated: 8279244: test accompaning fix for JDK-8205187 is
 failing in Windows
In-Reply-To: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
References: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
Message-ID: <3d4F-C5ewCKfG4o7hUlrhXJRtxyOz2yHwitlbHLNlN0=.500e1c5d-d0e8-4a6d-9fdf-83a424801103@github.com>

On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Fix for JDK-8205187 broke a Windows test. This patch is fixing that issue by avoiding to use a expected output containing a new line character,
> 
> TIA

Marked as reviewed by mikael (Reviewer).

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

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

From vromero at openjdk.java.net  Thu Dec 23 21:30:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 23 Dec 2021 21:30:44 GMT
Subject: Integrated: 8279244: test accompaning fix for JDK-8205187 is
 failing in Windows
In-Reply-To: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
References: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
Message-ID: <bFXd6yUqnXw8CNkqAgYbU6TxNJq6xboWsPcsPOBUEVw=.4510174d-90af-4ad6-aad6-41fb4617180a@github.com>

On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Fix for JDK-8205187 broke a Windows test. This patch is fixing that issue by avoiding to use a expected output containing a new line character,
> 
> TIA

thanks! and happy holidays

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

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

From vromero at openjdk.java.net  Thu Dec 23 21:30:45 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 23 Dec 2021 21:30:45 GMT
Subject: Integrated: 8279244: test accompaning fix for JDK-8205187 is failing
 in Windows
In-Reply-To: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
References: <HZ1p9gJUtsQf4hP-mDWl5aLArh5DacqNDRuf1qbceO0=.38bab2e6-d8ec-4e09-9515-4aae33df6ebf@github.com>
Message-ID: <rQxQiZ4ouPdL1KQr0zQzgXEOqprdzHfzSKH6iWmJfhk=.69b7b02f-2b60-441c-8c46-8f4ccad0c3d3@github.com>

On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Fix for JDK-8205187 broke a Windows test. This patch is fixing that issue by avoiding to use a expected output containing a new line character,
> 
> TIA

This pull request has now been integrated.

Changeset: 4669bcd8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4669bcd877c89b63739abd8087ea934c7126fb3f
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8279244: test accompaning fix for JDK-8205187 is failing in Windows

Reviewed-by: dcubed, mikael

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

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