From alex.buckley at oracle.com Thu Oct 1 00:38:42 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Sep 2020 17:38:42 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com> Message-ID: <0b01b652-2a39-ca37-6bdd-fb247fb0f173@oracle.com> On 9/30/2020 4:48 PM, Joe Darcy wrote:> Conversely, the fact that an API element is preview on one release and > non-preview in a subsequent one does not necessarily imply the spec has > changed. (Although it might have changed, of course.) > > Non-preview methods don't necessarily have *exactly* the same semantics > between releases either, subject to our general API evolution policies. I recognize that a permanent API element may have its behavior changed in some situations, and we would leave @since alone in that context. For example, a method flagged with @since 8 might have been extended in 9 to handle modules, and we would not dream of saying @since 9. However, a preview API element has an order of magnitude more freedom to change than a permanent API element. This means that the element previewing in 15 might have the same name and signature as the element which previewed in 14, but with novel behavior in some _or even all_ situations ... if that happens, then it would be misleading to suggest that the novel aspect of the element's spec has been present since 14 just because the element itself has been present since 14. The element in 15 is not really the same element as in 14, and the element in 16 might not be the same element as in 15. Updating @since to 16 when the element becomes permanent wipes the slate clean (the preview behavior no longer matters) and lets the element join the club of "non-preview and not-deprecated-for-removal API elements" which "can be assumed to be present in the next release." Alex From vromero at openjdk.java.net Thu Oct 1 01:31:04 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:31:04 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary jtreg tags from tests, remove othervm etc when applicable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/76e3d278..7501148d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=07-08 Stats: 102 lines in 54 files changed: 33 ins; 19 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Oct 1 01:33:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:33:58 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 30 Sep 2020 08:54:14 GMT, Chris Hegarty wrote: >> test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: >> >>> 31: * jdk.compiler/com.sun.tools.javac.util >>> 32: * @build combo.ComboTestHelper >>> 33: * @compile LocalStaticDeclarations.java >> >> This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the >> at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version >> options could be passed to javac - neither of which are needed any more. > > Does this test need an @run tag rather than an @compile tag ? ( the @run with implicitly compile the source file, > before running it ) @ChrisHegarty I have created commit [7501148](https://github.com/openjdk/jdk/pull/290/commits/7501148dd4c21847699a84d6dc5ef100d993b78d) to address this issue, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Thu Oct 1 09:32:03 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 1 Oct 2020 09:32:03 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> Message-ID: On Thu, 1 Oct 2020 01:31:04 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary jtreg tags from tests, remove othervm etc when applicable Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From amaembo at gmail.com Thu Oct 1 11:29:52 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Thu, 1 Oct 2020 18:29:52 +0700 Subject: void return type check in method reference to PolymorphicSignature method Message-ID: Hello! I've found that this code is not compilable in Java 9 and Java 10, but compilable in Java 11 or later (yet fails at runtime): import java.lang.invoke.MethodHandles; import java.lang.invoke.VarHandle; import java.util.Arrays; class Test { interface VH { int set(int[] arr, int idx, int val); } public static void main(String[] args) { VarHandle vh = MethodHandles.arrayElementVarHandle(int[].class); //VH mr = (arr, idx, val) -> vh.set(arr, idx, val); // not compilable VH mr = vh::set; // compilable but runtime error int[] data = {0}; mr.set(data, 0, 2); System.out.println(Arrays.toString(data)); } } Fails with Exception in thread "main" java.lang.NoSuchMethodError: VarHandle.set(int[],int,int)int at java.base/java.lang.invoke.MethodHandleNatives.newNoSuchMethodErrorOnVarHandle(MethodHandleNatives.java:589) at java.base/java.lang.invoke.MethodHandleNatives.varHandleOperationLinkerMethod(MethodHandleNatives.java:542) at java.base/java.lang.invoke.MethodHandleNatives.linkMethodImpl(MethodHandleNatives.java:475) at java.base/java.lang.invoke.MethodHandleNatives.linkMethod(MethodHandleNatives.java:463) at Test.main(Test.java:15) However, very similar lambda is expectedly not compilable. Is it expected behavior? Looks like a regression to me. I don't see any changes in JLS 15.13 between Java 10 and Java 11. Am I missing something? With best regards, Tagir Valeev From jlahoda at openjdk.java.net Thu Oct 1 12:46:52 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 1 Oct 2020 12:46:52 GMT Subject: RFR: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows Message-ID: @rwestberg prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548 I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b) improve ToolBox to check and reject file names that are reserved. Note that testHelloWorldWithAux uses the name "Aux" intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in memory, and won't be written as a file, so will not cause the issue. The use of name "Aux" in the testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing the actual test, so it seems fine to change the name. @jonathan-gibbons, could you please take a look? Thanks! ------------- Commit messages: - 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows Changes: https://git.openjdk.java.net/jdk/pull/456/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=456&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249095 Stats: 29 lines in 2 files changed: 21 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/456.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/456/head:pull/456 PR: https://git.openjdk.java.net/jdk/pull/456 From alanb at openjdk.java.net Thu Oct 1 13:31:46 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 1 Oct 2020 13:31:46 GMT Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 05:38:18 GMT, Christian Stein wrote: > This commit replaces `"/!"` with `"!/"` in order to generate > valid URIs when printing a module description of a modular > JAR file. A valid URI is described here: [1] > > https://bugs.openjdk.java.net/browse/JDK-8253761 > > [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html The change looks good. test/jdk/tools/jar/modularJar/Basic.java has tests for jar --describe-module and maybe we could add a test to this to make sure that it outputs the expected JAR URL. ------------- PR: https://git.openjdk.java.net/jdk/pull/393 From jlaskey at openjdk.java.net Thu Oct 1 13:32:42 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Oct 2020 13:32:42 GMT Subject: RFR: 8224225: Tokenizer improvements [v2] In-Reply-To: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@github.com> References: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@github.com> Message-ID: <4XVzJx4GEx7uiQ8WHgt5wJ2YT3iyDUJlxDgs-1xJ8pY=.649f8c1b-23ea-4d6a-86e4-e55f4dfb2b1e@github.com> > Please review these changes to the javac scanner. > > I recommend looking at the "new" versions of 1. UnicodeReader, then 2. JavaTokenizer and then 3. JavadocTokenizer > before venturing into the diffs. > Rationale, under the heading of technical debt and separation of concerns: There is a lot "going on" in the > JavaTokenizer/JavadocTokenizer that needed to be cleaned up. > - The UnicodeReader shouldn't really be accumulating characters for literals. > - A tokenizer shouldn't need to be aware of the unicode translations. > - There is no need for peek ahead. > - There were a lot of repetitive tasks that should be done in methods instead of complex expressions. > - Names of existing methods were often confusing. > > To avoid disruption, I avoided changing logical, except in the UnicodeReader. There are some relics in the > JavaTokenizer/JavadocTokenizer that could be cleaned up but require deeper analysis. > Some details; > > - UnicodeReader was reworked to provide tokenizers a running stream of unicode characters/codepoints. Steps: > - characters are read from the buffer. > - if the character is a '' then check to see if the character is the beginning of an unicode escape sequence, If so, > then translate. - if the character is a high surrogate then check to see if next character is the low surrogate. If so > then combine. - A tokenizer can test a codepoint with the isSurrogate predicate (when/if needed.) > The result of putting this logic on UnicodeReader's shoulders means that a tokenizer does not need have any unicode > "logical." > > - The old UnicodeReader modified the source buffer to insert an EOI character at the end to mark the last character. > - This meant the buffer had to be large enough (grown) to accommodate. > - There really was no need since we can simply return an EOI when trying to read past the end of buffer. > > - The only buffer mutability left behind is when reading digits. > - Unicode digits are still replaced with ASCII digits. > - This seems unnecessary, but I didn't want to risk messing around with the existing logic. Maybe someone can > enlighten me. > - The sequence '\' is special cased in the UnicodeReader so that the sequence "\\uXXXX" is handled properly. > - Thus, tokenizers don't have to special case '\' (happened frequently in the JavadocTokenizer.) > > - JavaTokenizer was modified to accumulate scanned literals in a StringBuilder. > - This simplified/clarified the code significantly. > > - Since a lot of the functionality needed by the JavaTokenizer comes directly from a UnicodeReader, I made JavaTokenizer > a subclass of UnicodeReader. > - Otherwise, I would have had to reference "reader." everywhere or would have to create JavaTokenizer methods to > repeat the same logic. This was simpler and cleaner. > - Since the pattern "if (ch == 'X') bpos++" occurred a lot, I switched to using "if (accept('X')) " patterns. > - Actually, I tightened up a lot of these patterns, as you will see in the code. > > - There are a lot of great mysteries in JavadocTokenizer, but I think I cracked most of them. The code is simpler and > more modular. > > - The new scanner is slower to warm up due to new layers of method calls (ex. HelloWorld is 5% slower). However, once > warmed up, this new scanner is faster than the existing code. The JDK java code compiles 5-10% faster. > > Previous review: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-August/014806.html Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8224225 - 8224225: Tokenizer improvements ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/435/files - new: https://git.openjdk.java.net/jdk/pull/435/files/c4531476..0ee36a3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=435&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=435&range=00-01 Stats: 8720 lines in 1728 files changed: 2446 ins; 1579 del; 4695 mod Patch: https://git.openjdk.java.net/jdk/pull/435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/435/head:pull/435 PR: https://git.openjdk.java.net/jdk/pull/435 From mcimadamore at openjdk.java.net Thu Oct 1 13:41:15 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Oct 2020 13:41:15 GMT Subject: RFR: 8224225: Tokenizer improvements [v2] In-Reply-To: <4XVzJx4GEx7uiQ8WHgt5wJ2YT3iyDUJlxDgs-1xJ8pY=.649f8c1b-23ea-4d6a-86e4-e55f4dfb2b1e@github.com> References: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@github.com> <4XVzJx4GEx7uiQ8WHgt5wJ2YT3iyDUJlxDgs-1xJ8pY=.649f8c1b-23ea-4d6a-86e4-e55f4dfb2b1e@github.com> Message-ID: On Thu, 1 Oct 2020 13:32:42 GMT, Jim Laskey wrote: >> Please review these changes to the javac scanner. >> >> I recommend looking at the "new" versions of 1. UnicodeReader, then 2. JavaTokenizer and then 3. JavadocTokenizer >> before venturing into the diffs. >> Rationale, under the heading of technical debt and separation of concerns: There is a lot "going on" in the >> JavaTokenizer/JavadocTokenizer that needed to be cleaned up. >> - The UnicodeReader shouldn't really be accumulating characters for literals. >> - A tokenizer shouldn't need to be aware of the unicode translations. >> - There is no need for peek ahead. >> - There were a lot of repetitive tasks that should be done in methods instead of complex expressions. >> - Names of existing methods were often confusing. >> >> To avoid disruption, I avoided changing logical, except in the UnicodeReader. There are some relics in the >> JavaTokenizer/JavadocTokenizer that could be cleaned up but require deeper analysis. >> Some details; >> >> - UnicodeReader was reworked to provide tokenizers a running stream of unicode characters/codepoints. Steps: >> - characters are read from the buffer. >> - if the character is a '' then check to see if the character is the beginning of an unicode escape sequence, If so, >> then translate. - if the character is a high surrogate then check to see if next character is the low surrogate. If so >> then combine. - A tokenizer can test a codepoint with the isSurrogate predicate (when/if needed.) >> The result of putting this logic on UnicodeReader's shoulders means that a tokenizer does not need have any unicode >> "logical." >> >> - The old UnicodeReader modified the source buffer to insert an EOI character at the end to mark the last character. >> - This meant the buffer had to be large enough (grown) to accommodate. >> - There really was no need since we can simply return an EOI when trying to read past the end of buffer. >> >> - The only buffer mutability left behind is when reading digits. >> - Unicode digits are still replaced with ASCII digits. >> - This seems unnecessary, but I didn't want to risk messing around with the existing logic. Maybe someone can >> enlighten me. >> - The sequence '\' is special cased in the UnicodeReader so that the sequence "\\uXXXX" is handled properly. >> - Thus, tokenizers don't have to special case '\' (happened frequently in the JavadocTokenizer.) >> >> - JavaTokenizer was modified to accumulate scanned literals in a StringBuilder. >> - This simplified/clarified the code significantly. >> >> - Since a lot of the functionality needed by the JavaTokenizer comes directly from a UnicodeReader, I made JavaTokenizer >> a subclass of UnicodeReader. >> - Otherwise, I would have had to reference "reader." everywhere or would have to create JavaTokenizer methods to >> repeat the same logic. This was simpler and cleaner. >> - Since the pattern "if (ch == 'X') bpos++" occurred a lot, I switched to using "if (accept('X')) " patterns. >> - Actually, I tightened up a lot of these patterns, as you will see in the code. >> >> - There are a lot of great mysteries in JavadocTokenizer, but I think I cracked most of them. The code is simpler and >> more modular. >> >> - The new scanner is slower to warm up due to new layers of method calls (ex. HelloWorld is 5% slower). However, once >> warmed up, this new scanner is faster than the existing code. The JDK java code compiles 5-10% faster. >> >> Previous review: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-August/014806.html > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since > the last revision: > - Merge branch 'master' into 8224225 > - 8224225: Tokenizer improvements Approved as per: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-August/014810.html ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/435 From vromero at openjdk.java.net Thu Oct 1 15:21:04 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 15:21:04 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 20:25:27 GMT, Jonathan Gibbons wrote: > This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. > > Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initiate code can be > moved out of `WorkArounds`. > The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the > type-kind visitor. just a nit comment, no need for another iteration, the changes looks good to me src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 117: > 115: > 116: /* > 117: * TODO: This method exists because of a bug in javac which does not probably a good idea to include the bug ID here? ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/412 From jlaskey at openjdk.java.net Thu Oct 1 15:43:09 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Oct 2020 15:43:09 GMT Subject: Integrated: 8224225: Tokenizer improvements In-Reply-To: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@github.com> References: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@github.com> Message-ID: On Wed, 30 Sep 2020 14:19:21 GMT, Jim Laskey wrote: > Please review these changes to the javac scanner. > > I recommend looking at the "new" versions of 1. UnicodeReader, then 2. JavaTokenizer and then 3. JavadocTokenizer > before venturing into the diffs. > Rationale, under the heading of technical debt and separation of concerns: There is a lot "going on" in the > JavaTokenizer/JavadocTokenizer that needed to be cleaned up. > - The UnicodeReader shouldn't really be accumulating characters for literals. > - A tokenizer shouldn't need to be aware of the unicode translations. > - There is no need for peek ahead. > - There were a lot of repetitive tasks that should be done in methods instead of complex expressions. > - Names of existing methods were often confusing. > > To avoid disruption, I avoided changing logical, except in the UnicodeReader. There are some relics in the > JavaTokenizer/JavadocTokenizer that could be cleaned up but require deeper analysis. > Some details; > > - UnicodeReader was reworked to provide tokenizers a running stream of unicode characters/codepoints. Steps: > - characters are read from the buffer. > - if the character is a '' then check to see if the character is the beginning of an unicode escape sequence, If so, > then translate. - if the character is a high surrogate then check to see if next character is the low surrogate. If so > then combine. - A tokenizer can test a codepoint with the isSurrogate predicate (when/if needed.) > The result of putting this logic on UnicodeReader's shoulders means that a tokenizer does not need have any unicode > "logical." > > - The old UnicodeReader modified the source buffer to insert an EOI character at the end to mark the last character. > - This meant the buffer had to be large enough (grown) to accommodate. > - There really was no need since we can simply return an EOI when trying to read past the end of buffer. > > - The only buffer mutability left behind is when reading digits. > - Unicode digits are still replaced with ASCII digits. > - This seems unnecessary, but I didn't want to risk messing around with the existing logic. Maybe someone can > enlighten me. > - The sequence '\' is special cased in the UnicodeReader so that the sequence "\\uXXXX" is handled properly. > - Thus, tokenizers don't have to special case '\' (happened frequently in the JavadocTokenizer.) > > - JavaTokenizer was modified to accumulate scanned literals in a StringBuilder. > - This simplified/clarified the code significantly. > > - Since a lot of the functionality needed by the JavaTokenizer comes directly from a UnicodeReader, I made JavaTokenizer > a subclass of UnicodeReader. > - Otherwise, I would have had to reference "reader." everywhere or would have to create JavaTokenizer methods to > repeat the same logic. This was simpler and cleaner. > - Since the pattern "if (ch == 'X') bpos++" occurred a lot, I switched to using "if (accept('X')) " patterns. > - Actually, I tightened up a lot of these patterns, as you will see in the code. > > - There are a lot of great mysteries in JavadocTokenizer, but I think I cracked most of them. The code is simpler and > more modular. > > - The new scanner is slower to warm up due to new layers of method calls (ex. HelloWorld is 5% slower). However, once > warmed up, this new scanner is faster than the existing code. The JDK java code compiles 5-10% faster. > > Previous review: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-August/014806.html This pull request has now been integrated. Changeset: 90c131f2 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/90c131f2 Stats: 2353 lines in 18 files changed: 1119 ins; 603 del; 631 mod 8224225: Tokenizer improvements Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/435 From jjg at openjdk.java.net Thu Oct 1 17:17:07 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 1 Oct 2020 17:17:07 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 15:13:20 GMT, Vicente Romero wrote: >> This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. >> >> Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initiate code can be >> moved out of `WorkArounds`. >> The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the >> type-kind visitor. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 117: > >> 115: >> 116: /* >> 117: * TODO: This method exists because of a bug in javac which does not > > probably a good idea to include the bug ID here? @vicente-romero-oracle This relates to a discussion we should have elsewhere, separately, about the interactions between deprecation and packages, and whether we should support depicted packages. JLS does not list packages in the list of kinds of elements that can be deprecated, in which case this comment is probably incorrect, as the bug may actually be here in javadoc for trying to support deprecated packages! ------------- PR: https://git.openjdk.java.net/jdk/pull/412 From jjg at openjdk.java.net Thu Oct 1 17:25:15 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 1 Oct 2020 17:25:15 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 15:18:44 GMT, Vicente Romero wrote: >> This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. >> >> Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initiate code can be >> moved out of `WorkArounds`. >> The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the >> type-kind visitor. > > just a nit comment, no need for another iteration, the changes looks good to me @vicente-romero-oracle thanks for the review. I raised the number of reviewers to have a javadoc reviewer participate as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/412 From jlaskey at openjdk.java.net Thu Oct 1 17:45:12 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Oct 2020 17:45:12 GMT Subject: Integrated: 8253904: Revert Tokenizer improvements JDK-8224225 Message-ID: This reverts commit 90c131f29f23ba1be2c5ac50a780d39a752e2444. Github test gave false positive. https://bugs.openjdk.java.net/browse/JDK-8253904 https://github.com/JimLaskey/jdk/actions/runs/282419921 Sorry for the inconvenience. ------------- Commit messages: - Revert "8224225: Tokenizer improvements" Changes: https://git.openjdk.java.net/jdk/pull/471/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=471&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253904 Stats: 2336 lines in 18 files changed: 586 ins; 1102 del; 648 mod Patch: https://git.openjdk.java.net/jdk/pull/471.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/471/head:pull/471 PR: https://git.openjdk.java.net/jdk/pull/471 From mcimadamore at openjdk.java.net Thu Oct 1 17:45:12 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Oct 2020 17:45:12 GMT Subject: Integrated: 8253904: Revert Tokenizer improvements JDK-8224225 In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 17:35:27 GMT, Jim Laskey wrote: > This reverts commit 90c131f29f23ba1be2c5ac50a780d39a752e2444. > > Github test gave false positive. > > https://bugs.openjdk.java.net/browse/JDK-8253904 > > https://github.com/JimLaskey/jdk/actions/runs/282419921 > > > Sorry for the inconvenience. Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/471 From jlaskey at openjdk.java.net Thu Oct 1 17:45:13 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 1 Oct 2020 17:45:13 GMT Subject: Integrated: 8253904: Revert Tokenizer improvements JDK-8224225 In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 17:35:27 GMT, Jim Laskey wrote: > This reverts commit 90c131f29f23ba1be2c5ac50a780d39a752e2444. > > Github test gave false positive. > > https://bugs.openjdk.java.net/browse/JDK-8253904 > > https://github.com/JimLaskey/jdk/actions/runs/282419921 > > > Sorry for the inconvenience. This pull request has now been integrated. Changeset: 8fda5b82 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/8fda5b82 Stats: 2336 lines in 18 files changed: 586 ins; 1102 del; 648 mod 8253904: Revert Tokenizer improvements JDK-8224225 Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/471 From paul.sandoz at oracle.com Thu Oct 1 23:33:48 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Oct 2020 16:33:48 -0700 Subject: void return type check in method reference to PolymorphicSignature method In-Reply-To: References: Message-ID: <3D94AE45-8C1A-4C20-8FF0-106052FA92DB@oracle.com> Hi Tagir, I think it is a regression introduced by: 8203488: Remove error generation from TransTypes I managed to fix it by ensuring the sig poly method's return type dominates if its not Object (polymorphic in its return type), which then results in a compilation error. However, it needs someone with more expertise that I in javac to ensure that the fix is correct. Paul. diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java index 6fd598340b7..dbc176b751c 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java @@ -2747,6 +2747,18 @@ public class Resolve { } } + Type spReturnType = spMethod.asType().getReturnType(); + if (types.isSameType(spReturnType, syms.objectType)) { + // Polymorphic return, pass through mtype + } else if (!types.isSameType(spReturnType, mtype.getReturnType())) { + // Retain the sig poly method's return type, which differs from that of mtype + // Should result in compilation error later + mtype = new MethodType(mtype.getParameterTypes(), + spReturnType, + mtype.getThrownTypes(), + syms.methodClass); + } + // Create the desired method // Retain static modifier is to support invocations to // MethodHandle.linkTo* methods > On Oct 1, 2020, at 4:29 AM, Tagir Valeev wrote: > > Hello! > > I've found that this code is not compilable in Java 9 and Java 10, but > compilable in Java 11 or later (yet fails at runtime): > > import java.lang.invoke.MethodHandles; > import java.lang.invoke.VarHandle; > import java.util.Arrays; > > class Test { > interface VH { > int set(int[] arr, int idx, int val); > } > > public static void main(String[] args) { > VarHandle vh = MethodHandles.arrayElementVarHandle(int[].class); > //VH mr = (arr, idx, val) -> vh.set(arr, idx, val); // not compilable > VH mr = vh::set; // compilable but runtime error > int[] data = {0}; > mr.set(data, 0, 2); > System.out.println(Arrays.toString(data)); > } > } > > Fails with > > Exception in thread "main" java.lang.NoSuchMethodError: > VarHandle.set(int[],int,int)int > at java.base/java.lang.invoke.MethodHandleNatives.newNoSuchMethodErrorOnVarHandle(MethodHandleNatives.java:589) > at java.base/java.lang.invoke.MethodHandleNatives.varHandleOperationLinkerMethod(MethodHandleNatives.java:542) > at java.base/java.lang.invoke.MethodHandleNatives.linkMethodImpl(MethodHandleNatives.java:475) > at java.base/java.lang.invoke.MethodHandleNatives.linkMethod(MethodHandleNatives.java:463) > at Test.main(Test.java:15) > > However, very similar lambda is expectedly not compilable. Is it > expected behavior? Looks like a regression to me. I don't see any > changes in JLS 15.13 between Java 10 and Java 11. Am I missing > something? > > With best regards, > Tagir Valeev From ksrini at openjdk.java.net Fri Oct 2 00:10:06 2020 From: ksrini at openjdk.java.net (Kumar Srinivasan) Date: Fri, 2 Oct 2020 00:10:06 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 20:25:27 GMT, Jonathan Gibbons wrote: > This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. > > Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initiate code can be > moved out of `WorkArounds`. > The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the > type-kind visitor. Nice to see WorkArounds being chipped away. It is not clear to me if additional tests are warranted for getConstantValue for TestConstantValuesDriver.java, in langtools test I saw only ElementStructureTest.java. I will leave it to you, maybe file a follow up issue. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2274: > 2272: if (cve == null) > 2273: cve = new ConstantValueExpression(); > 2274: return cve.visit(ve.asType(), ve.getConstantValue()); yay test/langtools/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java line 60: > 58: public static final byte > 59: href="TestConstantValues.html#BYTE_MAX_VALUE">BYTE_MAX_VALUE 60: class="col-last">0x7f""", Should there be tests for Float, Double, Long ? ------------- Marked as reviewed by ksrini (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/412 From ksrini at openjdk.java.net Fri Oct 2 00:28:05 2020 From: ksrini at openjdk.java.net (Kumar Srinivasan) Date: Fri, 2 Oct 2020 00:28:05 GMT Subject: RFR: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 12:40:07 GMT, Jan Lahoda wrote: > @rwestberg prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for > Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the > testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548 > I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the > test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b) improve > ToolBox to check and reject file names that are reserved. Note that testHelloWorldWithAux uses the name "Aux" > intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I > believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in > memory, and won't be written as a file, so will not cause the issue. The use of name "Aux" in the > testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing > the actual test, so it seems fine to change the name. @jonathan-gibbons, could you please take a look? Thanks! Hi Jan, thanks for the summary, that was my take as well, when I observed this issue. It is rather strange that we observed this issue, while others did not. I will let Jon approve this, but I am ok with the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/456 From bsrbnd at gmail.com Fri Oct 2 13:50:35 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 2 Oct 2020 15:50:35 +0200 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static Message-ID: Hi, Consider the following example from JDK-8238213: public class JavacBrokenError { public static void main(String[] args) { test(5.0); } void test(double d) {} /* static */ void test(Double d) {} } It seems that javac correctly finds 'test(double)' during the strict resolution phase (?15.12.2.2) but doesn't stop with a static error as mandated by ?15.12.3 and continues with the loose resolution phase (?15.12.2.3) which ends up wrongly with the ambiguous error instead. The following fix addresses this on jdk14u (langtools:tier1 is OK): diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java @@ -3283,7 +3283,7 @@ */ final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { return phase.ordinal() > maxPhase.ordinal() || - !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS; + !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR; } /** On jdk16, see: https://github.com/openjdk/jdk/blob/b8966e1f7bfa2408f0e5330ac310526dd5c3cb2d/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java#L3310 What do you think? Thanks, Bernard From jjg at openjdk.java.net Fri Oct 2 16:21:45 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 2 Oct 2020 16:21:45 GMT Subject: Integrated: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 20:25:27 GMT, Jonathan Gibbons wrote: > This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. > > Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initialization code can > be moved out of `WorkArounds`. > The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the > type-kind visitor. This pull request has now been integrated. Changeset: 77780475 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/77780475 Stats: 423 lines in 9 files changed: 190 ins; 155 del; 78 mod 8253736: Cleanup some of WorkArounds and usage thereof Reviewed-by: vromero, ksrini ------------- PR: https://git.openjdk.java.net/jdk/pull/412 From jjg at openjdk.java.net Fri Oct 2 16:21:44 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 2 Oct 2020 16:21:44 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 23:23:54 GMT, Kumar Srinivasan wrote: >> This cleanup is primarily focussed on the WorkArounds class, simplifying/removing code that is no longer required. >> >> Also, simplified DocLint initialization such that it no longer needs a `JavacTask` and so the initialization code can >> be moved out of `WorkArounds`. >> The "constant value expression" in Utils is simplified to remove a redundant level of enclosing nested class for the >> type-kind visitor. > > test/langtools/jdk/javadoc/doclet/constantValues/TestConstantValuesDriver.java line 60: > >> 58: public static final byte >> 59: > href="TestConstantValues.html#BYTE_MAX_VALUE">BYTE_MAX_VALUE 60: > class="col-last">0x7f""", > > Should there be tests for Float, Double, Long ? https://bugs.openjdk.java.net/browse/JDK-8253941 ------------- PR: https://git.openjdk.java.net/jdk/pull/412 From maurizio.cimadamore at oracle.com Fri Oct 2 16:47:23 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 2 Oct 2020 17:47:23 +0100 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: References: Message-ID: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> I agree that seems to be a discrepancy from what the JLS is saying (and, I believe even from what earlier javac versions were doing - e.g. prior to 8). I tried this in Java 7 and this returned: foo.java:3: error: non-static method test(double) cannot be referenced from a static context ??? test(5.0); ??? ^ as expected. Maurizio On 02/10/2020 14:50, B. Blaser wrote: > Hi, > > Consider the following example from JDK-8238213: > > public class JavacBrokenError { > public static void main(String[] args) { > test(5.0); > } > > void test(double d) {} > /* static */ void test(Double d) {} > } > > It seems that javac correctly finds 'test(double)' during the strict > resolution phase (?15.12.2.2) but doesn't stop with a static error as > mandated by ?15.12.3 and continues with the loose resolution phase > (?15.12.2.3) which ends up wrongly with the ambiguous error instead. > > The following fix addresses this on jdk14u (langtools:tier1 is OK): > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > @@ -3283,7 +3283,7 @@ > */ > final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { > return phase.ordinal() > maxPhase.ordinal() || > - !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS; > + !sym.kind.isResolutionError() || sym.kind == > AMBIGUOUS || sym.kind == STATICERR; > } > > /** > > On jdk16, see: > > https://github.com/openjdk/jdk/blob/b8966e1f7bfa2408f0e5330ac310526dd5c3cb2d/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java#L3310 > > What do you think? > > Thanks, > Bernard From bsrbnd at gmail.com Fri Oct 2 17:10:27 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 2 Oct 2020 19:10:27 +0200 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> Message-ID: Thanks for the confirmation, Maurizio. Being still not up-to-date with the new git work-flow, could someone help pushing it on my behalf? Cheers, Bernard On Fri, 2 Oct 2020 at 18:47, Maurizio Cimadamore wrote: > > I agree that seems to be a discrepancy from what the JLS is saying (and, > I believe even from what earlier javac versions were doing - e.g. prior > to 8). > > I tried this in Java 7 and this returned: > > foo.java:3: error: non-static method test(double) cannot be referenced > from a static context > test(5.0); > ^ > > as expected. > > Maurizio > > On 02/10/2020 14:50, B. Blaser wrote: > > Hi, > > > > Consider the following example from JDK-8238213: > > > > public class JavacBrokenError { > > public static void main(String[] args) { > > test(5.0); > > } > > > > void test(double d) {} > > /* static */ void test(Double d) {} > > } > > > > It seems that javac correctly finds 'test(double)' during the strict > > resolution phase (?15.12.2.2) but doesn't stop with a static error as > > mandated by ?15.12.3 and continues with the loose resolution phase > > (?15.12.2.3) which ends up wrongly with the ambiguous error instead. > > > > The following fix addresses this on jdk14u (langtools:tier1 is OK): > > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java > > @@ -3283,7 +3283,7 @@ > > */ > > final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { > > return phase.ordinal() > maxPhase.ordinal() || > > - !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS; > > + !sym.kind.isResolutionError() || sym.kind == > > AMBIGUOUS || sym.kind == STATICERR; > > } > > > > /** > > > > On jdk16, see: > > > > https://github.com/openjdk/jdk/blob/b8966e1f7bfa2408f0e5330ac310526dd5c3cb2d/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java#L3310 > > > > What do you think? > > > > Thanks, > > Bernard From psandoz at openjdk.java.net Fri Oct 2 17:44:48 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 2 Oct 2020 17:44:48 GMT Subject: RFR: 8253944: Certain method references to VarHandle methods should fail Message-ID: A regression was introduced in javac when processing method references to signature polymorphic methods whose return type is not polymorphic. It is possible to successfully target type a method reference for a VarHandle sig-poly method to a functional interface whose methods return type is incompatible with the VarHandle method. This results in a runtime linkage error rather than a source compile time error. See the following email thread for more details: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015088.html The fix is to "patch-back" the method's return type if it is not polymorphic. As a result it was possible to simplify the inference logic and keep it focused more on inference. ------------- Commit messages: - 8253944: Certain method references to VarHandle methods should fail Changes: https://git.openjdk.java.net/jdk/pull/487/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=487&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253944 Stats: 158 lines in 5 files changed: 125 ins; 13 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/487.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/487/head:pull/487 PR: https://git.openjdk.java.net/jdk/pull/487 From mcimadamore at openjdk.java.net Fri Oct 2 20:28:38 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 2 Oct 2020 20:28:38 GMT Subject: RFR: 8253944: Certain method references to VarHandle methods should fail In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 17:38:19 GMT, Paul Sandoz wrote: > A regression was introduced in javac when processing method references to signature polymorphic methods whose return > type is not polymorphic. > It is possible to successfully target type a method reference for a VarHandle sig-poly method to a functional interface > whose methods return type is incompatible with the VarHandle method. This results in a runtime linkage error rather > than a source compile time error. See the following email thread for more details: > > https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015088.html > > The fix is to "patch-back" the method's return type if it is not polymorphic. As a result it was possible to simplify > the inference logic and keep it focused more on inference. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/487 From maurizio.cimadamore at oracle.com Fri Oct 2 20:48:14 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 2 Oct 2020 21:48:14 +0100 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> Message-ID: <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> Hi Bernard, since there's not a lot of rush for getting this one in, I'd suggest it maybe better for you to spend time to get acquainted with the new process? For instance, I don't think we can "push on your behalf" (like we could e.g. on mercurial if you provided a commit patch); the best we could do I think would be to list you as a contributor. Let me know how you want to proceed. My sense is that you'd have to do it sooner or later, so this might be as a good bug as any other :-) Maurizio On 02/10/2020 18:10, B. Blaser wrote: > Thanks for the confirmation, Maurizio. > > Being still not up-to-date with the new git work-flow, could someone > help pushing it on my behalf? > > Cheers, > Bernard > > On Fri, 2 Oct 2020 at 18:47, Maurizio Cimadamore > wrote: >> I agree that seems to be a discrepancy from what the JLS is saying (and, >> I believe even from what earlier javac versions were doing - e.g. prior >> to 8). >> >> I tried this in Java 7 and this returned: >> >> foo.java:3: error: non-static method test(double) cannot be referenced >> from a static context >> test(5.0); >> ^ >> >> as expected. >> >> Maurizio >> >> On 02/10/2020 14:50, B. Blaser wrote: >>> Hi, >>> >>> Consider the following example from JDK-8238213: >>> >>> public class JavacBrokenError { >>> public static void main(String[] args) { >>> test(5.0); >>> } >>> >>> void test(double d) {} >>> /* static */ void test(Double d) {} >>> } >>> >>> It seems that javac correctly finds 'test(double)' during the strict >>> resolution phase (?15.12.2.2) but doesn't stop with a static error as >>> mandated by ?15.12.3 and continues with the loose resolution phase >>> (?15.12.2.3) which ends up wrongly with the ambiguous error instead. >>> >>> The following fix addresses this on jdk14u (langtools:tier1 is OK): >>> >>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java >>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java >>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java >>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java >>> @@ -3283,7 +3283,7 @@ >>> */ >>> final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) { >>> return phase.ordinal() > maxPhase.ordinal() || >>> - !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS; >>> + !sym.kind.isResolutionError() || sym.kind == >>> AMBIGUOUS || sym.kind == STATICERR; >>> } >>> >>> /** >>> >>> On jdk16, see: >>> >>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/b8966e1f7bfa2408f0e5330ac310526dd5c3cb2d/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java*L3310__;Iw!!GqivPVa7Brio!Kd_zf6Yom6G_TjVtH616SxZrclJ6cb8iAX_1E06X_s5ksEm5wZ_LG59TXuX-BFSqExB0DV0$ >>> >>> What do you think? >>> >>> Thanks, >>> Bernard From hive7003 at outlook.com Sat Oct 3 11:03:56 2020 From: hive7003 at outlook.com (Zi Xin) Date: Sat, 3 Oct 2020 11:03:56 +0000 Subject: [sealed][15] javac rejects type parameters extending intersection sealed types Message-ID: Hello! The following code does not compile on openjdk 15 GA: sealed interface Up permits DownImpl { T foo(); } sealed interface Aux0 permits Ver1 { } sealed interface Sti1 permits Ver1 { } sealed abstract class Asc3 permits Ver1 { } interface Open { } final class Ver1 extends Asc3 implements Aux0, Sti1 { } final class Fin2 {} final class DownImpl implements Up { @Override //sealed1 & sealed2 public T foo() { return null; } //sealed2 & sealed1 public static void bar() {} //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected //sealed2 & non-sealed public static void baz() {} //non-sealed & sealed1 public static void thud() {} //sealed abstract & non-sealed public static void qux() {} //sealed abstract & sealed1 public static void corge() {} //sealed abstract & non-sealed public static void waldo() {} // //non-sealed & sealed abstract // public static void grault() {} //should not pass //sealed2 public static T passed_2() { return null; } } //sealed1 class Parameterized { } // passed! //sealed1 & sealed2 class ParameterizedIntersect { } -------------------------------------------------------------- javac displays following errors: IssueErr.java:4: error: class is not allowed to extend sealed class: Aux0 T foo(); ^ IssueErr.java:22: error: class is not allowed to extend sealed class: Aux0 public T foo() { ^ IssueErr.java:27: error: class is not allowed to extend sealed class: Sti1 public static void bar() {} ^ IssueErr.java:31: error: class is not allowed to extend sealed class: Sti1 public static void baz() {} ^ IssueErr.java:34: error: class is not allowed to extend sealed class: Aux0 public static void thud() {} ^ IssueErr.java:37: error: class is not allowed to extend sealed class: Asc3 public static void qux() {} ^ IssueErr.java:40: error: class is not allowed to extend sealed class: Asc3 public static void corge() {} ^ IssueErr.java:43: error: class is not allowed to extend sealed class: Asc3 public static void waldo() {} ^ IssueErr.java:57: error: class is not allowed to extend sealed class: Aux0 class ParameterizedIntersect { } ^ Note: IssueErr.java uses preview language features. Note: Recompile with -Xlint:preview for details. 9 errors Process finished with exit code 1 --------------------------------- I would expect that the code compiles since a final class name may be used in type bound declarations [1]. IMO the same goes for sealed classes. And I couldn't find any topic on it in the spec[2][3] or JEP[4]. Is it an implementation oversight or a spec issue? Best regards, Zhou Zi-yan [1] final class FinalV1 {} class Pa1 {} [2] https://docs.oracle.com/javase/specs/jls/se15/jls15.pdf [3] https://docs.oracle.com/javase/specs/jls/se15/preview/specs/sealed-classes-jls.html [4] http://openjdk.java.net/jeps/360 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsrbnd at gmail.com Sat Oct 3 13:52:28 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 3 Oct 2020 15:52:28 +0200 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> Message-ID: Hi Maurizio, I'm currently really too busy to integrate the new git process, other imperatives coming first. So, the best I can do is to postpone this wonderful fix ;-) to a subsequent version (TBD). But, if you need it impatiently to 16 (or so), feel free to push it at your convenience and simply list me as a contributor. Ciao, Bernard On Fri, 2 Oct 2020 at 22:48, Maurizio Cimadamore wrote: > > Hi Bernard, > since there's not a lot of rush for getting this one in, I'd suggest it > maybe better for you to spend time to get acquainted with the new > process? For instance, I don't think we can "push on your behalf" (like > we could e.g. on mercurial if you provided a commit patch); the best we > could do I think would be to list you as a contributor. > > Let me know how you want to proceed. My sense is that you'd have to do > it sooner or later, so this might be as a good bug as any other :-) > > Maurizio From alanb at openjdk.java.net Sun Oct 4 08:44:38 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 4 Oct 2020 08:44:38 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 14:41:59 GMT, Weijun Wang wrote: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Changes requested by alanb (Reviewer). test/lib/jdk/test/lib/util/JarUtils.java line 90: > 88: String name = toJarEntryName(entry); > 89: jos.putNextEntry(new JarEntry(name)); > 90: if (Files.exists(dir.resolve(entry))) { This is test infrastructure that we use in several areas and changing it to allow file paths to files that don't exist be problematic. Is there any reason why the jarsigner can't create an empty or dummy file to put into the JAR file? ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Sun Oct 4 13:34:38 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 4 Oct 2020 13:34:38 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 08:41:28 GMT, Alan Bateman wrote: >> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: >> >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >> >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature >> algorithms >> >> - A new JarSigner property "directsign" >> >> - Updating the jarsigner tool doc >> >> Major code changes: >> >> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm >> there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. >> >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > test/lib/jdk/test/lib/util/JarUtils.java line 90: > >> 88: String name = toJarEntryName(entry); >> 89: jos.putNextEntry(new JarEntry(name)); >> 90: if (Files.exists(dir.resolve(entry))) { > > This is test infrastructure that we use in several areas and changing it to allow file paths to files that don't exist > be problematic. Is there any reason why the jarsigner can't create an empty or dummy file to put into the JAR file? Sorry, I'll revert the change and create files myself. I just thought any existing call to this method should have the file already created there, but it could be a problem if the creation is not trivial and might fail. ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Sun Oct 4 14:02:49 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 4 Oct 2020 14:02:49 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v2] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - extract some methods, rollback JarUtils, deperated version from 15 to 16. - Merge - 8242068: Signed JAR support for RSASSA-PSS and EdDSA ------------- Changes: https://git.openjdk.java.net/jdk/pull/322/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=01 Stats: 1696 lines in 21 files changed: 972 ins; 555 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Sun Oct 4 14:09:48 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 4 Oct 2020 14:09:48 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v3] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: extract some methods, rollback JarUtils, deprecated version from 15 to 16. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/322/files - new: https://git.openjdk.java.net/jdk/pull/322/files/c05af70a..5d455bae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Sun Oct 4 14:12:37 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 4 Oct 2020 14:12:37 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v3] In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 08:41:40 GMT, Alan Bateman wrote: >> Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > Changes requested by alanb (Reviewer). Note: I force pushed a new commit to correct a typo in the summary line. ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Sun Oct 4 17:29:50 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sun, 4 Oct 2020 17:29:50 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v4] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: fotgot to read one property ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/322/files - new: https://git.openjdk.java.net/jdk/pull/322/files/5d455bae..fecf30d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=02-03 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From amaembo at gmail.com Mon Oct 5 05:06:57 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 5 Oct 2020 12:06:57 +0700 Subject: [sealed][15] javac rejects type parameters extending intersection sealed types In-Reply-To: References: Message-ID: Hello! > //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected Should be fixed in 2020.3 EAP, please check. With best regards, Tagir Valeev. On Sat, Oct 3, 2020 at 6:04 PM Zi Xin wrote: > > Hello! > > The following code does not compile on openjdk 15 GA: > > > sealed interface Up permits DownImpl { > T foo(); > } > > sealed interface Aux0 permits Ver1 { } > > sealed interface Sti1 permits Ver1 { } > > sealed abstract class Asc3 permits Ver1 { } > > interface Open { } > > final class Ver1 extends Asc3 implements Aux0, Sti1 { } > > final class Fin2 {} > > final class DownImpl implements Up { > @Override > //sealed1 & sealed2 > public T foo() { > return null; > } > > //sealed2 & sealed1 > public static void bar() {} > //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected > > //sealed2 & non-sealed > public static void baz() {} > > //non-sealed & sealed1 > public static void thud() {} > > //sealed abstract & non-sealed > public static void qux() {} > > //sealed abstract & sealed1 > public static void corge() {} > > //sealed abstract & non-sealed > public static void waldo() {} > > // //non-sealed & sealed abstract > // public static void grault() {} //should not pass > > //sealed2 > public static T passed_2() { > return null; > } > } > > //sealed1 > class Parameterized { } // passed! > //sealed1 & sealed2 > class ParameterizedIntersect { } > > -------------------------------------------------------------- > > javac displays following errors: > > IssueErr.java:4: error: class is not allowed to extend sealed class: Aux0 > T foo(); > ^ > IssueErr.java:22: error: class is not allowed to extend sealed class: Aux0 > public T foo() { > ^ > IssueErr.java:27: error: class is not allowed to extend sealed class: Sti1 > public static void bar() {} > ^ > IssueErr.java:31: error: class is not allowed to extend sealed class: Sti1 > public static void baz() {} > ^ > IssueErr.java:34: error: class is not allowed to extend sealed class: Aux0 > public static void thud() {} > ^ > IssueErr.java:37: error: class is not allowed to extend sealed class: Asc3 > public static void qux() {} > ^ > IssueErr.java:40: error: class is not allowed to extend sealed class: Asc3 > public static void corge() {} > ^ > IssueErr.java:43: error: class is not allowed to extend sealed class: Asc3 > public static void waldo() {} > ^ > IssueErr.java:57: error: class is not allowed to extend sealed class: Aux0 > class ParameterizedIntersect { } > ^ > Note: IssueErr.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > 9 errors > > Process finished with exit code 1 > > --------------------------------- > > I would expect that the code compiles since a final class name may be used in type bound declarations [1]. IMO the same goes for sealed classes. > And I couldn't find any topic on it in the spec[2][3] or JEP[4]. > Is it an implementation oversight or a spec issue? > > Best regards, > Zhou Zi-yan > > > [1] > final class FinalV1 {} > class Pa1 {} > [2] https://docs.oracle.com/javase/specs/jls/se15/jls15.pdf > [3] https://docs.oracle.com/javase/specs/jls/se15/preview/specs/sealed-classes-jls.html > [4] http://openjdk.java.net/jeps/360 From maurizio.cimadamore at oracle.com Mon Oct 5 09:58:35 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 5 Oct 2020 10:58:35 +0100 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> Message-ID: <1f3e1785-61da-725a-f0df-5b33d860f3bd@oracle.com> Thanks - I've reset the fix version field and reassigned to Vicente - he can perhaps take a look and see what needs to be done to integrate this (this is an area where we would at least need some good testing coverage, perhaps by using the overload test framework that was put in few years ago - see [1] for an example). Maurizio [1] - https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/resolve/tests/InnerOverOuter.java On 03/10/2020 14:52, B. Blaser wrote: > Hi Maurizio, > > I'm currently really too busy to integrate the new git process, other > imperatives coming first. > So, the best I can do is to postpone this wonderful fix ;-) to a > subsequent version (TBD). > But, if you need it impatiently to 16 (or so), feel free to push it at > your convenience and simply list me as a contributor. > > Ciao, > Bernard > > On Fri, 2 Oct 2020 at 22:48, Maurizio Cimadamore > wrote: >> Hi Bernard, >> since there's not a lot of rush for getting this one in, I'd suggest it >> maybe better for you to spend time to get acquainted with the new >> process? For instance, I don't think we can "push on your behalf" (like >> we could e.g. on mercurial if you provided a commit patch); the best we >> could do I think would be to list you as a contributor. >> >> Let me know how you want to proceed. My sense is that you'd have to do >> it sooner or later, so this might be as a good bug as any other :-) >> >> Maurizio From psandoz at openjdk.java.net Mon Oct 5 17:18:45 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 5 Oct 2020 17:18:45 GMT Subject: Integrated: 8253944: Certain method references to VarHandle methods should fail In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 17:38:19 GMT, Paul Sandoz wrote: > A regression was introduced in javac when processing method references to signature polymorphic methods whose return > type is not polymorphic. > It is possible to successfully target type a method reference for a VarHandle sig-poly method to a functional interface > whose methods return type is incompatible with the VarHandle method. This results in a runtime linkage error rather > than a source compile time error. See the following email thread for more details: > > https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015088.html > > The fix is to "patch-back" the method's return type if it is not polymorphic. As a result it was possible to simplify > the inference logic and keep it focused more on inference. This pull request has now been integrated. Changeset: b29e1086 Author: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/b29e1086 Stats: 158 lines in 5 files changed: 125 ins; 13 del; 20 mod 8253944: Certain method references to VarHandle methods should fail Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/487 From hive7003 at outlook.com Tue Oct 6 07:22:08 2020 From: hive7003 at outlook.com (Zi Xin) Date: Tue, 6 Oct 2020 07:22:08 +0000 Subject: =?gb2312?B?u9i4tDogW3NlYWxlZF1bMTVdIGphdmFjIHJlamVjdHMgdHlwZSBwYXJhbWV0?= =?gb2312?Q?ers_extending_intersection_sealed_types?= In-Reply-To: References: , Message-ID: I see, thanks. Best Regards, Zhou Zi-yan ???: Tagir Valeev ????: 2020?10?5? 13:07 ???: Zi Xin ??: amber-dev at openjdk.java.net; compiler-dev at openjdk.java.net ??: Re: [sealed][15] javac rejects type parameters extending intersection sealed types Hello! > //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected Should be fixed in 2020.3 EAP, please check. With best regards, Tagir Valeev. On Sat, Oct 3, 2020 at 6:04 PM Zi Xin wrote: > > Hello! > > The following code does not compile on openjdk 15 GA: > > > sealed interface Up permits DownImpl { > T foo(); > } > > sealed interface Aux0 permits Ver1 { } > > sealed interface Sti1 permits Ver1 { } > > sealed abstract class Asc3 permits Ver1 { } > > interface Open { } > > final class Ver1 extends Asc3 implements Aux0, Sti1 { } > > final class Fin2 {} > > final class DownImpl implements Up { > @Override > //sealed1 & sealed2 > public T foo() { > return null; > } > > //sealed2 & sealed1 > public static void bar() {} > //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected > > //sealed2 & non-sealed > public static void baz() {} > > //non-sealed & sealed1 > public static void thud() {} > > //sealed abstract & non-sealed > public static void qux() {} > > //sealed abstract & sealed1 > public static void corge() {} > > //sealed abstract & non-sealed > public static void waldo() {} > > // //non-sealed & sealed abstract > // public static void grault() {} //should not pass > > //sealed2 > public static T passed_2() { > return null; > } > } > > //sealed1 > class Parameterized { } // passed! > //sealed1 & sealed2 > class ParameterizedIntersect { } > > -------------------------------------------------------------- > > javac displays following errors: > > IssueErr.java:4: error: class is not allowed to extend sealed class: Aux0 > T foo(); > ^ > IssueErr.java:22: error: class is not allowed to extend sealed class: Aux0 > public T foo() { > ^ > IssueErr.java:27: error: class is not allowed to extend sealed class: Sti1 > public static void bar() {} > ^ > IssueErr.java:31: error: class is not allowed to extend sealed class: Sti1 > public static void baz() {} > ^ > IssueErr.java:34: error: class is not allowed to extend sealed class: Aux0 > public static void thud() {} > ^ > IssueErr.java:37: error: class is not allowed to extend sealed class: Asc3 > public static void qux() {} > ^ > IssueErr.java:40: error: class is not allowed to extend sealed class: Asc3 > public static void corge() {} > ^ > IssueErr.java:43: error: class is not allowed to extend sealed class: Asc3 > public static void waldo() {} > ^ > IssueErr.java:57: error: class is not allowed to extend sealed class: Aux0 > class ParameterizedIntersect { } > ^ > Note: IssueErr.java uses preview language features. > Note: Recompile with -Xlint:preview for details. > 9 errors > > Process finished with exit code 1 > > --------------------------------- > > I would expect that the code compiles since a final class name may be used in type bound declarations [1]. IMO the same goes for sealed classes. > And I couldn't find any topic on it in the spec[2][3] or JEP[4]. > Is it an implementation oversight or a spec issue? > > Best regards, > Zhou Zi-yan > > > [1] > final class FinalV1 {} > class Pa1 {} > [2] https://docs.oracle.com/javase/specs/jls/se15/jls15.pdf > [3] https://docs.oracle.com/javase/specs/jls/se15/preview/specs/sealed-classes-jls.html > [4] http://openjdk.java.net/jeps/360 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hive7003 at outlook.com Tue Oct 6 07:34:02 2020 From: hive7003 at outlook.com (Zi Xin) Date: Tue, 6 Oct 2020 07:34:02 +0000 Subject: [sealed][16ea] type parameter can't extend intersection type including sealed classses In-Reply-To: References: Message-ID: The problem continues on OpenJDK 16 EA+18-901, windows build IssueErr.java:4: error: class is not allowed to extend sealed class: Aux0 (as it is not listed in its permits clause) T foo(); ^ IssueErr.java:22: error: class is not allowed to extend sealed class: Aux0 (as it is not listed in its permits clause) public T foo() { ^ IssueErr.java:27: error: class is not allowed to extend sealed class: Sti1 (as it is not listed in its permits clause) public static void bar() {} ^ IssueErr.java:30: error: class is not allowed to extend sealed class: Sti1 (as it is not listed in its permits clause) public static void baz() {} ^ IssueErr.java:33: error: class is not allowed to extend sealed class: Aux0 (as it is not listed in its permits clause) public static void thud() {} ^ IssueErr.java:36: error: class is not allowed to extend sealed class: Asc3 (as it is not listed in its permits clause) public static void qux() {} ^ IssueErr.java:39: error: class is not allowed to extend sealed class: Asc3 (as it is not listed in its permits clause) public static void corge() {} ^ IssueErr.java:56: error: class is not allowed to extend sealed class: Aux0 (as it is not listed in its permits clause) class ParameterizedIntersect { } ^ IssueErr.java uses preview language features. Note: Recompile with -Xlint:preview for details. 8 errors Best regards, Zhou Zi-yan ???: Zi Xin ????: 2020?10?3? 19:04 ???: amber-dev at openjdk.java.net; compiler-dev at openjdk.java.net ??: [sealed][15] javac rejects type parameters extending intersection sealed types Hello! The following code does not compile on openjdk 15 GA: sealed interface Up permits DownImpl { T foo(); } sealed interface Aux0 permits Ver1 { } sealed interface Sti1 permits Ver1 { } sealed abstract class Asc3 permits Ver1 { } interface Open { } final class Ver1 extends Asc3 implements Aux0, Sti1 { } final class Fin2 {} final class DownImpl implements Up { @Override //sealed1 & sealed2 public T foo() { return null; } //sealed2 & sealed1 public static void bar() {} //Intellij 2020.2: "<'T' exte": sealed non-sealed or final modifiers expected //sealed2 & non-sealed public static void baz() {} //non-sealed & sealed1 public static void thud() {} //sealed abstract & non-sealed public static void qux() {} //sealed abstract & sealed1 public static void corge() {} //sealed abstract & non-sealed public static void waldo() {} // //non-sealed & sealed abstract // public static void grault() {} //should not pass //sealed2 public static T passed_2() { return null; } } //sealed1 class Parameterized { } // passed! //sealed1 & sealed2 class ParameterizedIntersect { } -------------------------------------------------------------- javac displays following errors: IssueErr.java:4: error: class is not allowed to extend sealed class: Aux0 T foo(); ^ IssueErr.java:22: error: class is not allowed to extend sealed class: Aux0 public T foo() { ^ IssueErr.java:27: error: class is not allowed to extend sealed class: Sti1 public static void bar() {} ^ IssueErr.java:31: error: class is not allowed to extend sealed class: Sti1 public static void baz() {} ^ IssueErr.java:34: error: class is not allowed to extend sealed class: Aux0 public static void thud() {} ^ IssueErr.java:37: error: class is not allowed to extend sealed class: Asc3 public static void qux() {} ^ IssueErr.java:40: error: class is not allowed to extend sealed class: Asc3 public static void corge() {} ^ IssueErr.java:43: error: class is not allowed to extend sealed class: Asc3 public static void waldo() {} ^ IssueErr.java:57: error: class is not allowed to extend sealed class: Aux0 class ParameterizedIntersect { } ^ Note: IssueErr.java uses preview language features. Note: Recompile with -Xlint:preview for details. 9 errors Process finished with exit code 1 --------------------------------- I would expect that the code compiles since a final class name may be used in type bound declarations [1]. IMO the same goes for sealed classes. And I couldn't find any topic on it in the spec[2][3] or JEP[4]. Is it an implementation oversight or a spec issue? Best regards, Zhou Zi-yan [1] final class FinalV1 {} class Pa1 {} [2] https://docs.oracle.com/javase/specs/jls/se15/jls15.pdf [3] https://docs.oracle.com/javase/specs/jls/se15/preview/specs/sealed-classes-jls.html [4] http://openjdk.java.net/jeps/360 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.java.net Tue Oct 6 14:07:15 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 6 Oct 2020 14:07:15 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) Message-ID: This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was reverted. This revision contains the changes of that pull request plus: diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { * * Thus, to find the source position of any position, p, in the comment * string, find the index, i, of the pair whose string offset - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + + * (p - map[i * NOFFSETS + SB_OFFSET]) }. */ static class OffsetMap { /** @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { int start = 0; int end = size / NOFFSETS; - while (start < end - NOFFSETS) { + while (start < end - 1) { // find an index midway between start and end int index = (start + end) / 2; int indexScaled = index * NOFFSETS; diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java @@ -221,48 +221,49 @@ public class UnicodeReader { private boolean unicodeEscape() { // Start of unicode escape (past backslash.) int start = position + width; - int index; + + // Default to backslash result, unless proven otherwise. + character = '\'; + width = 1; // Skip multiple 'u'. + int index; for (index = start; index < length; index++) { if (buffer[index] != 'u') { break; } } - // Needs to be at least backslash-u. - if (index != start) { - // If enough characters available. - if (index + 4 < length) { - // Convert four hex digits to codepoint. If any digit is invalid then the - // result is negative. - int code = (Character.digit(buffer[index++], 16) << 12) | - (Character.digit(buffer[index++], 16) << 8) | - (Character.digit(buffer[index++], 16) << 4) | - Character.digit(buffer[index++], 16); - - // If all digits are good. - if (code >= 0) { - width = index - position; - character = (char)code; - - return true; - } - } + // Needs to have been at least one u. + if (index == start) { + return false; + } - // Did not work out. - log.error(position, Errors.IllegalUnicodeEsc); - width = index - position; + int code = 0; - // Return true so that the invalid unicode escape is skipped. - return true; + for (int i = 0; i < 4; i++) { + int digit = Character.digit(buffer[index], 16); + code = code << 4 | digit; + + if (code < 0) { + break; + } + + index++; } - // Must be just a backslash. - character = '\'; - width = 1; + // Skip digits even if error. + width = index - position; - return false; + // If all digits are good. + if (code >= 0) { + character = (char)code; + } else { + log.error(position, Errors.IllegalUnicodeEsc); + } + + // Return true even if error so that the invalid unicode escape is skipped. + return true; } /** @@ -549,7 +550,7 @@ public class UnicodeReader { /** * Offset from the beginning of the original reader buffer. */ - private int offset; + final private int offset; /** * Current column in the comment. ------------- Commit messages: - Merge branch 'master' into 8254073 - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) Changes: https://git.openjdk.java.net/jdk/pull/525/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254073 Stats: 2349 lines in 18 files changed: 1115 ins; 597 del; 637 mod Patch: https://git.openjdk.java.net/jdk/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/525/head:pull/525 PR: https://git.openjdk.java.net/jdk/pull/525 From mcimadamore at openjdk.java.net Tue Oct 6 14:41:07 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Oct 2020 14:41:07 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:01:11 GMT, Jim Laskey wrote: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 245: > 243: > 244: for (int i = 0; i < 4; i++) { > 245: int digit = Character.digit(buffer[index], 16); This looks suspicious - what if index ends up being bigger than (or equal to) `buffer.length` ? Maybe we need a test for incomplete unicode sequences at the end of the tokenizer input - e.g. `\u123` ------------- PR: https://git.openjdk.java.net/jdk/pull/525 From jlaskey at openjdk.java.net Tue Oct 6 15:01:08 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 6 Oct 2020 15:01:08 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:37:32 GMT, Maurizio Cimadamore wrote: >> This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was >> reverted. >> This revision contains the changes of that pull request plus: >> >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { >> * >> * Thus, to find the source position of any position, p, in the comment >> * string, find the index, i, of the pair whose string offset >> - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, >> - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. >> + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater >> + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + >> + * (p - map[i * NOFFSETS + SB_OFFSET]) }. >> */ >> static class OffsetMap { >> /** >> @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { >> int start = 0; >> int end = size / NOFFSETS; >> >> - while (start < end - NOFFSETS) { >> + while (start < end - 1) { >> // find an index midway between start and end >> int index = (start + end) / 2; >> int indexScaled = index * NOFFSETS; >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> @@ -221,48 +221,49 @@ public class UnicodeReader { >> private boolean unicodeEscape() { >> // Start of unicode escape (past backslash.) >> int start = position + width; >> - int index; >> + >> + // Default to backslash result, unless proven otherwise. >> + character = '\'; >> + width = 1; >> >> // Skip multiple 'u'. >> + int index; >> for (index = start; index < length; index++) { >> if (buffer[index] != 'u') { >> break; >> } >> } >> >> - // Needs to be at least backslash-u. >> - if (index != start) { >> - // If enough characters available. >> - if (index + 4 < length) { >> - // Convert four hex digits to codepoint. If any digit is invalid then the >> - // result is negative. >> - int code = (Character.digit(buffer[index++], 16) << 12) | >> - (Character.digit(buffer[index++], 16) << 8) | >> - (Character.digit(buffer[index++], 16) << 4) | >> - Character.digit(buffer[index++], 16); >> - >> - // If all digits are good. >> - if (code >= 0) { >> - width = index - position; >> - character = (char)code; >> - >> - return true; >> - } >> - } >> + // Needs to have been at least one u. >> + if (index == start) { >> + return false; >> + } >> >> - // Did not work out. >> - log.error(position, Errors.IllegalUnicodeEsc); >> - width = index - position; >> + int code = 0; >> >> - // Return true so that the invalid unicode escape is skipped. >> - return true; >> + for (int i = 0; i < 4; i++) { >> + int digit = Character.digit(buffer[index], 16); >> + code = code << 4 | digit; >> + >> + if (code < 0) { >> + break; >> + } >> + >> + index++; >> } >> >> - // Must be just a backslash. >> - character = '\'; >> - width = 1; >> + // Skip digits even if error. >> + width = index - position; >> >> - return false; >> + // If all digits are good. >> + if (code >= 0) { >> + character = (char)code; >> + } else { >> + log.error(position, Errors.IllegalUnicodeEsc); >> + } >> + >> + // Return true even if error so that the invalid unicode escape is skipped. >> + return true; >> } >> >> /** >> @@ -549,7 +550,7 @@ public class UnicodeReader { >> /** >> * Offset from the beginning of the original reader buffer. >> */ >> - private int offset; >> + final private int offset; >> >> /** >> * Current column in the comment. > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 245: > >> 243: >> 244: for (int i = 0; i < 4; i++) { >> 245: int digit = Character.digit(buffer[index], 16); > > This looks suspicious - what if index ends up being bigger than (or equal to) `buffer.length` ? > Maybe we need a test for incomplete unicode sequences at the end of the tokenizer input - e.g. `\u123` You are correct. Will revise. ------------- PR: https://git.openjdk.java.net/jdk/pull/525 From jjg at openjdk.java.net Tue Oct 6 15:50:07 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 6 Oct 2020 15:50:07 GMT Subject: RFR: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 12:40:07 GMT, Jan Lahoda wrote: > @rwestberg prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for > Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the > testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548 > I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the > test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b) improve > ToolBox to check and reject file names that are reserved. Note that testHelloWorldWithAux uses the name "Aux" > intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I > believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in > memory, and won't be written as a file, so will not cause the issue. The use of name "Aux" in the > testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing > the actual test, so it seems fine to change the name. @jonathan-gibbons, could you please take a look? Thanks! Marked as reviewed by jjg (Reviewer). test/langtools/tools/lib/toolbox/ToolBox.java line 729: > 727: } > 728: } > 729: } nice ------------- PR: https://git.openjdk.java.net/jdk/pull/456 From jjg at openjdk.java.net Tue Oct 6 15:50:07 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 6 Oct 2020 15:50:07 GMT Subject: RFR: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 00:25:15 GMT, Kumar Srinivasan wrote: >> @rwestberg prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for >> Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the >> testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548 >> I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the >> test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b) improve >> ToolBox to check and reject file names that are reserved. Note that testHelloWorldWithAux uses the name "Aux" >> intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I >> believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in >> memory, and won't be written as a file, so will not cause the issue. The use of name "Aux" in the >> testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing >> the actual test, so it seems fine to change the name. @jonathan-gibbons, could you please take a look? Thanks! > > Hi Jan, thanks for the summary, that was my take as well, when I observed this issue. After reading Robin's > evaluation, I now understand why we discovered this problem at VMware, I am using "jtreg -xml:verify ....." which > produces the right results in Jenkins. I will let Jon approve this, I am ok with the fix. I like the changes to `ToolBox`, but I am concerned that we do not understand why the problem has not shown up before. I get that @rwestberg has added new ways to run tests, but we've been running this test on Windows internally within Oracle for a long time now. I guess maybe it could be a characteristic of the underlying (version of) the OS and/or file system. ------------- PR: https://git.openjdk.java.net/jdk/pull/456 From jlaskey at openjdk.java.net Tue Oct 6 19:05:23 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 6 Oct 2020 19:05:23 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v2] In-Reply-To: References: Message-ID: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: 8254073: Tokenizer improvements (revised) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/525/files - new: https://git.openjdk.java.net/jdk/pull/525/files/0879e7b4..6d6b3eec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=00-01 Stats: 178 lines in 2 files changed: 177 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/525/head:pull/525 PR: https://git.openjdk.java.net/jdk/pull/525 From jlaskey at openjdk.java.net Tue Oct 6 19:05:23 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 6 Oct 2020 19:05:23 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v2] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:58:18 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 245: >> >>> 243: >>> 244: for (int i = 0; i < 4; i++) { >>> 245: int digit = Character.digit(buffer[index], 16); >> >> This looks suspicious - what if index ends up being bigger than (or equal to) `buffer.length` ? >> Maybe we need a test for incomplete unicode sequences at the end of the tokenizer input - e.g. `\u123` > > You are correct. Will revise. Added change to int digit = index < length ? Character.digit(buffer[index], 16) : -1; Also added new test. ------------- PR: https://git.openjdk.java.net/jdk/pull/525 From mcimadamore at openjdk.java.net Tue Oct 6 20:52:08 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Oct 2020 20:52:08 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v2] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 19:05:23 GMT, Jim Laskey wrote: >> This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was >> reverted. >> This revision contains the changes of that pull request plus: >> >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { >> * >> * Thus, to find the source position of any position, p, in the comment >> * string, find the index, i, of the pair whose string offset >> - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, >> - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. >> + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater >> + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + >> + * (p - map[i * NOFFSETS + SB_OFFSET]) }. >> */ >> static class OffsetMap { >> /** >> @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { >> int start = 0; >> int end = size / NOFFSETS; >> >> - while (start < end - NOFFSETS) { >> + while (start < end - 1) { >> // find an index midway between start and end >> int index = (start + end) / 2; >> int indexScaled = index * NOFFSETS; >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> @@ -221,48 +221,49 @@ public class UnicodeReader { >> private boolean unicodeEscape() { >> // Start of unicode escape (past backslash.) >> int start = position + width; >> - int index; >> + >> + // Default to backslash result, unless proven otherwise. >> + character = '\'; >> + width = 1; >> >> // Skip multiple 'u'. >> + int index; >> for (index = start; index < length; index++) { >> if (buffer[index] != 'u') { >> break; >> } >> } >> >> - // Needs to be at least backslash-u. >> - if (index != start) { >> - // If enough characters available. >> - if (index + 4 < length) { >> - // Convert four hex digits to codepoint. If any digit is invalid then the >> - // result is negative. >> - int code = (Character.digit(buffer[index++], 16) << 12) | >> - (Character.digit(buffer[index++], 16) << 8) | >> - (Character.digit(buffer[index++], 16) << 4) | >> - Character.digit(buffer[index++], 16); >> - >> - // If all digits are good. >> - if (code >= 0) { >> - width = index - position; >> - character = (char)code; >> - >> - return true; >> - } >> - } >> + // Needs to have been at least one u. >> + if (index == start) { >> + return false; >> + } >> >> - // Did not work out. >> - log.error(position, Errors.IllegalUnicodeEsc); >> - width = index - position; >> + int code = 0; >> >> - // Return true so that the invalid unicode escape is skipped. >> - return true; >> + for (int i = 0; i < 4; i++) { >> + int digit = Character.digit(buffer[index], 16); >> + code = code << 4 | digit; >> + >> + if (code < 0) { >> + break; >> + } >> + >> + index++; >> } >> >> - // Must be just a backslash. >> - character = '\'; >> - width = 1; >> + // Skip digits even if error. >> + width = index - position; >> >> - return false; >> + // If all digits are good. >> + if (code >= 0) { >> + character = (char)code; >> + } else { >> + log.error(position, Errors.IllegalUnicodeEsc); >> + } >> + >> + // Return true even if error so that the invalid unicode escape is skipped. >> + return true; >> } >> >> /** >> @@ -549,7 +550,7 @@ public class UnicodeReader { >> /** >> * Offset from the beginning of the original reader buffer. >> */ >> - private int offset; >> + final private int offset; >> >> /** >> * Current column in the comment. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > 8254073: Tokenizer improvements (revised) Looks good - I've added optional suggestions for the test test/langtools/tools/javac/lexer/JavaLexerTest2.java line 50: > 48: public class JavaLexerTest2 { > 49: static final TestTuple[] TESTS = { > 50: new TestTuple("0bL", LONGLITERAL, true), Stylistic (optional) comment - we could have a common TestTuple superclass and two subclasses called Success and Failure, so that, by looking at the TESTS array it will be apparent what the behavior should be test/langtools/tools/javac/lexer/JavaLexerTest2.java line 110: > 108: boolean willFail; > 109: > 110: TestTuple(String input, TokenKind kind, String expected, boolean willFail) { Is anything using this? test/langtools/tools/javac/lexer/JavaLexerTest2.java line 48: > 46: import static com.sun.tools.javac.parser.Tokens.TokenKind.*; > 47: > 48: public class JavaLexerTest2 { Should we merge JavaLexerTest and this one? After all you have all the required infra in here? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/525 From jlahoda at openjdk.java.net Wed Oct 7 06:56:08 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Oct 2020 06:56:08 GMT Subject: Integrated: 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 12:40:07 GMT, Jan Lahoda wrote: > @rwestberg prepared a script that runs various tests in GitHub Actions. But, sadly, with a recently proposed fix for > Windows handling (see https://github.com/openjdk/jdk/pull/437), the SourceLauncherTest is failing (the > testNoSourceOnClassPath sub-test): https://github.com/rwestberg/jdk/runs/1188397548 > I don't think this has much to do with javac (or source launcher) itself - the test fails while it tries to write the > test source file, before the source launcher is invoked. So this patch tries to: a) avoid doing that; b) improve > ToolBox to check and reject file names that are reserved. Note that testHelloWorldWithAux uses the name "Aux" > intentionally, and it passes because it never actually writes file with name "Aux" - the source file will be (I > believe) named "HelloWorld", and while it will contain also a class named "Aux", the classfile will only ever exist in > memory, and won't be written as a file, so will not cause the issue. The use of name "Aux" in the > testNoSourceOnClassPath test does not seem to be necessary, and the issue happens in the test set-up, not while doing > the actual test, so it seems fine to change the name. @jonathan-gibbons, could you please take a look? Thanks! This pull request has now been integrated. Changeset: cd4faff0 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/cd4faff0 Stats: 29 lines in 2 files changed: 21 ins; 0 del; 8 mod 8249095: tools/javac/launcher/SourceLauncherTest.java fails on Windows Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/456 From hannesw at openjdk.java.net Wed Oct 7 12:42:32 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 7 Oct 2020 12:42:32 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v4] In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes Hannes Walln?fer 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: - Fix test failure - Merge branch 'master' into JDK-8216497 - Rename --no-platform-link option plus minor cleanup - Merge pull request #1 from lahodaj/JDK-8216497 Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under development - Generating current release list for javadoc; using hardcoded lists for versions < 11 - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data. - 8216497: javadoc should auto-link to platform classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/6009dd70..991daef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=02-03 Stats: 69874 lines in 2995 files changed: 23958 ins; 34697 del; 11219 mod Patch: https://git.openjdk.java.net/jdk/pull/171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171 PR: https://git.openjdk.java.net/jdk/pull/171 From hannesw at openjdk.java.net Wed Oct 7 13:12:13 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 7 Oct 2020 13:12:13 GMT Subject: Integrated: 8216497: javadoc should auto-link to platform classes In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Walln?fer wrote: > This pull request is identical with the RFR previously sent for the Mercurial repository: > > https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html > > I'm copy-pasting the comments from the original RFR below. > > Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting > code for setting up external links. > The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for > prereleases. Platform documentation URLs can be configured using the new --link-platform-properties option to > provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on > the new options. The feature can be disabled using the --no-platform-link option, generating the same output as > previously. One problem I had to solve was how to handle the transition from prerelease versions to final releases, > since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that > switch via code change at a time shortly before release. The way it is done is that we determine if the current > javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(), > and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This > means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with > source version 15 will generate links to the final release documentation) but I think this is acceptable. Another > issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to > pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally > there should be one test with a clear message. Because of this, when a release is encountered for which no > element-list is available a warning is generated instead of an error, and the documentation is generated without > platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new > test to fail with a relatively clear message of what is wrong. > *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we > still need to maintain element-lists for older versions, so I?m not sure it?s worth it. > > For existing tests that check output affected by the new option I added the --no-platform-link option to disable the > feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static > release or source version, which we don?t want either). I updated the CSR to the new code. It also needs to be > reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181 > > Thanks, > Hannes This pull request has now been integrated. Changeset: 1e8e543b Author: Hannes Walln?fer URL: https://git.openjdk.java.net/jdk/commit/1e8e543b Stats: 1844 lines in 51 files changed: 1831 ins; 4 del; 9 mod 8216497: javadoc should auto-link to platform classes Co-authored-by: Jan Lahoda Reviewed-by: erikj, jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From vromero at openjdk.java.net Wed Oct 7 13:36:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Oct 2020 13:36:29 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v10] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing unused jcod file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/7501148d..1bcda595 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08-09 Stats: 256 lines in 1 file changed: 0 ins; 256 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From jlaskey at openjdk.java.net Wed Oct 7 14:35:28 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 7 Oct 2020 14:35:28 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v3] In-Reply-To: References: Message-ID: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. Jim Laskey 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 8254073 - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/525/files - new: https://git.openjdk.java.net/jdk/pull/525/files/6d6b3eec..db7a2062 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=01-02 Stats: 4797 lines in 114 files changed: 3083 ins; 1090 del; 624 mod Patch: https://git.openjdk.java.net/jdk/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/525/head:pull/525 PR: https://git.openjdk.java.net/jdk/pull/525 From jlaskey at openjdk.java.net Wed Oct 7 14:35:30 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 7 Oct 2020 14:35:30 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v2] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 20:48:34 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> 8254073: Tokenizer improvements (revised) > > test/langtools/tools/javac/lexer/JavaLexerTest2.java line 50: > >> 48: public class JavaLexerTest2 { >> 49: static final TestTuple[] TESTS = { >> 50: new TestTuple("0bL", LONGLITERAL, true), > > Stylistic (optional) comment - we could have a common TestTuple superclass and two subclasses called Success and > Failure, so that, by looking at the TESTS array it will be apparent what the behavior should be Done > test/langtools/tools/javac/lexer/JavaLexerTest2.java line 110: > >> 108: boolean willFail; >> 109: >> 110: TestTuple(String input, TokenKind kind, String expected, boolean willFail) { > > Is anything using this? It does now. > test/langtools/tools/javac/lexer/JavaLexerTest2.java line 48: > >> 46: import static com.sun.tools.javac.parser.Tokens.TokenKind.*; >> 47: >> 48: public class JavaLexerTest2 { > > Should we merge JavaLexerTest and this one? After all you have all the required infra in here? Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/525 From mcimadamore at openjdk.java.net Wed Oct 7 15:50:17 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 7 Oct 2020 15:50:17 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v3] In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 14:35:28 GMT, Jim Laskey wrote: >> This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was >> reverted. >> This revision contains the changes of that pull request plus: >> >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java >> @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { >> * >> * Thus, to find the source position of any position, p, in the comment >> * string, find the index, i, of the pair whose string offset >> - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, >> - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. >> + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater >> + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + >> + * (p - map[i * NOFFSETS + SB_OFFSET]) }. >> */ >> static class OffsetMap { >> /** >> @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { >> int start = 0; >> int end = size / NOFFSETS; >> >> - while (start < end - NOFFSETS) { >> + while (start < end - 1) { >> // find an index midway between start and end >> int index = (start + end) / 2; >> int indexScaled = index * NOFFSETS; >> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 >> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java >> @@ -221,48 +221,49 @@ public class UnicodeReader { >> private boolean unicodeEscape() { >> // Start of unicode escape (past backslash.) >> int start = position + width; >> - int index; >> + >> + // Default to backslash result, unless proven otherwise. >> + character = '\'; >> + width = 1; >> >> // Skip multiple 'u'. >> + int index; >> for (index = start; index < length; index++) { >> if (buffer[index] != 'u') { >> break; >> } >> } >> >> - // Needs to be at least backslash-u. >> - if (index != start) { >> - // If enough characters available. >> - if (index + 4 < length) { >> - // Convert four hex digits to codepoint. If any digit is invalid then the >> - // result is negative. >> - int code = (Character.digit(buffer[index++], 16) << 12) | >> - (Character.digit(buffer[index++], 16) << 8) | >> - (Character.digit(buffer[index++], 16) << 4) | >> - Character.digit(buffer[index++], 16); >> - >> - // If all digits are good. >> - if (code >= 0) { >> - width = index - position; >> - character = (char)code; >> - >> - return true; >> - } >> - } >> + // Needs to have been at least one u. >> + if (index == start) { >> + return false; >> + } >> >> - // Did not work out. >> - log.error(position, Errors.IllegalUnicodeEsc); >> - width = index - position; >> + int code = 0; >> >> - // Return true so that the invalid unicode escape is skipped. >> - return true; >> + for (int i = 0; i < 4; i++) { >> + int digit = Character.digit(buffer[index], 16); >> + code = code << 4 | digit; >> + >> + if (code < 0) { >> + break; >> + } >> + >> + index++; >> } >> >> - // Must be just a backslash. >> - character = '\'; >> - width = 1; >> + // Skip digits even if error. >> + width = index - position; >> >> - return false; >> + // If all digits are good. >> + if (code >= 0) { >> + character = (char)code; >> + } else { >> + log.error(position, Errors.IllegalUnicodeEsc); >> + } >> + >> + // Return true even if error so that the invalid unicode escape is skipped. >> + return true; >> } >> >> /** >> @@ -549,7 +550,7 @@ public class UnicodeReader { >> /** >> * Offset from the beginning of the original reader buffer. >> */ >> - private int offset; >> + final private int offset; >> >> /** >> * Current column in the comment. > > Jim Laskey 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 8254073 > - 8254073: Tokenizer improvements (revised) > - 8254073: Tokenizer improvements (revised) > - 8254073: Tokenizer improvements (revised) > - Merge branch 'master' into 8254073 > - Merge branch 'master' into 8254073 > - 8254073: Tokenizer improvements (revised) Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/525 From bsrbnd at gmail.com Thu Oct 8 09:44:32 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 8 Oct 2020 11:44:32 +0200 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: <1f3e1785-61da-725a-f0df-5b33d860f3bd@oracle.com> References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> <1f3e1785-61da-725a-f0df-5b33d860f3bd@oracle.com> Message-ID: Testing a few more, I note that a discrepancy with the JLS in this area might have deeper consequences beyond wrong diagnostics, consider: public class Test { public static void main(String[] args) { test((Double)5.0); } void test(Number n) { System.out.println(Number.class); } static void test(Double... d) { System.out.println(Double.class); } } JDK16 currently resolves and runs 'test(Double...)' instead of raising a static error as mandated by ?15.12 and according to the suggested fix. I'm not sure where to find JDK7 x86_64 binaries, so maybe you could try this one too and share your thoughts? Bernard On Mon, 5 Oct 2020 at 12:00, Maurizio Cimadamore wrote: > > Thanks - I've reset the fix version field and reassigned to Vicente - he > can perhaps take a look and see what needs to be done to integrate this > (this is an area where we would at least need some good testing > coverage, perhaps by using the overload test framework that was put in > few years ago - see [1] for an example). > > Maurizio > > [1] - > https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/resolve/tests/InnerOverOuter.java From maurizio.cimadamore at oracle.com Thu Oct 8 10:54:14 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 8 Oct 2020 11:54:14 +0100 Subject: JDK-8238213: javac emits wrong error when calling an non-static overloaded method from static In-Reply-To: References: <2e02b194-a4f5-da9d-59e5-3d708cf68811@oracle.com> <26b06945-f34c-e944-17ef-501b87b22670@oracle.com> <1f3e1785-61da-725a-f0df-5b33d860f3bd@oracle.com> Message-ID: <4c1c50cd-f9f2-71d4-5f74-fd45c0b1028b@oracle.com> Your example works in Java 7. I agree that the compatibility impact of fixing something like this might be non trivial. Maurizio On 08/10/2020 10:44, B. Blaser wrote: > Testing a few more, I note that a discrepancy with the JLS in this > area might have deeper consequences beyond wrong diagnostics, > consider: > > public class Test { > public static void main(String[] args) { > test((Double)5.0); > } > > void test(Number n) { > System.out.println(Number.class); > } > > static void test(Double... d) { > System.out.println(Double.class); > } > } > > JDK16 currently resolves and runs 'test(Double...)' instead of raising > a static error as mandated by ?15.12 and according to the suggested > fix. > I'm not sure where to find JDK7 x86_64 binaries, so maybe you could > try this one too and share your thoughts? > > Bernard > > On Mon, 5 Oct 2020 at 12:00, Maurizio Cimadamore > wrote: >> Thanks - I've reset the fix version field and reassigned to Vicente - he >> can perhaps take a look and see what needs to be done to integrate this >> (this is an area where we would at least need some good testing >> coverage, perhaps by using the overload test framework that was put in >> few years ago - see [1] for an example). >> >> Maurizio >> >> [1] - >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/langtools/tools/javac/resolve/tests/InnerOverOuter.java__;!!GqivPVa7Brio!NroBbo6P7_xLMhNZVOf6wYXN3s5oPHH0YN0-aWr9MOW5Sah-sYVAJOG7vakveKhg7XUQRR0$ From jlahoda at openjdk.java.net Thu Oct 8 11:55:51 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Oct 2020 11:55:51 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) Message-ID: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. A summary of changes: -making the feature permanent (non-preview) -making the binding variables non-final (as per current specification proposal) -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. This change will not be integrated until JEP 394 is targetted. ------------- Commit messages: - Fixing more tests. - Correcting positions. - Improve the AST model. - Merge branch 'master' into patterns-instanceof3 - Updating @since tags. - Merge branch 'master' into patterns-instanceof3 - Cleaning up preview comments in javadoc. - Merge branch 'master' into patterns-instanceof3 - Updating tests. - Cleanup. - ... and 3 more: https://git.openjdk.java.net/jdk/compare/97ff38ca...69c7dce8 Changes: https://git.openjdk.java.net/jdk/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250625 Stats: 655 lines in 90 files changed: 242 ins; 302 del; 111 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Thu Oct 8 12:01:50 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 8 Oct 2020 12:01:50 GMT Subject: RFR: 8233685: Test tools/javac/modules/AddLimitMods.java fails Message-ID: The ToolBox' JavaTask by default picks up content of system property "test.java.opts". In the case of this bug, test.java.opts contains "-XX:+FlightRecorder". And one of the sub-tests (testRuntime2Compile) of the AddLimitMods test tries to invoke the java launcher with "--limit-modules java.base", and this fails because flight recorder cannot start. The proposal is to avoid using the content of test.java.opts for that test. ------------- Commit messages: - 8233685: Test tools/javac/modules/AddLimitMods.java fails Changes: https://git.openjdk.java.net/jdk/pull/560/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=560&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233685 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/560.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/560/head:pull/560 PR: https://git.openjdk.java.net/jdk/pull/560 From vromero at openjdk.java.net Thu Oct 8 12:55:45 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 8 Oct 2020 12:55:45 GMT Subject: RFR: 8233685: Test tools/javac/modules/AddLimitMods.java fails In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 11:56:44 GMT, Jan Lahoda wrote: > The ToolBox' JavaTask by default picks up content of system property "test.java.opts". In the case of this bug, > test.java.opts contains "-XX:+FlightRecorder". And one of the sub-tests (testRuntime2Compile) of the AddLimitMods test > tries to invoke the java launcher with "--limit-modules java.base", and this fails because flight recorder cannot > start. The proposal is to avoid using the content of test.java.opts for that test. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/560 From jlaskey at openjdk.java.net Thu Oct 8 13:36:02 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 8 Oct 2020 13:36:02 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v4] In-Reply-To: References: Message-ID: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. Jim Laskey 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 10 additional commits since the last revision: - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/525/files - new: https://git.openjdk.java.net/jdk/pull/525/files/db7a2062..53ff5369 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=02-03 Stats: 8151 lines in 124 files changed: 3542 ins; 4209 del; 400 mod Patch: https://git.openjdk.java.net/jdk/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/525/head:pull/525 PR: https://git.openjdk.java.net/jdk/pull/525 From jlaskey at openjdk.java.net Thu Oct 8 14:10:03 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 8 Oct 2020 14:10:03 GMT Subject: RFR: 8254073: Tokenizer improvements (revised) [v5] In-Reply-To: References: Message-ID: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. Jim Laskey 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 12 additional commits since the last revision: - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - Merge branch 'master' into 8254073 - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - 8254073: Tokenizer improvements (revised) - Merge branch 'master' into 8254073 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7d2f70ad...d12ee280 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/525/files - new: https://git.openjdk.java.net/jdk/pull/525/files/53ff5369..d12ee280 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=525&range=03-04 Stats: 49 lines in 6 files changed: 45 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/525/head:pull/525 PR: https://git.openjdk.java.net/jdk/pull/525 From vromero at openjdk.java.net Fri Oct 9 00:10:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Oct 2020 00:10:36 GMT Subject: RFR: 8254105: allow static members in inner classes, add binary =?UTF-8?B?Y29tcGF0aWJpbOKApg==?= In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: <2FO64qXpIpHlQBKzDtQdQTQtdUWhZTsw--VPeSKFw3A=.19353e8e-77e1-40e0-9f72-23977455d8d6@github.com> On Fri, 9 Oct 2020 00:01:12 GMT, Vicente Romero wrote: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is > to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and > Nested Static > Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change > is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined > inside inner classes but also interfaces, enums, static classes and methods. TIA, Vicente test/langtools/tools/javac/LocalInterface.java line 6: > 4: * @summary test for local interfaces > 5: * @compile/fail/ref=LocalInterface.out -XDrawDiagnostics LocalInterface.java > 6: * @compile --enable-preview -source ${jdk.version} LocalInterface.java the current patch is supposed to be applied after the code being reviewed at [PR-290](https://github.com/openjdk/jdk/pull/290) which also modifies this particular line, once [PR-290](https://github.com/openjdk/jdk/pull/290) has been pushed this line and others removing the --enable-preview option from tests will change test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. this code is not strictly related to the patch but this test is just basically testing the changes Chapter 13 int the record spec. I'm OK moving this to another PR if needed ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Fri Oct 9 00:10:35 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Oct 2020 00:10:35 GMT Subject: RFR: 8254105: allow static members in inner classes, add binary =?UTF-8?B?Y29tcGF0aWJpbOKApg==?= Message-ID: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. TIA, Vicente ------------- Commit messages: - 8254105: allow static members in inner classes, add binary compatibility tests Changes: https://git.openjdk.java.net/jdk/pull/571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254105 Stats: 664 lines in 24 files changed: 459 ins; 140 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From david.holmes at oracle.com Fri Oct 9 01:16:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Oct 2020 11:16:28 +1000 Subject: =?UTF-8?Q?Re=3a_RFR=3a_8254105=3a_allow_static_members_in_inner_cla?= =?UTF-8?Q?sses=2c_add_binary_compatibil=e2=80=a6?= In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: Hi Vincente, On 9/10/2020 10:10 am, Vicente Romero wrote: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is > to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and > Nested Static > Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change > is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined > inside inner classes but also interfaces, enums, static classes and methods. I'm rather confused. Is this intended to be the issue under which the implementation of JEP 395 is done? JEP 395 is only a Candidate at the moment so nothing in relation to that should be getting integrated yet. It is also unclear how the JDK-8254105 issue relates to the JDK-8246774 issues, which appears to be intended to be the implementation issue for JEP 395. ??? Thanks, David > TIA, > Vicente > > ------------- > > Commit messages: > - 8254105: allow static members in inner classes, add binary compatibility tests > > Changes: https://git.openjdk.java.net/jdk/pull/571/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8254105 > Stats: 664 lines in 24 files changed: 459 ins; 140 del; 65 mod > Patch: https://git.openjdk.java.net/jdk/pull/571.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 > > PR: https://git.openjdk.java.net/jdk/pull/571 > From vromero at openjdk.java.net Fri Oct 9 03:58:27 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Oct 2020 03:58:27 GMT Subject: RFR: 8254105: allow static members in inner classes, add binary compatibility tests In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Fri, 9 Oct 2020 00:01:12 GMT, Vicente Romero wrote: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is > to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and > Nested Static > Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change > is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined > inside inner classes but also interfaces, enums, static classes and methods. TIA, Vicente PS: the records spec can be > accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). > This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK > moving that test to a separate PR. Hi David, This issue is a subtask of JEP 395 along with JDK-8246774. JDK-8246774 is basically removing all the preview annotations from record's code and preview options from the related tests so that records can be used as a standard feature in Java. But issues like this one, and probably another I'm still working on related to annotations on record components, was, IMO, complex enough to deserve a separate review process. I'm OK with creating an umbrella issue, if that sounds better to you, that contains all implementation tasks and make JDK-8246774 and this current task subtasks of that umbrella issue. Thanks, Vicente ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From jlahoda at openjdk.java.net Fri Oct 9 06:26:20 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 9 Oct 2020 06:26:20 GMT Subject: Integrated: 8233685: Test tools/javac/modules/AddLimitMods.java fails In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 11:56:44 GMT, Jan Lahoda wrote: > The ToolBox' JavaTask by default picks up content of system property "test.java.opts". In the case of this bug, > test.java.opts contains "-XX:+FlightRecorder". And one of the sub-tests (testRuntime2Compile) of the AddLimitMods test > tries to invoke the java launcher with "--limit-modules java.base", and this fails because flight recorder cannot > start. The proposal is to avoid using the content of test.java.opts for that test. This pull request has now been integrated. Changeset: a2f65190 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/a2f65190 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8233685: Test tools/javac/modules/AddLimitMods.java fails Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/560 From maurizio.cimadamore at oracle.com Fri Oct 9 09:42:53 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Oct 2020 10:42:53 +0100 Subject: switch expression type with 'null' return expression In-Reply-To: References: Message-ID: Hi Anna, yes, this looks like a compiler bug. Behavior should be the same as: Z pick(Z z1, Z z2, Z z3) { .... } pick(i1, null, i2) --> lub(I1, I2) --> I Seems like the `null` is tripping javac up Maurizio On 30/09/2020 10:50, Anna Kozlova wrote: > Hi all, > > The following code doesn't compile (infers i_ to Object) > interface I { > void m(); > } > interface I1 extends I {} > interface I2 extends I {} > > static void n(I1 i1,I2 i2,int s) { > var i_ =switch (s) { > case 1 -> i1; > case 2 ->null; > default -> i2; > }; > if (i_ !=null) { > i_.m(); //cannot find symbol m() > } > } > > If you permute "case 1" and "case 2" switch rules, the code starts to > compile (infers i_ to I). > > Looks like a bug? > > Thanks, > Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri Oct 9 09:46:37 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 9 Oct 2020 10:46:37 +0100 Subject: switch expression type with 'null' return expression In-Reply-To: References: Message-ID: Filed this: https://bugs.openjdk.java.net/browse/JDK-8254286 Maurizio On 09/10/2020 10:42, Maurizio Cimadamore wrote: > > Hi Anna, > yes, this looks like a compiler bug. > > Behavior should be the same as: > > Z pick(Z z1, Z z2, Z z3) { .... } > > pick(i1, null, i2) > > --> lub(I1, I2) --> I > > Seems like the `null` is tripping javac up > > Maurizio > > On 30/09/2020 10:50, Anna Kozlova wrote: >> Hi all, >> >> The following code doesn't compile (infers i_ to Object) >> interface I { >> void m(); >> } >> interface I1 extends I {} >> interface I2 extends I {} >> >> static void n(I1 i1,I2 i2,int s) { >> var i_ =switch (s) { >> case 1 -> i1; >> case 2 ->null; >> default -> i2; >> }; >> if (i_ !=null) { >> i_.m(); //cannot find symbol m() >> } >> } >> >> If you permute "case 1" and "case 2" switch rules, the code starts to >> compile (infers i_ to I). >> >> Looks like a bug? >> >> Thanks, >> Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.java.net Fri Oct 9 11:12:23 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 9 Oct 2020 11:12:23 GMT Subject: Integrated: 8254073: Tokenizer improvements (revised) In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 14:01:11 GMT, Jim Laskey wrote: > This is a full revision of https://github.com/openjdk/jdk/pull/435 which contained two 'out by one' bugs and was > reverted. > This revision contains the changes of that pull request plus: > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java index 39d9eadcf3a..b8425ad1ecb 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java > @@ -306,8 +306,9 @@ public class JavadocTokenizer extends JavaTokenizer { > * > * Thus, to find the source position of any position, p, in the comment > * string, find the index, i, of the pair whose string offset > - * ({@code map[i + SB_OFFSET] }) is closest to but not greater than p. Then, > - * {@code sourcePos(p) = map[i + POS_OFFSET] + (p - map[i + SB_OFFSET]) }. > + * ({@code map[i * NOFFSETS + SB_OFFSET] }) is closest to but not greater > + * than p. Then, {@code sourcePos(p) = map[i * NOFFSETS + POS_OFFSET] + > + * (p - map[i * NOFFSETS + SB_OFFSET]) }. > */ > static class OffsetMap { > /** > @@ -426,7 +427,7 @@ public class JavadocTokenizer extends JavaTokenizer { > int start = 0; > int end = size / NOFFSETS; > > - while (start < end - NOFFSETS) { > + while (start < end - 1) { > // find an index midway between start and end > int index = (start + end) / 2; > int indexScaled = index * NOFFSETS; > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java index 2472632dbcd..7584b79044b 100644 > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java > @@ -221,48 +221,49 @@ public class UnicodeReader { > private boolean unicodeEscape() { > // Start of unicode escape (past backslash.) > int start = position + width; > - int index; > + > + // Default to backslash result, unless proven otherwise. > + character = '\'; > + width = 1; > > // Skip multiple 'u'. > + int index; > for (index = start; index < length; index++) { > if (buffer[index] != 'u') { > break; > } > } > > - // Needs to be at least backslash-u. > - if (index != start) { > - // If enough characters available. > - if (index + 4 < length) { > - // Convert four hex digits to codepoint. If any digit is invalid then the > - // result is negative. > - int code = (Character.digit(buffer[index++], 16) << 12) | > - (Character.digit(buffer[index++], 16) << 8) | > - (Character.digit(buffer[index++], 16) << 4) | > - Character.digit(buffer[index++], 16); > - > - // If all digits are good. > - if (code >= 0) { > - width = index - position; > - character = (char)code; > - > - return true; > - } > - } > + // Needs to have been at least one u. > + if (index == start) { > + return false; > + } > > - // Did not work out. > - log.error(position, Errors.IllegalUnicodeEsc); > - width = index - position; > + int code = 0; > > - // Return true so that the invalid unicode escape is skipped. > - return true; > + for (int i = 0; i < 4; i++) { > + int digit = Character.digit(buffer[index], 16); > + code = code << 4 | digit; > + > + if (code < 0) { > + break; > + } > + > + index++; > } > > - // Must be just a backslash. > - character = '\'; > - width = 1; > + // Skip digits even if error. > + width = index - position; > > - return false; > + // If all digits are good. > + if (code >= 0) { > + character = (char)code; > + } else { > + log.error(position, Errors.IllegalUnicodeEsc); > + } > + > + // Return true even if error so that the invalid unicode escape is skipped. > + return true; > } > > /** > @@ -549,7 +550,7 @@ public class UnicodeReader { > /** > * Offset from the beginning of the original reader buffer. > */ > - private int offset; > + final private int offset; > > /** > * Current column in the comment. This pull request has now been integrated. Changeset: 4f9a1ffc Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/4f9a1ffc Stats: 2471 lines in 19 files changed: 1215 ins; 605 del; 651 mod 8254073: Tokenizer improvements (revised) Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/525 From jlahoda at openjdk.java.net Fri Oct 9 17:17:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 9 Oct 2020 17:17:16 GMT Subject: RFR: 8254286: Wrong inference in switch expression with "null" arm Message-ID: Basically, for code like: var t1 = switch (s) { case 1 -> i1; case 2 -> null; default -> i2; }; Attr.condType is currently passing , BOT, to Types.lub. But Types.lub needs the list without BOT, so filtering BOT(s) out of the list. ------------- Commit messages: - Improving tests. - 8254286: Wrong inference in switch expression with "null" arm Changes: https://git.openjdk.java.net/jdk/pull/583/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=583&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254286 Stats: 58 lines in 3 files changed: 55 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/583.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/583/head:pull/583 PR: https://git.openjdk.java.net/jdk/pull/583 From vromero at openjdk.java.net Fri Oct 9 21:19:23 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Oct 2020 21:19:23 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: <4-RukNqR8mw_y9cNdDzi0YLj-5pai7_t9xW8by6ujsU=.630a90fb-55bd-492a-9388-9e4d7fd12ca8@github.com> On Mon, 21 Sep 2020 23:31:51 GMT, Vicente Romero wrote: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente thanks for the comments, I have updated the PR changing `@since 14` to `@since 16` ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From vromero at openjdk.java.net Fri Oct 9 21:19:23 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 9 Oct 2020 21:19:23 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com> > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating @since from 14 to 16 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/f5682fc2..cd27384d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=04-05 Stats: 13 lines in 11 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 From bsrbnd at gmail.com Sat Oct 10 14:43:08 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 10 Oct 2020 16:43:08 +0200 Subject: LUB computation involving NULL (was: switch expression type with 'null' return expression) In-Reply-To: References: Message-ID: Hi, This one is interesting. Unless I read JLS15 too quickly, neither ?15.28.1 mandates explicitly to skip null types before computing the LUB: "Otherwise, boxing conversion (?5.1.7) is applied to each result expression that has a primitive type, after which the type of the switch expression is the result of applying capture conversion (?5.1.10) to the least upper bound (?4.10.4) of the types of the result expressions." nor ?4.10.4 explicitly specifies how to handle them. So, ignoring null types not to interfere with this computation seems implicitly deduced from the fact that they can match any reference type and Jan's pull request [1] looks therefore reasonable. However, compilation currently succeeds with the first arm being null (as initially reported), suggesting probably to fix this more directly in Types::lub as here under (langtools:tier1 being OK on jdk14u). What do you think? Thanks, Bernard [1] https://git.openjdk.java.net/jdk/pull/583 diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java @@ -3970,33 +3970,29 @@ case CLASS_BOUND: // calculate lub(A, B) - int startIdx = 0; - for (int i = 0; i < ts.length ; i++) { - Type t = ts[i]; - if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { - break; - } else { - startIdx++; - } - } - Assert.check(startIdx < ts.length); //step 1 - compute erased candidate set (EC) - List cl = erasedSupertypes(ts[startIdx]); - for (int i = startIdx + 1 ; i < ts.length ; i++) { - Type t = ts[i]; + List cl = null; + for (Type t: ts) { if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) - cl = intersect(cl, erasedSupertypes(t)); - } + cl = cl == null ? erasedSupertypes(t) : intersect(cl, erasedSupertypes(t)); + } + Assert.checkNonNull(cl); + //step 2 - compute minimal erased candidate set (MEC) List mec = closureMin(cl); //step 3 - for each element G in MEC, compute lci(Inv(G)) List candidates = List.nil(); for (Type erasedSupertype : mec) { - List lci = List.of(asSuper(ts[startIdx], erasedSupertype.tsym)); - for (int i = startIdx + 1 ; i < ts.length ; i++) { - Type superType = asSuper(ts[i], erasedSupertype.tsym); - lci = intersect(lci, superType != null ? List.of(superType) : List.nil()); + List lci = null; + for (Type t: ts) { + if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { + Type superType = asSuper(t, erasedSupertype.tsym); + List stl = superType != null ? List.of(superType) : List.nil(); + lci = lci == null ? stl : intersect(lci, stl); + } } + Assert.checkNonNull(lci); + candidates = candidates.appendList(lci); } //step 4 - let MEC be { G1, G2 ... Gn }, then we have that On Fri, 9 Oct 2020 at 11:46, Maurizio Cimadamore wrote: > > Filed this: > > https://bugs.openjdk.java.net/browse/JDK-8254286 > > Maurizio > > On 09/10/2020 10:42, Maurizio Cimadamore wrote: > > Hi Anna, > yes, this looks like a compiler bug. > > Behavior should be the same as: > > Z pick(Z z1, Z z2, Z z3) { .... } > > pick(i1, null, i2) > > --> lub(I1, I2) --> I > > Seems like the `null` is tripping javac up > > Maurizio > > On 30/09/2020 10:50, Anna Kozlova wrote: > > Hi all, > > The following code doesn't compile (infers i_ to Object) > > interface I { > void m(); > } > interface I1 extends I {} > interface I2 extends I {} > > static void n(I1 i1, I2 i2, int s) { > var i_ = switch (s) { > case 1 -> i1; > case 2 -> null; > default -> i2; > }; > if (i_ != null) { > i_.m(); //cannot find symbol m() > } > } > > > If you permute "case 1" and "case 2" switch rules, the code starts to compile (infers i_ to I). > > Looks like a bug? > > Thanks, > Anna From attila.kelemen85 at gmail.com Sat Oct 10 16:22:22 2020 From: attila.kelemen85 at gmail.com (Attila Kelemen) Date: Sat, 10 Oct 2020 18:22:22 +0200 Subject: POC implementation of string interpolation Message-ID: Hi, I have implemented a version of string interpolation in my local fork [1] for fun. I know it is a lot to ask, but I'm hoping to find some generous souls who could review my changes [2], if this is sensible way to alter javac. The format is "\{expression}", where the `expression` can be any legal Java expression (line endings are currently forbidden). It works with both normal strings and text blocks (which is of course, the main pain without string interpolation). Hopefully I did not miss many features that are a must with such a change. For example, I have adjusted string folding and the compile time constant parsing to work with interpolated strings as well. As for the implementation, I had to allow the tokenizer to create a parser. This is somewhat awkward, because now the tokenizer is no longer regular, but I saw no way around it. There are some controversial parts of the implementation of course: - I have created `JCInterpolatedString`, which is a list of expressions to be concatenated to a string. The only caveat with this is that it is possible to nest string literals like "\{"ABC"}". If this is parsed naively, then it will contain a single JCLiteral (string). However, this would mean that `Pretty` will print it back as "ABC", which is surprising. So, I got around this by wrapping such string literals into a `JCInterpolatedString`. There are many alternatives I have considered, but this seemed to be the least error prone to use. - The string folding within `JavacParser` is currently folding only string constants. However, this could be adjusted to fold every literal, because unlike `PLUS`, interpolated strings are always strings anyway. - There are no tests at the moment, but that is because it is now just a proof of concept, so I didn't want to make extreme efforts on that. Thanks, Attila Kelemen [1] https://github.com/kelemen/jdk/tree/string_interpolation [2] https://github.com/kelemen/jdk/commit/029b4ccde7d43b9ad57b74f3ebfa536084b80910 ps.: LambdaTranslationTest1 and LambdaTranslationTest2 does not work on my local, because of the decimal separator being "," instead of ".". From darcy at openjdk.java.net Sat Oct 10 16:57:09 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 10 Oct 2020 16:57:09 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6] In-Reply-To: <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com> Message-ID: On Fri, 9 Oct 2020 21:19:23 GMT, Vicente Romero wrote: >> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort >> to make records a final feature of the Java Language. The rest of the code has been published in >> [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, >> Vicente > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > updating @since from 14 to 16 Marked as reviewed by darcy (Reviewer). src/java.base/share/classes/jdk/internal/PreviewFeature.java line 65: > 63: // necessary for PreviewFeature in JDK 15 to declare the enum constant. > 64: TEXT_BLOCKS, > 65: /* It doesn't really matter, but it would look more consistent if TEXT_BLOCKS and RECORDS used the same kind of comment syntax. ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From vromero at openjdk.java.net Sat Oct 10 18:21:22 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sat, 10 Oct 2020 18:21:22 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v7] In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating comment syntax for Feature.RECORDS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/cd27384d..a0373100 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=05-06 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291 PR: https://git.openjdk.java.net/jdk/pull/291 From vromero at openjdk.java.net Sat Oct 10 18:21:23 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sat, 10 Oct 2020 18:21:23 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com> Message-ID: On Sat, 10 Oct 2020 16:54:06 GMT, Joe Darcy wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> updating @since from 14 to 16 > > src/java.base/share/classes/jdk/internal/PreviewFeature.java line 65: > >> 63: // necessary for PreviewFeature in JDK 15 to declare the enum constant. >> 64: TEXT_BLOCKS, >> 65: /* > > It doesn't really matter, but it would look more consistent if TEXT_BLOCKS and RECORDS used the same kind of comment > syntax. thanks for the comment, I have uploaded commit [a037310](https://github.com/openjdk/jdk/pull/291/commits/a03731005bae069a18e4ef2f0dced7019c2a4081) to fix this ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From mcimadamore at openjdk.java.net Mon Oct 12 10:28:08 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 12 Oct 2020 10:28:08 GMT Subject: RFR: 8254286: Wrong inference in switch expression with "null" arm In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:08:36 GMT, Jan Lahoda wrote: > Basically, for code like: > > var t1 = switch (s) { > case 1 -> i1; > case 2 -> null; > default -> i2; > }; > > Attr.condType is currently passing , BOT, to Types.lub. But Types.lub needs the list without > BOT, so filtering BOT(s) out of the list. The fix looks fine. Note that in method inference we also skip the erroneous case: @Override public boolean accepts(Type t) { return !t.isErroneous() && !inferenceContext.free(t) && !t.hasTag(BOT); } Not sure whether this applies here too - maybe erroneous types are already skipped earlier? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/583 From maurizio.cimadamore at oracle.com Mon Oct 12 10:29:56 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 12 Oct 2020 11:29:56 +0100 Subject: LUB computation involving NULL In-Reply-To: References: Message-ID: On 10/10/2020 15:43, B. Blaser wrote: > Hi, > > This one is interesting. > > Unless I read JLS15 too quickly, neither ?15.28.1 mandates explicitly > to skip null types before computing the LUB: > > "Otherwise, boxing conversion (?5.1.7) is applied to each result > expression that has a primitive type, after which the type of the > switch expression is the result of applying capture conversion > (?5.1.10) to the least upper bound (?4.10.4) of the types of the > result expressions." > > nor ?4.10.4 explicitly specifies how to handle them. > > So, ignoring null types not to interfere with this computation seems > implicitly deduced from the fact that they can match any reference > type and Jan's pull request [1] looks therefore reasonable. > > However, compilation currently succeeds with the first arm being null > (as initially reported), suggesting probably to fix this more directly > in Types::lub as here under (langtools:tier1 being OK on jdk14u). For method type inference, we already filter types before applying lub. I think we should do the same here. Of course we could also fix deeper, but I think it's better to start simple. From a spec perspective, I think the filtering is implicit in 18.2. ``` A constraint formula of the form ?S <: T? is reduced as follows: ??? ... ??? Otherwise, if S is the null type, the constraint reduces to true. ``` In other words, if the actual type (S) has the null type, we never even generate a bound for lub to contemplate - that subtyping constraint is instead implicitly satisfied. Which seems to suggest a pre-filtering step (which is what the compiler does). Maurizio > > What do you think? > > Thanks, > Bernard > > [1] https://git.openjdk.java.net/jdk/pull/583 > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java > @@ -3970,33 +3970,29 @@ > > case CLASS_BOUND: > // calculate lub(A, B) > - int startIdx = 0; > - for (int i = 0; i < ts.length ; i++) { > - Type t = ts[i]; > - if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { > - break; > - } else { > - startIdx++; > - } > - } > - Assert.check(startIdx < ts.length); > //step 1 - compute erased candidate set (EC) > - List cl = erasedSupertypes(ts[startIdx]); > - for (int i = startIdx + 1 ; i < ts.length ; i++) { > - Type t = ts[i]; > + List cl = null; > + for (Type t: ts) { > if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) > - cl = intersect(cl, erasedSupertypes(t)); > - } > + cl = cl == null ? erasedSupertypes(t) : > intersect(cl, erasedSupertypes(t)); > + } > + Assert.checkNonNull(cl); > + > //step 2 - compute minimal erased candidate set (MEC) > List mec = closureMin(cl); > //step 3 - for each element G in MEC, compute lci(Inv(G)) > List candidates = List.nil(); > for (Type erasedSupertype : mec) { > - List lci = List.of(asSuper(ts[startIdx], > erasedSupertype.tsym)); > - for (int i = startIdx + 1 ; i < ts.length ; i++) { > - Type superType = asSuper(ts[i], erasedSupertype.tsym); > - lci = intersect(lci, superType != null ? > List.of(superType) : List.nil()); > + List lci = null; > + for (Type t: ts) { > + if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { > + Type superType = asSuper(t, erasedSupertype.tsym); > + List stl = superType != null ? > List.of(superType) : List.nil(); > + lci = lci == null ? stl : intersect(lci, stl); > + } > } > + Assert.checkNonNull(lci); > + > candidates = candidates.appendList(lci); > } > //step 4 - let MEC be { G1, G2 ... Gn }, then we have that > > On Fri, 9 Oct 2020 at 11:46, Maurizio Cimadamore > wrote: >> Filed this: >> >> https://bugs.openjdk.java.net/browse/JDK-8254286 >> >> Maurizio >> >> On 09/10/2020 10:42, Maurizio Cimadamore wrote: >> >> Hi Anna, >> yes, this looks like a compiler bug. >> >> Behavior should be the same as: >> >> Z pick(Z z1, Z z2, Z z3) { .... } >> >> pick(i1, null, i2) >> >> --> lub(I1, I2) --> I >> >> Seems like the `null` is tripping javac up >> >> Maurizio >> >> On 30/09/2020 10:50, Anna Kozlova wrote: >> >> Hi all, >> >> The following code doesn't compile (infers i_ to Object) >> >> interface I { >> void m(); >> } >> interface I1 extends I {} >> interface I2 extends I {} >> >> static void n(I1 i1, I2 i2, int s) { >> var i_ = switch (s) { >> case 1 -> i1; >> case 2 -> null; >> default -> i2; >> }; >> if (i_ != null) { >> i_.m(); //cannot find symbol m() >> } >> } >> >> >> If you permute "case 1" and "case 2" switch rules, the code starts to compile (infers i_ to I). >> >> Looks like a bug? >> >> Thanks, >> Anna From lgxbslgx at gmail.com Mon Oct 12 10:31:35 2020 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Mon, 12 Oct 2020 18:31:35 +0800 Subject: 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation Message-ID: Hi, I have viewed the Java Language Specifications(JLS) from 8 to 15 about the description of this issue. The most important content is the last paragraph in JLS 9.6.4.1. The Java versions, from 8 to 13 included, state it as below: >> If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T , then T is applicable in all declaration contexts except type parameter declarations, and in no type contexts. These contexts are the syntactic locations where annotations were allowed in Java SE 7. The Java versions 14 and 15 state it as below: >>If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T , then T is applicable in all nine declaration contexts and in all 16 type contexts. So I think it is an issue of incompatibility between the implementation of javac and the standard of JLS in version 14 and 15. I write a draft patch to solve this issue. Could anyone give more information about this problem or some suggestions to my idea and patch? The patch is shown below. diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java index f1725857891..758c462b829 100644 --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java @@ -119,7 +119,8 @@ public class Check { names = Names.instance(context); dfltTargetMeta = new Name[] { names.PACKAGE, names.TYPE, names.FIELD, names.RECORD_COMPONENT, names.METHOD, names.CONSTRUCTOR, - names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER}; + names.ANNOTATION_TYPE, names.LOCAL_VARIABLE, names.PARAMETER, + names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE }; log = Log.instance(context); rs = Resolve.instance(context); syms = Symtab.instance(context); diff --git a/test/langtools/tools/javac/annotations/8254023/T8254023.java b/test/langtools/tools/javac/annotations/8254023/T8254023.java new file mode 100644 index 00000000000..ec64f42a7a9 --- /dev/null +++ b/test/langtools/tools/javac/annotations/8254023/T8254023.java @@ -0,0 +1,7 @@ + +/** + * @test + * @bug 8254023 + * @summary A module declaration is not allowed to be a target of an annotation that lacks an (at)Target meta-annotation + * @compile module-info.java test/A.java + */ diff --git a/test/langtools/tools/javac/annotations/8254023/module-info.java b/test/langtools/tools/javac/annotations/8254023/module-info.java new file mode 100644 index 00000000000..936038a24a9 --- /dev/null +++ b/test/langtools/tools/javac/annotations/8254023/module-info.java @@ -0,0 +1,2 @@ + at test.A +module test { } \ No newline at end of file diff --git a/test/langtools/tools/javac/annotations/8254023/test/A.java b/test/langtools/tools/javac/annotations/8254023/test/A.java new file mode 100644 index 00000000000..824f0362207 --- /dev/null +++ b/test/langtools/tools/javac/annotations/8254023/test/A.java @@ -0,0 +1,3 @@ +package test; + +public @interface A { } Best Regards. ------------------------ Name: Guoxiong Li Email: lgxbslgx at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlahoda at openjdk.java.net Mon Oct 12 10:40:09 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 12 Oct 2020 10:40:09 GMT Subject: RFR: 8254286: Wrong inference in switch expression with "null" arm In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 10:25:33 GMT, Maurizio Cimadamore wrote: > The fix looks fine. Note that in method inference we also skip the erroneous case: > > ``` > @Override > public boolean accepts(Type t) { > return !t.isErroneous() && !inferenceContext.free(t) && > !t.hasTag(BOT); > } > ``` > > Not sure whether this applies here too - maybe erroneous types are already skipped earlier? Right - I believe errors are handled by the preceding conditions in condType. ------------- PR: https://git.openjdk.java.net/jdk/pull/583 From bsrbnd at gmail.com Mon Oct 12 12:09:16 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 12 Oct 2020 14:09:16 +0200 Subject: LUB computation involving NULL In-Reply-To: References: Message-ID: Hi Maurizio, On Mon, 12 Oct 2020 at 12:32, Maurizio Cimadamore wrote: > > > On 10/10/2020 15:43, B. Blaser wrote: > > Hi, > > > > This one is interesting. > > > > Unless I read JLS15 too quickly, neither ?15.28.1 mandates explicitly > > to skip null types before computing the LUB: > > > > "Otherwise, boxing conversion (?5.1.7) is applied to each result > > expression that has a primitive type, after which the type of the > > switch expression is the result of applying capture conversion > > (?5.1.10) to the least upper bound (?4.10.4) of the types of the > > result expressions." > > > > nor ?4.10.4 explicitly specifies how to handle them. > > > > So, ignoring null types not to interfere with this computation seems > > implicitly deduced from the fact that they can match any reference > > type and Jan's pull request [1] looks therefore reasonable. > > > > However, compilation currently succeeds with the first arm being null > > (as initially reported), suggesting probably to fix this more directly > > in Types::lub as here under (langtools:tier1 being OK on jdk14u). > > For method type inference, we already filter types before applying lub. > I think we should do the same here. Of course we could also fix deeper, > but I think it's better to start simple. > > From a spec perspective, I think the filtering is implicit in 18.2. > > ``` > A constraint formula of the form ?S <: T? is reduced as follows: > > ... > > Otherwise, if S is the null type, the constraint reduces to true. > ``` > > In other words, if the actual type (S) has the null type, we never even > generate a bound for lub to contemplate - that subtyping constraint is > instead implicitly satisfied. Which seems to suggest a pre-filtering > step (which is what the compiler does). > > Maurizio For method type inference, I agree that ?18.2 is clear enough not to involve 'null' in the LUB computation but ?15.28.1 might be more explicit, at my mind. Another option on spec side would be to factorize this logic directly in ?4.10.4 (LUB computation). On an implementation perspective and without any precise requirement from the spec, I believe this would be more robust to have the 'null' handling directly in Types::lub or at least a comment to warn about that. But for now on, I agree that Jan's solution would be suitable enough, although I strongly believe some refactoring would be necessary in this area since the following lines seem still obscure to me, as said previously: @@ -3970,33 +3970,29 @@ case CLASS_BOUND: // calculate lub(A, B) - int startIdx = 0; - for (int i = 0; i < ts.length ; i++) { - Type t = ts[i]; - if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { - break; - } else { - startIdx++; - } - } - Assert.check(startIdx < ts.length); Should I file a JBS issue to keep track of this along with the patch I'm suggesting? Bernard From vromero at openjdk.java.net Mon Oct 12 13:46:21 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 12 Oct 2020 13:46:21 GMT Subject: RFR: 8254286: Wrong inference in switch expression with "null" arm In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:08:36 GMT, Jan Lahoda wrote: > Basically, for code like: > > var t1 = switch (s) { > case 1 -> i1; > case 2 -> null; > default -> i2; > }; > > Attr.condType is currently passing , BOT, to Types.lub. But Types.lub needs the list without > BOT, so filtering BOT(s) out of the list. looks sensible ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/583 From maurizio.cimadamore at oracle.com Mon Oct 12 15:11:35 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 12 Oct 2020 16:11:35 +0100 Subject: LUB computation involving NULL In-Reply-To: References: Message-ID: <8c69a2e3-0a57-fcbe-ba8f-dbc12ae9194e@oracle.com> I agree that the lub implementation should at least check for absence of null types (since that's not how this function is supposed to be used). Maurizio On 12/10/2020 13:09, B. Blaser wrote: > Hi Maurizio, > > On Mon, 12 Oct 2020 at 12:32, Maurizio Cimadamore > wrote: >> >> On 10/10/2020 15:43, B. Blaser wrote: >>> Hi, >>> >>> This one is interesting. >>> >>> Unless I read JLS15 too quickly, neither ?15.28.1 mandates explicitly >>> to skip null types before computing the LUB: >>> >>> "Otherwise, boxing conversion (?5.1.7) is applied to each result >>> expression that has a primitive type, after which the type of the >>> switch expression is the result of applying capture conversion >>> (?5.1.10) to the least upper bound (?4.10.4) of the types of the >>> result expressions." >>> >>> nor ?4.10.4 explicitly specifies how to handle them. >>> >>> So, ignoring null types not to interfere with this computation seems >>> implicitly deduced from the fact that they can match any reference >>> type and Jan's pull request [1] looks therefore reasonable. >>> >>> However, compilation currently succeeds with the first arm being null >>> (as initially reported), suggesting probably to fix this more directly >>> in Types::lub as here under (langtools:tier1 being OK on jdk14u). >> For method type inference, we already filter types before applying lub. >> I think we should do the same here. Of course we could also fix deeper, >> but I think it's better to start simple. >> >> From a spec perspective, I think the filtering is implicit in 18.2. >> >> ``` >> A constraint formula of the form ?S <: T? is reduced as follows: >> >> ... >> >> Otherwise, if S is the null type, the constraint reduces to true. >> ``` >> >> In other words, if the actual type (S) has the null type, we never even >> generate a bound for lub to contemplate - that subtyping constraint is >> instead implicitly satisfied. Which seems to suggest a pre-filtering >> step (which is what the compiler does). >> >> Maurizio > For method type inference, I agree that ?18.2 is clear enough not to > involve 'null' in the LUB computation but ?15.28.1 might be more > explicit, at my mind. Another option on spec side would be to > factorize this logic directly in ?4.10.4 (LUB computation). > > On an implementation perspective and without any precise requirement > from the spec, I believe this would be more robust to have the 'null' > handling directly in Types::lub or at least a comment to warn about > that. > > But for now on, I agree that Jan's solution would be suitable enough, > although I strongly believe some refactoring would be necessary in > this area since the following lines seem still obscure to me, as said > previously: > > @@ -3970,33 +3970,29 @@ > > case CLASS_BOUND: > // calculate lub(A, B) > - int startIdx = 0; > - for (int i = 0; i < ts.length ; i++) { > - Type t = ts[i]; > - if (t.hasTag(CLASS) || t.hasTag(TYPEVAR)) { > - break; > - } else { > - startIdx++; > - } > - } > - Assert.check(startIdx < ts.length); > > Should I file a JBS issue to keep track of this along with the patch > I'm suggesting? > > Bernard From vromero at openjdk.java.net Mon Oct 12 21:35:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 12 Oct 2020 21:35:36 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v11] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=10 Stats: 856 lines in 109 files changed: 64 ins; 552 del; 240 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From weijun at openjdk.java.net Tue Oct 13 12:35:26 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Oct 2020 12:35:26 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v5] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: support rfc5652 CMSAlgorithmProtection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/322/files - new: https://git.openjdk.java.net/jdk/pull/322/files/fecf30d7..81513907 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=03-04 Stats: 72 lines in 5 files changed: 65 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From herrick at openjdk.java.net Tue Oct 13 12:59:22 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 13 Oct 2020 12:59:22 GMT Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage Message-ID: JDK-8252870: Finalize (remove "incubator" from) jpackage ------------- Commit messages: - JDK-8252870: Finalize (remove "incubator" from) jpackage - 8252869 Finalize (remove incubator from) jpackage (implementation) Changes: https://git.openjdk.java.net/jdk/pull/633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252870 Stats: 1796 lines in 262 files changed: 723 ins; 732 del; 341 mod Patch: https://git.openjdk.java.net/jdk/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633 PR: https://git.openjdk.java.net/jdk/pull/633 From weijun at openjdk.java.net Tue Oct 13 13:34:27 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Oct 2020 13:34:27 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v6] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: support rfc6211 CMSAlgorithmProtection ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/322/files - new: https://git.openjdk.java.net/jdk/pull/322/files/81513907..ffaae532 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Tue Oct 13 13:34:27 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Oct 2020 13:34:27 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v6] In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 14:09:26 GMT, Weijun Wang wrote: >> Changes requested by alanb (Reviewer). > > Note: I force pushed a new commit to correct a typo in the summary line. Add support for [RFC 6211: Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute](https://tools.ietf.org/html/rfc6211) to protect against algorithm substitution attacks. This attribute is signed and it contains copies of digestAlgorithm and signatureAlgorithm which are unprotected in SignerInfo. Before this enhancement, the two algorithms can be implied from the signature itself (i.e. if you change any of them the signature size would not match or the key will not decrypt). However, with the introduction of RSASSA-PSS, the signature algorithm can be modified and it still looks like the signature is valid. This particular case is [described in the RFC](https://tools.ietf.org/html/rfc6211#page-5): signatureAlgorithm has been protected by implication in the past. The use of an RSA public key implied that the RSA v1.5 signature algorithm was being used. The hash algorithm and this fact could be checked by the internal padding defined. This is no longer true with the addition of the RSA-PSS signature algorithms. ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From weijun at openjdk.java.net Tue Oct 13 13:34:27 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 13 Oct 2020 13:34:27 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v6] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:24:50 GMT, Weijun Wang wrote: >> Note: I force pushed a new commit to correct a typo in the summary line. > > Add support for [RFC 6211: Cryptographic Message Syntax (CMS) Algorithm Identifier Protection > Attribute](https://tools.ietf.org/html/rfc6211) to protect against algorithm substitution attacks. This attribute is > signed and it contains copies of digestAlgorithm and signatureAlgorithm which are unprotected in SignerInfo. Before > this enhancement, the two algorithms can be implied from the signature itself (i.e. if you change any of them the > signature size would not match or the key will not decrypt). However, with the introduction of RSASSA-PSS, the > signature algorithm can be modified and it still looks like the signature is valid. This particular case is [described > in the RFC](https://tools.ietf.org/html/rfc6211#page-5): > signatureAlgorithm has been protected by implication in the past. > The use of an RSA public key implied that the RSA v1.5 signature > algorithm was being used. The hash algorithm and this fact could > be checked by the internal padding defined. This is no longer > true with the addition of the RSA-PSS signature algorithms. A force push to fix the RFC number typo in the latest commit. No content update. ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From kcr at openjdk.java.net Tue Oct 13 13:54:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 13 Oct 2020 13:54:14 GMT Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:49:13 GMT, Kevin Rushforth wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week. @andyherrick the "reviewer credit" command should not be used in this manner. It is intended for the case where an offline review of a PR has been done elsewhere and you wish to record that in the commit. It is not how you ask someone to do a review. ------------- PR: https://git.openjdk.java.net/jdk/pull/633 From kcr at openjdk.java.net Tue Oct 13 13:54:14 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 13 Oct 2020 13:54:14 GMT Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 12:51:54 GMT, Andy Herrick wrote: > JDK-8252870: Finalize (remove "incubator" from) jpackage I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week. make/data/symbols/jdk.jpackage-E.sym.txt line 29: > 27: # ########################################################## > 28: # > 29: module name jdk.jpackage I think you need to revert this. Note this comment: # ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ### make/data/symbols/symbols line 40: > 38: platform version C base B files > java.base-C.sym.txt:java.compiler-C.sym.txt:java.desktop-C.sym.txt:java.naming-C.sym.txt:java.rmi-C.sym.txt:java.xml-C.sym.txt:jdk.compiler-C.sym.txt:jdk.jfr-C.sym.txt:jdk.jsobject-C.sym.txt:jdk.unsupported-C.sym.txt > 39: platform version D base C files > java.base-D.sym.txt:java.compiler-D.sym.txt:java.desktop-D.sym.txt:java.management-D.sym.txt:java.management.rmi-D.sym.txt:java.net.http-D.sym.txt:java.security.jgss-D.sym.txt:java.xml-D.sym.txt:java.xml.crypto-D.sym.txt:jdk.compiler-D.sym.txt:jdk.httpserver-D.sym.txt:jdk.jartool-D.sym.txt:jdk.javadoc-D.sym.txt:jdk.jlink-D.sym.txt:jdk.jshell-D.sym.txt > 40: platform version E base D files > java.base-E.sym.txt:java.compiler-E.sym.txt:java.desktop-E.sym.txt:java.xml-E.sym.txt:jdk.compiler-E.sym.txt:jdk.httpserver-E.sym.txt:jdk.incubator.foreign-E.sym.txt:jdk.jpackage-E.sym.txt:jdk.jfr-E.sym.txt:jdk.jlink-E.sym.txt:jdk.jshell-E.sym.txt:jdk.jsobject-E.sym.txt:jdk.management-E.sym.txt:jdk.net-E.sym.txt:jdk.pack-E.sym.txt Similarly, I think you need to revert this. src/jdk.jpackage/share/classes/module-info.java line 49: > 47: */ > 48: > 49: module jdk.jpackage { Change to `@since 16` ------------- PR: https://git.openjdk.java.net/jdk/pull/633 From kcr at openjdk.java.net Tue Oct 13 14:34:20 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 13 Oct 2020 14:34:20 GMT Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:51:27 GMT, Kevin Rushforth wrote: >> I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week. > > @andyherrick the "reviewer credit" command should not be used in this manner. It is intended for the case where an > offline review of a PR has been done elsewhere and you wish to record that in the commit. It is not how you ask someone > to do a review. You can't directly, so I usually just mention in a comment who I want to review it. If you use their GitHub username it will notify them (unless they have disabled all notifications). Something like this: @prrace @kevinrushforth @sashamatveev @alexeysemenyukoracle please review ------------- PR: https://git.openjdk.java.net/jdk/pull/633 From herrick at openjdk.java.net Tue Oct 13 14:48:40 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Tue, 13 Oct 2020 14:48:40 GMT Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2] In-Reply-To: References: Message-ID: > JDK-8252870: Finalize (remove "incubator" from) jpackage Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8252870: Finalize (remove "incubator" from) jpackage - reverting two auto-generated files, and changing module-info to "@since 16" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/633/files - new: https://git.openjdk.java.net/jdk/pull/633/files/4b95b41c..4b1e6363 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00-01 Stats: 64 lines in 4 files changed: 31 ins; 31 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633 PR: https://git.openjdk.java.net/jdk/pull/633 From vicente.romero at oracle.com Tue Oct 13 19:51:34 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 13 Oct 2020 15:51:34 -0400 Subject: RFR: JDK-8254105: allow static members in inner classes Message-ID: <03482eb6-6f68-bf8a-6bf6-db3ab9df3881@oracle.com> Hi, I'm not sure if github sent any email about this review, could you please take a look at this PR [1]? Thanks, Vicente [1] https://github.com/openjdk/jdk/pull/571 From weijun at openjdk.java.net Wed Oct 14 03:51:23 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 14 Oct 2020 03:51:23 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v7] In-Reply-To: References: Message-ID: > Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature > algorithms > > - A new JarSigner property "directsign" > > - Updating the jarsigner tool doc > > Major code changes: > > - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm > there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: signing time, jarsigner -directsign, and digest algorithm check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/322/files - new: https://git.openjdk.java.net/jdk/pull/322/files/ffaae532..734fd034 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=05-06 Stats: 53 lines in 5 files changed: 42 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From valeriep at openjdk.java.net Wed Oct 14 04:03:14 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 14 Oct 2020 04:03:14 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v6] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 13:34:27 GMT, Weijun Wang wrote: >> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: >> >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >> >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature >> algorithms >> >> - A new JarSigner property "directsign" >> >> - Updating the jarsigner tool doc >> >> Major code changes: >> >> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm >> there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. >> >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > Weijun Wang has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 113: > 111: } > 112: > 113: public AlgorithmId(ObjectIdentifier oid, DerValue params) Now that this is public, can we add a javadoc spec for it? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 50: > 48: > 49: /** > 50: * Convent OID.1.2.3.4 or 1.2.3.4 to the matched stdName. Convent => Convert? matched => matching? Or maybe just "Match OID..... to the stdName" src/java.base/share/classes/sun/security/util/SignatureUtil.java line 53: > 51: * > 52: * @param algName input, could be in any form > 53: * @return the original name is it does not look like an OID, is => if? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 54: > 52: * @param algName input, could be in any form > 53: * @return the original name is it does not look like an OID, > 54: * the matched name for an OID, or the OID itself Maybe use "the OID value"? The term "itself" reminds me of the specified argument somehow. Just nit. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 94: > 92: * @return an AlgorithmParameterSpec object > 93: * @throws ProviderException > 94: */ Well, I am a bit unsure about your changes to this method. With your change, it returns default parameter spec (instead of null) when the specified AlgorithmParameters object is null. This may not be desirable for all cases? Existing callers would have to check for (params != null) before calling this method. The javadoc description also seems a bit strange with the to-be-converted AlgorithmParameters object being optional. Maybe add a separate method like `getParamSpecWithDefault` on top of this method or add a separate boolean argument `useDefault`? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 164: > 162: } > 163: } else { > 164: paramSpec = getDefaultAlgorithmParameterSpec(sigName, null); Same comment here as for the getParamSpec(String, AlgorithmParameters) above. Given that there are two methods named getParamSpec(...), maybe add a boolean argument to indicate whether to return default value if the to-be-converted object is null? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 290: > 288: * that must be initialized with a AlgorithmParameterSpec now. > 289: */ > 290: public static AlgorithmParameterSpec getDefaultAlgorithmParameterSpec( Maybe we can just use "getDefaultParamSpec" to match other methods' name in this class. Just a suggestion. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 511: > 509: } > 510: > 511: // Same values for RSA and DSA Update the comment with "Return the default message digest algorithm with the same security strength as the specified IFC/FFC key size"? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 499: > 497: } > 498: > 499: // Values from SP800-57 part 1 rev 4 tables 2 and 3 Update the comment with "Return the default message digest algorithm with the same security strength as the specified EC key size"? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 367: > 365: * @param sigEngine the signature object > 366: * @param key the private key > 367: * @return the AlgorithmIA, not null IA => Id? src/java.base/share/classes/sun/security/util/SignatureUtil.java line 268: > 266: > 267: /** > 268: * Extracts the digest algorithm names from a signature names => name src/java.base/share/classes/sun/security/util/SignatureUtil.java line 205: > 203: try { > 204: sha512 = AlgorithmId.get(KnownOIDs.SHA_512.stdName()); > 205: shake256 = AlgorithmId.get(KnownOIDs.SHAKE256.stdName()); For these two, why not just do `new AlgorithmId(ObjectIdentifier.of(ko))` where ko = KnownOIDs.SHA_512, KnownOIDs.SHAKE256? More direct this way. ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From valeriep at openjdk.java.net Wed Oct 14 04:07:19 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 14 Oct 2020 04:07:19 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v7] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 03:51:23 GMT, Weijun Wang wrote: >> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: >> >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >> >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature >> algorithms >> >> - A new JarSigner property "directsign" >> >> - Updating the jarsigner tool doc >> >> Major code changes: >> >> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm >> there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. >> >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > signing time, jarsigner -directsign, and digest algorithm check src/java.base/share/classes/sun/security/util/KnownOIDs.java line 147: > 145: SHAKE128("2.16.840.1.101.3.4.2.11"), > 146: SHAKE256("2.16.840.1.101.3.4.2.12"), > 147: SHAKE256_LEN("2.16.840.1.101.3.4.2.18", "SHAKE256-LEN"), Can we move this down a little? The ordering within the section is based on the oid value. It's easier to check for unlisted/unsupported oid value this way. Why not also add SHAKE128_LEN? ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From github.com+13688759+lgxbslgx at openjdk.java.net Wed Oct 14 13:18:23 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Wed, 14 Oct 2020 13:18:23 GMT Subject: RFR: 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation Message-ID: Hi all, The Java Language Specifications(JLS), from 8 to 13 included, state it as below: > If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T , then T is applicable in all declaration contexts except type parameter declarations, and in no type contexts. These contexts are the syntactic locations where annotations were allowed in Java SE 7. The JLS 14 and 15 state it as below: >If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T , then T is applicable in all nine declaration contexts and in all 16 type contexts. This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation Changes: https://git.openjdk.java.net/jdk/pull/622/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=622&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254023 Stats: 82 lines in 4 files changed: 81 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/622/head:pull/622 PR: https://git.openjdk.java.net/jdk/pull/622 From valeriep at openjdk.java.net Wed Oct 14 19:03:13 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 14 Oct 2020 19:03:13 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v7] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 03:51:23 GMT, Weijun Wang wrote: >> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: >> >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >> >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature >> algorithms >> >> - A new JarSigner property "directsign" >> >> - Updating the jarsigner tool doc >> >> Major code changes: >> >> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm >> there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. >> >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > signing time, jarsigner -directsign, and digest algorithm check src/java.base/share/classes/sun/security/util/SignatureUtil.java line 210: > 208: new DerValue((byte) 2, new byte[]{2, 0})); // int 512 > 209: } catch (IOException | NoSuchAlgorithmException e) { > 210: throw new AssertionError("Shoudl not happen", e); Shoudl => Should src/java.base/share/classes/sun/security/util/SignatureUtil.java line 215: > 213: } > 214: /** > 215: * Determines the digestEncryptionAlgorithmId in PKCS& SignerInfo. &=>7 src/java.base/share/classes/sun/security/util/SignatureUtil.java line 217: > 215: * Determines the digestEncryptionAlgorithmId in PKCS& SignerInfo. > 216: * > 217: * @param signer Signature object that tells you RSASA-PSS params RSASA=>RSASSA src/java.base/share/classes/sun/security/util/SignatureUtil.java line 221: > 219: * @param privateKey key tells you EdDSA params > 220: * @param directsign Ed448 uses different digest algs depending on this > 221: * @return the digest alg alg => algid src/java.base/share/classes/sun/security/util/SignatureUtil.java line 218: > 216: * > 217: * @param signer Signature object that tells you RSASA-PSS params > 218: * @param sigalg Signature algorithm tells you who with who who with who? ------------- PR: https://git.openjdk.java.net/jdk/pull/322 From bsrbnd at gmail.com Thu Oct 15 14:56:18 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 15 Oct 2020 16:56:18 +0200 Subject: Intersection type and method ref bug ? In-Reply-To: References: <1315346770.317146.1540375538284.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, Resurrecting this old thread as the following expression: Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); still throws a LCE at runtime: "Type mismatch for lambda argument 0: class Test$C is not convertible to interface Test$I". >From 'Stream::of' we have 'Stream' and then: Stream map(Function mapper); Further, wildcards are removed per JLS15 ?9.9 resulting to the functional descriptor 'apply(C & I)' finally erased to 'apply(C)' which isn't convertible to 'lambda$main$0(Test$I)' that javac currently generates, failing to detect the intersection type 'C & I'. The following patch adds the missing lines to 'LambdaToMethod' on jdk14u (langtools:tier1 is OK). What do you think? Bernard diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java @@ -968,6 +968,10 @@ // If the unerased parameter type is a type variable whose // bound is an intersection (eg. ) then // use the SAM parameter type + if (checkForIntersection && descPTypes.head.getKind() == TypeKind.INTERSECTION) { + parmType = samPTypes.head; + } + if (checkForIntersection && descPTypes.head.getKind() == TypeKind.TYPEVAR) { TypeVar tv = (TypeVar) descPTypes.head; if (tv.getUpperBound().getKind() == TypeKind.INTERSECTION) { On Fri, 26 Oct 2018 at 15:21, Vicente Romero wrote: > > Hi Remi, Francois, > > Thanks for reporting this. I have created [1] to track this issue, > > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8213032 > > On 10/24/18 6:05 AM, Remi Forax wrote: > > This bug was discovered by Francois Green when testing records, but the bug is independent of the record, > > method reference and intersection type doesn't mix well. > > > > public class RecordBadType { > > interface I {} > > static abstract class C { } > > static class A extends C implements I { } > > static class B extends C implements I { } > > > > static String f(I i) { return null; } > > > > public static void main(String[] args) { > > Stream.of(new A(), new B()) > > .map(RecordBadType::f) // here the compiler should generate a bridge method no ? > > .forEach(System.out::println); > > } > > } > > > > this code compiles but you get a LambdaConversionException at runtime. > > > > R?mi > From vromero at openjdk.java.net Fri Oct 16 00:35:21 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Oct 2020 00:35:21 GMT Subject: RFR: 8254784: javac should reject records with @SafeVarargs applied to varargs record component Message-ID: Please review this fix for issue [1]. This is the background, for a record defined like: record R(@SafeVarargs String... s) {} an the following accessor will be generated: `@SafeVararags public String[] s() { return s; }` this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr. We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. The proposed fix is to issue an error as soon as the compiler finds out that the @SVA annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code. TIA for the reviews, Vicente [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784) ------------- Commit messages: - 8254784: javac should reject records with @SafeVarargs applied to varargs record component Changes: https://git.openjdk.java.net/jdk/pull/690/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=690&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254784 Stats: 62 lines in 4 files changed: 58 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/690.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/690/head:pull/690 PR: https://git.openjdk.java.net/jdk/pull/690 From jlahoda at openjdk.java.net Fri Oct 16 15:27:22 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 16 Oct 2020 15:27:22 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 Message-ID: This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. The notable changes are: * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings * improving error/warning messages. Please see [1] for a list of cases/examples. * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. Please also see the CSR [6] for more information. [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 ------------- Commit messages: - Fixing tests. - Various cleanup. - The Preview taglet is not needed anymore. - There is not jdk.internal package anymore - No, jdk.incubator.vector does not need jdk.internal package. - Merging master into JDK-8250768 - Fixing tests. - Adding forgotten files. - Updating build. - Post-merge fix. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9359ff03...efb37a9b Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250768 Stats: 3179 lines in 158 files changed: 2487 ins; 410 del; 282 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From mcimadamore at openjdk.java.net Fri Oct 16 16:12:11 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 16 Oct 2020 16:12:11 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com> On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc > behavior to more closely adhere to JEP 12. > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs > associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, > false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the > preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as > preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a > note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of > preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring > elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] > http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 I've done a quick pass over the javac changes, things look good, apart from some (minor) comments. I'm a bit worried about the scalability of the output in this page: http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/use/Factory.html E.g. if the types which use preview features are a lot (e.g. 50), what would the text inside the black box look like? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 108: > 106: Modules modules; > 107: JCDiagnostic.Factory diags; > 108: Preview preview; Are these changes spurious? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3565: > 3563: } > 3564: } > 3565: private boolean declaredUsingPreviewFeature(Symbol sym) { I wonder, maybe this routine should go in Preview.java? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2649: > 2647: } > 2648: if (isRecordStart() && allowRecords) { > 2649: checkSourceLevel(Feature.RECORDS); Is this change really related to the JEP 12? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3713: > 3711: return classDeclaration(mods, dc); > 3712: } if (isRecordStart()) { > 3713: checkSourceLevel(Feature.RECORDS); Same here src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 166: > 164: s = "compiler.misc.tree.tag." + StringUtils.toLowerCase(((Tag) arg).name()); > 165: } else if (arg instanceof Source && arg == Source.DEFAULT && > 166: CODES_NEEDING_SOURCE_NORMALIZATION.contains(diag.getCode())) { Nice trick to keep raw output constant across versions :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From erikj at openjdk.java.net Fri Oct 16 16:50:12 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 16 Oct 2020 16:50:12 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc > behavior to more closely adhere to JEP 12. > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs > associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, > false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the > preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as > preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a > note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of > preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring > elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] > http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Fri Oct 16 17:26:10 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 16 Oct 2020 17:26:10 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc > behavior to more closely adhere to JEP 12. > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs > associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, > false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the > preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as > preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a > note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of > preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring > elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] > http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 209: > 207: "sealed".equals(modifiersPart) || "non-sealed".equals(modifiersPart)) { > 208: pre.add(modifiersPart); > 209: pre.add(new HtmlTree(TagName.SUP).add(HtmlTree.A("#preview", contents.previewMark))); This will likely clash with a public field named "preview". You should choose a name for the anchor that is not a Java identifier. Also, in general, it is better to use the `Links` class if possible to create links. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Fri Oct 16 20:02:19 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 16 Oct 2020 20:02:19 GMT Subject: RFR: 8253385: annotation processors remove varargs information from record components Message-ID: Please review this fix for a corner case bug. Essentially for code like: import java.lang.annotation.*; @Target({ElementType.TYPE_USE}) @interface Simple {} record R(@Simple int ...val) { static void test() { R rec = new R(10, 20); } } assuming that there is an AP present, after the first annotation processing round, the record component's symbol is set to `null` and thus the flags info is lost. So once the symbols and their types are determined again after every annotation processing round, there is no recollection that the record component was a varargs. Remember that the AST for the record component declaration is not kept but it is used to extract information from it and to derive compiler generated code like fields, canonical constructor, etc. The proposed solution is to keep the information about the vararg-ness of the record component in a dedicated field in the record component so that this information can be recovered later on as needed. TIA, Vicente ------------- Commit messages: - 8253385: annotation processors remove varargs information from record components Changes: https://git.openjdk.java.net/jdk/pull/709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253385 Stats: 44 lines in 2 files changed: 43 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/709/head:pull/709 PR: https://git.openjdk.java.net/jdk/pull/709 From github.com+13688759+lgxbslgx at openjdk.java.net Sat Oct 17 13:27:19 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Sat, 17 Oct 2020 13:27:19 GMT Subject: RFR: 8254557: Compiler crashes with java.lang.AssertionError: isSubtype UNKNOWN Message-ID: Hi all, [JDK-8254557](https://bugs.openjdk.java.net/browse/JDK-8254557) is similar to [JDK-8203277](https://bugs.openjdk.java.net/browse/JDK-8203277). The method `Attr.preFlow` shouldn't visit class definitions and lambda expressions that have not yet been entered and attributed. The [JDK-8181287](https://bugs.openjdk.java.net/browse/JDK-8231826) submitted some code that uses `Attr.preFlow` which causes this bug. Thank you for taking the time to review. Best Regards. ------------- Commit messages: - Polish some comments. - 8254557: Compiler crashes with java.lang.AssertionError: isSubtype UNKNOWN Changes: https://git.openjdk.java.net/jdk/pull/718/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=718&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254557 Stats: 145 lines in 2 files changed: 145 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/718/head:pull/718 PR: https://git.openjdk.java.net/jdk/pull/718 From vromero at openjdk.java.net Sun Oct 18 16:12:22 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:12:22 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v12] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-8246774 - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 16:40:31 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:40:31 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v13] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing reference to unused jcod file from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/5bfbde59..3e472bc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11-12 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 18:58:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 18:58:16 GMT Subject: Integrated: 8246774: implement Record Classes as a standard feature in Java In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:30:51 GMT, Vicente Romero wrote: > 8246774: implement Record Classes as a standard feature in Java This pull request has now been integrated. Changeset: c17d5851 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/c17d5851 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod 8246774: implement Record Classes as a standard feature in Java Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Chris Hegarty Reviewed-by: coleenp, jlahoda, sspitsyn, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Mon Oct 19 02:08:15 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 19 Oct 2020 02:08:15 GMT Subject: Integrated: 8253455: Record Classes javax.lang.model changes In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: On Mon, 21 Sep 2020 23:31:51 GMT, Vicente Romero wrote: > Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort > to make records a final feature of the Java Language. The rest of the code has been published in > [PR#290](https://github.com/openjdk/jdk/pull/290) Thanks, > Vicente This pull request has now been integrated. Changeset: 272bb5d5 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/272bb5d5 Stats: 144 lines in 12 files changed: 5 ins; 126 del; 13 mod 8253455: Record Classes javax.lang.model changes Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From joel.p.borggren-franck at oracle.com Mon Oct 19 09:48:57 2020 From: joel.p.borggren-franck at oracle.com (=?UTF-8?Q?Joel_Borggr=c3=a9n-Franck?=) Date: Mon, 19 Oct 2020 11:48:57 +0200 Subject: Spec clarification, where are annotations without @Target applicable? Message-ID: <3fa4dbc0-cd73-b606-66a0-820852147bf3@oracle.com> Hello JLS experts, When reviewing the proposed fix for annotations not being applicable to modules by default [3] I noticed that the Javadoc [1] and JLS wording [2] for which annotation contexts are applicable by default have diverged since Java 14. The javaoc for j.l.a.Target keeps the old wording: "If an @Target meta-annotation is not present on an annotation type T, then an annotation of type T may be written as a modifier for any declaration except a type parameter declaration." While the JLS since 14 states: "If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T, then T is applicable in all nine declaration contexts and in all 16 type contexts." vs JLS 13: "If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T, then T is applicable in all declaration contexts except type parameter declarations, and in no type contexts. These contexts are the syntactic locations where annotations were allowed in Java SE 7." I can't find any mention of this change in a CSR so it is not yet clear to me if the Javadoc or the JLS needs to be updated. cheers /Joel [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html [2] https://docs.oracle.com/javase/specs/jls/se15/html/jls-9.html#jls-9.6.4.1 [3] https://github.com/openjdk/jdk/pull/622 From brian.goetz at oracle.com Mon Oct 19 10:34:26 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 19 Oct 2020 06:34:26 -0400 Subject: Spec clarification, where are annotations without @Target applicable? In-Reply-To: <3fa4dbc0-cd73-b606-66a0-820852147bf3@oracle.com> References: <3fa4dbc0-cd73-b606-66a0-820852147bf3@oracle.com> Message-ID: <5741F31D-9589-4538-A0D8-9A27C929F194@oracle.com> The JLS 13 text seems right to me. The ambiguity between deco and type contexts makes ?all contexts? problematic. I don?t recall this change as a ?decision?. Sent from my iPad > On Oct 19, 2020, at 5:49 AM, Joel Borggr?n-Franck wrote: > > ?Hello JLS experts, > > When reviewing the proposed fix for annotations not being applicable to modules by default [3] I noticed that the Javadoc [1] and JLS wording [2] for which annotation contexts are applicable by default have diverged since Java 14. The javaoc for j.l.a.Target keeps the old wording: > > "If an @Target meta-annotation is not present on an annotation type T, then an annotation of type T may be written as a modifier for any declaration except a type parameter declaration." > > While the JLS since 14 states: > > "If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T, then T is applicable in all nine declaration contexts and in all 16 type contexts." > > vs JLS 13: > > "If an annotation of type java.lang.annotation.Target is not present on the declaration of an annotation type T, then T is applicable in all declaration contexts except type parameter declarations, and in no type contexts. > > These contexts are the syntactic locations where annotations were allowed in Java SE 7." > > I can't find any mention of this change in a CSR so it is not yet clear to me if the Javadoc or the JLS needs to be updated. > > cheers > /Joel > > [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html > [2] https://docs.oracle.com/javase/specs/jls/se15/html/jls-9.html#jls-9.6.4.1 > [3] https://github.com/openjdk/jdk/pull/622 > From jfranck at openjdk.java.net Mon Oct 19 11:10:16 2020 From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=) Date: Mon, 19 Oct 2020 11:10:16 GMT Subject: RFR: 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 04:02:36 GMT, Guoxiong Li wrote: > Hi all, > > The Java Language Specifications(JLS), from 8 to 13 included, state it as below: > >> If an annotation of type java.lang.annotation.Target is not present on the > declaration of an annotation type T , then T is applicable in all declaration contexts > except type parameter declarations, and in no type contexts. > These contexts are the syntactic locations where annotations were allowed in Java SE 7. > > The JLS 14 and 15 state it as below: > >>If an annotation of type java.lang.annotation.Target is not present on the > declaration of an annotation type T , then T is applicable in all nine declaration > contexts and in all 16 type contexts. > > This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` > to fix this issue. Thank you for taking the time to review. > > Best Regards. Hello, Thank you for the contribution. As you can see from the @Target javadoc ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html ) there is some ambiguity here. I have rased a separate discussion on compiler-dev, depending on the outcome of that discussion this patch will need to be revised. ------------- PR: https://git.openjdk.java.net/jdk/pull/622 From wdietl at gmail.com Mon Oct 19 13:11:54 2020 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 19 Oct 2020 09:11:54 -0400 Subject: Spec clarification, where are annotations without @Target applicable? In-Reply-To: <5741F31D-9589-4538-A0D8-9A27C929F194@oracle.com> References: <3fa4dbc0-cd73-b606-66a0-820852147bf3@oracle.com> <5741F31D-9589-4538-A0D8-9A27C929F194@oracle.com> Message-ID: I think this is a relevant discussion: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html cu, WMD. On Mon, Oct 19, 2020 at 6:34 AM Brian Goetz wrote: > The JLS 13 text seems right to me. The ambiguity between deco and type > contexts makes ?all contexts? problematic. I don?t recall this change as a > ?decision?. > > Sent from my iPad > > > On Oct 19, 2020, at 5:49 AM, Joel Borggr?n-Franck < > joel.p.borggren-franck at oracle.com> wrote: > > > > ?Hello JLS experts, > > > > When reviewing the proposed fix for annotations not being applicable to > modules by default [3] I noticed that the Javadoc [1] and JLS wording [2] > for which annotation contexts are applicable by default have diverged since > Java 14. The javaoc for j.l.a.Target keeps the old wording: > > > > "If an @Target meta-annotation is not present on an annotation type T, > then an annotation of type T may be written as a modifier for any > declaration except a type parameter declaration." > > > > While the JLS since 14 states: > > > > "If an annotation of type java.lang.annotation.Target is not present on > the declaration of an annotation type T, then T is applicable in all nine > declaration contexts and in all 16 type contexts." > > > > vs JLS 13: > > > > "If an annotation of type java.lang.annotation.Target is not present on > the declaration of an annotation type T, then T is applicable in all > declaration contexts except type parameter declarations, and in no type > contexts. > > > > These contexts are the syntactic locations where annotations were > allowed in Java SE 7." > > > > I can't find any mention of this change in a CSR so it is not yet clear > to me if the Javadoc or the JLS needs to be updated. > > > > cheers > > /Joel > > > > [1] > https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html > > [2] > https://docs.oracle.com/javase/specs/jls/se15/html/jls-9.html#jls-9.6.4.1 > > [3] https://github.com/openjdk/jdk/pull/622 > > > > -- https://ece.uwaterloo.ca/~wdietl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannesw at openjdk.java.net Mon Oct 19 14:12:19 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 19 Oct 2020 14:12:19 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: Message-ID: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com> On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda wrote: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc > behavior to more closely adhere to JEP 12. > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs > associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, > false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the > preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as > preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a > note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of > preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring > elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] > http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238: > 2236: if (previewTree != null) { > 2237: previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview") > 2238: .add(new > RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false)))); The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as @jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do this would be to add the element name to the id value, e.g. `preview-`. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From hannesw at openjdk.java.net Mon Oct 19 14:25:11 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 19 Oct 2020 14:25:11 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com> References: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com> Message-ID: On Mon, 19 Oct 2020 14:09:51 GMT, Hannes Walln?fer wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc >> behavior to more closely adhere to JEP 12. >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs >> associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, >> false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the >> preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as >> preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a >> note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of >> preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring >> elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] >> http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238: > >> 2236: if (previewTree != null) { >> 2237: previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview") >> 2238: .add(new >> RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false)))); > > The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as > @jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do > this would be to add the element name to the id value, e.g. `preview-`. Of course the element name won't do for overloaded methods and constructors... `Links#getAnchor(ExecutableElement)` should be used for those. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Mon Oct 19 14:52:14 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 19 Oct 2020 14:52:14 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 In-Reply-To: References: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com> Message-ID: On Mon, 19 Oct 2020 14:22:17 GMT, Hannes Walln?fer wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238: >> >>> 2236: if (previewTree != null) { >>> 2237: previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview") >>> 2238: .add(new >>> RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false)))); >> >> The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as >> @jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do >> this would be to add the element name to the id value, e.g. `preview-`. > > Of course the element name won't do for overloaded methods and constructors... `Links#getAnchor(ExecutableElement)` > should be used for those. Uh, originally, there was only preview section per file, and I didn't fully realize the JDK's javadoc may have multiple such section. I'll work on this. Thanks for the pointer! ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Mon Oct 19 15:21:30 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 19 Oct 2020 15:21:30 GMT Subject: RFR: 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon Message-ID: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> Hi, I pushed the fixes for JDK-8246774 and JDK-8253455 too soon as the JEP is still not targeted so this fix will delta apply them until the JEP is finally targeted, Sorry for the noise, Vicente ------------- Commit messages: - 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon Changes: https://git.openjdk.java.net/jdk/pull/740/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=740&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255009 Stats: 1000 lines in 121 files changed: 688 ins; 77 del; 235 mod Patch: https://git.openjdk.java.net/jdk/pull/740.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/740/head:pull/740 PR: https://git.openjdk.java.net/jdk/pull/740 From jlahoda at openjdk.java.net Mon Oct 19 15:32:14 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 19 Oct 2020 15:32:14 GMT Subject: RFR: 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon In-Reply-To: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> References: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> Message-ID: On Mon, 19 Oct 2020 15:05:46 GMT, Vicente Romero wrote: > Hi, > > I pushed the fixes for JDK-8246774 and JDK-8253455 too soon as the JEP is still not targeted so this fix will delta > apply them until the JEP is finally targeted, > Sorry for the noise, > Vicente Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/740 From jlahoda at openjdk.java.net Mon Oct 19 15:32:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 19 Oct 2020 15:32:16 GMT Subject: RFR: 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon In-Reply-To: References: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> Message-ID: On Mon, 19 Oct 2020 15:29:35 GMT, Jan Lahoda wrote: >> Hi, >> >> I pushed the fixes for JDK-8246774 and JDK-8253455 too soon as the JEP is still not targeted so this fix will delta >> apply them until the JEP is finally targeted, >> Sorry for the noise, >> Vicente > > Marked as reviewed by jlahoda (Reviewer). Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/740 From vromero at openjdk.java.net Mon Oct 19 15:59:12 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 19 Oct 2020 15:59:12 GMT Subject: Integrated: 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon In-Reply-To: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> References: <4U5k9NvYcEEPLHyzTv4a2zebWXF-46fzvWae1T3NYDQ=.ae00c20a-7897-4443-8426-36b9341cdac8@github.com> Message-ID: On Mon, 19 Oct 2020 15:05:46 GMT, Vicente Romero wrote: > Hi, > > I pushed the fixes for JDK-8246774 and JDK-8253455 too soon as the JEP is still not targeted so this fix will delta > apply them until the JEP is finally targeted, > Sorry for the noise, > Vicente This pull request has now been integrated. Changeset: 1da28de8 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/1da28de8 Stats: 1000 lines in 121 files changed: 688 ins; 77 del; 235 mod 8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/740 From darcy at openjdk.java.net Tue Oct 20 01:36:22 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 20 Oct 2020 01:36:22 GMT Subject: RFR: 8254974: Fix stutter typo in TypeElement Message-ID: Fix "the the" stutter typo. ------------- Commit messages: - 8254974: Fix stutter typo in TypeElement Changes: https://git.openjdk.java.net/jdk/pull/754/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=754&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254974 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/754/head:pull/754 PR: https://git.openjdk.java.net/jdk/pull/754 From joe.darcy at oracle.com Tue Oct 20 02:32:50 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 19 Oct 2020 19:32:50 -0700 Subject: RFR: 8254974: Fix stutter typo in TypeElement In-Reply-To: References: Message-ID: <5435a980-9e86-1f9f-8db2-6bc683d565e9@oracle.com> Sorry for the noise; user error on my part with Git - will resend. -Joe On 10/19/2020 6:36 PM, Joe Darcy wrote: > Fix "the the" stutter typo. > > ------------- > > Commit messages: > - 8254974: Fix stutter typo in TypeElement > > Changes: https://git.openjdk.java.net/jdk/pull/754/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=754&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8254974 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/754.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/754/head:pull/754 > > PR: https://git.openjdk.java.net/jdk/pull/754 From darcy at openjdk.java.net Tue Oct 20 02:34:23 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 20 Oct 2020 02:34:23 GMT Subject: RFR: 8254974: Fix stutter typo in TypeElement [v2] In-Reply-To: References: Message-ID: > Fix "the the" stutter typo. Joe Darcy has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/754/files - new: https://git.openjdk.java.net/jdk/pull/754/files/3802146b..0f4fb367 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=754&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=754&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/754/head:pull/754 PR: https://git.openjdk.java.net/jdk/pull/754 From darcy at openjdk.java.net Tue Oct 20 02:34:24 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 20 Oct 2020 02:34:24 GMT Subject: Integrated: 8254974: Fix stutter typo in TypeElement In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 01:27:38 GMT, Joe Darcy wrote: > Fix "the the" stutter typo. This pull request has now been integrated. Changeset: 0f4fb367 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0f4fb367 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8255032: Conflict between recent pushes breaks the build Reviewed-by: redestad, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/754 From vromero at openjdk.java.net Tue Oct 20 03:19:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 20 Oct 2020 03:19:16 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda wrote: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type > (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved > and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop > Tree, etc. > > This change will not be integrated until JEP 394 is targetted. Changes requested by vromero (Reviewer). test/langtools/tools/javac/patterns/BindingsTest1.java line 28: > 26: * @bug 8231827 > 27: * @summary Basic tests for bindings from instanceof > 28: * @compile BindingsTest1.java the @compile can be removed test/langtools/tools/javac/patterns/BindingsTest1.java line 29: > 27: * @summary Basic tests for bindings from instanceof > 28: * @compile BindingsTest1.java > 29: * @run main BindingsTest1 and this line too test/langtools/tools/javac/patterns/ExamplesFromProposal.java line 29: > 27: * @summary All example code from "Pattern Matching for Java" document, released April 2017, adjusted to current > state (no switches, etc) 28: * @compile ExamplesFromProposal.java > 29: * @run main ExamplesFromProposal these two lines can be removed now, there are other tests in this commit in which they can also be eliminated test/langtools/tools/javac/patterns/LocalVariableTable.java line 29: > 27: * @summary Ensure the LV table entries are generated for bindings > 28: * @modules jdk.jdeps/com.sun.tools.classfile > 29: * @compile -g LocalVariableTable.java I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove that line as superfluous test/langtools/tools/javac/patterns/PatternsSimpleVisitorTest.java line 108: > 106: StringWriter out = new StringWriter(); > 107: JavacTask ct = (JavacTask) tool.getTask(out, null, noErrors, > 108: List.of(), null, nit: what about passing `null` instead of `List.of()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Oct 20 05:41:11 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 20 Oct 2020 05:41:11 GMT Subject: RFR: 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation In-Reply-To: References: Message-ID: <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com> On Mon, 19 Oct 2020 11:07:30 GMT, Joel Borggr?n-Franck wrote: >> Hi all, >> >> The Java Language Specifications(JLS), from 8 to 13 included, state it as below: >> >>> If an annotation of type java.lang.annotation.Target is not present on the >> declaration of an annotation type T , then T is applicable in all declaration contexts >> except type parameter declarations, and in no type contexts. >> These contexts are the syntactic locations where annotations were allowed in Java SE 7. >> >> The JLS 14 and 15 state it as below: >> >>>If an annotation of type java.lang.annotation.Target is not present on the >> declaration of an annotation type T , then T is applicable in all nine declaration >> contexts and in all 16 type contexts. >> >> This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` >> to fix this issue. Thank you for taking the time to review. >> >> Best Regards. > > Hello, > > Thank you for the contribution. > > As you can see from the @Target javadoc ( > https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html ) there is some ambiguity > here. I have rased a separate discussion on compiler-dev, depending on the outcome of that discussion this patch will > need to be revised. Thanks for focusing on this patch. I will continue to follow the discussion and revise my patch based on the outcome of the discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/622 From jlahoda at openjdk.java.net Tue Oct 20 10:09:25 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 20 Oct 2020 10:09:25 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Tue, 20 Oct 2020 03:02:03 GMT, Vicente Romero wrote: >> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. >> >> A summary of changes: >> -making the feature permanent (non-preview) >> -making the binding variables non-final (as per current specification proposal) >> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type >> (as per current specification proposal) >> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved >> and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop >> Tree, etc. >> >> This change will not be integrated until JEP 394 is targetted. > > test/langtools/tools/javac/patterns/BindingsTest1.java line 28: > >> 26: * @bug 8231827 >> 27: * @summary Basic tests for bindings from instanceof >> 28: * @compile BindingsTest1.java > > the @compile can be removed I guess I prefer to keep @compile for javac non-programatic tests. The reason is that, for these tests, we can expect we modify javac, but not the test. And if @build (implicit or explicit) is used, the test will not be re-compiled unless their timestamp changes. So we can actually execute an older (already built) version of the test's class file, instead of a newly built class file, which would reflect the changes in javac. So, for tests like this, I prefer to have an explicit @compile, as that ensures the file is compiled every time, regardless how the working directories are set-up, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Tue Oct 20 11:39:19 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 20 Oct 2020 11:39:19 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Tue, 20 Oct 2020 03:09:27 GMT, Vicente Romero wrote: >> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. >> >> A summary of changes: >> -making the feature permanent (non-preview) >> -making the binding variables non-final (as per current specification proposal) >> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type >> (as per current specification proposal) >> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved >> and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop >> Tree, etc. >> >> This change will not be integrated until JEP 394 is targetted. > > test/langtools/tools/javac/patterns/LocalVariableTable.java line 29: > >> 27: * @summary Ensure the LV table entries are generated for bindings >> 28: * @modules jdk.jdeps/com.sun.tools.classfile >> 29: * @compile -g LocalVariableTable.java > > I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove > that line as superfluous I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g, as the test itself requires the debugging info/LocalVariableTable? ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Tue Oct 20 12:15:23 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 20 Oct 2020 12:15:23 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc > behavior to more closely adhere to JEP 12. > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs > associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, > false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the > preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as > preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a > note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of > preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring > elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] > http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] > http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 - More fixing tests. - Fixing tests. - Using unique sections for preview warning sections, as suggested. - Merge branch 'master' into JDK-8250768 - Reflecting review comments. - Fixing tests. - Various cleanup. - The Preview taglet is not needed anymore. - There is not jdk.internal package anymore - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=01 Stats: 3206 lines in 156 files changed: 2515 ins; 409 del; 282 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Tue Oct 20 12:19:12 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 20 Oct 2020 12:19:12 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 16:47:25 GMT, Erik Joelsson wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 35 commits: >> - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 >> - More fixing tests. >> - Fixing tests. >> - Using unique sections for preview warning sections, as suggested. >> - Merge branch 'master' into JDK-8250768 >> - Reflecting review comments. >> - Fixing tests. >> - Various cleanup. >> - The Preview taglet is not needed anymore. >> - There is not jdk.internal package anymore >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 > > Build changes look good. I've updated the patch based on the comments: mostly updating the anchors in the javadoc, but also removing the updates to JavacParser, which are only loosely related to the primary focus of this patch, and should possibly be done separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From darcy at openjdk.java.net Tue Oct 20 12:53:20 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 20 Oct 2020 12:53:20 GMT Subject: RFR: 8254974: Fix stutter typo in TypeElement Message-ID: Fix "the the" stutter typo. ------------- Commit messages: - 8254974: Fix stutter typo in TypeElement Changes: https://git.openjdk.java.net/jdk/pull/755/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=755&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254974 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/755.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/755/head:pull/755 PR: https://git.openjdk.java.net/jdk/pull/755 From shade at openjdk.java.net Tue Oct 20 12:53:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 12:53:20 GMT Subject: RFR: 8254974: Fix stutter typo in TypeElement In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 02:47:44 GMT, Joe Darcy wrote: > Fix "the the" stutter typo. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/755 From redestad at openjdk.java.net Tue Oct 20 13:06:19 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 20 Oct 2020 13:06:19 GMT Subject: RFR: 8254974: Fix stutter typo in TypeElement In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 02:47:44 GMT, Joe Darcy wrote: > Fix "the the" stutter typo. Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/755 From mcimadamore at openjdk.java.net Tue Oct 20 13:27:26 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 20 Oct 2020 13:27:26 GMT Subject: RFR: 8254557: Compiler crashes with java.lang.AssertionError: isSubtype UNKNOWN In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 13:21:21 GMT, Guoxiong Li wrote: > Hi all, > > [JDK-8254557](https://bugs.openjdk.java.net/browse/JDK-8254557) is similar to > [JDK-8203277](https://bugs.openjdk.java.net/browse/JDK-8203277). The method `Attr.preFlow` shouldn't visit class > definitions and lambda expressions that have not yet been entered and attributed. > The [JDK-8181287](https://bugs.openjdk.java.net/browse/JDK-8231826) submitted some code that uses `Attr.preFlow` > which causes this bug. > Thank you for taking the time to review. > > Best Regards. Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/718 From mcimadamore at openjdk.java.net Tue Oct 20 13:40:22 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 20 Oct 2020 13:40:22 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 12:15:23 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc >> behavior to more closely adhere to JEP 12. >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs >> associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, >> false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the >> preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as >> preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a >> note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of >> preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring >> elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] >> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5] >> http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 35 commits: > - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 > - More fixing tests. > - Fixing tests. > - Using unique sections for preview warning sections, as suggested. > - Merge branch 'master' into JDK-8250768 > - Reflecting review comments. > - Fixing tests. > - Various cleanup. > - The Preview taglet is not needed anymore. > - There is not jdk.internal package anymore > - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 javac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From darcy at openjdk.java.net Tue Oct 20 14:50:12 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 20 Oct 2020 14:50:12 GMT Subject: Integrated: 8254974: Fix stutter typo in TypeElement In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 02:47:44 GMT, Joe Darcy wrote: > Fix "the the" stutter typo. This pull request has now been integrated. Changeset: 44f9271d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/44f9271d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254974: Fix stutter typo in TypeElement Reviewed-by: shade, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/755 From github.com+13688759+lgxbslgx at openjdk.java.net Tue Oct 20 15:48:17 2020 From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li) Date: Tue, 20 Oct 2020 15:48:17 GMT Subject: Integrated: 8254557: Compiler crashes with java.lang.AssertionError: isSubtype UNKNOWN In-Reply-To: References: Message-ID: On Sat, 17 Oct 2020 13:21:21 GMT, Guoxiong Li wrote: > Hi all, > > [JDK-8254557](https://bugs.openjdk.java.net/browse/JDK-8254557) is similar to > [JDK-8203277](https://bugs.openjdk.java.net/browse/JDK-8203277). The method `Attr.preFlow` shouldn't visit class > definitions and lambda expressions that have not yet been entered and attributed. > The [JDK-8181287](https://bugs.openjdk.java.net/browse/JDK-8231826) submitted some code that uses `Attr.preFlow` > which causes this bug. > Thank you for taking the time to review. > > Best Regards. This pull request has now been integrated. Changeset: cb6167b2 Author: Guoxiong Li Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/cb6167b2 Stats: 145 lines in 2 files changed: 145 ins; 0 del; 0 mod 8254557: Compiler crashes with java.lang.AssertionError: isSubtype UNKNOWN Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/718 From bsrbnd at gmail.com Tue Oct 20 18:46:29 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 20 Oct 2020 20:46:29 +0200 Subject: Experimental fix for capturing anonymous classes inside lambda (JDK-8229862) Message-ID: Hi, JDK-8229862 reveals that capturing anonymous classes inside lambda seem not to be properly implemented yet, although the opposite currently works fine in JDK-16 (see [1] or [2], for example). The following experimental fix (on jdk14u) searches for local variables captured by anonymous classes inside lambda (in LambdaToMethod) and translates them according to corresponding proxies (in Lower). What do you think (langtools:tier1 is OK)? Thanks, Bernard [1] test/langtools/tools/javac/lambda/T8209407/VerifierErrorInnerPlusLambda.java [2] test/langtools/tools/javac/lambda/methodReference/ProtectedInaccessibleMethodRefTest.java diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java @@ -1380,9 +1380,18 @@ super.visitIdent(tree); } + boolean inLambda = false; + @Override public void visitLambda(JCLambda tree) { - analyzeLambda(tree, "lambda.stat"); + boolean prevInLambda = inLambda; + try { + inLambda = true; + analyzeLambda(tree, "lambda.stat"); + } + finally { + inLambda = prevInLambda; + } } private void analyzeLambda(JCLambda tree, JCExpression methodReferenceReceiver) { @@ -1430,6 +1439,16 @@ @Override public void visitNewClass(JCNewClass tree) { + if (tree.def != null && inLambda) { + try { + inLambda = false; + visitClassDef(tree.def); + } + finally { + inLambda = true; + } + } + TypeSymbol def = tree.type.tsym; boolean inReferencedClass = currentlyInClass(def); boolean isLocal = def.isLocal(); diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java @@ -2812,7 +2812,14 @@ // If we have an anonymous class, create its flat version, rather // than the class or interface following new. if (tree.def != null) { - translate(tree.def); + Map prevLambdaTranslationMap = lambdaTranslationMap; + try { + lambdaTranslationMap = null; + translate(tree.def); + } finally { + lambdaTranslationMap = prevLambdaTranslationMap; + } + tree.clazz = access(make_at(tree.clazz.pos()).Ident(tree.def.sym)); tree.def = null; } else { From vromero at openjdk.java.net Tue Oct 20 18:54:21 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 20 Oct 2020 18:54:21 GMT Subject: RFR: 8255013: implement Record Classes as a standard feature in Java, follow-up Message-ID: Hi, I made the mistake of pushing the fix for [JDK-8246774](https://bugs.openjdk.java.net/browse/JDK-8246774) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-290](https://github.com/openjdk/jdk/pull/290), Thanks and sorry for the unnecessary loop, Vicente ------------- Commit messages: - 8255013: implement Record Classes as a standard feature in Java, follow-up Changes: https://git.openjdk.java.net/jdk/pull/769/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=769&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255013 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/769/head:pull/769 PR: https://git.openjdk.java.net/jdk/pull/769 From vromero at openjdk.java.net Tue Oct 20 18:58:20 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 20 Oct 2020 18:58:20 GMT Subject: RFR: 8255014: Record Classes javax.lang.model changes, follow-up Message-ID: Hi, I made the mistake of pushing the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-291](https://github.com/openjdk/jdk/pull/291), Thanks and sorry for the unnecessary loop, Vicente ------------- Commit messages: - 8255014: Record Classes javax.lang.model changes, follow-up Changes: https://git.openjdk.java.net/jdk/pull/770/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=770&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255014 Stats: 144 lines in 12 files changed: 5 ins; 126 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/770.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/770/head:pull/770 PR: https://git.openjdk.java.net/jdk/pull/770 From vicente.romero at oracle.com Tue Oct 20 20:06:15 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 20 Oct 2020 16:06:15 -0400 Subject: Intersection type and method ref bug ? In-Reply-To: References: <1315346770.317146.1540375538284.JavaMail.zimbra@u-pem.fr> Message-ID: <746c4494-6d61-953a-da91-8b8a6ddefc99@oracle.com> Hi Bernard, The patch looks good to me. Do you need help with the git PR? Vicente On 10/15/20 10:56 AM, B. Blaser wrote: > Hi, > > Resurrecting this old thread as the following expression: > > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > > still throws a LCE at runtime: "Type mismatch for lambda argument 0: > class Test$C is not convertible to interface Test$I". > > From 'Stream::of' we have 'Stream' and then: > > Stream map(Function mapper); > > Further, wildcards are removed per JLS15 ?9.9 resulting to the > functional descriptor 'apply(C & I)' finally erased to 'apply(C)' > which isn't convertible to 'lambda$main$0(Test$I)' that javac > currently generates, failing to detect the intersection type 'C & I'. > > The following patch adds the missing lines to 'LambdaToMethod' on > jdk14u (langtools:tier1 is OK). > > What do you think? > Bernard > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > @@ -968,6 +968,10 @@ > // If the unerased parameter type is a type variable whose > // bound is an intersection (eg. ) then > // use the SAM parameter type > + if (checkForIntersection && descPTypes.head.getKind() > == TypeKind.INTERSECTION) { > + parmType = samPTypes.head; > + } > + > if (checkForIntersection && descPTypes.head.getKind() > == TypeKind.TYPEVAR) { > TypeVar tv = (TypeVar) descPTypes.head; > if (tv.getUpperBound().getKind() == > TypeKind.INTERSECTION) { > > > On Fri, 26 Oct 2018 at 15:21, Vicente Romero wrote: >> Hi Remi, Francois, >> >> Thanks for reporting this. I have created [1] to track this issue, >> >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8213032 >> >> On 10/24/18 6:05 AM, Remi Forax wrote: >>> This bug was discovered by Francois Green when testing records, but the bug is independent of the record, >>> method reference and intersection type doesn't mix well. >>> >>> public class RecordBadType { >>> interface I {} >>> static abstract class C { } >>> static class A extends C implements I { } >>> static class B extends C implements I { } >>> >>> static String f(I i) { return null; } >>> >>> public static void main(String[] args) { >>> Stream.of(new A(), new B()) >>> .map(RecordBadType::f) // here the compiler should generate a bridge method no ? >>> .forEach(System.out::println); >>> } >>> } >>> >>> this code compiles but you get a LambdaConversionException at runtime. >>> >>> R?mi From vromero at openjdk.java.net Wed Oct 21 00:21:22 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 21 Oct 2020 00:21:22 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: <0SU2aKGcx0k7_gdxnWAAlfXorDf-jCjSLw3k6ucqhjg=.8c4832df-512e-4017-a2b6-fab5d4e1caec@github.com> On Tue, 20 Oct 2020 12:03:39 GMT, Jan Lahoda wrote: >> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. >> >> A summary of changes: >> -making the feature permanent (non-preview) >> -making the binding variables non-final (as per current specification proposal) >> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type >> (as per current specification proposal) >> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved >> and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop >> Tree, etc. >> >> This change will not be integrated until JEP 394 is targetted. > > 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 15 additional commits since > the last revision: > - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask > - Merge branch 'master' into patterns-instanceof3 > - Fixing more tests. > - Correcting positions. > - Improve the AST model. > - Merge branch 'master' into patterns-instanceof3 > - Updating @since tags. > - Merge branch 'master' into patterns-instanceof3 > - Cleaning up preview comments in javadoc. > - Merge branch 'master' into patterns-instanceof3 > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/3b3bcc2a...5978bca0 src/jdk.compiler/share/classes/com/sun/source/tree/BindingPatternTree.java line 48: > 46: * @deprecated Use getVariable().getType() > 47: */ > 48: @Deprecated shouldn't we use `@Deprecated(since=versionNumber)` ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From vromero at openjdk.java.net Wed Oct 21 03:16:23 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 21 Oct 2020 03:16:23 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> On Tue, 20 Oct 2020 12:03:39 GMT, Jan Lahoda wrote: >> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. >> >> A summary of changes: >> -making the feature permanent (non-preview) >> -making the binding variables non-final (as per current specification proposal) >> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type >> (as per current specification proposal) >> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved >> and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop >> Tree, etc. >> >> This change will not be integrated until JEP 394 is targetted. > > 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 15 additional commits since > the last revision: > - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask > - Merge branch 'master' into patterns-instanceof3 > - Fixing more tests. > - Correcting positions. > - Improve the AST model. > - Merge branch 'master' into patterns-instanceof3 > - Updating @since tags. > - Merge branch 'master' into patterns-instanceof3 > - Cleaning up preview comments in javadoc. > - Merge branch 'master' into patterns-instanceof3 > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/062b3b15...5978bca0 Changes requested by vromero (Reviewer). src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 34: > 32: * @since 16 > 33: */ > 34: public interface PatternTree extends Tree {} I think that this interface is there for forward compatibility, it is still weird to have an empty interface and then an empty class in JCTree implementing this interface. Doesn't it make sense to move any method from BindingPatternTree up to this interface? I think that if having this empty interface is deemed unavoidable then, just an idea, we should acknowledge the fact that this is a forward looking interface. src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 29: > 27: > 28: /** > 29: * A tree node used as the base class for the different kinds of the javadoc seems to need an update ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From vromero at openjdk.java.net Wed Oct 21 03:30:14 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 21 Oct 2020 03:30:14 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Tue, 20 Oct 2020 11:36:41 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/patterns/LocalVariableTable.java line 29: >> >>> 27: * @summary Ensure the LV table entries are generated for bindings >>> 28: * @modules jdk.jdeps/com.sun.tools.classfile >>> 29: * @compile -g LocalVariableTable.java >> >> I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove >> that line as superfluous > > I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g, > as the test itself requires the debugging info/LocalVariableTable? sure I understand that the `-g` option is necessary. I was just wondering if `-g` is not passed always by jtreg. If the option is passed by default then it is superfluous, although just a comment, I understand that it is safer to pass it ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From ysuenaga at openjdk.java.net Wed Oct 21 04:38:09 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 21 Oct 2020 04:38:09 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Changes requested by ysuenaga (Reviewer). src/hotspot/share/services/diagnosticCommand.hpp line 589: > 587: return "Write map file for Linux perf tool."; > 588: } > 589: static const char* impact() { This operation does not seems to happen in Safepoint. It can be defined as "Low" IMHO. src/hotspot/share/code/codeCache.cpp line 1562: > 1560: } > 1561: > 1562: void CodeCache::write_perf_map(outputStream* st) { Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) src/hotspot/share/code/codeCache.cpp line 1570: > 1568: fileStream fs(fname, "w"); > 1569: if (!fs.is_open()) { > 1570: st->print_cr("Failed to create %s", fname); This message should be used Unified Logging. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:08 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:08 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: > When using the Linux "perf" tool to do system profiling, symbol names of > running Java methods cannot be decoded, resulting in unhelpful output > such as: > > 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 > > Perf can read a simple text file format describing the mapping between > address ranges and symbol names for a particular process [1]. > > It's possible to generate this already for Java processes using a JVMTI > plugin such as perf-map-agent [2]. However this requires compiling > third-party code and then loading the agent into your Java process. It > would be more convenient if Hotspot could write this file directly using > a diagnostic command. The information required is almost identical to > that of the existing Compiler.codelist command. > > This patch adds a Compiler.perfmap diagnostic command on Linux only. To > use, first run "jcmd Compiler.perfmap" and then "perf top" or > "perf record" and the report should show decoded Java symbol names for > that process. > > As this just writes a snapshot of the code cache when the command is > run, it will become stale if methods are compiled later or unloaded. > However this shouldn't be a big problem in practice if the map file is > generated after the application has warmed up. > > [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt > [2] https://github.com/jvm-profiling-tools/perf-map-agent Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: Update for review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/760/files - new: https://git.openjdk.java.net/jdk/pull/760/files/5b0c2695..a3cb0ed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=760&range=00-01 Stats: 16 lines in 3 files changed: 1 ins; 2 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/760.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/760/head:pull/760 PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:09 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:09 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 10:52:27 GMT, Aleksey Shipilev wrote: > > Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running? Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:10 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:10 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 04:34:44 GMT, Yasumasa Suenaga wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > src/hotspot/share/code/codeCache.cpp line 1562: > >> 1560: } >> 1561: >> 1562: void CodeCache::write_perf_map(outputStream* st) { > > Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ngasson at openjdk.java.net Wed Oct 21 09:13:11 2020 From: ngasson at openjdk.java.net (Nick Gasson) Date: Wed, 21 Oct 2020 09:13:11 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Tue, 20 Oct 2020 11:43:17 GMT, Vladimir Sitnikov wrote: >> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: >> >> Update for review comments > > test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java line 68: > >> 66: Matcher m = outputPattern.matcher(line); >> 67: >> 68: Assert.assertTrue(m.matches(), "Did not print map file name"); > > Suggestion: > > Assert.assertTrue(m.matches(), "Did not print map file name, line = " + line); Done, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From jlahoda at openjdk.java.net Tue Oct 20 12:03:39 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 20 Oct 2020 12:03:39 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type > (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved > and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop > Tree, etc. > > This change will not be integrated until JEP 394 is targetted. 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 15 additional commits since the last revision: - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask - Merge branch 'master' into patterns-instanceof3 - Fixing more tests. - Correcting positions. - Improve the AST model. - Merge branch 'master' into patterns-instanceof3 - Updating @since tags. - Merge branch 'master' into patterns-instanceof3 - Cleaning up preview comments in javadoc. - Merge branch 'master' into patterns-instanceof3 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/737668da...5978bca0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/559/files - new: https://git.openjdk.java.net/jdk/pull/559/files/69c7dce8..5978bca0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=00-01 Stats: 331339 lines in 1108 files changed: 314513 ins; 10715 del; 6111 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Wed Oct 21 10:08:02 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 21 Oct 2020 10:08:02 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: <_r6Ofs2YDbTpIn3oUavjOrwrItrumb8tQWczoOP8nSs=.47d03adc-fffa-4931-b513-cfea0258e998@github.com> On Wed, 21 Oct 2020 03:26:57 GMT, Vicente Romero wrote: >> I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g, as the test itself requires the debugging info/LocalVariableTable? > > sure I understand that the `-g` option is necessary. I was just wondering if `-g` is not passed always by jtreg. If the option is passed by default then it is superfluous, although just a comment, I understand that it is safer to pass it I tried with a plain jtreg invocation, and it didn't pass -g (and the test failed). But it depends on how jtreg is run, of course - some runs may have -g set. ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Wed Oct 21 10:08:01 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 21 Oct 2020 10:08:01 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> Message-ID: On Wed, 21 Oct 2020 03:11:28 GMT, Vicente Romero wrote: >> 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 15 additional commits since the last revision: >> >> - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask >> - Merge branch 'master' into patterns-instanceof3 >> - Fixing more tests. >> - Correcting positions. >> - Improve the AST model. >> - Merge branch 'master' into patterns-instanceof3 >> - Updating @since tags. >> - Merge branch 'master' into patterns-instanceof3 >> - Cleaning up preview comments in javadoc. >> - Merge branch 'master' into patterns-instanceof3 >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/0290d7bd...5978bca0 > > src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 34: > >> 32: * @since 16 >> 33: */ >> 34: public interface PatternTree extends Tree {} > > I think that this interface is there for forward compatibility, and I don't like empty interfaces but I found that we already did that with com.sun.source.tree.DirectiveTree We have multiple such interfaces - like StatementTree and ExpressionTree. It is a forward-looking interface, but I think necessary: InstanceofTree.getPattern() needs to return something, and having a PatternTree is (I think) better than returning generic Tree, or BindingPatternTree (the latter is likely to be insufficient sometime soon). ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Wed Oct 21 12:29:38 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 21 Oct 2020 12:29:38 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v3] In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. > > This change will not be integrated until JEP 394 is targetted. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/559/files - new: https://git.openjdk.java.net/jdk/pull/559/files/5978bca0..5699194b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Wed Oct 21 13:14:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 21 Oct 2020 13:14:16 GMT Subject: RFR: 8255014: Record Classes javax.lang.model changes, follow-up In-Reply-To: References: Message-ID: <_tCKru_UOWMuMOcNeuDCHgRJYaQypplrDQwcpecYELc=.c1c6a596-f71f-45ca-ae1d-2ed077f0dd21@github.com> On Tue, 20 Oct 2020 18:51:19 GMT, Vicente Romero wrote: > Hi, > > I made the mistake of pushing the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-291](https://github.com/openjdk/jdk/pull/291), > > Thanks and sorry for the unnecessary loop, > Vicente Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/770 From jlahoda at openjdk.java.net Wed Oct 21 13:15:23 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 21 Oct 2020 13:15:23 GMT Subject: RFR: 8255013: implement Record Classes as a standard feature in Java, follow-up In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 18:46:45 GMT, Vicente Romero wrote: > Hi, > > I made the mistake of pushing the fix for [JDK-8246774](https://bugs.openjdk.java.net/browse/JDK-8246774) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-290](https://github.com/openjdk/jdk/pull/290), > > Thanks and sorry for the unnecessary loop, > Vicente Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/769 From bsrbnd at gmail.com Wed Oct 21 13:46:20 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 21 Oct 2020 15:46:20 +0200 Subject: Intersection type and method ref bug ? In-Reply-To: <746c4494-6d61-953a-da91-8b8a6ddefc99@oracle.com> References: <1315346770.317146.1540375538284.JavaMail.zimbra@u-pem.fr> <746c4494-6d61-953a-da91-8b8a6ddefc99@oracle.com> Message-ID: Yes, please. Feel free to push it and simply list me as contributor until I have some cycles to get acquainted with the new git process. Thanks! Bernard On Tue, 20 Oct 2020 at 22:06, Vicente Romero wrote: > > Hi Bernard, > > The patch looks good to me. Do you need help with the git PR? > > Vicente > > On 10/15/20 10:56 AM, B. Blaser wrote: > > Hi, > > > > Resurrecting this old thread as the following expression: > > > > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > > > > still throws a LCE at runtime: "Type mismatch for lambda argument 0: > > class Test$C is not convertible to interface Test$I". > > > > From 'Stream::of' we have 'Stream' and then: > > > > Stream map(Function mapper); > > > > Further, wildcards are removed per JLS15 ?9.9 resulting to the > > functional descriptor 'apply(C & I)' finally erased to 'apply(C)' > > which isn't convertible to 'lambda$main$0(Test$I)' that javac > > currently generates, failing to detect the intersection type 'C & I'. > > > > The following patch adds the missing lines to 'LambdaToMethod' on > > jdk14u (langtools:tier1 is OK). > > > > What do you think? > > Bernard > > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > @@ -968,6 +968,10 @@ > > // If the unerased parameter type is a type variable whose > > // bound is an intersection (eg. ) then > > // use the SAM parameter type > > + if (checkForIntersection && descPTypes.head.getKind() > > == TypeKind.INTERSECTION) { > > + parmType = samPTypes.head; > > + } > > + > > if (checkForIntersection && descPTypes.head.getKind() > > == TypeKind.TYPEVAR) { > > TypeVar tv = (TypeVar) descPTypes.head; > > if (tv.getUpperBound().getKind() == > > TypeKind.INTERSECTION) { > > > > > > On Fri, 26 Oct 2018 at 15:21, Vicente Romero wrote: > >> Hi Remi, Francois, > >> > >> Thanks for reporting this. I have created [1] to track this issue, > >> > >> Vicente > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8213032 > >> > >> On 10/24/18 6:05 AM, Remi Forax wrote: > >>> This bug was discovered by Francois Green when testing records, but the bug is independent of the record, > >>> method reference and intersection type doesn't mix well. > >>> > >>> public class RecordBadType { > >>> interface I {} > >>> static abstract class C { } > >>> static class A extends C implements I { } > >>> static class B extends C implements I { } > >>> > >>> static String f(I i) { return null; } > >>> > >>> public static void main(String[] args) { > >>> Stream.of(new A(), new B()) > >>> .map(RecordBadType::f) // here the compiler should generate a bridge method no ? > >>> .forEach(System.out::println); > >>> } > >>> } > >>> > >>> this code compiles but you get a LambdaConversionException at runtime. > >>> > >>> R?mi > From hannesw at openjdk.java.net Wed Oct 21 15:29:19 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 21 Oct 2020 15:29:19 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 12:15:23 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: > > - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 > - More fixing tests. > - Fixing tests. > - Using unique sections for preview warning sections, as suggested. > - Merge branch 'master' into JDK-8250768 > - Reflecting review comments. > - Fixing tests. > - Various cleanup. > - The Preview taglet is not needed anymore. > - There is not jdk.internal package anymore > - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 The javadoc code changes look reasonable, and the preview bits in the generated documentation look good as well. Apart from my inline comments which all address minor issues, there are a few things I don't like around `PreviewListWriter`: its code replication with `DeprecatedListWriter, and it adds things to HtmlDocletWriter and HtmlStyle that I don't think are strictly necessary. However, I wouldn't expect you to know how we like things done in javadoc, so maybe the simplest solution would be for one of us to go over the javadoc bits, either as part of this pull request or (if you prefer to get it integrated rather sooner) as a follow-up task. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3164: > 3162: } > 3163: > 3164: public Set elementFlags(Element el) { It seems like the sole use of this method and the `ElementFlag` enum below is to determine whether a preview warning note should be generated for an element. Is there something that speaks against simplifying it to reflect that purpose, e.g. change its name to `hasPreviewNote` or `hasPreviewContent` and change the return type to `boolean`? Of course that's unless you foresee adding more `ElementFlag` values in the future. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 125: > 123: import static javax.lang.model.element.ElementKind.METHOD; > 124: import static javax.lang.model.element.ElementKind.PACKAGE; > 125: import jdk.javadoc.internal.doclets.formats.html.markup.RawHtml; These imports as well as HtmlAttr above aren't used. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java line 247: > 245: * The member this link points to (if any). > 246: */ > 247: public Element whereMember; I don't think `whereMember` is a great name (and `where` above is not a great name either). What about naming this `targetMember` or `targetElement`? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java line 47: > 45: CLEAR, > 46: COLS, > 47: COLSPAN, I don't think this is used anywhere. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java line 209: > 207: linkInfo.label = null; > 208: linkInfo.type = bound; > 209: ((LinkInfoImpl) linkInfo).skipPreview = false; I guess it would be nicer to move the `skipPreview` field to `LinkInfo` to avoid that cast. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1314: > 1312: div = HtmlTree.DIV(HtmlStyle.block, result); > 1313: htmltree.add(div); > 1314: } else { I notice that preview code above produces the same HTML output as non-preview code below in the `else` branch. Do we really need the `preview` parameter? ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From cjplummer at openjdk.java.net Wed Oct 21 18:00:19 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 18:00:19 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:08:06 GMT, Nick Gasson wrote: >> src/hotspot/share/code/codeCache.cpp line 1562: >> >>> 1560: } >>> 1561: >>> 1562: void CodeCache::write_perf_map(outputStream* st) { >> >> Should this code (and changes in header files) be included for Linux only? (`#ifdef LINUX` like the change in diagnosticCommand.cpp) > > I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From cjplummer at openjdk.java.net Wed Oct 21 18:06:22 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 21 Oct 2020 18:06:22 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments src/hotspot/share/code/codeCache.cpp line 1582: > 1580: cb->is_compiled() ? cb->as_compiled_method()->method()->external_name() > 1581: : cb->name(); > 1582: fs.print_cr(INTPTR_FORMAT " " INTPTR_FORMAT " %s", Indentation isn't right. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From sspitsyn at openjdk.java.net Wed Oct 21 21:04:15 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 21 Oct 2020 21:04:15 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 17:57:46 GMT, Chris Plummer wrote: >> I'm not sure, I didn't want to add too much `#ifdef` mess. The code will compile on other platforms, it just won't be called. Better to add `#ifdef`s around all of it? > > Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? +#ifdef LINUX + DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); +#endif // LINUX If this PR is for Linux only then I wonder if all changes have to be ifdef'ed the same or similar way. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From sspitsyn at openjdk.java.net Wed Oct 21 21:04:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 21 Oct 2020 21:04:16 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 21:00:01 GMT, Serguei Spitsyn wrote: >> Any reason not to have this dcmd supported on all platforms even though the output is really targeted for use with the perf tool on linux? Would a user ever have any other use for the output other than with the perf tool on linux? > > +#ifdef LINUX > + DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); > +#endif // LINUX > > If this PR is for Linux only then I wonder if all changes have to be ifdef'ed the same or similar way. Sorry, I've overlooked that @YaSuenag posted similar comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ysuenaga at openjdk.java.net Thu Oct 22 01:27:14 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 22 Oct 2020 01:27:14 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:09:49 GMT, Nick Gasson wrote: > Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. BTW we can use `Compiler.codelist` dcmd for this purpose now. If you implement `WritePerfMapOnExit`, we should consider code cache flushing and should use `Compiler.codelist` in some case. I've published perfmap generator from `Compiler.codelist` https://github.com/YaSuenag/saperf ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From ysuenaga at openjdk.java.net Thu Oct 22 02:09:14 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 22 Oct 2020 02:09:14 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments src/hotspot/share/code/codeCache.cpp line 1571: > 1569: if (!fs.is_open()) { > 1570: log_warning(codecache)("Failed to create %s for perf map", fname); > 1571: st->print_cr("Failed to create %s", fname); `st->print_cr()` is still needed? and also I've intended to replace all `print_cr()` to UL (L1587) ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From vromero at openjdk.java.net Thu Oct 22 02:09:12 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 22 Oct 2020 02:09:12 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Thu, 22 Oct 2020 01:24:20 GMT, Yasumasa Suenaga wrote: >>> >>> Because it seems that for the short jobs, we would like to just do "perf record java -XX:+WhatEver", followed by "perf report", without requiring user to invoke the diagnostic command while JVM is still running? >> >> Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? > >> Yes that sounds like a good idea. Add a (diagnostic?) option `-XX:+WritePerfMapOnExit`? > > I think we should use this option carefully because nmethod might be unloaded. So we should use this with `-XX:-UseCodeCacheFlushing`. > > BTW we can use `Compiler.codelist` dcmd for this purpose now. If you implement `WritePerfMapOnExit`, we should consider code cache flushing and should use `Compiler.codelist` in some case. I've published perfmap generator from `Compiler.codelist` https://github.com/YaSuenag/saperf \label remove compiler ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From vromero at openjdk.java.net Thu Oct 22 04:04:21 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 22 Oct 2020 04:04:21 GMT Subject: RFR: 8213032: program fails with LambdaConversionException at execution time Message-ID: 8213032: program fails with LambdaConversionException at execution time ------------- Commit messages: - merge - 8213032: program fails with LambdaConversionException at execution time - 8213032: program fails with LambdaConversionException at execution time Changes: https://git.openjdk.java.net/jdk/pull/792/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=792&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213032 Stats: 61 lines in 2 files changed: 54 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/792.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/792/head:pull/792 PR: https://git.openjdk.java.net/jdk/pull/792 From stuefe at openjdk.java.net Thu Oct 22 05:03:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Oct 2020 05:03:15 GMT Subject: RFR: 8254723: add diagnostic command to write Linux perf map file [v2] In-Reply-To: References: <7T_M6C-3WpLwXYH3RuRCuDQUW0qMyKIWAs8RaPW7D0s=.d659e5a0-e8a2-4816-8f60-1dd7653f4c7b@github.com> Message-ID: On Wed, 21 Oct 2020 09:13:08 GMT, Nick Gasson wrote: >> When using the Linux "perf" tool to do system profiling, symbol names of >> running Java methods cannot be decoded, resulting in unhelpful output >> such as: >> >> 10.52% [JIT] tid 236748 [.] 0x00007f6fdb75d223 >> >> Perf can read a simple text file format describing the mapping between >> address ranges and symbol names for a particular process [1]. >> >> It's possible to generate this already for Java processes using a JVMTI >> plugin such as perf-map-agent [2]. However this requires compiling >> third-party code and then loading the agent into your Java process. It >> would be more convenient if Hotspot could write this file directly using >> a diagnostic command. The information required is almost identical to >> that of the existing Compiler.codelist command. >> >> This patch adds a Compiler.perfmap diagnostic command on Linux only. To >> use, first run "jcmd Compiler.perfmap" and then "perf top" or >> "perf record" and the report should show decoded Java symbol names for >> that process. >> >> As this just writes a snapshot of the code cache when the command is >> run, it will become stale if methods are compiled later or unloaded. >> However this shouldn't be a big problem in practice if the map file is >> generated after the application has warmed up. >> >> [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt >> [2] https://github.com/jvm-profiling-tools/perf-map-agent > > Nick Gasson has updated the pull request incrementally with one additional commit since the last revision: > > Update for review comments Hi Nick, this is a very useful idea! I missed this in the past. Some remarks. I'll try to keep bikeshedding to a minimum since you already have enough input. Mostly ergonomics. 1) Like Alexey, I would really wish for an print-at-exit switch. The common naming seems to be xxxAtExit (so not, OnExit). "PrintXxx" seems to be printing stuff out to tty, "DumpXxxx" for writing separate files (e.g. CDS map). So I would name it DumpPerfMapAtExit. 2) Dumping to /tmp is unexpected for me, I would prefer if the default were dumping to the current directory. That seems to be the default for other files too (cds map, hs-err file etc). 3) Not necessary but nice would be a an option to specify location of the dump file. 4) I think it would be nice to have these switches always available, so real product switches. Which would require you to write up a small CSR but I still think it would make sense. Cheers, Thomas src/hotspot/share/code/codeCache.hpp line 194: > 192: static void print_summary(outputStream* st, bool detailed = true); // Prints a summary of the code cache usage > 193: static void log_state(outputStream* st); > 194: static void write_perf_map(outputStream* st); Seems weird for this function to have an outputStream parameter only to write the dump to an unrelated file and ignore the stream for everything but the final message. I would either pass in the file name as an option - preferably configurable - and write the last message out here; or just write the whole perf dump to the outputstream itself, piping it to jcmd and let the caller do what he wants with it (e.g. just redirecting). The latter is what most commands do. Not sure how large the perf dump gets though, may be impractical. src/hotspot/share/code/codeCache.cpp line 1562: > 1560: } > 1561: > 1562: void CodeCache::write_perf_map(outputStream* st) { Could this whole function possibly live inside os/linux in an own file? Or would that expose too many code heap internals? ------------- PR: https://git.openjdk.java.net/jdk/pull/760 From jlahoda at openjdk.java.net Thu Oct 22 09:10:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 22 Oct 2020 09:10:16 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> Message-ID: On Wed, 21 Oct 2020 03:12:08 GMT, Vicente Romero wrote: >> 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 15 additional commits since the last revision: >> >> - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask >> - Merge branch 'master' into patterns-instanceof3 >> - Fixing more tests. >> - Correcting positions. >> - Improve the AST model. >> - Merge branch 'master' into patterns-instanceof3 >> - Updating @since tags. >> - Merge branch 'master' into patterns-instanceof3 >> - Cleaning up preview comments in javadoc. >> - Merge branch 'master' into patterns-instanceof3 >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/efd3730b...5978bca0 > > src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 29: > >> 27: >> 28: /** >> 29: * A tree node used as the base class for the different kinds of > > the javadoc seems to need an update, probably: > `A tree node used as the base class for the different kinds of pattern matching expressions`? Patterns are not really expressions - they are a new kind of trees. Basically, before we had "statements" and "expressions" (+declarations, which are a bit special, ClassTree and VariableTree are "statements", but MethodTree, ModuleTree and PackageTree subtype Tree directly, so there is no common supertype). Now we have "patterns" in addition to that. For example, having: `o instanceof String s`, this is an expression, but `String s` is not - it is a pattern. It cannot stand on its own as an expression, it is a special part of the expression. ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Thu Oct 22 12:14:42 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 22 Oct 2020 12:14:42 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v4] In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. > > This change will not be integrated until JEP 394 is targetted. 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 18 additional commits since the last revision: - Removing the preview deprecated methods from BindingPatternTree. - Merge branch 'master' into patterns-instanceof3 - Fixing review comments. - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask - Merge branch 'master' into patterns-instanceof3 - Fixing more tests. - Correcting positions. - Improve the AST model. - Merge branch 'master' into patterns-instanceof3 - Updating @since tags. - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8c106e10...77468e24 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/559/files - new: https://git.openjdk.java.net/jdk/pull/559/files/5699194b..77468e24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=02-03 Stats: 32942 lines in 393 files changed: 22168 ins; 8599 del; 2175 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Thu Oct 22 12:14:47 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 22 Oct 2020 12:14:47 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2] In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com> Message-ID: On Wed, 21 Oct 2020 03:13:34 GMT, Vicente Romero wrote: >> 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 15 additional commits since the last revision: >> >> - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask >> - Merge branch 'master' into patterns-instanceof3 >> - Fixing more tests. >> - Correcting positions. >> - Improve the AST model. >> - Merge branch 'master' into patterns-instanceof3 >> - Updating @since tags. >> - Merge branch 'master' into patterns-instanceof3 >> - Cleaning up preview comments in javadoc. >> - Merge branch 'master' into patterns-instanceof3 >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/bf803de0...5978bca0 > > Changes requested by vromero (Reviewer). Based on an offline feedback, I've removed the old, preview, deprecated methods from BindingPatternTree. ------------- PR: https://git.openjdk.java.net/jdk/pull/559 From bsrbnd at gmail.com Thu Oct 22 12:18:14 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 22 Oct 2020 14:18:14 +0200 Subject: Intersection type and method ref bug ? In-Reply-To: References: <1315346770.317146.1540375538284.JavaMail.zimbra@u-pem.fr> <746c4494-6d61-953a-da91-8b8a6ddefc99@oracle.com> Message-ID: Thanks for the pull request, Vicente. However, it seems there are some failing tests. The patch looks globally good but I saw you added the following lines to my initial fix which don't look necessary: @@ -2321,7 +2326,7 @@ Type generatedRefSig() { } Type bridgedRefSig() { - return types.erasure(types.findDescriptorSymbol(tree.target.tsym).type); + return types.erasure(types.findDescriptorType(tree.target)); } } } So, I suggest you try to re-run the tests without the above change, keeping the intent of my original fix which passes tier1 on jdk14u. What do you think? Bernard On Wed, 21 Oct 2020 at 15:46, B. Blaser wrote: > > Yes, please. > Feel free to push it and simply list me as contributor until I have > some cycles to get acquainted with the new git process. > > Thanks! > Bernard > > On Tue, 20 Oct 2020 at 22:06, Vicente Romero wrote: > > > > Hi Bernard, > > > > The patch looks good to me. Do you need help with the git PR? > > > > Vicente > > > > On 10/15/20 10:56 AM, B. Blaser wrote: > > > Hi, > > > > > > Resurrecting this old thread as the following expression: > > > > > > Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); > > > > > > still throws a LCE at runtime: "Type mismatch for lambda argument 0: > > > class Test$C is not convertible to interface Test$I". > > > > > > From 'Stream::of' we have 'Stream' and then: > > > > > > Stream map(Function mapper); > > > > > > Further, wildcards are removed per JLS15 ?9.9 resulting to the > > > functional descriptor 'apply(C & I)' finally erased to 'apply(C)' > > > which isn't convertible to 'lambda$main$0(Test$I)' that javac > > > currently generates, failing to detect the intersection type 'C & I'. > > > > > > The following patch adds the missing lines to 'LambdaToMethod' on > > > jdk14u (langtools:tier1 is OK). > > > > > > What do you think? > > > Bernard > > > > > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java > > > @@ -968,6 +968,10 @@ > > > // If the unerased parameter type is a type variable whose > > > // bound is an intersection (eg. ) then > > > // use the SAM parameter type > > > + if (checkForIntersection && descPTypes.head.getKind() > > > == TypeKind.INTERSECTION) { > > > + parmType = samPTypes.head; > > > + } > > > + > > > if (checkForIntersection && descPTypes.head.getKind() > > > == TypeKind.TYPEVAR) { > > > TypeVar tv = (TypeVar) descPTypes.head; > > > if (tv.getUpperBound().getKind() == > > > TypeKind.INTERSECTION) { > > > > > > > > > On Fri, 26 Oct 2018 at 15:21, Vicente Romero wrote: > > >> Hi Remi, Francois, > > >> > > >> Thanks for reporting this. I have created [1] to track this issue, > > >> > > >> Vicente > > >> > > >> [1] https://bugs.openjdk.java.net/browse/JDK-8213032 > > >> > > >> On 10/24/18 6:05 AM, Remi Forax wrote: > > >>> This bug was discovered by Francois Green when testing records, but the bug is independent of the record, > > >>> method reference and intersection type doesn't mix well. > > >>> > > >>> public class RecordBadType { > > >>> interface I {} > > >>> static abstract class C { } > > >>> static class A extends C implements I { } > > >>> static class B extends C implements I { } > > >>> > > >>> static String f(I i) { return null; } > > >>> > > >>> public static void main(String[] args) { > > >>> Stream.of(new A(), new B()) > > >>> .map(RecordBadType::f) // here the compiler should generate a bridge method no ? > > >>> .forEach(System.out::println); > > >>> } > > >>> } > > >>> > > >>> this code compiles but you get a LambdaConversionException at runtime. > > >>> > > >>> R?mi > > From vicente.romero at oracle.com Thu Oct 22 15:32:32 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 22 Oct 2020 11:32:32 -0400 Subject: Intersection type and method ref bug ? In-Reply-To: References: <1315346770.317146.1540375538284.JavaMail.zimbra@u-pem.fr> <746c4494-6d61-953a-da91-8b8a6ddefc99@oracle.com> Message-ID: <8ab5fec3-aaff-3d80-4d4e-21c4a361f0b9@oracle.com> Hi Bernard, The PR is not final yet, I want to do some research. The change you are referring to has nothing to do with your patch but I think it is the right thing to do. I will investigate why those tests are failing. Vicente On 10/22/20 8:18 AM, B. Blaser wrote: > Thanks for the pull request, Vicente. > > However, it seems there are some failing tests. The patch looks > globally good but I saw you added the following lines to my initial > fix which don't look necessary: > > @@ -2321,7 +2326,7 @@ Type generatedRefSig() { > } > > Type bridgedRefSig() { > - return > types.erasure(types.findDescriptorSymbol(tree.target.tsym).type); > + return types.erasure(types.findDescriptorType(tree.target)); > } > } > } > > So, I suggest you try to re-run the tests without the above change, > keeping the intent of my original fix which passes tier1 on jdk14u. > > What do you think? > Bernard > > On Wed, 21 Oct 2020 at 15:46, B. Blaser wrote: >> Yes, please. >> Feel free to push it and simply list me as contributor until I have >> some cycles to get acquainted with the new git process. >> >> Thanks! >> Bernard >> >> On Tue, 20 Oct 2020 at 22:06, Vicente Romero wrote: >>> Hi Bernard, >>> >>> The patch looks good to me. Do you need help with the git PR? >>> >>> Vicente >>> >>> On 10/15/20 10:56 AM, B. Blaser wrote: >>>> Hi, >>>> >>>> Resurrecting this old thread as the following expression: >>>> >>>> Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println); >>>> >>>> still throws a LCE at runtime: "Type mismatch for lambda argument 0: >>>> class Test$C is not convertible to interface Test$I". >>>> >>>> From 'Stream::of' we have 'Stream' and then: >>>> >>>> Stream map(Function mapper); >>>> >>>> Further, wildcards are removed per JLS15 ?9.9 resulting to the >>>> functional descriptor 'apply(C & I)' finally erased to 'apply(C)' >>>> which isn't convertible to 'lambda$main$0(Test$I)' that javac >>>> currently generates, failing to detect the intersection type 'C & I'. >>>> >>>> The following patch adds the missing lines to 'LambdaToMethod' on >>>> jdk14u (langtools:tier1 is OK). >>>> >>>> What do you think? >>>> Bernard >>>> >>>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java >>>> @@ -968,6 +968,10 @@ >>>> // If the unerased parameter type is a type variable whose >>>> // bound is an intersection (eg. ) then >>>> // use the SAM parameter type >>>> + if (checkForIntersection && descPTypes.head.getKind() >>>> == TypeKind.INTERSECTION) { >>>> + parmType = samPTypes.head; >>>> + } >>>> + >>>> if (checkForIntersection && descPTypes.head.getKind() >>>> == TypeKind.TYPEVAR) { >>>> TypeVar tv = (TypeVar) descPTypes.head; >>>> if (tv.getUpperBound().getKind() == >>>> TypeKind.INTERSECTION) { >>>> >>>> >>>> On Fri, 26 Oct 2018 at 15:21, Vicente Romero wrote: >>>>> Hi Remi, Francois, >>>>> >>>>> Thanks for reporting this. I have created [1] to track this issue, >>>>> >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8213032 >>>>> >>>>> On 10/24/18 6:05 AM, Remi Forax wrote: >>>>>> This bug was discovered by Francois Green when testing records, but the bug is independent of the record, >>>>>> method reference and intersection type doesn't mix well. >>>>>> >>>>>> public class RecordBadType { >>>>>> interface I {} >>>>>> static abstract class C { } >>>>>> static class A extends C implements I { } >>>>>> static class B extends C implements I { } >>>>>> >>>>>> static String f(I i) { return null; } >>>>>> >>>>>> public static void main(String[] args) { >>>>>> Stream.of(new A(), new B()) >>>>>> .map(RecordBadType::f) // here the compiler should generate a bridge method no ? >>>>>> .forEach(System.out::println); >>>>>> } >>>>>> } >>>>>> >>>>>> this code compiles but you get a LambdaConversionException at runtime. >>>>>> >>>>>> R?mi From jjg at openjdk.java.net Thu Oct 22 17:29:21 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Oct 2020 17:29:21 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag Message-ID: The change is (just) to remove legacy usages of a JDK-private custom tag. ------------- Commit messages: - JDK-8255262: Remove use of legacy custom @spec tag Changes: https://git.openjdk.java.net/jdk/pull/814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=814&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255262 Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/814/head:pull/814 PR: https://git.openjdk.java.net/jdk/pull/814 From lancea at openjdk.java.net Thu Oct 22 17:35:15 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 22 Oct 2020 17:35:15 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. looks fine ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814 From iris at openjdk.java.net Thu Oct 22 17:46:16 2020 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 22 Oct 2020 17:46:16 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: <-NCS5lF0mdeaDq1CyQYTrh0gGVozPafltjNYsEpO488=.d795b2ec-acc2-4c06-8434-757b2095e386@github.com> On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Nice clean-up. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814 From mr at openjdk.java.net Thu Oct 22 17:46:15 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 22 Oct 2020 17:46:15 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. As the creator of these tags many moons ago, I approve this change. ------------- Marked as reviewed by mr (Lead). PR: https://git.openjdk.java.net/jdk/pull/814 From darcy at openjdk.java.net Thu Oct 22 17:46:18 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 22 Oct 2020 17:46:18 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: <5hlum1g6yK7pF3TkDMBvYSlK0Ca3bVh1VM3XJUVAvCk=.93e60ef2-400c-4775-a4c5-1f290e14ed57@github.com> On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From alanb at openjdk.java.net Thu Oct 22 17:46:17 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 22 Oct 2020 17:46:17 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From mchung at openjdk.java.net Thu Oct 22 17:56:16 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 22 Oct 2020 17:56:16 GMT Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From jjg at openjdk.java.net Thu Oct 22 19:49:22 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 22 Oct 2020 19:49:22 GMT Subject: Integrated: JDK-8255262: Remove use of legacy custom @spec tag In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. This pull request has now been integrated. Changeset: 0aa3c925 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/0aa3c925 Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod 8255262: Remove use of legacy custom @spec tag Reviewed-by: lancea, mr, iris, alanb, darcy, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/814 From jlahoda at openjdk.java.net Fri Oct 23 09:52:38 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 23 Oct 2020 09:52:38 GMT Subject: Integrated: 8254286: Wrong inference in switch expression with "null" arm In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 17:08:36 GMT, Jan Lahoda wrote: > Basically, for code like: > > var t1 = switch (s) { > case 1 -> i1; > case 2 -> null; > default -> i2; > }; > > Attr.condType is currently passing , BOT, to Types.lub. But Types.lub needs the list without BOT, so filtering BOT(s) out of the list. This pull request has now been integrated. Changeset: 0e920531 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/0e920531 Stats: 58 lines in 3 files changed: 55 ins; 0 del; 3 mod 8254286: Wrong inference in switch expression with "null" arm Reviewed-by: mcimadamore, vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/583 From jjg at openjdk.java.net Fri Oct 23 15:50:49 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 23 Oct 2020 15:50:49 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) Message-ID: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. As a block tag, the format is simply @spec url label which is handled in a manner analogous to @see label The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. ------------- Commit messages: - fix TestSpecTag.testEncodedURI - fix tests - remove support to workaround legacy @spec tag - Merge remote-tracking branch 'upstream/master' into new-spec-tag - fix trailing whitespace in test - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51` - JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) Changes: https://git.openjdk.java.net/jdk/pull/790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6251738 Stats: 1376 lines in 42 files changed: 1345 ins; 12 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790 PR: https://git.openjdk.java.net/jdk/pull/790 From jlahoda at openjdk.java.net Fri Oct 23 16:17:58 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 23 Oct 2020 16:17:58 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v3] In-Reply-To: References: Message-ID: <8Mdv3fmdDrN4fvcQDIFiq72Z4cgs8Xm9cuHhPUgqj5c=.be071ea4-94b8-4841-bfa8-a432424ba2e6@github.com> > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Using a more correct way to get URLs. - Reflecting review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/703/files - new: https://git.openjdk.java.net/jdk/pull/703/files/be1d8651..caa4fd34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=01-02 Stats: 41 lines in 7 files changed: 5 ins; 14 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Oct 23 16:21:53 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 23 Oct 2020 16:21:53 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Removing unnecessary cast. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/703/files - new: https://git.openjdk.java.net/jdk/pull/703/files/caa4fd34..461e7d15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Fri Oct 23 16:26:39 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 23 Oct 2020 16:26:39 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: <6VRynO1yt2p2xY5qSooueo-NLlQ-hD6zWJEkfVOXq94=.b95e79ef-9345-4acf-81cb-e4accbd4ed3c@github.com> On Wed, 21 Oct 2020 15:25:59 GMT, Hannes Walln?fer wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: >> >> - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 >> - More fixing tests. >> - Fixing tests. >> - Using unique sections for preview warning sections, as suggested. >> - Merge branch 'master' into JDK-8250768 >> - Reflecting review comments. >> - Fixing tests. >> - Various cleanup. >> - The Preview taglet is not needed anymore. >> - There is not jdk.internal package anymore >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 > > The javadoc code changes look reasonable, and the preview bits in the generated documentation look good as well. > > Apart from my inline comments which all address minor issues, there are a few things I don't like around `PreviewListWriter`: its code replication with `DeprecatedListWriter, and it adds things to HtmlDocletWriter and HtmlStyle that I don't think are strictly necessary. However, I wouldn't expect you to know how we like things done in javadoc, so maybe the simplest solution would be for one of us to go over the javadoc bits, either as part of this pull request or (if you prefer to get it integrated rather sooner) as a follow-up task. I have update the patch based on Hannes' comments. One open question is whether we should have Utils.elementFlags, or just Utils.isPreviewElement. @jonathan-gibbons, any preference? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From erikj at openjdk.java.net Fri Oct 23 16:40:37 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 23 Oct 2020 16:40:37 GMT Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com> Message-ID: On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons wrote: > This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box. > > As an inline tag, the format is `{@spec url label}`, which is roughly translated to `label` in the generated docs. > > As a block tag, the format is simply > > @spec url label > > which is handled in a manner analogous to > > @see label > > The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here. > > This change is only the _support_ for the new tag; it does _not_ include any changes to API docs to _use_ the new tag. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/790 From jjg at openjdk.java.net Fri Oct 23 17:05:40 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 23 Oct 2020 17:05:40 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 12:43:51 GMT, Hannes Walln?fer wrote: >> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits: >> >> - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 >> - More fixing tests. >> - Fixing tests. >> - Using unique sections for preview warning sections, as suggested. >> - Merge branch 'master' into JDK-8250768 >> - Reflecting review comments. >> - Fixing tests. >> - Various cleanup. >> - The Preview taglet is not needed anymore. >> - There is not jdk.internal package anymore >> - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651 > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3164: > >> 3162: } >> 3163: >> 3164: public Set elementFlags(Element el) { > > It seems like the sole use of this method and the `ElementFlag` enum below is to determine whether a preview warning note should be generated for an element. Is there something that speaks against simplifying it to reflect that purpose, e.g. change its name to `hasPreviewNote` or `hasPreviewContent` and change the return type to `boolean`? Of course that's unless you foresee adding more `ElementFlag` values in the future. There's a number of predicates on an element that the doclet might be interested in that could be cached/reified as "flags". Today, we have "preview" and "deprecated" that have similar handling; there have been discussions about handling native methods in a similar fashion. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jjg at openjdk.java.net Fri Oct 23 18:46:49 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 23 Oct 2020 18:46:49 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Removing unnecessary cast. I have primarily gone through all the javadoc changes. There are three main areas of feedback: 1. The ElementFlag question. We have gone from one kind of element with special treatment (deprecated) to two (deprecated, preview), and there are signs of a third kind coming soon, maybe as early as next year, for work currently being discussed in the Panama project. As the saying goes, three would be one too many. So, I agree `ElementFlag` is underutilized today and could reasonably be removed, but it does seem worthwhile to keep, and it would even be worth increasing its usage soon, such as to combine methods and classes for deprecated elements and preview elements. I'm not sure I can go back into looking at files while typing this message, but if we are to keep `ElementFlag` we should at a minimum provide a better description of its purpose. For example, can/should it be used for all predicates on elements, or just the elements that get "special" handling when generating docs. 2. The use of strings containing HTML, and use of `RawHtml`, instead of working in terms of `Content` nodes such as `HtmlTree` and `StringContent`. 3. Track recent updates to the repo, regarding Conditional Pages. See how we set up conditional pages for the deprecated list, and do the same for preview items. This is probably a must-do item, once you merge with mainline. -- Finally, I realize this is a big chunk of work (well done!), across many areas, and that getting through a review is hard. If it is too hard to address some of the comments here, I'm OK if you file follow-up bugs of at least the same priority and Fix Version as for the main bug here: JDK-8250768. (That applies to #1, #2 above; not #3). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 526: > 524: return (sym.flags() & Flags.PREVIEW_REFLECTIVE) != 0; > 525: } > 526: Generally, hacking your way into `Symbol` is undesirable (though accepted if there is no realistic alternative.) Adding new code into the `WorkArounds` class should be seen as a means of last resort when the required information cannot be obtained from public API ... which may require updating the public API as well. For example, should these methods be predicates on the Language Model `Elements` class? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 89: > 87: @Override > 88: protected Content getDeprecatedOrPreviewLink(Element member) { > 89: Content deprecatedLinkContent = new ContentBuilder(); name does not match usage. I suggest simplifying it to just "content". src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88: > 86: > 87: @Override > 88: protected Content getDeprecatedOrPreviewLink(Element member) { This name is a side-effect of the `ElementFlag` question. We should either use explicit field and method names, or we should use `ElementFlag` more consistently. This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java line 172: > 170: description.add(getDeprecatedPhrase(klass)); > 171: List tags = utils.getDeprecatedTrees(klass); > 172: if (!tags.isEmpty()) { There is potential for future parameterization using `ElementFlag` or its equivalent. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java line 205: > 203: protected Content getDeprecatedOrPreviewLink(Element member) { > 204: String name = utils.getFullyQualifiedName(member) + "." + member.getSimpleName(); > 205: return writer.getDocLink(LinkInfoImpl.Kind.MEMBER_DEPRECATED_PREVIEW, member, name); I suspect the MEMBER_DEPRECATED_PREVIEW will become more general in future src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 210: > 208: pre.add(modifiersPart); > 209: pre.add(new HtmlTree(TagName.SUP).add(links.createLink(getPreviewSectionAnchor(typeElement), > 210: contents.previewMark))); Possible future enhancement: use a set of modifiers that need flags src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 281: > 279: pre.add(DocletConstants.NL); > 280: pre.add("permits"); > 281: pre.add(new HtmlTree(TagName.SUP).add(links.createLink(getPreviewSectionAnchor(typeElement), @hns is it better to use `` or CSS? Either way is OK in this review. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 187: > 185: PreviewListWriter.generate(configuration); > 186: } > 187: This may need to be updated, by comparing against similar code for DEPRECATED, and/or you need to take `HtmlDocletWriter.ConditionalPage` into account, again by comparing with latest code for deprecated items. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 112: > 110: import jdk.javadoc.internal.doclets.toolkit.util.VisibleMemberTable; > 111: import jdk.javadoc.internal.doclets.toolkit.util.Utils; > 112: import jdk.javadoc.internal.doclets.toolkit.util.Utils.DeclarationPreviewLanguageFeatures; Uuugh on the long class name ;-) src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1039: > 1037: } else if (utils.isVariableElement(element) || utils.isTypeElement(element)) { > 1038: return getLink(new LinkInfoImpl(configuration, context, typeElement) > 1039: .label(label).where(links.getName(element.getSimpleName().toString())).targetMember(element)); Note to self (@jonathan-gibbons ) links.getName should accept a `CharSequence` to avoid the need for `toString()` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2219: > 2217: if (previewTree != null) { > 2218: div.add(HtmlTree.SPAN(HtmlStyle.previewLabel, > 2219: new RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, true)))); There's a big cringe here that there is a method in Utils returning HTML. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2281: > 2279: RawHtml note2 = > 2280: new RawHtml(resources.getText("doclet.PreviewTrailingNote2", > 2281: name)); This is a deviation from existing practice to allow HTML in resource files. That doesn't seem like the sort of stuff that should be localizable. In other situations, (e.g. the Help page) we put the plain-text contents in the resource file and generate the markup in the code. Elsewhere, I said that `WorkArounds` is a means of last resort. The same is true for `RawHtml`. Use it if you must, but it's better to use other forms of `Content`, like `HtmlTree`. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2322: > 2320: feature.features > 2321: .stream() > 2322: .map(f -> "" + f + "") Ugh for using string constants for HTML. Try and use `Content` instead, src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2329: > 2327: featureDisplayName, > 2328: featureCodes); > 2329: result.add(new RawHtml(text)); General ugh for many of the aforementioned reasons, all related to handling HTML in strings. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2351: > 2349: .map(this::toLink) > 2350: .map(link -> getLink(link).toString()) > 2351: .collect(Collectors.joining(", ")))); More of the same ... `RawHtml` and building HTML in strings src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java line 64: > 62: * Indicate that the link appears in member documentation on the Deprecated or Preview page. > 63: */ > 64: MEMBER_DEPRECATED_PREVIEW, Will need to be generalized, eventually src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 228: > 226: addTreeLink(tree); > 227: addDeprecatedLink(tree); > 228: addPreviewLink(tree); It's OK to put the link here, I guess, but it should also be on the INDEX page. See also recent updates for conditional pages. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 888: > 886: > 887: private void addPreviewLink(Content tree) { > 888: if (configuration.getIncludedModuleElements().stream().anyMatch(m -> m.getQualifiedName().contentEquals("java.base"))) { This becomes simpler with recent support for conditional pages. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java line 39: > 37: import com.sun.source.doctree.TextTree; > 38: import com.sun.source.doctree.UnknownInlineTagTree; > 39: import java.util.stream.Collectors; why these imports? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 288: > 286: doclet.Declared_Using_Preview.SEALED_PERMITS=Sealed Classes > 287: doclet.PreviewPlatformLeadingNote={0} is a preview API of the Java platform. > 288: doclet.ReflectivePreviewPlatformLeadingNote={0} is a reflective preview API of the Java platform. HTML in resource files is bad. It would be marginally better to move the HTML to the value being substituted (using strings from Content nodes) and even better to use a method that substitutes Content nodes into a resource string (Not sure if that method exists, but it could/should). src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java line 79: > 77: * @param annotationDocTree content tree to which the preview information will be added > 78: */ > 79: void addPreview(ExecutableElement member, Content contentTree); Note to javadoc-team: Consider using default methods to provide an empty implementation. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java line 28: > 26: package jdk.javadoc.internal.doclets.toolkit.builders; > 27: > 28: import static java.lang.invoke.ConstantBootstraps.enumConstant; Really? If it is required, it is in the wrong place. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 46: > 44: * deletion without notice. > 45: */ > 46: public class PreviewAPIListBuilder { OK for now, but it might be worth eventually trying to merge this with `DeprecatedListBuilder` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 79: > 77: for (PreviewElementKind kind : PreviewElementKind.values()) { > 78: previewMap.put(kind, > 79: new TreeSet<>(utils.comparators.makeDeprecatedComparator())); The use of `makeDeprecatedComparator` is not awful, but does smell a bit. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 86: > 84: /** > 85: * Build the sorted list of all the deprecated APIs in this run. > 86: * Build separate lists for deprecated modules, packages, classes, constructors, "d-word", twice src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 89: > 87: * methods and fields. > 88: */ > 89: private void buildDeprecatedAPIInfo() { D-word src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 133: > 131: } > 132: } > 133: composeDeprecatedList(previewMap.get(PreviewElementKind.FIELD), I suggest you grep this file for all uses of the d-word src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 158: > 156: * @param members members to be added in the list. > 157: */ > 158: private void composeDeprecatedList(SortedSet sset, List members) { Last time d-word comment. Consider all such uses to be flagged. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2848: > 2846: UnknownInlineTagTree previewTag = (UnknownInlineTagTree) t; > 2847: List previewContent = previewTag.getContent(); > 2848: String previewText = ((TextTree) previewContent.get(0)).getBody(); This looks unreasonably fragile. And, I thought the tag was going away... at least according to earlier files in this review. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2984: > 2982: SEALED(List.of("sealed")), > 2983: SEALED_PERMITS(List.of("sealed", "permits")), > 2984: RECORD(List.of("record")); I'm guessing this is about to go away soon? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980: > 2978: } > 2979: > 2980: public enum DeclarationPreviewLanguageFeatures { General thinking aloud question ... how does all this interact with source or release options for an earlier release? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3025: > 3023: case MODULE, PACKAGE -> { > 3024: } > 3025: default -> throw new IllegalStateException("Unexpected: " + el.getKind()); Should be `IllegalArgumentException` not `IllegalStateException` src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3145: > 3143: * Checks whether the given Element should be marked as a preview API. > 3144: * > 3145: * Note that is a type is marked as a preview, its members are not. probable typo: "is" -> "if" src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288: > 1286: case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER: > 1287: case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER: > 1288: case RECORD_COMPONENT: I'm not saying this is wrong, but I'd like to understand why it is necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Sat Oct 24 02:14:50 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sat, 24 Oct 2020 02:14:50 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v4] In-Reply-To: References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: On Thu, 22 Oct 2020 12:14:42 GMT, Jan Lahoda wrote: >> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. >> >> A summary of changes: >> -making the feature permanent (non-preview) >> -making the binding variables non-final (as per current specification proposal) >> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) >> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. >> >> This change will not be integrated until JEP 394 is targetted. > > 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 18 additional commits since the last revision: > > - Removing the preview deprecated methods from BindingPatternTree. > - Merge branch 'master' into patterns-instanceof3 > - Fixing review comments. > - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask > - Merge branch 'master' into patterns-instanceof3 > - Fixing more tests. > - Correcting positions. > - Improve the AST model. > - Merge branch 'master' into patterns-instanceof3 > - Updating @since tags. > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/68eec7af...77468e24 looks good! ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/559 From vromero at openjdk.java.net Sun Oct 25 02:40:00 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 25 Oct 2020 02:40:00 GMT Subject: RFR: 8254105: allow static nested declarations [v2] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8254105 - 8254105: allow static members in inner classes, add binary compatibility tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/571/files - new: https://git.openjdk.java.net/jdk/pull/571/files/bec9cd9f..a118ff5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=00-01 Stats: 412119 lines in 3595 files changed: 368117 ins; 26672 del; 17330 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From ihse at openjdk.java.net Mon Oct 26 09:56:16 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 26 Oct 2020 09:56:16 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda wrote: >> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. >> >> The notable changes are: >> >> * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: >> * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. >> * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings >> * improving error/warning messages. Please see [1] for a list of cases/examples. >> * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. >> * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). >> * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. >> * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. >> >> Please also see the CSR [6] for more information. >> >> [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html >> [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html >> [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html >> [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html >> [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ >> [6] https://bugs.openjdk.java.net/browse/JDK-8250769 > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Removing unnecessary cast. Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Tue Oct 27 01:22:32 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 27 Oct 2020 01:22:32 GMT Subject: RFR: 8254105: allow static nested declarations [v3] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: test cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/571/files - new: https://git.openjdk.java.net/jdk/pull/571/files/a118ff5e..431500d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=01-02 Stats: 738 lines in 1 file changed: 291 ins; 285 del; 162 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Tue Oct 27 14:23:37 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 27 Oct 2020 14:23:37 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing duplicated test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/571/files - new: https://git.openjdk.java.net/jdk/pull/571/files/431500d2..d4fef536 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=02-03 Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From jlahoda at openjdk.java.net Tue Oct 27 16:14:33 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 27 Oct 2020 16:14:33 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com> On Fri, 23 Oct 2020 17:22:33 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary cast. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88: > >> 86: >> 87: @Override >> 88: protected Content getDeprecatedOrPreviewLink(Element member) { > > This name is a side-effect of the `ElementFlag` question. We should either use explicit field and method names, or we should use `ElementFlag` more consistently. This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent. Note this method returns the same link for deprecate or preview - it just was named "getDeprecatedLink", and when using it work preview, I renamed it "getDeprecatedOrPreviewLink". We may need to think of a better name. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980: > >> 2978: } >> 2979: >> 2980: public enum DeclarationPreviewLanguageFeatures { > > General thinking aloud question ... how does all this interact with source or release options for an earlier release? I don't think there should be much interaction with -source . We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features. > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2984: > >> 2982: SEALED(List.of("sealed")), >> 2983: SEALED_PERMITS(List.of("sealed", "permits")), >> 2984: RECORD(List.of("record")); > > I'm guessing this is about to go away soon? Right, this is likely to go away soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From vromero at openjdk.java.net Tue Oct 27 20:49:34 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 27 Oct 2020 20:49:34 GMT Subject: RFR: 8255013: implement Record Classes as a standard feature in Java, follow-up [v2] In-Reply-To: References: Message-ID: > Hi, > > I made the mistake of pushing the fix for [JDK-8246774](https://bugs.openjdk.java.net/browse/JDK-8246774) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-290](https://github.com/openjdk/jdk/pull/290), > > Thanks and sorry for the unnecessary loop, > Vicente Vicente Romero 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 with master - 8255013: implement Record Classes as a standard feature in Java, follow-up ------------- Changes: https://git.openjdk.java.net/jdk/pull/769/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=769&range=01 Stats: 892 lines in 109 files changed: 75 ins; 595 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/769/head:pull/769 PR: https://git.openjdk.java.net/jdk/pull/769 From vromero at openjdk.java.net Tue Oct 27 21:18:30 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 27 Oct 2020 21:18:30 GMT Subject: RFR: 8255013: implement Record Classes as a standard feature in Java, follow-up [v3] In-Reply-To: References: Message-ID: > Hi, > > I made the mistake of pushing the fix for [JDK-8246774](https://bugs.openjdk.java.net/browse/JDK-8246774) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-290](https://github.com/openjdk/jdk/pull/290), > > Thanks and sorry for the unnecessary loop, > Vicente Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing unnecessary code from classFileParser ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/769/files - new: https://git.openjdk.java.net/jdk/pull/769/files/d4fc2572..80a1c282 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=769&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=769&range=01-02 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/769.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/769/head:pull/769 PR: https://git.openjdk.java.net/jdk/pull/769 From vromero at openjdk.java.net Tue Oct 27 21:40:33 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 27 Oct 2020 21:40:33 GMT Subject: RFR: 8255014: Record Classes javax.lang.model changes, follow-up [v2] In-Reply-To: References: Message-ID: > Hi, > > I made the mistake of pushing the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-291](https://github.com/openjdk/jdk/pull/291), > > Thanks and sorry for the unnecessary loop, > Vicente 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8255014 - 8255014: Record Classes javax.lang.model changes, follow-up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/770/files - new: https://git.openjdk.java.net/jdk/pull/770/files/37330cd1..649dd9a9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=770&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=770&range=00-01 Stats: 32459 lines in 563 files changed: 26138 ins; 4034 del; 2287 mod Patch: https://git.openjdk.java.net/jdk/pull/770.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/770/head:pull/770 PR: https://git.openjdk.java.net/jdk/pull/770 From vromero at openjdk.java.net Wed Oct 28 17:06:49 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 17:06:49 GMT Subject: RFR: 8255013: implement Record Classes as a standard feature in Java, follow-up [v3] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 13:11:52 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing unnecessary code from classFileParser > > Marked as reviewed by jlahoda (Reviewer). we are going live!!! go records!!! ------------- PR: https://git.openjdk.java.net/jdk/pull/769 From vromero at openjdk.java.net Wed Oct 28 17:23:46 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 17:23:46 GMT Subject: Integrated: 8255013: implement Record Classes as a standard feature in Java, follow-up In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 18:46:45 GMT, Vicente Romero wrote: > Hi, > > I made the mistake of pushing the fix for [JDK-8246774](https://bugs.openjdk.java.net/browse/JDK-8246774) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-290](https://github.com/openjdk/jdk/pull/290), > > Thanks and sorry for the unnecessary loop, > Vicente This pull request has now been integrated. Changeset: 8bde2f4e Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/8bde2f4e Stats: 894 lines in 109 files changed: 72 ins; 600 del; 222 mod 8255013: implement Record Classes as a standard feature in Java, follow-up Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Chris Hegarty Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/769 From vromero at openjdk.java.net Wed Oct 28 17:37:49 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 17:37:49 GMT Subject: Integrated: 8255014: Record Classes javax.lang.model changes, follow-up In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 18:51:19 GMT, Vicente Romero wrote: > Hi, > > I made the mistake of pushing the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) too soon and had to delta-apply it. This PR is basically proposing to push the same code as [PR-291](https://github.com/openjdk/jdk/pull/291), > > Thanks and sorry for the unnecessary loop, > Vicente This pull request has now been integrated. Changeset: 8ad7f383 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/8ad7f383 Stats: 144 lines in 12 files changed: 5 ins; 126 del; 13 mod 8255014: Record Classes javax.lang.model changes, follow-up Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/770 From mcimadamore at openjdk.java.net Wed Oct 28 18:02:48 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Oct 2020 18:02:48 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Tue, 27 Oct 2020 14:23:37 GMT, Vicente Romero wrote: >> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. >> >> TIA, >> Vicente >> >> PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > removing duplicated test The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says). src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1232: > 1230: mask |= STATIC; > 1231: else if ((flags & ENUM) != 0 || (flags & RECORD) != 0) { > 1232: //log.error(pos, Errors.StaticDeclarationNotAllowedInInnerClasses); Can't you get rid of the `else if` here? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1306: > 1304: SEALED, > 1305: FINAL | NON_SEALED) > 1306: && checkDisjoint(pos, flags, Where is this coming from? This seems outside the scope of the change? ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From mcimadamore at openjdk.java.net Wed Oct 28 18:02:49 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Oct 2020 18:02:49 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: <2FO64qXpIpHlQBKzDtQdQTQtdUWhZTsw--VPeSKFw3A=.19353e8e-77e1-40e0-9f72-23977455d8d6@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> <2FO64qXpIpHlQBKzDtQdQTQtdUWhZTsw--VPeSKFw3A=.19353e8e-77e1-40e0-9f72-23977455d8d6@github.com> Message-ID: <5d5kwv6MmNghtHD-M06EVvWrimBR2L1Tq2BqNqKUiRE=.252e0fd9-0779-4074-8565-903461d8b6d2@github.com> On Fri, 9 Oct 2020 00:07:35 GMT, Vicente Romero wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > this code is not strictly related to the patch but this test is just basically testing the changes introduced by Chapter 13 in the record spec. I'm OK moving this to another PR if needed I bet this is related to the extra disjoint test in Check.java - if so, yes, better moved in a different issue, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Oct 28 19:19:55 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 19:19:55 GMT Subject: RFR: 8254105: allow static nested declarations [v5] In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: > Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and Nested Static Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined inside inner classes but also interfaces, enums, static classes and methods. > > TIA, > Vicente > > PS: the records spec can be accessed here [Record Classes](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/records-jls.html). This patch also adds a test to check the changes in the Records spec to Chapter 13 "Binary Compatibility". I'm OK moving that test to a separate PR. Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - manual merge with master branch - removing duplicated test - test cleanup - Merge branch 'master' into JDK-8254105 - 8254105: allow static members in inner classes, add binary compatibility tests ------------- Changes: https://git.openjdk.java.net/jdk/pull/571/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=04 Stats: 1093 lines in 21 files changed: 575 ins; 275 del; 243 mod Patch: https://git.openjdk.java.net/jdk/pull/571.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571 PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Oct 28 20:49:48 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 20:49:48 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 28 Oct 2020 17:55:00 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1232: > >> 1230: mask |= STATIC; >> 1231: else if ((flags & ENUM) != 0 || (flags & RECORD) != 0) { >> 1232: //log.error(pos, Errors.StaticDeclarationNotAllowedInInnerClasses); > > Can't you get rid of the `else if` here? oops, sure ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Oct 28 20:56:47 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 20:56:47 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 28 Oct 2020 17:55:51 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1306: > >> 1304: SEALED, >> 1305: FINAL | NON_SEALED) >> 1306: && checkDisjoint(pos, flags, > > Where is this coming from? This seems outside the scope of the change? sure I will remove it ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From vromero at openjdk.java.net Wed Oct 28 21:00:46 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 28 Oct 2020 21:00:46 GMT Subject: RFR: 8254105: allow static nested declarations [v5] In-Reply-To: <5d5kwv6MmNghtHD-M06EVvWrimBR2L1Tq2BqNqKUiRE=.252e0fd9-0779-4074-8565-903461d8b6d2@github.com> References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> <2FO64qXpIpHlQBKzDtQdQTQtdUWhZTsw--VPeSKFw3A=.19353e8e-77e1-40e0-9f72-23977455d8d6@github.com> <5d5kwv6MmNghtHD-M06EVvWrimBR2L1Tq2BqNqKUiRE=.252e0fd9-0779-4074-8565-903461d8b6d2@github.com> Message-ID: On Wed, 28 Oct 2020 17:58:17 GMT, Maurizio Cimadamore wrote: >> test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. >> >> this code is not strictly related to the patch but this test is just basically testing the changes introduced by Chapter 13 in the record spec. I'm OK moving this to another PR if needed > > I bet this is related to the extra disjoint test in Check.java - if so, yes, better moved in a different issue, thanks. not really but it is true that it is not strictly related to the patch, will create another issue for it ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From weijun at openjdk.java.net Wed Oct 28 21:01:52 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 28 Oct 2020 21:01:52 GMT Subject: RFR: 8255536: Remove the directsign property and option Message-ID: I regret adding the `directsign` property/option to JarSigner/jarsigner. See the bug for details. ------------- Commit messages: - 8255536: Remove the directsign property and option Changes: https://git.openjdk.java.net/jdk/pull/915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=915&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255536 Stats: 184 lines in 7 files changed: 14 ins; 162 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/915/head:pull/915 PR: https://git.openjdk.java.net/jdk/pull/915 From jlahoda at openjdk.java.net Thu Oct 29 09:28:51 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 09:28:51 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 18:28:12 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary cast. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288: > >> 1286: case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER: >> 1287: case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER: >> 1288: case RECORD_COMPONENT: > > I'm not saying this is wrong, but I'd like to understand why it is necessary. HtmlDocletWriter.getPreviewNotes analyzes classes and their members, to see if some are using aspects that are under preview. When looking at the members, it uses utils.isIncluded on the member, and that eventually gets here. And if the member is a RECORD_COMPONENT, it would fail here. But we can avoid asking for RECORD_COMPONENTS, if needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Oct 29 09:41:50 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 09:41:50 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 17:58:42 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary cast. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 228: > >> 226: addTreeLink(tree); >> 227: addDeprecatedLink(tree); >> 228: addPreviewLink(tree); > > It's OK to put the link here, I guess, but it should also be on the INDEX page. > > See also recent updates for conditional pages. I believe the link is in the navigation bar on all pages (as DEPRECATED is). ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Oct 29 09:46:46 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 09:46:46 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: References: Message-ID: <3izxrckqtdi9Hg7tV7-EUeIV0M7oqmMl3j802UTtFuM=.014127ae-6ca1-4309-91b7-a622e5fe89c4@github.com> On Fri, 23 Oct 2020 18:19:13 GMT, Jonathan Gibbons wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing unnecessary cast. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2848: > >> 2846: UnknownInlineTagTree previewTag = (UnknownInlineTagTree) t; >> 2847: List previewContent = previewTag.getContent(); >> 2848: String previewText = ((TextTree) previewContent.get(0)).getBody(); > > This looks unreasonably fragile. And, I thought the tag was going away... at least according to earlier files in this review. This was intended to allow Preview APIs to provide their own text instead of the generic one. But, looking again at JEP 12, this shouldn't be supported, so removing. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Oct 29 09:46:47 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 09:46:47 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v4] In-Reply-To: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com> References: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com> Message-ID: On Tue, 27 Oct 2020 16:11:18 GMT, Jan Lahoda wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980: >> >>> 2978: } >>> 2979: >>> 2980: public enum DeclarationPreviewLanguageFeatures { >> >> General thinking aloud question ... how does all this interact with source or release options for an earlier release? > > I don't think there should be much interaction with -source . We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features. We don't support preview features from previous releases, AFAIK. So javadoc for JDK 16 should not accept e.g. record class when running with -source 15. ------------- PR: https://git.openjdk.java.net/jdk/pull/703 From jlahoda at openjdk.java.net Thu Oct 29 13:37:55 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 13:37:55 GMT Subject: RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v5] In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com> Message-ID: > This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof. > > A summary of changes: > -making the feature permanent (non-preview) > -making the binding variables non-final (as per current specification proposal) > -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal) > -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc. > > This change will not be integrated until JEP 394 is targetted. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merging master into patterns-instanceof3 - Removing the preview deprecated methods from BindingPatternTree. - Merge branch 'master' into patterns-instanceof3 - Fixing review comments. - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask - Merge branch 'master' into patterns-instanceof3 - Fixing more tests. - Correcting positions. - Improve the AST model. - Merge branch 'master' into patterns-instanceof3 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/ea26ff11...8fbed8c9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=04 Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod Patch: https://git.openjdk.java.net/jdk/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559 PR: https://git.openjdk.java.net/jdk/pull/559 From jlahoda at openjdk.java.net Thu Oct 29 13:47:45 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 29 Oct 2020 13:47:45 GMT Subject: RFR: 8254105: allow static nested declarations [v4] In-Reply-To: References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com> Message-ID: On Wed, 28 Oct 2020 18:00:18 GMT, Maurizio Cimadamore wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> removing duplicated test > > The changes look good, but I have one concern: this patch seem to apply the improvements unconditionally, regardless of the source version - is this what we want? While I understand that the risk is low (this patch makes space of compilable programs bigger), at the same times it feels wrong that when compiling with `--source 14` I can now nest static classes inside member classes (which is not compatible with what the SE 14 spec says). As @mcimadamore, I think this should only be allowed for -source 16+, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/571 From jlahoda at openjdk.java.net Fri Oct 30 08:30:58 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 30 Oct 2020 08:30:58 GMT Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12 [v5] In-Reply-To: References: Message-ID: > This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12. > > The notable changes are: > > * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes: > * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning. > * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings > * improving error/warning messages. Please see [1] for a list of cases/examples. > * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not. > * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package). > * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed. > * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5]. > > Please also see the CSR [6] for more information. > > [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html > [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html > [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html > [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html > [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ > [6] https://bugs.openjdk.java.net/browse/JDK-8250769 Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Updating tests after records are a final feature. - Fixing tests. - Finalizing removal of record preview hooks. - Merging master into JDK-8250768 - Reflecting review comments. - Merge branch 'master' into JDK-8250768 - Removing unnecessary cast. - Using a more correct way to get URLs. - Reflecting review comments. - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/ea26ff11...d76eb293 ------------- Changes: https://git.openjdk.java.net/jdk/pull/703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=04 Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod Patch: https://git.openjdk.java.net/jdk/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703 PR: https://git.openjdk.java.net/jdk/pull/703