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: References: Message-ID: On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: On Mon, 29 Nov 2021 17:29:03 GMT, Naoto Sato 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: References: Message-ID: On Fri, 19 Nov 2021 07:00:44 GMT, Ichiroh Takiguchi 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: 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: References: Message-ID: > Add a new --source-date (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 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 - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard ------------- 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: References: Message-ID: <9Q9BgKB7M_k_ldtqDALrT6LP6G7OPxkthTvHpbC2jJE=.94897652-9e7a-4706-96be-47b883272e93@github.com> On Wed, 1 Dec 2021 01:37:55 GMT, John Neffenger 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 > > 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: 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: References: Message-ID: On Mon, 29 Nov 2021 18:43:02 GMT, Jan Lahoda 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: References: Message-ID: On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing 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: References: Message-ID: On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman 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: References: Message-ID: On Wed, 1 Dec 2021 11:06:12 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard 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: References: <-1tFPYpJo0jzPExxhijSGpBSI-aHdvGv6inGY6I_KJM=.3236556e-bade-41e4-9bd6-f5b49c39af99@github.com> Message-ID: On Fri, 26 Nov 2021 14:35:27 GMT, Jan Lahoda 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: References: Message-ID: On Mon, 29 Nov 2021 18:43:02 GMT, Jan Lahoda 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: References: Message-ID: <_cwURlxQvtpRZxMA1t4UCTJ5Jtiv4XO_z09AsQyzhrA=.d70f4220-c155-4331-8828-2372fb83c5fe@github.com> On Wed, 1 Dec 2021 16:13:30 GMT, Guoxiong Li 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: Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using .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 .super and permits calls of .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: References: Message-ID: On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona 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 .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 .super and permits calls of .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: <_cwURlxQvtpRZxMA1t4UCTJ5Jtiv4XO_z09AsQyzhrA=.d70f4220-c155-4331-8828-2372fb83c5fe@github.com> Message-ID: On Wed, 1 Dec 2021 16:37:36 GMT, Jan Lahoda 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: References: Message-ID: On Wed, 1 Dec 2021 08:49:09 GMT, Ichiroh Takiguchi 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: References: Message-ID: <6ty6T5AqRlRapXF5V5ugplxLdbJs8SpL4DjztK4v_jk=.f23fe84e-2870-4dc2-89cc-a4eff31a1561@github.com> On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona 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 .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 .super and permits calls of .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: References: Message-ID: On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona 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 .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 .super and permits calls of .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: References: Message-ID: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> > Add a new --source-date (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 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 ------------- 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: References: 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: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> Message-ID: On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: 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: References: Message-ID: > Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using .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 .super and permits calls of .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: References: Message-ID: On Wed, 1 Dec 2021 16:49:08 GMT, Maurizio Cimadamore 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: <6ty6T5AqRlRapXF5V5ugplxLdbJs8SpL4DjztK4v_jk=.f23fe84e-2870-4dc2-89cc-a4eff31a1561@github.com> Message-ID: On Wed, 1 Dec 2021 17:43:06 GMT, Vicente Romero 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: References: Message-ID: On Tue, 30 Nov 2021 01:59:55 GMT, Liam Miller-Cushon 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: References: Message-ID: <0IzHgK-PQhvuVSF3QSGjl43RAoI__cxILZyLjVEcaiw=.af50e235-b881-46e9-8a5f-d7a7b544f964@github.com> On Wed, 1 Dec 2021 20:29:37 GMT, Adam Sotona 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: References: Message-ID: On Wed, 1 Dec 2021 20:35:09 GMT, Adam Sotona 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 .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 .super and permits calls of .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: References: Message-ID: On Wed, 1 Dec 2021 20:47:16 GMT, Joe Darcy 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: References: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> Message-ID: <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com> On Wed, 1 Dec 2021 18:20:11 GMT, John Neffenger 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: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> Message-ID: On Wed, 1 Dec 2021 18:02:05 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com> Message-ID: On Wed, 1 Dec 2021 21:50:46 GMT, Andrew Leonard 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: References: Message-ID: > 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: References: Message-ID: > Pull request #4376 (with fix of 8261006: 'super' qualified method references cannot occur in a static context) regressed compilation of all inner classes using .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 .super and permits calls of .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 .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: 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: References: Message-ID: On Wed, 1 Dec 2021 21:27:17 GMT, Maurizio Cimadamore 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 .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: References: Message-ID: On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam 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: References: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com> Message-ID: On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger 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: <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 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 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: References: Message-ID: > Add a new --source-date (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 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 - 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 - 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 - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - ... 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: References: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@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 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 > > 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: References: Message-ID: <6xWxKJ-I2oHIlkzwFiymYmEM9l7iSR9wBi1kmRYQkw0=.a53d3f0b-84be-423e-931e-fae8a0e5ffc7@github.com> On Thu, 2 Dec 2021 08:32:14 GMT, Adam Sotona 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 .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 .super and permits calls of .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 .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: References: 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 .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 .super and permits calls of .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: <6xWxKJ-I2oHIlkzwFiymYmEM9l7iSR9wBi1kmRYQkw0=.a53d3f0b-84be-423e-931e-fae8a0e5ffc7@github.com> Message-ID: On Thu, 2 Dec 2021 11:30:36 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed handling of .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: <_VfExHBkh85Xv-lBl1JVI7gPYd-f1nFmEFA0R_9A12Q=.f5245ac1-ef70-46a5-8771-a0630b7320dd@github.com> Message-ID: On Thu, 2 Dec 2021 12:23:59 GMT, Adam Sotona 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 .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 .super and permits calls of .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: References: Message-ID: On Wed, 1 Dec 2021 16:32:55 GMT, Adam Sotona 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 .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 .super and permits calls of .super > > Plus it adds a new test. > > Thanks, > Adam This pull request has now been integrated. Changeset: 8d9cb2ef Author: Adam Sotona 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: References: Message-ID: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com> > Add a new --source-date (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 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 - 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 - 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 - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - ... 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: References: Message-ID: On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam 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: References: Message-ID: > 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: References: Message-ID: On Wed, 1 Dec 2021 21:30:05 GMT, Liam Miller-Cushon 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: References: Message-ID: On Tue, 30 Nov 2021 01:59:55 GMT, Liam Miller-Cushon 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 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: References: Message-ID: <0gXyEfJJNpaLR25-eBZpRR-Jn8dX0LCYxsEdBI3u5DA=.79af9dd2-895d-4f8c-b853-78a5d1ee2015@github.com> On Thu, 2 Dec 2021 02:36:47 GMT, Tim Prinzing 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: References: Message-ID: On Thu, 18 Nov 2021 03:22:50 GMT, Tim Prinzing wrote: > JDK-8276674 : Malformed Javadoc inline tags in JDK source This pull request has now been integrated. Changeset: 652b5f85 Author: Tim Prinzing Committer: Brent Christian 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: 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: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing 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: References: Message-ID: > 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: References: Message-ID: On Sat, 20 Nov 2021 04:09:51 GMT, Tim Prinzing wrote: > JDK-8276681: Additional malformed Javadoc inline tags in JDK source This pull request has now been integrated. Changeset: b8ac0d20 Author: Tim Prinzing Committer: Lance Andersen 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: 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: 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: References: Message-ID: On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons 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: References: Message-ID: > 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: References: Message-ID: > 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: <5OpbfB2ehARyHljM7cfEKC1Fyf5c9JFkidF-m28GqPQ=.e8329a13-3b72-4e37-b52b-7a4bf6a90704@github.com> Message-ID: On Thu, 2 Dec 2021 15:35:40 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 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 > - 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - ... 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: On Tue, 10 Aug 2021 20:46:32 GMT, Jan Lahoda 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 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: References: Message-ID: On Fri, 3 Dec 2021 00:26:10 GMT, Jonathan Gibbons 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: 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: References: Message-ID: > Add a new --source-date (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 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 - 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 - 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 - 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 - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - 8276766: Enable jar and jmod to produce deterministic timestamped content Signed-off-by: Andrew Leonard - ... 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: References: Message-ID: On Fri, 3 Dec 2021 00:18:09 GMT, Jonathan Gibbons 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: References: Message-ID: On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda 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: References: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com> Message-ID: On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger 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: References: Message-ID: On Fri, 3 Dec 2021 00:41:23 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Mon, 29 Nov 2021 17:07:52 GMT, Alan Bateman 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: References: Message-ID: On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda 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: References: <2OPQeloa83eAI-w20Ih_j6K7DRAWm-mr6nLTDukhm8w=.dd41537c-4eba-4097-b797-819894c395a7@github.com> <6dJVzuK3eFutCkwiXoQVjbaBFXZWs3OldAcyh3u-i7U=.f1bc513e-46f8-430a-8788-3de62d41fa33@github.com> Message-ID: On Thu, 2 Dec 2021 01:53:47 GMT, John Neffenger 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: References: Message-ID: On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 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 > - 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 > - 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - ... 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: References: Message-ID: On Tue, 30 Nov 2021 00:09:23 GMT, PROgrm_JARvis 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: References: Message-ID: On Tue, 5 Oct 2021 07:52:40 GMT, Andrey Turbanov 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: References: Message-ID: On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 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 > - 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 > - 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - ... 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: References: Message-ID: On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 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 > - 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 > - 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - ... 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: References: Message-ID: On Thu, 2 Dec 2021 08:24:51 GMT, Srikanth Adayapalam 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 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: References: Message-ID: <-9ssbXq65tUHosgSJDcziTtkueh6eX4FQFwl8fZZRgk=.9c4018dc-82fa-4b8e-bac8-37d16cb9edce@github.com> On Fri, 3 Dec 2021 08:31:52 GMT, Jan Lahoda 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 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: On Mon, 6 Dec 2021 10:36:39 GMT, Jan Lahoda 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: References: Message-ID: > Add a new --source-date (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 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 ------------- 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: References: Message-ID: On Fri, 3 Dec 2021 10:05:43 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 > - 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 > - 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 > - 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 > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - 8276766: Enable jar and jmod to produce deterministic timestamped content > > Signed-off-by: Andrew Leonard > - ... 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: References: Message-ID: On Mon, 6 Dec 2021 00:15:13 GMT, Lance Andersen 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 >> - 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 >> - 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 >> - 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 >> - 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard >> - 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard >> - 8276766: Enable jar and jmod to produce deterministic timestamped content >> >> Signed-off-by: Andrew Leonard >> - ... 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: References: Message-ID: > 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: References: Message-ID: > Add a new --source-date (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 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 ------------- 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: References: Message-ID: On Tue, 16 Nov 2021 20:21:03 GMT, Jan Lahoda 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 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: References: Message-ID: > 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: References: Message-ID: On Mon, 29 Nov 2021 19:05:59 GMT, Vicente Romero 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: References: Message-ID: On Mon, 6 Dec 2021 13:57:48 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: > Add a new --source-date (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 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 ------------- 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: References: Message-ID: On Mon, 6 Dec 2021 16:36:37 GMT, Alan Bateman 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 > > 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: References: Message-ID: <3VHyKp-lqs2LwNAxotV1buStEUkcs6DkMvMAyXXa9gI=.950b3374-826b-4ff9-bfff-7e5677a5f3f3@github.com> On Mon, 6 Dec 2021 19:04:06 GMT, Andrew Leonard 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: References: Message-ID: On Wed, 6 Oct 2021 13:24:49 GMT, Jan Lahoda 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: References: Message-ID: On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: 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: <_d8rNveaqey7aemyE58e24CDL9eOMhyqswLgxUzwUFU=.52aee6d6-b513-43c1-9806-5d09ca0a7e39@github.com> Message-ID: On Mon, 29 Nov 2021 19:08:43 GMT, Lance Andersen 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: References: Message-ID: > 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: 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: References: Message-ID: On Tue, 7 Dec 2021 00:19:45 GMT, Jonathan Gibbons 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: References: Message-ID: > 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: References: Message-ID: On Tue, 7 Dec 2021 00:19:45 GMT, Jonathan Gibbons 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 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: References: Message-ID: <4YcA9pBfgNQpQ7UmFfKwwL7OOXmdsGgKpD-QSJb6pt4=.04ff3193-bc64-413d-aa96-f62aaa48c3b1@github.com> On Fri, 3 Dec 2021 00:40:03 GMT, Magnus Ihse Bursie 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: References: Message-ID: On Fri, 3 Dec 2021 13:47:05 GMT, Erik Joelsson 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: References: Message-ID: > 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: 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: References: Message-ID: On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: On Tue, 7 Dec 2021 09:24:44 GMT, Alan Bateman 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: References: Message-ID: On Tue, 7 Dec 2021 09:32:47 GMT, Andrew Leonard 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: References: Message-ID: On Tue, 7 Dec 2021 12:03:10 GMT, Lance Andersen 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: References: Message-ID: On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 @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: References: Message-ID: <322owcuKtMUGmQvVrIZC223CtXQrUxPswORBfLGZv0o=.617c1da6-b354-4578-86b0-addf79d7bd97@github.com> On Tue, 7 Dec 2021 03:05:41 GMT, Jonathan Gibbons 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: References: Message-ID: On Tue, 7 Dec 2021 13:10:53 GMT, Andrew Leonard 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: References: Message-ID: On Mon, 6 Dec 2021 19:11:45 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: > 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: References: Message-ID: On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy 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 Committer: Jesper Wilhelmsson 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: References: Message-ID: > Add a new --source-date (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 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 ------------- 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: References: Message-ID: On Wed, 8 Dec 2021 16:51:05 GMT, Alan Bateman 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 > > 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: References: Message-ID: On Tue, 7 Dec 2021 19:25:05 GMT, Lance Andersen 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 > > 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: References: Message-ID: On Thu, 9 Dec 2021 07:58:33 GMT, Christian Stein 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: 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: References: Message-ID: <2et17tjQvi1-JDSPCD67bQMDOjp1Aw9TVeZ4kxliBTM=.a1c25693-e1e5-46c6-a2d3-c0d9e381a8e9@github.com> On Thu, 9 Dec 2021 21:05:50 GMT, Jonathan Gibbons 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: References: Message-ID: On Thu, 9 Dec 2021 18:07:58 GMT, Andrew Leonard wrote: >> Add a new --source-date (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 > > 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 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: References: Message-ID: On Thu, 9 Dec 2021 21:05:50 GMT, Jonathan Gibbons 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 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: References: Message-ID: On Thu, 9 Dec 2021 18:14:13 GMT, Lance Andersen 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 > > 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 wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: ec0a5ac8 Author: Jesper Wilhelmsson 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: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons 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: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons 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 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 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 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: On Fri, 10 Dec 2021 02:48:43 GMT, Jonathan Gibbons 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: On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons 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: References: Message-ID: > 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: References: Message-ID: On Thu, 9 Dec 2021 18:37:11 GMT, Alan Bateman 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 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 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: References: Message-ID: <4GBNHwF6NlDHsQlgt4HM7Gatr4SStsQdn833oZFBRRo=.30c50bd4-e4ff-4eed-a1c1-5dad3b896e3f@github.com> On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein 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: References: Message-ID: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com> On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein 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: 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: References: Message-ID: On Fri, 10 Dec 2021 17:51:31 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 61736f81 Author: Jesper Wilhelmsson 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: References: Message-ID: On Fri, 10 Dec 2021 08:16:46 GMT, Christian Stein 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: References: Message-ID: > 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: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com> Message-ID: On Fri, 10 Dec 2021 16:30:37 GMT, Jonathan Gibbons 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: <_0AxepENVOSu6YhuLVZQsyA3fJ3aTId_NtIpbrCGk0s=.e4b3fe0a-3cac-4b8a-b577-7516fc48091e@github.com> Message-ID: On Fri, 10 Dec 2021 16:37:35 GMT, Jonathan Gibbons 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: References: Message-ID: > 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: <_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 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: References: Message-ID: On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein 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: References: Message-ID: On Sat, 11 Dec 2021 11:29:50 GMT, Christian Stein 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: References: Message-ID: On Wed, 8 Dec 2021 15:26:23 GMT, Christian Stein 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 Committer: Lance Andersen 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: References: Message-ID: > 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: 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: 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: References: Message-ID: On Tue, 14 Dec 2021 22:39:32 GMT, Liam Miller-Cushon 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: References: Message-ID: On Tue, 14 Dec 2021 22:39:32 GMT, Liam Miller-Cushon 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 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: 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: References: Message-ID: On Tue, 14 Dec 2021 19:58:47 GMT, Jonathan Gibbons 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: References: Message-ID: <_rSzQMFLz1p_r5YYveEPJCjveiTZCtWnrR1djA6BFzk=.fdd1c05a-46a0-40ac-b309-c363e16321de@github.com> On Wed, 15 Sep 2021 07:24:35 GMT, Andrey Turbanov 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 Committer: Vicente Romero 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: 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: References: Message-ID: <9t0HMccxqJkAc2Jt2e8IPGDK_zxbxLMX0CkpmA6PhpQ=.4eeafc83-0f9f-4b89-ae4e-b982c2731526@github.com> On Mon, 13 Dec 2021 20:45:50 GMT, Vicente Romero 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: <9t0HMccxqJkAc2Jt2e8IPGDK_zxbxLMX0CkpmA6PhpQ=.4eeafc83-0f9f-4b89-ae4e-b982c2731526@github.com> Message-ID: On Sun, 19 Dec 2021 01:53:53 GMT, liach 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: 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: References: Message-ID: On Mon, 13 Dec 2021 20:45:50 GMT, Vicente Romero 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: References: Message-ID: On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero 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: References: Message-ID: <9hhECtbsxZgbdhiX_APSdGs765RPnycULc204vzPE8k=.8d55e14b-9864-445e-92ff-bede55dcb593@github.com> On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero 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: References: Message-ID: On Wed, 22 Dec 2021 16:08:47 GMT, Jonathan Gibbons 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: 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: 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: References: Message-ID: <9jgldUFioVg3480JEn0FHW0gh2U0cnSqeK8kiBxCGw8=.383c07c1-2d57-4b4a-9704-c5e30abfb785@github.com> On Mon, 20 Dec 2021 19:48:18 GMT, Vicente Romero 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 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: References: Message-ID: On Thu, 16 Dec 2021 14:14:44 GMT, Hannes Walln?fer 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: References: Message-ID: On Thu, 16 Dec 2021 16:07:07 GMT, Hannes Walln?fer 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: References: Message-ID: <_E99Y5yFGYaqqLpCD3yLyU9RIy01N1KoyCIU2e6MIc8=.28093152-b702-4205-8818-96b4c91de912@github.com> On Tue, 14 Dec 2021 19:58:47 GMT, Jonathan Gibbons 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 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: 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: References: Message-ID: On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero 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: References: Message-ID: <3d4F-C5ewCKfG4o7hUlrhXJRtxyOz2yHwitlbHLNlN0=.500e1c5d-d0e8-4a6d-9fdf-83a424801103@github.com> On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero 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: References: Message-ID: On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero 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: References: Message-ID: On Thu, 23 Dec 2021 21:18:49 GMT, Vicente Romero 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 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