From vicente.romero at oracle.com Tue Sep 1 15:51:57 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 1 Sep 2020 11:51:57 -0400 Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to fields In-Reply-To: References: Message-ID: ping On 8/31/20 1:10 PM, Vicente Romero wrote: > Hi, > > Please review fix for [1] at [2]. There were several issues at play > here. First the parameters added by the compiler to the compact > constructor were not marked as generated, meaning that later on when > checking for annotations, at Check::validateAnnotation, it couldn't be > determine if the annotations were added automatically with the > intention to remove them if out of place. Which is the strategy for > elements generated from the record components. Or if they were > explicitly added by the user. The current implementation was assuming > the last option and thus flagging an error. Also I realized that at > Check::getApplicableTargets, the case when the target is MODULE was > not covered. This was not the product of the records patch which > rewrote this method, this was like this since the modules times. I > think that for completeness, and correctness, there should be a case > for target MODULE at Check::getApplicableTargets. The compiler was > accepting annotations applied to ElementType.MODULE, just because it > was accepting annotations applied to unknown targets assuming that > there was a bug in the source that would be flagged anyway. I realize > that this change to Check::getApplicableTargets could be considered > outside of the reach of this patch so I'm OK with removing it and file > a separate bug if we consider it a better approach, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8252307 > [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/ From vicente.romero at oracle.com Tue Sep 1 15:52:30 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 1 Sep 2020 11:52:30 -0400 Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec In-Reply-To: <89c5f00b-b871-8bc8-16fe-f73c7638ad4f@oracle.com> References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com> <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com> <3448c708-c675-b844-18cf-31bb83447d06@oracle.com> <89c5f00b-b871-8bc8-16fe-f73c7638ad4f@oracle.com> Message-ID: ping On 8/28/20 12:20 PM, Vicente Romero wrote: > Hi Jan, > > I agree with your comments, I have uploaded another iteration at [1]. > The only changes are in PoolReader, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8230776/webrev.02/ > > On 8/28/20 9:57 AM, Jan Lahoda wrote: >> Hi Vicente, >> >> I think it looks great overall. >> >> Basically my only comment is for PoolReader. Given the performance of >> this code is potentially important, would it make sense to make the >> validity checks as fast as possible? E.g. having something like: >> readIfNeeded(int index, BitSet expectedTags) { >> >> ... >> if (!expectedTags.get(currentTag)) { >> ??? throw reader.badClassFile("unexpected.const.pool.tag.at", >> tag(index), offset(index)); >> } >> >> And having static final pre-created BitSets used to pass into this >> method? >> >> Thanks, >> ??? Jan >> >> On 28. 08. 20 0:01, Vicente Romero wrote: >>> Hi Jan, >>> >>> Please review another iteration of the patch at [1], this one is a >>> bit more complex as it addresses several very related bugs together. >>> These bugs are [2-6]. The common factor is that javac interrupts >>> compilation with an exception or assertion error while compiling a >>> source file that extends a fuzzed class file. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8230776/webrev.01/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8231311 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230964 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8230963 >>> [5] https://bugs.openjdk.java.net/browse/JDK-8230919 >>> [6] https://bugs.openjdk.java.net/browse/JDK-8230776 >>> >>> >>> On 8/26/20 4:26 AM, Jan Lahoda wrote: >>>> Hi Vicente, >>>> >>>> I am sorry, but I don't think this is a fix on a good place. >>>> >>>> The root cause here is that the classfile for Test has an invalid >>>> method descriptor for the Test's constructor (returns float instead >>>> of void). See JVMS 4.6., descriptor_index. I think it would be much >>>> better to validate method descriptors, and reject classfiles with >>>> descriptors not adhering to JVMS. The user would then get a much >>>> more helpful error, saying something like: >>>> --- >>>> Sub.java:1: error: cannot access Test >>>> class Sub extends Test {} >>>> ????????????????? ^ >>>> ? bad class file: >>>> /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/nb-jtreg/work/classes/tools/javac/T8230776/AssertionErrorTest.d/Test.class >>>> >>>> ??? method descriptor invalid for >>>> ??? Please remove or make sure it appears in the correct >>>> subdirectory of the classpath. >>>> 1 error >>>> --- >>>> >>>> What do you think? >>>> >>>> Jan >>>> >>>> On 25. 08. 20 19:23, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. The fix is ending the >>>>> compilation at the code generation phase if a statement cant be >>>>> generated and there is no way for the compilation to continue. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230776 >>>>> [2] http://cr.openjdk.java.net/~vromero/8230776/webrev.00/ >>> > From james.laskey at oracle.com Tue Sep 1 16:00:04 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 1 Sep 2020 13:00:04 -0300 Subject: RFR: JDK-8224225 - Tokenizer improvements In-Reply-To: References: <5e91df74-0469-fa73-2295-ef3f65c49240@oracle.com> Message-ID: <83CFDC6D-D434-4CAA-998A-CEDE67BD4E82@oracle.com> I've been waiting for the jdk build to switch to using a jdk-15 bootstrap (soon.) In the meantime, I've updated the webrev with requested changes. webrev: http://cr.openjdk.java.net/~jlaskey/8224225/webrev-05 Cheers, -- Jim > On Aug 14, 2020, at 7:05 PM, James Laskey wrote: > > Agree. Will work it up. > > ?? > >> On Aug 14, 2020, at 6:30 PM, Jonathan Gibbons wrote: >> >> ? >> Re SubChar.java >> >> The correct solution is to dynamically generate any files with non-standard whitespace, even if it is simple as >> Files.writeString(tmpPath, Fies.readString(srcPath).trim()) >> >> -- Jon >> >> On 8/14/20 11:09 AM, Jim Laskey wrote: >>> Thank you. >>> >>> The commentary for SubChar.java reads. >>> >>> "Note: this source file has been crafted very carefully to end with the >>> unicode escape sequence for the control-Z character without a >>> following newline. The scanner is specified to allow control-Z there. >>> If you edit this source file, please make sure that your editor does >>> not insert a newline after that trailing line." >>> >>> The person that checked in the test did exactly that - added a newline after that trailing line (this was done when moving to mercurial in 2007.) >>> >>> This patch is to remove that newline. Note that jcheck doesn't check tests for missing last newline. >>> >>> Cheers, >>> >>> -- Jim >>> >>> >>>> On Aug 14, 2020, at 2:42 PM, Maurizio Cimadamore > wrote: >>>> >>>> Hi Jim, >>>> this is a very good cleanup. I like how the new code makes the tokenizers a lot less verbose than before, and I like how you have refactored the various UnicodeReader vs. DocReader (now PositionTrackingReader), as the status quo was messy, and we had a lot of flexibility on paper that wasn't really used in practice and ended up making the code more complex than it needed to be. >>>> >>>> Big thumbs up from me. >>>> >>>> Minor comment: what's up with SubChar.java? Webrev is empty, but patch reports following diff: >>>> >>>> iff --git a/test/langtools/tools/javac/unicode/SubChar.java b/test/langtools/tools/javac/unicode/SubChar.java >>>> --- a/test/langtools/tools/javac/unicode/SubChar.java >>>> +++ b/test/langtools/tools/javac/unicode/SubChar.java >>>> @@ -45,4 +45,4 @@ >>>> return; >>>> } >>>> } >>>> -/* \u001A */ >>>> +/* \u001A */ >>>> \ No newline at end of file >>>> >>>> >>>> Is that deliberate? >>>> >>>> >>>> >>>> Maurizio >>>> >>>> >>>> >>>> On 13/08/2020 18:32, Jim Laskey wrote: >>>>> webrev: http://cr.openjdk.java.net/~jlaskey/8224225/webrev-04 >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8224225 >>>>> >>>>> 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: 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. >>>>> >>>>> All comments, suggestions and contributions welcome. >>>>> >>>>> Cheers, >>>>> >>>>> --- Jim >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lahoda at oracle.com Tue Sep 1 16:10:48 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 1 Sep 2020 18:10:48 +0200 Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec In-Reply-To: <89c5f00b-b871-8bc8-16fe-f73c7638ad4f@oracle.com> References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com> <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com> <3448c708-c675-b844-18cf-31bb83447d06@oracle.com> <89c5f00b-b871-8bc8-16fe-f73c7638ad4f@oracle.com> Message-ID: Looks good to me. Jan On 28. 08. 20 18:20, Vicente Romero wrote: > Hi Jan, > > I agree with your comments, I have uploaded another iteration at [1]. > The only changes are in PoolReader, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8230776/webrev.02/ > > On 8/28/20 9:57 AM, Jan Lahoda wrote: >> Hi Vicente, >> >> I think it looks great overall. >> >> Basically my only comment is for PoolReader. Given the performance of >> this code is potentially important, would it make sense to make the >> validity checks as fast as possible? E.g. having something like: >> readIfNeeded(int index, BitSet expectedTags) { >> >> ... >> if (!expectedTags.get(currentTag)) { >> ??? throw reader.badClassFile("unexpected.const.pool.tag.at", >> tag(index), offset(index)); >> } >> >> And having static final pre-created BitSets used to pass into this >> method? >> >> Thanks, >> ??? Jan >> >> On 28. 08. 20 0:01, Vicente Romero wrote: >>> Hi Jan, >>> >>> Please review another iteration of the patch at [1], this one is a >>> bit more complex as it addresses several very related bugs together. >>> These bugs are [2-6]. The common factor is that javac interrupts >>> compilation with an exception or assertion error while compiling a >>> source file that extends a fuzzed class file. >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8230776/webrev.01/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8231311 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8230964 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8230963 >>> [5] https://bugs.openjdk.java.net/browse/JDK-8230919 >>> [6] https://bugs.openjdk.java.net/browse/JDK-8230776 >>> >>> >>> On 8/26/20 4:26 AM, Jan Lahoda wrote: >>>> Hi Vicente, >>>> >>>> I am sorry, but I don't think this is a fix on a good place. >>>> >>>> The root cause here is that the classfile for Test has an invalid >>>> method descriptor for the Test's constructor (returns float instead >>>> of void). See JVMS 4.6., descriptor_index. I think it would be much >>>> better to validate method descriptors, and reject classfiles with >>>> descriptors not adhering to JVMS. The user would then get a much >>>> more helpful error, saying something like: >>>> --- >>>> Sub.java:1: error: cannot access Test >>>> class Sub extends Test {} >>>> ????????????????? ^ >>>> ? bad class file: >>>> /home/jlahoda/src/jdk/jdk/build/linux-x86_64-server-release/nb-jtreg/work/classes/tools/javac/T8230776/AssertionErrorTest.d/Test.class >>>> >>>> ??? method descriptor invalid for >>>> ??? Please remove or make sure it appears in the correct >>>> subdirectory of the classpath. >>>> 1 error >>>> --- >>>> >>>> What do you think? >>>> >>>> Jan >>>> >>>> On 25. 08. 20 19:23, Vicente Romero wrote: >>>>> Please review fix for [1] at [2]. The fix is ending the compilation >>>>> at the code generation phase if a statement cant be generated and >>>>> there is no way for the compilation to continue. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8230776 >>>>> [2] http://cr.openjdk.java.net/~vromero/8230776/webrev.00/ >>> > From jan.lahoda at oracle.com Wed Sep 2 10:59:06 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 Sep 2020 12:59:06 +0200 Subject: RFR: JDK-8245664: javac erroneously issues deprecation warning for use of a deprecated package Message-ID: <493d5f10-1fbf-4fc8-0025-672b817a32f0@oracle.com> Hi, If a package is marked with @Deprecated, javac may issue a deprecation warning on usages of that package. This contradicts JLS 9.6.4.6. Proposed fix is to avoid the warning when a package has a @Deprecated annotations. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8245664/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8245664 How does this look? Thanks, Jan From jan.lahoda at oracle.com Wed Sep 2 15:46:51 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 2 Sep 2020 17:46:51 +0200 Subject: RFR: JDK-8160601: unexpected error compiling @Deprecated package Message-ID: Hi, Having a package-info.java like this: /** * @deprecated This is a deprecated package. */ @Deprecated package com.example.foobar; javac reports: $ javac package-info.java package-info.java:5: error: modifier deprecated not allowed here package com.example.foobar; ^ 1 error This is because the @deprecated tag is internally in the parser viewed as a modifier, and packages cannot have modifiers. The tag is wrong on a package, of course, but it is in a comment, so javac should not report a compile-time error. The proposed fix is to simply ignore the deprecated internal flag when verifying the package does not have modifiers. There is already a similar code for modules. Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8160601/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8160601 How does this look? Thanks, Jan From james.laskey at oracle.com Wed Sep 2 15:50:02 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 2 Sep 2020 12:50:02 -0300 Subject: RFR: JDK-8160601: unexpected error compiling @Deprecated package In-Reply-To: References: Message-ID: LGTM > On Sep 2, 2020, at 12:46 PM, Jan Lahoda wrote: > > Hi, > > Having a package-info.java like this: > /** > * @deprecated This is a deprecated package. > */ > @Deprecated > package com.example.foobar; > > javac reports: > $ javac package-info.java > package-info.java:5: error: modifier deprecated not allowed here > package com.example.foobar; > ^ > 1 error > > This is because the @deprecated tag is internally in the parser viewed as a modifier, and packages cannot have modifiers. The tag is wrong on a package, of course, but it is in a comment, so javac should not report a compile-time error. > > The proposed fix is to simply ignore the deprecated internal flag when verifying the package does not have modifiers. There is already a similar code for modules. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8160601/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8160601 > > How does this look? > > Thanks, > Jan From vicente.romero at oracle.com Wed Sep 2 16:15:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Sep 2020 12:15:50 -0400 Subject: RFR: JDK-8245664: javac erroneously issues deprecation warning for use of a deprecated package In-Reply-To: <493d5f10-1fbf-4fc8-0025-672b817a32f0@oracle.com> References: <493d5f10-1fbf-4fc8-0025-672b817a32f0@oracle.com> Message-ID: <2df1e518-d341-a499-7b08-ce0152871337@oracle.com> looks good, Vicente On 9/2/20 6:59 AM, Jan Lahoda wrote: > Hi, > > If a package is marked with @Deprecated, javac may issue a deprecation > warning on usages of that package. This contradicts JLS 9.6.4.6. > > Proposed fix is to avoid the warning when a package has a @Deprecated > annotations. > > Proposed webrev: > http://cr.openjdk.java.net/~jlahoda/8245664/webrev.00/ > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8245664 > > How does this look? > > Thanks, > ??? Jan From vicente.romero at oracle.com Wed Sep 2 18:10:51 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Sep 2020 14:10:51 -0400 Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to fields In-Reply-To: References: Message-ID: <5572d500-3de9-27fc-b8fb-0fbc6ecb5772@oracle.com> ping On 9/1/20 11:51 AM, Vicente Romero wrote: > ping > > On 8/31/20 1:10 PM, Vicente Romero wrote: >> Hi, >> >> Please review fix for [1] at [2]. There were several issues at play >> here. First the parameters added by the compiler to the compact >> constructor were not marked as generated, meaning that later on when >> checking for annotations, at Check::validateAnnotation, it couldn't >> be determine if the annotations were added automatically with the >> intention to remove them if out of place. Which is the strategy for >> elements generated from the record components. Or if they were >> explicitly added by the user. The current implementation was assuming >> the last option and thus flagging an error. Also I realized that at >> Check::getApplicableTargets, the case when the target is MODULE was >> not covered. This was not the product of the records patch which >> rewrote this method, this was like this since the modules times. I >> think that for completeness, and correctness, there should be a case >> for target MODULE at Check::getApplicableTargets. The compiler was >> accepting annotations applied to ElementType.MODULE, just because it >> was accepting annotations applied to unknown targets assuming that >> there was a bug in the source that would be flagged anyway. I realize >> that this change to Check::getApplicableTargets could be considered >> outside of the reach of this patch so I'm OK with removing it and >> file a separate bug if we consider it a better approach, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8252307 >> [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/ > From vicente.romero at oracle.com Wed Sep 2 18:36:27 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 2 Sep 2020 14:36:27 -0400 Subject: RFR: JDK-8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results Message-ID: <4e0e19d9-32df-f94c-f930-badef5076114@oracle.com> Hi, Please review fix for [1] at [2]. While fixing a bug a while ago I realized that com.sun.tools.javac.api.JavacTaskImpl could swallow compiler exceptions implying that for the invoking test, the compilation went fine and so the test was incorrectly passing. With this patch, JavacTaskImpl is now grumpier so that clients can't make the false assumption that the compilation passed. The patch is also fixing a test that was passing for the wrong reason, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8250217 [2] http://cr.openjdk.java.net/~vromero/8250217/webrev.00/ From vicente.romero at oracle.com Thu Sep 3 16:12:29 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 3 Sep 2020 12:12:29 -0400 Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to fields In-Reply-To: <5572d500-3de9-27fc-b8fb-0fbc6ecb5772@oracle.com> References: <5572d500-3de9-27fc-b8fb-0fbc6ecb5772@oracle.com> Message-ID: <168b26be-84aa-1959-cf82-40dda86c0122@oracle.com> ping, I would like to push this one before the github transition, Thanks, Vicente On 9/2/20 2:10 PM, Vicente Romero wrote: > ping > > On 9/1/20 11:51 AM, Vicente Romero wrote: >> ping >> >> On 8/31/20 1:10 PM, Vicente Romero wrote: >>> Hi, >>> >>> Please review fix for [1] at [2]. There were several issues at play >>> here. First the parameters added by the compiler to the compact >>> constructor were not marked as generated, meaning that later on when >>> checking for annotations, at Check::validateAnnotation, it couldn't >>> be determine if the annotations were added automatically with the >>> intention to remove them if out of place. Which is the strategy for >>> elements generated from the record components. Or if they were >>> explicitly added by the user. The current implementation was >>> assuming the last option and thus flagging an error. Also I realized >>> that at Check::getApplicableTargets, the case when the target is >>> MODULE was not covered. This was not the product of the records >>> patch which rewrote this method, this was like this since the >>> modules times. I think that for completeness, and correctness, there >>> should be a case for target MODULE at Check::getApplicableTargets. >>> The compiler was accepting annotations applied to >>> ElementType.MODULE, just because it was accepting annotations >>> applied to unknown targets assuming that there was a bug in the >>> source that would be flagged anyway. I realize that this change to >>> Check::getApplicableTargets could be considered outside of the reach >>> of this patch so I'm OK with removing it and file a separate bug if >>> we consider it a better approach, >>> >>> Thanks, >>> Vicente >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8252307 >>> [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/ >> > From vicente.romero at oracle.com Fri Sep 4 01:31:11 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 3 Sep 2020 21:31:11 -0400 Subject: RFR: JDK-8247352: improve error messages for sealed classes and records Message-ID: Hi, Please review the fix for [1] at [2]. The patch is basically changing some error messages for records and sealed classes trying to make them easier to digest by the user. The bug entry at [1] list some code snippets that motivated this fix, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8247352 [2] http://cr.openjdk.java.net/~vromero/8247352/webrev.00/ From dawid.weiss at gmail.com Fri Sep 4 07:59:21 2020 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 4 Sep 2020 09:59:21 +0200 Subject: Stop compilation after N warnings with -Werror? Message-ID: Hello folks, Is there any way to have both -Werror (error on warnings) *and* more than *one* warning emitted during compilation? When running on a CI it'd be good to see a number of warnings causing the final error - not just the first one. I thought something like this may work: -Werror -Xmaxerrs 10 -Xmaxwarns 10 but this still stops after the first warning, saying - somewhat misleadingly (because there are a number more errors/warnings during full compile cycle): error: warnings found and -Werror specified 1 error 1 warning I looked at the code in [1] but couldn't pinpoint why it doesn't work, exactly. Dawid [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/file/95da35fd7597/src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java#l576 From forax at univ-mlv.fr Fri Sep 4 12:05:26 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 Sep 2020 14:05:26 +0200 (CEST) Subject: RFR: JDK-8247352: improve error messages for sealed classes and records In-Reply-To: References: Message-ID: <1935580798.1051159.1599221126860.JavaMail.zimbra@u-pem.fr> Hi, there is another message that could be improved, when someone try to use inheritance with a record, the error message is pretty obscure. record Foo() extends Object { } the current error message is Error: '{' expected record Foo() extends Object {} ^ regards, R?mi ----- Mail original ----- > De: "Vicente Romero" > ?: "compiler-dev" > Envoy?: Vendredi 4 Septembre 2020 03:31:11 > Objet: RFR: JDK-8247352: improve error messages for sealed classes and records > Hi, > > Please review the fix for [1] at [2]. The patch is basically changing > some error messages for records and sealed classes trying to make them > easier to digest by the user. The bug entry at [1] list some code > snippets that motivated this fix, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8247352 > [2] http://cr.openjdk.java.net/~vromero/8247352/webrev.00/ From vicente.romero at oracle.com Fri Sep 4 15:13:02 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 4 Sep 2020 11:13:02 -0400 Subject: RFR: JDK-8247352: improve error messages for sealed classes and records In-Reply-To: <1935580798.1051159.1599221126860.JavaMail.zimbra@u-pem.fr> References: <1935580798.1051159.1599221126860.JavaMail.zimbra@u-pem.fr> Message-ID: <3358cec4-d841-96b1-c257-02227f5c544e@oracle.com> right we can improve that as a separate effort, but currently this is the behavior for tokens not expected by the parser. This is not exclusive for records, so could be part of an extended effort. Thanks, Vicente On 9/4/20 8:05 AM, Remi Forax wrote: > Hi, > there is another message that could be improved, > when someone try to use inheritance with a record, > the error message is pretty obscure. > > record Foo() extends Object { > } > > > the current error message is > Error: > '{' expected > record Foo() extends Object {} > ^ > > regards, > R?mi > > ----- Mail original ----- >> De: "Vicente Romero" >> ?: "compiler-dev" >> Envoy?: Vendredi 4 Septembre 2020 03:31:11 >> Objet: RFR: JDK-8247352: improve error messages for sealed classes and records >> Hi, >> >> Please review the fix for [1] at [2]. The patch is basically changing >> some error messages for records and sealed classes trying to make them >> easier to digest by the user. The bug entry at [1] list some code >> snippets that motivated this fix, >> >> Thanks, >> Vicente >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8247352 >> [2] http://cr.openjdk.java.net/~vromero/8247352/webrev.00/ From joe.darcy at oracle.com Fri Sep 4 16:56:23 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 4 Sep 2020 09:56:23 -0700 Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to fields In-Reply-To: <168b26be-84aa-1959-cf82-40dda86c0122@oracle.com> References: <5572d500-3de9-27fc-b8fb-0fbc6ecb5772@oracle.com> <168b26be-84aa-1959-cf82-40dda86c0122@oracle.com> Message-ID: Looks okay; cheers, -Joe On 9/3/2020 9:12 AM, Vicente Romero wrote: > ping, I would like to push this one before the github transition, > > Thanks, > Vicente > > On 9/2/20 2:10 PM, Vicente Romero wrote: >> ping >> >> On 9/1/20 11:51 AM, Vicente Romero wrote: >>> ping >>> >>> On 8/31/20 1:10 PM, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review fix for [1] at [2]. There were several issues at play >>>> here. First the parameters added by the compiler to the compact >>>> constructor were not marked as generated, meaning that later on >>>> when checking for annotations, at Check::validateAnnotation, it >>>> couldn't be determine if the annotations were added automatically >>>> with the intention to remove them if out of place. Which is the >>>> strategy for elements generated from the record components. Or if >>>> they were explicitly added by the user. The current implementation >>>> was assuming the last option and thus flagging an error. Also I >>>> realized that at Check::getApplicableTargets, the case when the >>>> target is MODULE was not covered. This was not the product of the >>>> records patch which rewrote this method, this was like this since >>>> the modules times. I think that for completeness, and correctness, >>>> there should be a case for target MODULE at >>>> Check::getApplicableTargets. The compiler was accepting annotations >>>> applied to ElementType.MODULE, just because it was accepting >>>> annotations applied to unknown targets assuming that there was a >>>> bug in the source that would be flagged anyway. I realize that this >>>> change to Check::getApplicableTargets could be considered outside >>>> of the reach of this patch so I'm OK with removing it and file a >>>> separate bug if we consider it a better approach, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252307 >>>> [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/ >>> >> > From vicente.romero at oracle.com Fri Sep 4 17:36:04 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 4 Sep 2020 13:36:04 -0400 Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to fields In-Reply-To: References: <5572d500-3de9-27fc-b8fb-0fbc6ecb5772@oracle.com> <168b26be-84aa-1959-cf82-40dda86c0122@oracle.com> Message-ID: <0a7c4460-5008-0742-55a7-1536c3997941@oracle.com> thanks! Vicente On 9/4/20 12:56 PM, Joe Darcy wrote: > Looks okay; cheers, > > -Joe > > On 9/3/2020 9:12 AM, Vicente Romero wrote: >> ping, I would like to push this one before the github transition, >> >> Thanks, >> Vicente >> >> On 9/2/20 2:10 PM, Vicente Romero wrote: >>> ping >>> >>> On 9/1/20 11:51 AM, Vicente Romero wrote: >>>> ping >>>> >>>> On 8/31/20 1:10 PM, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review fix for [1] at [2]. There were several issues at >>>>> play here. First the parameters added by the compiler to the >>>>> compact constructor were not marked as generated, meaning that >>>>> later on when checking for annotations, at >>>>> Check::validateAnnotation, it couldn't be determine if the >>>>> annotations were added automatically with the intention to remove >>>>> them if out of place. Which is the strategy for elements generated >>>>> from the record components. Or if they were explicitly added by >>>>> the user. The current implementation was assuming the last option >>>>> and thus flagging an error. Also I realized that at >>>>> Check::getApplicableTargets, the case when the target is MODULE >>>>> was not covered. This was not the product of the records patch >>>>> which rewrote this method, this was like this since the modules >>>>> times. I think that for completeness, and correctness, there >>>>> should be a case for target MODULE at Check::getApplicableTargets. >>>>> The compiler was accepting annotations applied to >>>>> ElementType.MODULE, just because it was accepting annotations >>>>> applied to unknown targets assuming that there was a bug in the >>>>> source that would be flagged anyway. I realize that this change to >>>>> Check::getApplicableTargets could be considered outside of the >>>>> reach of this patch so I'm OK with removing it and file a separate >>>>> bug if we consider it a better approach, >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252307 >>>>> [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/ >>>> >>> >> From maurizio.cimadamore at oracle.com Fri Sep 4 20:49:22 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 4 Sep 2020 21:49:22 +0100 Subject: RFR: JDK-8247352: improve error messages for sealed classes and records In-Reply-To: References: Message-ID: Looks good the only comment is that you use strings like "anonymous" and "local" as direct diagnostic arguments. This makes localization complex (if not impossible) because not all the English text is defined in compiler.properties. I suggest introducing a diagnostic fragment for this purpose, and pass the fragment as an argument to the "cant extends sealed" diagnostics. Maurizio On 04/09/2020 02:31, Vicente Romero wrote: > > [1] https://bugs.openjdk.java.net/browse/J From vicente.romero at oracle.com Fri Sep 4 20:51:50 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 4 Sep 2020 16:51:50 -0400 Subject: RFR: JDK-8247352: improve error messages for sealed classes and records In-Reply-To: References: Message-ID: <44988473-dc98-846d-ed3a-4280ac41afcd@oracle.com> Hi, Thanks for the review, I will do that before pushing the final version, Vicente On 9/4/20 4:49 PM, Maurizio Cimadamore wrote: > Looks good > > the only comment is that you use strings like "anonymous" and "local" > as direct diagnostic arguments. This makes localization complex (if > not impossible) because not all the English text is defined in > compiler.properties. > > I suggest introducing a diagnostic fragment for this purpose, and pass > the fragment as an argument to the "cant extends sealed" diagnostics. > > Maurizio > > On 04/09/2020 02:31, Vicente Romero wrote: >> >> [1] https://bugs.openjdk.java.net/browse/J From jlahoda at openjdk.java.net Mon Sep 7 08:04:07 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Sep 2020 08:04:07 GMT Subject: RFR: 8250840: some tests use --enable-preview unnecessarily Message-ID: 8250840: some tests use --enable-preview unnecessarily ------------- Commit messages: - 8250840: some tests use --enable-preview unnecessarily Changes: https://git.openjdk.java.net/jdk/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250840 Stats: 11 lines in 6 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk/pull/41 From jlahoda at openjdk.java.net Mon Sep 7 09:02:56 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Sep 2020 09:02:56 GMT Subject: RFR: 8235229: Compilation against a modular, multi-release JAR erroneous with --release Message-ID: A combination of a multi-release modular jar and --release option does not work well, because the appropriate file manager does not have a multi-release option set. The proposal is to set the multi-release option to the file manager. ------------- Commit messages: - 8235229: Compilation against a modular, multi-release JAR erroneous with --release Changes: https://git.openjdk.java.net/jdk/pull/43/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=43&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235229 Stats: 55 lines in 2 files changed: 54 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/43.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/43/head:pull/43 PR: https://git.openjdk.java.net/jdk/pull/43 From jlahoda at openjdk.java.net Mon Sep 7 11:35:05 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 7 Sep 2020 11:35:05 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference Message-ID: When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to non working code completion in JShell (and possibly other tools). For example (in JShell): Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. and press - this leads to no proposals currently, as the type of "v" is not inferred. The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. ------------- Commit messages: - 8240658: Code completion not working for lambdas in method invocations that require type inference Changes: https://git.openjdk.java.net/jdk/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240658 Stats: 661 lines in 9 files changed: 625 ins; 6 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk/pull/50 From github.com+46417962+jlahoda-jackpot at openjdk.java.net Mon Sep 7 12:50:22 2020 From: github.com+46417962+jlahoda-jackpot at openjdk.java.net (Advanced Static Source Code Analysis) Date: Mon, 7 Sep 2020 12:50:22 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:28:45 GMT, Jan Lahoda wrote: > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 130: > 128: lambda.body = new TreeTranslator() { > 129: @SuppressWarnings("unchecked") > 130: public T translate(T t) { Jackpot: warning: Add @Override Annotation src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 82: > 80: > 81: protected AttrRecover(Context context) { > 82: context.put(attrRepairKey, this); Jackpot: warning: Leaking this in constructor ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From github.com+46417962+jlahoda-jackpot at openjdk.java.net Mon Sep 7 15:30:29 2020 From: github.com+46417962+jlahoda-jackpot at openjdk.java.net (Advanced Static Source Code Analysis) Date: Mon, 7 Sep 2020 15:30:29 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:28:45 GMT, Jan Lahoda wrote: > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 24: > 22: */ > 23: > 24: package test; Jackpot: warning: Incorrect Package test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 24: > 22: */ > 23: > 24: package test; Jackpot: warning: Incorrect Package test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 30: > 28: private static void test() { > 29: Test.of(1).convert(c1 -> {Object o = c1/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 30: Test.of(1).consume(c2 -> {Object o = c2/*getTypeMirror:DECLARED:java.lang.Integer*/; return null;}); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 34: > 32: convert(0, c4 -> {Object o = c4/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 33: consume(0, c5 -> {Object o = c5/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 34: convertVarArgs(0, c6 -> {Object o = c6/*getTypeMirror:DECLARED:java.lang.Integer*/;}, 1, 2, 3, 4); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 29: > 27: > 28: private static void test() { > 29: Test.of(1).convert(c1 -> {Object o = c1/*getTypeMirror:DECLARED:java.lang.Integer*/;}); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 35: > 33: consume(0, c5 -> {Object o = c5/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 34: convertVarArgs(0, c6 -> {Object o = c6/*getTypeMirror:DECLARED:java.lang.Integer*/;}, 1, 2, 3, 4); > 35: consumeVarArgs(0, c7 -> {Object o = c7/*getTypeMirror:DECLARED:java.lang.Integer*/;}, 1, 2, 3, 4); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 33: > 31: Test.of(1).consumeWithParam(c3 -> {Object o = c3/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 32: convert(0, c4 -> {Object o = c4/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 33: consume(0, c5 -> {Object o = c5/*getTypeMirror:DECLARED:java.lang.Integer*/;}); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 32: > 30: Test.of(1).consume(c2 -> {Object o = c2/*getTypeMirror:DECLARED:java.lang.Integer*/; return null;}); > 31: Test.of(1).consumeWithParam(c3 -> {Object o = c3/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 32: convert(0, c4 -> {Object o = c4/*getTypeMirror:DECLARED:java.lang.Integer*/;}); Jackpot: warning: Variable o is never read test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 28: > 26: public class TestGetTypeMirrorReferenceData { > 27: > 28: private static void test() { Jackpot: warning: test is never used test/langtools/tools/javac/api/TestGetTypeMirrorReferenceData.java line 31: > 29: Test.of(1).convert(c1 -> {Object o = c1/*getTypeMirror:DECLARED:java.lang.Integer*/;}); > 30: Test.of(1).consume(c2 -> {Object o = c2/*getTypeMirror:DECLARED:java.lang.Integer*/; return null;}); > 31: Test.of(1).consumeWithParam(c3 -> {Object o = c3/*getTypeMirror:DECLARED:java.lang.Integer*/;}); Jackpot: warning: Variable o is never read ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From vromero at openjdk.java.net Tue Sep 8 16:11:45 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 8 Sep 2020 16:11:45 GMT Subject: RFR: 8250840: some tests use --enable-preview unnecessarily In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 07:58:40 GMT, Jan Lahoda wrote: > 8250840: some tests use --enable-preview unnecessarily just a minor change could be needed, there is no need for another round test/langtools/tools/javac/ConditionalExpressionResolvePending.java line 38: > 36: * @build combo.ComboTestHelper > 37: * @compile ConditionalExpressionResolvePending.java > 38: * @run main/othervm --enable-preview ConditionalExpressionResolvePending do you still need the @run main/othervm? ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/41 From jlahoda at openjdk.java.net Tue Sep 8 16:25:18 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 8 Sep 2020 16:25:18 GMT Subject: RFR: 8250840: some tests use --enable-preview unnecessarily In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 16:08:20 GMT, Vicente Romero wrote: >> 8250840: some tests use --enable-preview unnecessarily > > test/langtools/tools/javac/ConditionalExpressionResolvePending.java line 38: > >> 36: * @build combo.ComboTestHelper >> 37: * @compile ConditionalExpressionResolvePending.java >> 38: * @run main/othervm --enable-preview ConditionalExpressionResolvePending > > do you still need the @run main/othervm? Yes, that's still needed. The test internally compiles some code with --enable-preview and then tries to load and run the code in a separate ClassLoader in the same VM. So --enable-preview at runtime is required. ------------- PR: https://git.openjdk.java.net/jdk/pull/41 From vromero at openjdk.java.net Tue Sep 8 16:28:18 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 8 Sep 2020 16:28:18 GMT Subject: RFR: 8235229: Compilation against a modular, multi-release JAR erroneous with --release In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 08:57:49 GMT, Jan Lahoda wrote: > A combination of a multi-release modular jar and --release option does not work well, because the appropriate file > manager does not have a multi-release option set. The proposal is to set the multi-release option to the file manager. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/43 From vromero at openjdk.java.net Tue Sep 8 16:30:49 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 8 Sep 2020 16:30:49 GMT Subject: RFR: 8250840: some tests use --enable-preview unnecessarily In-Reply-To: References: Message-ID: <1MsuYMF6TQTPDuZOB3xhQxeopb3DM4H52QHcE1YKwYQ=.c61d5618-61bf-438c-9215-3f6f51b8861d@github.com> On Tue, 8 Sep 2020 16:22:34 GMT, Jan Lahoda wrote: >> test/langtools/tools/javac/ConditionalExpressionResolvePending.java line 38: >> >>> 36: * @build combo.ComboTestHelper >>> 37: * @compile ConditionalExpressionResolvePending.java >>> 38: * @run main/othervm --enable-preview ConditionalExpressionResolvePending >> >> do you still need the @run main/othervm? > > Yes, that's still needed. The test internally compiles some code with --enable-preview and then tries to load and run > the code in a separate ClassLoader in the same VM. So --enable-preview at runtime is required. ok looks good ------------- PR: https://git.openjdk.java.net/jdk/pull/41 From vromero at openjdk.java.net Wed Sep 9 00:00:38 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 9 Sep 2020 00:00:38 GMT Subject: RFR: 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results Message-ID: 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results ------------- Commit messages: - 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results Changes: https://git.openjdk.java.net/jdk/pull/88/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=88&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250217 Stats: 27 lines in 2 files changed: 17 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/88.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/88/head:pull/88 PR: https://git.openjdk.java.net/jdk/pull/88 From jlahoda at openjdk.java.net Wed Sep 9 07:54:43 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Sep 2020 07:54:43 GMT Subject: Integrated: 8250840: some tests use --enable-preview unnecessarily In-Reply-To: References: Message-ID: <0YR_XSJAJmbtiZ1NZBZWm6R24LeKYJcI6lE8ORCwXPs=.974e2c65-1a20-4dd8-9ded-d8411d3b98d8@github.com> On Mon, 7 Sep 2020 07:58:40 GMT, Jan Lahoda wrote: > 8250840: some tests use --enable-preview unnecessarily This pull request has now been integrated. Changeset: c98417eb Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/c98417eb Stats: 11 lines in 6 files changed: 0 ins; 0 del; 11 mod 8250840: some tests use --enable-preview unnecessarily Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/41 From gdub at openjdk.java.net Wed Sep 9 08:25:10 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Wed, 9 Sep 2020 08:25:10 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Message-ID: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance behaviour of lambdas in either direction. ------------- Commit messages: - 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Changes: https://git.openjdk.java.net/jdk/pull/93/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242451 Stats: 97 lines in 2 files changed: 73 ins; 5 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From jlahoda at openjdk.java.net Wed Sep 9 12:18:53 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Sep 2020 12:18:53 GMT Subject: RFR: 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 23:53:36 GMT, Vicente Romero wrote: > 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test > results To me, looks reasonable. src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java line 110: > 108: return result.fst; > 109: } else { > 110: return (result.snd instanceof FatalError) ? Main.Result.SYSERR : Main.Result.ABNORMAL; It would be nicer if we didn't have to use an instanceof here, although I see it is somewhat difficult, so does not seem necessary. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/88 From jlahoda at openjdk.java.net Wed Sep 9 12:21:25 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Sep 2020 12:21:25 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: > 27: * @summary Add lambda tests > 28: * Test bridge methods for certain SAM conversions > 29: * Test the set of generate fields I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under test/langtools/tools/javac. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From jlahoda at openjdk.java.net Wed Sep 9 13:05:42 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 9 Sep 2020 13:05:42 GMT Subject: Integrated: 8235229: Compilation against a modular, multi-release JAR erroneous with --release In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 08:57:49 GMT, Jan Lahoda wrote: > A combination of a multi-release modular jar and --release option does not work well, because the appropriate file > manager does not have a multi-release option set. The proposal is to set the multi-release option to the file manager. This pull request has now been integrated. Changeset: 5fef8dda Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/5fef8dda Stats: 55 lines in 2 files changed: 0 ins; 54 del; 1 mod 8235229: Compilation against a modular, multi-release JAR erroneous with --release Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/43 From vromero at openjdk.java.net Wed Sep 9 14:07:42 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 9 Sep 2020 14:07:42 GMT Subject: RFR: 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results In-Reply-To: References: Message-ID: <90VH_VL6jHEK6oUmGc5AD_YDHt75lxhAiBXV7U0P274=.0a4e3a20-7b36-4099-a5cc-16bde86f1ce0@github.com> On Wed, 9 Sep 2020 12:07:59 GMT, Jan Lahoda wrote: >> 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test >> results > > src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java line 110: > >> 108: return result.fst; >> 109: } else { >> 110: return (result.snd instanceof FatalError) ? Main.Result.SYSERR : Main.Result.ABNORMAL; > > It would be nicer if we didn't have to use an instanceof here, although I see it is somewhat difficult, so does not > seem necessary. right there are not many options ------------- PR: https://git.openjdk.java.net/jdk/pull/88 From vromero at openjdk.java.net Wed Sep 9 14:07:43 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 9 Sep 2020 14:07:43 GMT Subject: Integrated: 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 23:53:36 GMT, Vicente Romero wrote: > 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test > results This pull request has now been integrated. Changeset: 43339420 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/43339420 Stats: 27 lines in 2 files changed: 0 ins; 17 del; 10 mod 8250217: com.sun.tools.javac.api.JavacTaskImpl swallows compiler exceptions potentially producing false positive test results Reviewed-by: jlahoda ------------- PR: https://git.openjdk.java.net/jdk/pull/88 From mchung at openjdk.java.net Wed Sep 9 16:39:20 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:39:20 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 215: > 213: if (disableEagerInitialization) { > 214: try { > 215: return new ConstantCallSite(caller.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD, > invokedType.returnType())); Nit: it'd be good to wrap this long line. There are a couple long lines in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Wed Sep 9 16:43:45 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:43:45 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Looks good. I agree with Jan's suggestion that it's good to move the test to test/jdk/java/lang/invoke/lambda which is a better home for it. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Wed Sep 9 16:43:45 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Sep 2020 16:43:45 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Wed, 9 Sep 2020 12:19:04 GMT, Jan Lahoda wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: > >> 27: * @summary Add lambda tests >> 28: * Test bridge methods for certain SAM conversions >> 29: * Test the set of generate fields > > I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under > test/langtools/tools/javac. It's a good suggestion as `disableEagerInitialization` support is not part of javac. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From vromero at openjdk.java.net Wed Sep 9 17:50:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 9 Sep 2020 17:50:16 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:28:45 GMT, Jan Lahoda wrote: > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 103: > 101: if ((todo.candSym.flags() & Flags.VARARGS) == 0 && > 102: mit.args.length() > todo.candSym.type.getParameterTypes().length()) { > 103: break RECOVER; //too many actual parameters, skip question: why not covering varargs too? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 151: > 149: } > 150: @Override > 151: public void visitClassDef(JCClassDecl tree) { just wondering, shouldn't anonymous classes be avoided too? ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From github.com+2210496+thatsIch at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+2210496+thatsIch at openjdk.java.net (thatsIch) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). @doom369 jcheck requires an associated issue ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:21 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:21 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() Message-ID: **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). ------------- Commit messages: - Merge branch 'master' of https://github.com/doom369/jdk into reaplce_equals_with_is_empty - revert change in classes that maintain jdk 1.4 compatibility - Improvement: replace all occurrences of the .equals("") usages with .isEmpty() Changes: https://git.openjdk.java.net/jdk/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252999 Stats: 234 lines in 150 files changed: 0 ins; 0 del; 234 mod Patch: https://git.openjdk.java.net/jdk/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 08:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the `2d` area). ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > @doom369 jcheck requires an associated issue @mrserb hello. Thanks for the review. Any further actions required from me? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 08:52:29 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 08:52:29 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java line 187: > 185: String format = spi.getFormatNames()[0].toLowerCase(); > 186: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 187: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java line 146: > 144: String format = spi.getFormatNames()[0].toLowerCase(); > 145: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 146: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:26 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:26 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote: >> @mrserb hello. Thanks for the review. Any further actions required from me? > > Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a > Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement > request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once > you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing > "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you > should expect a longer review process, since someone from each functional area will need to look at the changes in > their area (like @mrserb started to do for the `2d` area). @kevinrushforth thanks. Done. Similar issues: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 could be joined somehow? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From alanb at openjdk.java.net Thu Sep 10 10:42:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 10:42:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement >> request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once >> you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing >> "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you >> should expect a longer review process, since someone from each functional area will need to look at the changes in >> their area (like @mrserb started to do for the `2d` area). > > @kevinrushforth thanks. Done. > > Similar issues: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 > > could be joined somehow? The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use JDK-8215014 rather than creating a new issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 11:24:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 11:24:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 >> >> could be joined somehow? > > The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do > the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more > more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code > (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan > code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use > JDK-8215014 rather than creating a new issue. This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From gdub at openjdk.java.net Thu Sep 10 11:52:47 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 11:52:47 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Wed, 9 Sep 2020 16:39:25 GMT, Mandy Chung wrote: >> test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29: >> >>> 27: * @summary Add lambda tests >>> 28: * Test bridge methods for certain SAM conversions >>> 29: * Test the set of generate fields >> >> I would suggest to consider having the test under test/jdk/(java/lang/invoke/lambda), not under >> test/langtools/tools/javac. > > It's a good suggestion as `disableEagerInitialization` support is not part of javac. OK makes sense. I guess it's still good to clean the test comments of the old `disableEagerInitialization` references? ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 12:07:57 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 12:07:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 12:21:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 12:21:25 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From jlahoda at openjdk.java.net Thu Sep 10 13:56:46 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 10 Sep 2020 13:56:46 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v2] In-Reply-To: References: Message-ID: <9kOjJIx2_i4SvMp4J7QRWvc3G3d-n4Lvw5-Di0RGqrY=.f68458ed-6194-457a-948a-74bf31f56c4e@github.com> > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Improving behavior for vararg method invocations. - Merge branch 'master' into JDK-8240658 - 8240658: Code completion not working for lambdas in method invocations that require type inference ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/50/files - new: https://git.openjdk.java.net/jdk/pull/50/files/7f4e903e..32845ddb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=50&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=50&range=00-01 Stats: 15586 lines in 549 files changed: 10380 ins; 2664 del; 2542 mod Patch: https://git.openjdk.java.net/jdk/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk/pull/50 From dholmes at openjdk.java.net Thu Sep 10 13:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 13:56:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests > each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. > Maybe @AlanBateman or @jddarcy can offer some advice? 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to: " Too many recipients to the message" I have a longer email coming once it gets through the moderator approval delay. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From jlahoda at openjdk.java.net Thu Sep 10 14:00:32 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 10 Sep 2020 14:00:32 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v2] In-Reply-To: References: Message-ID: <4naY6DWeKRTutTKmr_WA5XX8enazMYoQRPCMUXW4Xwg=.d302c33b-84d2-4d1a-8c9a-285389e23113@github.com> On Tue, 8 Sep 2020 22:54:24 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 three additional commits since >> the last revision: >> - Improving behavior for vararg method invocations. >> - Merge branch 'master' into JDK-8240658 >> - 8240658: Code completion not working for lambdas in method invocations that require type inference > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 151: > >> 149: } >> 150: @Override >> 151: public void visitClassDef(JCClassDecl tree) { > > just wondering, shouldn't anonymous classes be avoided too? Anonymous classes (JCNewClass) contain JCClassDecl representing the actual anonymous class, so this should avoid anonymous classes as well. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 103: > >> 101: if ((todo.candSym.flags() & Flags.VARARGS) == 0 && >> 102: mit.args.length() > todo.candSym.type.getParameterTypes().length()) { >> 103: break RECOVER; //too many actual parameters, skip > > question: why not covering varargs too? Note this is a case where the invoked method is not a varargs method, and there are too many actual parameters. But it is true the varags handling could be improved, which I tried to do in a recent patch (32845dd). ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From gdub at openjdk.java.net Thu Sep 10 15:23:14 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:14 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: - Remove extra field test from LambdaTest6 - Wrap long lines - Add deciated test in the jdk tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/979186b8..422cd01d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=00-01 Stats: 111 lines in 3 files changed: 76 ins; 32 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Thu Sep 10 15:23:16 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:16 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 16:36:43 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: >> >> - Remove extra field test from LambdaTest6 >> - Wrap long lines >> - Add deciated test in the jdk tests > > src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 215: > >> 213: if (disableEagerInitialization) { >> 214: try { >> 215: return new ConstantCallSite(caller.findStaticGetter(innerClass, LAMBDA_INSTANCE_FIELD, >> invokedType.returnType())); > > Nit: it'd be good to wrap this long line. There are a couple long lines in this patch. I have wrapped some lines that were longer than the typical line in this file. Let me know if the wrapping looks good to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Thu Sep 10 15:23:17 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Thu, 10 Sep 2020 15:23:17 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> <9ARL_A2daS8-nEhhporpJpuRtdJJz8XY1mwyH_i99I8=.c3c3df72-8039-4243-b8c6-bd5040aabe64@github.com> Message-ID: On Thu, 10 Sep 2020 11:50:04 GMT, Gilles Duboscq wrote: >> It's a good suggestion as `disableEagerInitialization` support is not part of javac. > > OK makes sense. I guess it's still good to clean the test comments of the old `disableEagerInitialization` references? I have created a new test under `test/jdk/java/lang/invoke/lambda` and cleaned up `LambdaTest6.java` ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From alanb at openjdk.java.net Thu Sep 10 15:53:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 15:53:05 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. >> Maybe @AlanBateman or @jddarcy can offer some advice? > > 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will > be delayed due to all of the mails being held up for moderator approval due to: > " Too many recipients to the message" > > I have a longer email coming once it gets through the moderator approval delay. :( Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From mchung at openjdk.java.net Thu Sep 10 16:36:51 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Sep 2020 16:36:51 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v2] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Thu, 10 Sep 2020 15:23:14 GMT, Gilles Duboscq wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > Gilles Duboscq has updated the pull request incrementally with three additional commits since the last revision: > > - Remove extra field test from LambdaTest6 > - Wrap long lines > - Add deciated test in the jdk tests test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 33: > 31: * @compile LambdaTest6.java > 32: * @run main LambdaTest6 > 33: */ This line was added by JDK-8232806 (https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695). I assume you want to move the test case for JDK-8232806 to test/jdk/java/lang/invoke? If so, BridgeMethod.java should be looked at too. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From jvernee at openjdk.java.net Thu Sep 10 16:40:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Sep 2020 16:40:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> Message-ID: On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due to: >> " Too many recipients to the message" >> >> I have a longer email coming once it gets through the moderator approval delay. :( > > Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests > or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from > the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should > reduce the patch down to a manageable 24 or so files that should be trivial to review. Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang). Also, what testing has been done for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From vromero at openjdk.java.net Thu Sep 10 18:16:12 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 10 Sep 2020 18:16:12 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v2] In-Reply-To: <4naY6DWeKRTutTKmr_WA5XX8enazMYoQRPCMUXW4Xwg=.d302c33b-84d2-4d1a-8c9a-285389e23113@github.com> References: <4naY6DWeKRTutTKmr_WA5XX8enazMYoQRPCMUXW4Xwg=.d302c33b-84d2-4d1a-8c9a-285389e23113@github.com> Message-ID: <6ZnZiKLaas0Eivg64_UxVfn-XFdrl1xSmbI8heoz73Q=.3a96000d-4190-4e62-9733-e02f7ccdfaa9@github.com> On Thu, 10 Sep 2020 13:58:03 GMT, Jan Lahoda wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/AttrRecover.java line 103: >> >>> 101: if ((todo.candSym.flags() & Flags.VARARGS) == 0 && >>> 102: mit.args.length() > todo.candSym.type.getParameterTypes().length()) { >>> 103: break RECOVER; //too many actual parameters, skip >> >> question: why not covering varargs too? > > Note this is a case where the invoked method is not a varargs method, and there are too many actual parameters. But it > is true the varags handling could be improved, which I tried to do in a recent patch (32845dd). I like the patch. I think it is great. My only comment would be about test: TestGetTypeMirrorReference.java which does a golden file like comparison but I understand that there are not many options. I would suggest though to place this test along with file: TestGetTypeMirrorReferenceData.java in a separate folder and add some doc to the test so that it would be easier to modify it in the future ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From vromero at openjdk.java.net Thu Sep 10 18:16:11 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 10 Sep 2020 18:16:11 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v2] In-Reply-To: <9kOjJIx2_i4SvMp4J7QRWvc3G3d-n4Lvw5-Di0RGqrY=.f68458ed-6194-457a-948a-74bf31f56c4e@github.com> References: <9kOjJIx2_i4SvMp4J7QRWvc3G3d-n4Lvw5-Di0RGqrY=.f68458ed-6194-457a-948a-74bf31f56c4e@github.com> Message-ID: On Thu, 10 Sep 2020 13:56:46 GMT, Jan Lahoda wrote: >> When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is >> a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to >> non working code completion in JShell (and possibly other tools). For example (in JShell): >> Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. >> >> and press - this leads to no proposals currently, as the type of "v" is not inferred. >> >> The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, >> and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - Improving behavior for vararg method invocations. > - Merge branch 'master' into JDK-8240658 > - 8240658: Code completion not working for lambdas in method invocations that require type inference Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From jjg at openjdk.java.net Thu Sep 10 23:02:41 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:02:41 GMT Subject: RFR: 8236142: DocTrees should provide getCharacters(EntityTree) Message-ID: A new method is added to the `DocTrees` utility class to return the characters represented by a named or numeric entity, as represented in an `EntityTree`. ------------- Commit messages: - add DocTrees.getCharacters(EntityTree) Changes: https://git.openjdk.java.net/jdk/pull/122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236142 Stats: 4460 lines in 7 files changed: 2230 ins; 2222 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk/pull/122 From jjg at openjdk.java.net Thu Sep 10 23:10:48 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:10:48 GMT Subject: RFR: 8236142: DocTrees should provide getCharacters(EntityTree) In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 22:53:42 GMT, Jonathan Gibbons wrote: > A new method is added to the `DocTrees` utility class to return the characters represented by a named or numeric > entity, as represented in an `EntityTree`. Note that as well as the simple move for the `Entity.java` file, the init for the class is optimized to be significantly smaller byte codes. That particular change was automated: there should be no change to the set of strings that are accepted by the class. ------------- PR: https://git.openjdk.java.net/jdk/pull/122 From jjg at openjdk.java.net Thu Sep 10 23:31:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:31:29 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy wrote: > I have in mind dozens of improvements all over the code like this one. That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 11 00:00:15 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 11 Sep 2020 00:00:15 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). 1) This is un-necessary churn. 2) I can't even be sure I am finding the ones in my area because there's so much here 3) The ones I can find have no need of whatever performance improvement this might bring. I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/29 From jjg at openjdk.java.net Fri Sep 11 03:02:36 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 11 Sep 2020 03:02:36 GMT Subject: RFR: 8236142: DocTrees should provide getCharacters(EntityTree) [v2] In-Reply-To: References: Message-ID: > A new method is added to the `DocTrees` utility class to return the characters represented by a named or numeric > entity, as represented in an `EntityTree`. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update Copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/122/files - new: https://git.openjdk.java.net/jdk/pull/122/files/33f2e636..1d3489c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=122&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=122&range=00-01 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/122/head:pull/122 PR: https://git.openjdk.java.net/jdk/pull/122 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: Withdrawn: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > 1) This is un-necessary churn. > 2) I can't even be sure I am finding the ones in my area because there's so much here > 3) The ones I can find have no need of whatever performance improvement this might bring. > I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various > cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates > you are making. Ok, sorry for the distraction. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From jlahoda at openjdk.java.net Fri Sep 11 13:51:21 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 11 Sep 2020 13:51:21 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v3] In-Reply-To: References: Message-ID: > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Moving the TestGetTypeMirrorReference test into a separate folder. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/50/files - new: https://git.openjdk.java.net/jdk/pull/50/files/32845ddb..988f85be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=50&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=50&range=01-02 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk/pull/50 From jlahoda at openjdk.java.net Fri Sep 11 13:56:59 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 11 Sep 2020 13:56:59 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v3] In-Reply-To: <6ZnZiKLaas0Eivg64_UxVfn-XFdrl1xSmbI8heoz73Q=.3a96000d-4190-4e62-9733-e02f7ccdfaa9@github.com> References: <4naY6DWeKRTutTKmr_WA5XX8enazMYoQRPCMUXW4Xwg=.d302c33b-84d2-4d1a-8c9a-285389e23113@github.com> <6ZnZiKLaas0Eivg64_UxVfn-XFdrl1xSmbI8heoz73Q=.3a96000d-4190-4e62-9733-e02f7ccdfaa9@github.com> Message-ID: On Thu, 10 Sep 2020 18:11:24 GMT, Vicente Romero wrote: >> Note this is a case where the invoked method is not a varargs method, and there are too many actual parameters. But it >> is true the varags handling could be improved, which I tried to do in a recent patch (32845dd). > > I like the patch. I think it is great. My only comment would be about test: TestGetTypeMirrorReference.java which does > a golden file like comparison but I understand that there are not many options. I would suggest though to place this > test along with file: TestGetTypeMirrorReferenceData.java in a separate folder and add some doc to the test so that it > would be easier to modify it in the future Thanks! I've tried to improve the text (moved to a separate directory, added comment) in 988f85b. ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From prappo at openjdk.java.net Fri Sep 11 14:47:07 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Fri, 11 Sep 2020 14:47:07 GMT Subject: RFR: 8236142: DocTrees should provide getCharacters(EntityTree) [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 03:02:36 GMT, Jonathan Gibbons wrote: >> A new method is added to the `DocTrees` utility class to return the characters represented by a named or numeric >> entity, as represented in an `EntityTree`. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Update Copyright years Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/122 From jjg at openjdk.java.net Fri Sep 11 14:50:08 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 11 Sep 2020 14:50:08 GMT Subject: Integrated: 8236142: DocTrees should provide getCharacters(EntityTree) In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 22:53:42 GMT, Jonathan Gibbons wrote: > A new method is added to the `DocTrees` utility class to return the characters represented by a named or numeric > entity, as represented in an `EntityTree`. This pull request has now been integrated. Changeset: 7f27d0b0 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/7f27d0b0 Stats: 4464 lines in 7 files changed: 2222 ins; 2230 del; 12 mod 8236142: DocTrees should provide getCharacters(EntityTree) Reviewed-by: prappo ------------- PR: https://git.openjdk.java.net/jdk/pull/122 From gdub at openjdk.java.net Fri Sep 11 15:07:23 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 11 Sep 2020 15:07:23 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: Remove disableEagerInitialization concerns from BridgeMethod.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/422cd01d..625feb94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=01-02 Stats: 32 lines in 1 file changed: 0 ins; 22 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Fri Sep 11 15:07:24 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 11 Sep 2020 15:07:24 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Thu, 10 Sep 2020 16:34:02 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove disableEagerInitialization concerns from BridgeMethod.java > > test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 33: > >> 31: * @compile LambdaTest6.java >> 32: * @run main LambdaTest6 >> 33: */ > > This line was added by JDK-8232806 (https://hg.openjdk.java.net/jdk/jdk/rev/27c2d2a4b695). > I assume you want to move the test case for JDK-8232806 to test/jdk/java/lang/invoke? If so, > BridgeMethod.java should be looked at too. I have removed all the `disableEagerInitialization` tests from `BridgeMethod.java`. It is now restored to its pre-JDK-8232806 state. ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From wetmore at openjdk.java.net Fri Sep 11 15:20:36 2020 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 11 Sep 2020 15:20:36 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy wrote: >> 1) This is un-necessary churn. >> 2) I can't even be sure I am finding the ones in my area because there's so much here >> 3) The ones I can find have no need of whatever performance improvement this might bring. >> I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various >> cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates >> you are making. > > Ok, sorry for the distraction. Our local Santuario maintainer says: In general, changes to Apache Santuario should also be made at Apache so we stay in sync. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From jjg at openjdk.java.net Fri Sep 11 17:18:28 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 11 Sep 2020 17:18:28 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module Message-ID: doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the `-Xdoclint` family of options. When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller disturbance to the `JavadocFormatter` class. ------------- Commit messages: - Merge - move doclint to jdk.javadoc module - add DocTrees.getCharacters(EntityTree) Changes: https://git.openjdk.java.net/jdk/pull/133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252712 Stats: 605 lines in 104 files changed: 49 ins; 413 del; 143 mod Patch: https://git.openjdk.java.net/jdk/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk/pull/133 From mchung at openjdk.java.net Fri Sep 11 18:22:56 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Sep 2020 18:22:56 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v3] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: <5L4AuJbxZaEaS14dbG3o9stCf4ZfdvJX8Db2xnJplcs=.ebfe1a20-d39e-4119-9c34-e4c70a6a5a3e@github.com> On Wed, 9 Sep 2020 16:41:22 GMT, Mandy Chung wrote: >> Gilles Duboscq has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove disableEagerInitialization concerns from BridgeMethod.java > > Looks good. I agree with Jan's suggestion that it's good to move the test to test/jdk/java/lang/invoke/lambda which > is a better home for it. Thanks for updating BridgeMethod.java. I expected that the new LambdaEagerInitTest.java will be updated to verify the capturing lambda case that does not have the static `LAMBDA_INSTANCE$` field. BTW, this new regression test should be moved to `test/jdk/java/lang/invoke/lambda/` instead of `test/jdk/java/lang/invoke`. The test uses `assert`. Note that java assertion is not enabled by default. So regression tests should do an explicit check and throw runtime exception when the test fails. You can also use the JDK test library `jdk.test.lib.Asserts` or make this a testng test to use TestNG Asserts API. I updated and improved the test for your reference (send you separately). ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From vromero at openjdk.java.net Fri Sep 11 20:48:51 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Sep 2020 20:48:51 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v2] In-Reply-To: References: <9kOjJIx2_i4SvMp4J7QRWvc3G3d-n4Lvw5-Di0RGqrY=.f68458ed-6194-457a-948a-74bf31f56c4e@github.com> Message-ID: On Thu, 10 Sep 2020 18:11:41 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 three additional commits since >> the last revision: >> - Improving behavior for vararg method invocations. >> - Merge branch 'master' into JDK-8240658 >> - 8240658: Code completion not working for lambdas in method invocations that require type inference > > Marked as reviewed by vromero (Reviewer). I like the changes done at (988f85b) thanks. I think the patch is ready to go ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From vromero at openjdk.java.net Fri Sep 11 20:48:48 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 11 Sep 2020 20:48:48 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v3] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 13:51:21 GMT, Jan Lahoda wrote: >> When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is >> a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to >> non working code completion in JShell (and possibly other tools). For example (in JShell): >> Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. >> >> and press - this leads to no proposals currently, as the type of "v" is not inferred. >> >> The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, >> and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Moving the TestGetTypeMirrorReference test into a separate folder. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From jlahoda at openjdk.java.net Mon Sep 14 08:16:08 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 14 Sep 2020 08:16:08 GMT Subject: Integrated: 8240658: Code completion not working for lambdas in method invocations that require type inference In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:28:45 GMT, Jan Lahoda wrote: > When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is > a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to > non working code completion in JShell (and possibly other tools). For example (in JShell): > Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. > > and press - this leads to no proposals currently, as the type of "v" is not inferred. > > The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, > and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. This pull request has now been integrated. Changeset: 68da63dc Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/68da63dc Stats: 708 lines in 9 files changed: 9 ins; 672 del; 27 mod 8240658: Code completion not working for lambdas in method invocations that require type inference Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From prappo at openjdk.java.net Mon Sep 14 09:16:42 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 14 Sep 2020 09:16:42 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler Message-ID: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of compiler. ------------- Commit messages: - Misc. cleanup - Fixed an embarrassing typo in `{@docroot}`. (Yes, I know that "{@docroot}" is case-insensitive when passed on a command line.) - 1. Added missing `bp < buflen` conditions to all but one(!) `while` loops. Those conditions guard against infinite loops. Perhaps in the future we should use `boolean notEOF() { return bp < buflen; }` instead. The only naked `while` loop left is in `erroneous(...)`; that method needs to be revisited anyway. I suspect it's not rolling back correctly. Changes: https://git.openjdk.java.net/jdk/pull/148/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=148&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252882 Stats: 93 lines in 12 files changed: 36 ins; 7 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/148/head:pull/148 PR: https://git.openjdk.java.net/jdk/pull/148 From vromero at openjdk.java.net Mon Sep 14 13:58:02 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Sep 2020 13:58:02 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On Mon, 14 Sep 2020 09:09:11 GMT, Pavel Rappo wrote: > Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of > compiler. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 290: > 288: > 289: protected void inlineTag(ListBuffer list) { > 290: assert buf[bp] == '{' : buf[bp]; not sure that this is what you want to do. We usually use com.sun.tools.javac.util.Assert for this as they can't be skipped if the code is not executed with assertions off. Same for similar changes in this patch ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From prappo at openjdk.java.net Mon Sep 14 14:11:27 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 14 Sep 2020 14:11:27 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On Mon, 14 Sep 2020 13:47:28 GMT, Vicente Romero wrote: >> Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of >> compiler. > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 290: > >> 288: >> 289: protected void inlineTag(ListBuffer list) { >> 290: assert buf[bp] == '{' : buf[bp]; > > not sure that this is what you want to do. We usually use com.sun.tools.javac.util.Assert for this as they can't be > skipped if the code is not executed with assertions off. Same for similar changes in this patch I was hoping to use the `assert` facility for the purposes it was designed for. That particular occurrence of `assert` as well as others in this pull request are about asserting that **our code** is being correct rather than input being correct. The invariants those assertions establish MUST hold regardless of the input. ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From vromero at openjdk.java.net Mon Sep 14 14:59:03 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Sep 2020 14:59:03 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On Mon, 14 Sep 2020 14:08:50 GMT, Pavel Rappo wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 290: >> >>> 288: >>> 289: protected void inlineTag(ListBuffer list) { >>> 290: assert buf[bp] == '{' : buf[bp]; >> >> not sure that this is what you want to do. We usually use com.sun.tools.javac.util.Assert for this as they can't be >> skipped if the code is not executed with assertions off. Same for similar changes in this patch > > I was hoping to use the `assert` facility for the purposes it was designed for. That particular occurrence of `assert` > as well as others in this pull request are about asserting that **our code** is being correct rather than input being > correct. The invariants those assertions establish MUST hold regardless of the input. right in that case you should certainly use com.sun.tools.javac.util.Assert instead ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From prappo at openjdk.java.net Mon Sep 14 15:09:29 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 14 Sep 2020 15:09:29 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On Mon, 14 Sep 2020 14:56:39 GMT, Vicente Romero wrote: >> I was hoping to use the `assert` facility for the purposes it was designed for. That particular occurrence of `assert` >> as well as others in this pull request are about asserting that **our code** is being correct rather than input being >> correct. The invariants those assertions establish MUST hold regardless of the input. > > right in that case you should certainly use com.sun.tools.javac.util.Assert instead I won't use the `com.sun.tools.javac.util.Assert` facility as it has a number of disadvantages over `assert` in that particular case. However, I will remove `assert` statements and update the pull request. Will that do? ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From jonathan.gibbons at oracle.com Mon Sep 14 15:42:26 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 14 Sep 2020 08:42:26 -0700 Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On 9/14/20 7:11 AM, Pavel Rappo wrote: > I was hoping to use the `assert` facility for the purposes it was designed for. That particular occurrence of `assert` > as well as others in this pull request are about asserting that **our code** is being correct rather than input being > correct. The invariants those assertions establish MUST hold regardless of the input. Assert/assert in all its forms should only be used to assert that our code is correct. It is (and always has been) an anti-pattern to use it for asserting that input is correct, whether that is user input, illegal arguments, etc. As Jan explained at one point, the use of the Assert class is to better manage failures in case our code was incorrect, by failing-fast at well-defined, instead of carrying on regardless, until the code fell over for downstream reasons. -- Jon From prappo at openjdk.java.net Mon Sep 14 16:12:18 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 14 Sep 2020 16:12:18 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler [v2] In-Reply-To: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: <-AYZhyztkRN_rxo857cUPZPLNJ_Ya56_az5y8z6NJyw=.eb40accc-5e14-47eb-8870-7b782697b474@github.com> > Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of > compiler. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: To address pull-request feedback, I removed 4 `assert` statements I introduced earlier. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/148/files - new: https://git.openjdk.java.net/jdk/pull/148/files/acb118a3..67fa917b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=148&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=148&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/148.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/148/head:pull/148 PR: https://git.openjdk.java.net/jdk/pull/148 From vromero at openjdk.java.net Mon Sep 14 16:52:17 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Sep 2020 16:52:17 GMT Subject: RFR: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler [v2] In-Reply-To: <-AYZhyztkRN_rxo857cUPZPLNJ_Ya56_az5y8z6NJyw=.eb40accc-5e14-47eb-8870-7b782697b474@github.com> References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> <-AYZhyztkRN_rxo857cUPZPLNJ_Ya56_az5y8z6NJyw=.eb40accc-5e14-47eb-8870-7b782697b474@github.com> Message-ID: On Mon, 14 Sep 2020 16:12:18 GMT, Pavel Rappo wrote: >> Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of >> compiler. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > To address pull-request feedback, I removed 4 `assert` statements I introduced earlier. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From prappo at openjdk.java.net Mon Sep 14 17:24:41 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 14 Sep 2020 17:24:41 GMT Subject: Integrated: 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler In-Reply-To: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> References: <54zLF1sOOj16oY8fE4T1M9XnmnP9UrpPd0JYokcnzFQ=.ad86988e-ef3c-4c50-ab60-2349de56a6ee@github.com> Message-ID: On Mon, 14 Sep 2020 09:09:11 GMT, Pavel Rappo wrote: > Yet another cleanup change that has accumulated during my work on `DocCommentParser` and other javadoc-related areas of > compiler. This pull request has now been integrated. Changeset: e6a493ab Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/e6a493ab Stats: 89 lines in 11 files changed: 7 ins; 32 del; 50 mod 8252882: Clean up jdk.javadoc and the related parts of jdk.compiler Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/148 From mcimadamore at openjdk.java.net Mon Sep 14 20:33:45 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 14 Sep 2020 20:33:45 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v3] In-Reply-To: References: Message-ID: <9c2GPF7-DotiEhk5_XRU2ukPxPCph-bRMmAlIim3PuE=.c5b81718-b651-4a0d-99a5-533a67e28c57@github.com> On Fri, 11 Sep 2020 13:51:21 GMT, Jan Lahoda wrote: >> When a method invocation requires type inference, and the user is in the process of typing of a (block) lambda that is >> a parameter to the method invocation, javac may not, in some cases, perform the type inference, which then may lead to >> non working code completion in JShell (and possibly other tools). For example (in JShell): >> Arrays.stream(new Integer[]{1}).forEach(v -> { System.err.println(v. >> >> and press - this leads to no proposals currently, as the type of "v" is not inferred. >> >> The idea of the proposed patch is to improve the recovery in cases significant for cases where the text is being typed, >> and allow type inference in these cases. The type of "v" is then inferred, and the code completion works. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Moving the TestGetTypeMirrorReference test into a separate folder. Late to the party; I like the fact that the recovery logic now seats neatly in its own class. In fact, I think we should probably push this even further, and explore the possibility of decoupling regular attribution from recovery attribution completely - e.g. have recovery attribution run in its separate compiler pass. Probably a bit tricky to pull off in full, but I think it will significantly simplify the maintenance of the attr code going forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From darcy at openjdk.java.net Mon Sep 14 23:49:29 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Sep 2020 23:49:29 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM Message-ID: The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. ------------- Commit messages: - Update symbol generation to accomodate Git as the SCM Changes: https://git.openjdk.java.net/jdk/pull/161/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253034 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/161/head:pull/161 PR: https://git.openjdk.java.net/jdk/pull/161 From adityam at openjdk.java.net Tue Sep 15 01:22:13 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 15 Sep 2020 01:22:13 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. make/scripts/generate-symbol-data.sh line 66: > 64: fi; > 65: > 66: if [ "`git status -s .`x" != "x" ] ; then Just a suggestion: perhaps you want to use the porcelain format here instead of short? https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From hannesw at openjdk.java.net Tue Sep 15 09:18:20 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 09:18:20 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes Message-ID: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> 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 ------------- Commit messages: - 8216497: javadoc should auto-link to platform classes Changes: https://git.openjdk.java.net/jdk/pull/171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8216497 Stats: 3230 lines in 53 files changed: 3220 ins; 4 del; 6 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 jlahoda at openjdk.java.net Tue Sep 15 10:53:16 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 15 Sep 2020 10:53:16 GMT Subject: RFR: 8240658: Code completion not working for lambdas in method invocations that require type inference [v3] In-Reply-To: <9c2GPF7-DotiEhk5_XRU2ukPxPCph-bRMmAlIim3PuE=.c5b81718-b651-4a0d-99a5-533a67e28c57@github.com> References: <9c2GPF7-DotiEhk5_XRU2ukPxPCph-bRMmAlIim3PuE=.c5b81718-b651-4a0d-99a5-533a67e28c57@github.com> Message-ID: On Mon, 14 Sep 2020 20:30:56 GMT, Maurizio Cimadamore wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Moving the TestGetTypeMirrorReference test into a separate folder. > > Late to the party; I like the fact that the recovery logic now seats neatly in its own class. In fact, I think we > should probably push this even further, and explore the possibility of decoupling regular attribution from recovery > attribution completely - e.g. have recovery attribution run in its separate compiler pass. Probably a bit tricky to > pull off in full, but I think it will significantly simplify the maintenance of the attr code going forward. @mcimadamore - sure, I'll look into that! ------------- PR: https://git.openjdk.java.net/jdk/pull/50 From jlahoda at openjdk.java.net Tue Sep 15 11:32:50 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 15 Sep 2020 11:32:50 GMT Subject: RFR: 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 I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that here: https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690 Some comments on the attempt: -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto element-list-10.txt)? -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list for some of the past versions would be better than having to create a new list for each new release. -the patch does not yet generate the list for the current release, but that should be doable. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From jpai at openjdk.java.net Tue Sep 15 12:26:12 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:26:12 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v2] In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8244706? > The commit here sets the `OS` header flag to `255` (which represents `unknown`) as noted in [1]. A new test has been > included in this commit to verify the change. Furthermore, this doesn't impact the `java.util.zip.GZIPInputStream` > since it ignores [2] this header value while reading the headers from the stream. [1] > https://tools.ietf.org/html/rfc1952#page-7 [2] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai 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: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) Reviewed-By: ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/130/files - new: https://git.openjdk.java.net/jdk/pull/130/files/afad1261..159684de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/130/head:pull/130 PR: https://git.openjdk.java.net/jdk/pull/130 From jpai at openjdk.java.net Tue Sep 15 12:31:15 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 12:31:15 GMT Subject: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v3] In-Reply-To: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> References: <1cKL6SKmrX26pDHkIk7Qf13afAEaM13e2ZxyB9_8s1Q=.14f4d4f5-b76f-46d5-b769-8f58e8f7a628@github.com> Message-ID: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-8244706? > The commit here sets the `OS` header flag to `255` (which represents `unknown`) as noted in [1]. A new test has been > included in this commit to verify the change. Furthermore, this doesn't impact the `java.util.zip.GZIPInputStream` > since it ignores [2] this header value while reading the headers from the stream. [1] > https://tools.ietf.org/html/rfc1952#page-7 [2] > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#L173 Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Improve the comment for the OS_UNKNOWN field ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/130/files - new: https://git.openjdk.java.net/jdk/pull/130/files/159684de..7679b119 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=130&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/130.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/130/head:pull/130 PR: https://git.openjdk.java.net/jdk/pull/130 From erikj at openjdk.java.net Tue Sep 15 12:57:17 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Sep 2020 12:57:17 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From hannesw at openjdk.java.net Tue Sep 15 12:58:44 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 12:58:44 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 15 Sep 2020 11:30:09 GMT, Jan Lahoda 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 > > I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym > historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that > here: https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690 > Some comments on the attempt: > -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto > element-list-10.txt)? > -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not > exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list > for some of the past versions would be better than having to create a new list for each new release. > -the patch does not yet generate the list for the current release, but that should be doable. Thanks for the suggestions and help, Jan! > I think it would be awesome if we could generate (most of) the {element,package}-list-VERSION.txt from the ct.sym > historical data at build time. This would (hopefully) help with long-term maintenance. I've started to sketch that > here: [lahodaj at 36c1510](https://github.com/lahodaj/jdk/commit/36c1510587a4b050b148eda87ae7a7a89aff9690) I agree files should be generated dynamically. I knew about the sym files but wasn't sure how to go about it. Thanks a lot for stepping in and helping out, it's very much appreciated! > Some comments on the attempt: > -in this PR, there is package-list-9.txt - should it be element-list-9.txt, and should it contain module names (dtto > element-list-10.txt)? Javadoc in 9 still uses the old package-centric layout (package-list and no module names in URL paths). It only became fully module-aware in 10. > -we may (for historical reasons) want to keep the lists for 7, 8, 9 and 10 (as the historical data in ct.sym do not > exactly match what is in the package/element lists). It would be better to generate everything, but having a fixed list > for some of the past versions would be better than having to create a new list for each new release. > -the patch does not yet generate the list for the current release, but that should be doable. I definitely agree. I'll work on a new version that generates as much of the lists as possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From erikj at openjdk.java.net Tue Sep 15 12:58:44 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Sep 2020 12:58:44 GMT Subject: RFR: 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: <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> 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 Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/171 From hannesw at openjdk.java.net Tue Sep 15 13:15:18 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Sep 2020 13:15:18 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes In-Reply-To: <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> <4CDMu2V_lHE_0xOp3zfR4An3GKV91vukCXMDq4AuO-k=.e6b96bf7-c4d1-4951-904c-dfb9521bbb71@github.com> Message-ID: On Tue, 15 Sep 2020 12:56:13 GMT, Erik Joelsson 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 > > Build changes look good. Converted to draft as @lahodaj has offered to enhance the feature as described in the comments above. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From ehelin at openjdk.java.net Tue Sep 15 13:48:07 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Tue, 15 Sep 2020 13:48:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 01:19:32 GMT, Aditya Mandaleeka wrote: >> The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. > > make/scripts/generate-symbol-data.sh line 66: > >> 64: fi; >> 65: >> 66: if [ "`git status -s .`x" != "x" ] ; then > > Just a suggestion: perhaps you want to use the porcelain format here instead of short? > https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt I agree with @adityamandaleeka, please use `git status --porcelain=v1`. See the git status [documentation](https://git-scm.com/docs/git-status#_porcelain_format_version_1) for the specification for the output. ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From darcy at openjdk.java.net Tue Sep 15 20:10:42 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:10:42 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 13:45:40 GMT, Erik Helin wrote: >> make/scripts/generate-symbol-data.sh line 66: >> >>> 64: fi; >>> 65: >>> 66: if [ "`git status -s .`x" != "x" ] ; then >> >> Just a suggestion: perhaps you want to use the porcelain format here instead of short? >> https://git-scm.com/docs/git-status#Documentation/git-status.txt---porcelainltversiongt > > I agree with @adityamandaleeka, please use `git status --porcelain=v1`. See the git status > [documentation](https://git-scm.com/docs/git-status#_porcelain_format_version_1) for the specification for the output. @adityamandaleeka and @edvbld, thanks for the suggestion; I'll update the patch accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From darcy at openjdk.java.net Tue Sep 15 20:21:07 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:21:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM [v2] In-Reply-To: References: Message-ID: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/161/files - new: https://git.openjdk.java.net/jdk/pull/161/files/2910def1..c577063c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=161&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/161.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/161/head:pull/161 PR: https://git.openjdk.java.net/jdk/pull/161 From adityam at openjdk.java.net Tue Sep 15 20:21:07 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 15 Sep 2020 20:21:07 GMT Subject: RFR: 8253034: Update symbol generation to accomodate Git as the SCM [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:18:31 GMT, Joe Darcy wrote: >> The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback Marked as reviewed by adityam (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From darcy at openjdk.java.net Tue Sep 15 20:44:52 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Sep 2020 20:44:52 GMT Subject: Integrated: 8253034: Update symbol generation to accomodate Git as the SCM In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 23:41:52 GMT, Joe Darcy wrote: > The symbol generation script assumed Mercurial was being used as the SCM. This should now be updated to Git. This pull request has now been integrated. Changeset: fc36328d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/fc36328d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253034: Update symbol generation to accomodate Git as the SCM Reviewed-by: erikj, adityam ------------- PR: https://git.openjdk.java.net/jdk/pull/161 From jlahoda at openjdk.java.net Wed Sep 16 08:05:08 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 16 Sep 2020 08:05:08 GMT Subject: RFR: 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release Message-ID: Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168. ------------- Commit messages: - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release Changes: https://git.openjdk.java.net/jdk/pull/200/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253168 Stats: 523 lines in 3 files changed: 465 ins; 30 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk/pull/200 From vromero at openjdk.java.net Wed Sep 16 19:41:49 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 16 Sep 2020 19:41:49 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda wrote: > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements > across all modules in the module graph, and only return a value when they find exactly one element. This is > troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from > any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that > these unqualified methods would first look for elements visible from the root modules, and would search the internals > of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: > https://bugs.openjdk.java.net/browse/JDK-8253168. I have also made some small edits to the CSR and added myself as reviewer src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 59: > 57: * If running with modules, packages of the given name are searched in a > 58: * two-stage process: > 59: * -find non-empty packages with the given name returned by {@link #getPackageElement(ModuleElement, > CharSequence)}, where the provided ModuleSymbol is any root module, it would be nice to try to keep the line width as close as possible to 80 chars, same for the CSR src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 134: > 132: * If running with modules, type elements of the given name are searched in a > 133: * two-stage process: > 134: * -find type elements with the given name returned by {@link #getTypeElement(ModuleElement, CharSequence)}, > where the provided ModuleSymbol is any root module, same comment as above src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 203: > 201: Set found = new LinkedHashSet<>(); > 202: > 203: for (Set allModules : Arrays.asList(modules.getRootModules(), modules.allModules())) { does it make sense to obtain a diff between the the root modules and the all-modules set in order to avoid searching twice in the root modules if the symbol is not found there in the first try? src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 237: > 235: return Optional.empty(); > 236: } else { > 237: //not found, try another option probably this else {} can be removed right? ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From mail at smogura.eu Thu Sep 17 05:29:08 2020 From: mail at smogura.eu (=?utf-8?B?UmFkb3PFgmF3IFNtb2d1cmE=?=) Date: Thu, 17 Sep 2020 05:29:08 +0000 Subject: Getting class output file (modules vs non-modules) Message-ID: Hi all, I?m trying to write class transformer which will cooperate with JavaC compiler. To make this working I detect changed class and I?m using FileManager obtained from JavacProcessingEnvironment to get Java File Object for output, and than read and store changed byte code. However I have to determine output location, and I wonder for what kind of elements I have to do care about this? In source code of JavaC writer I?ve seen it happens only if owner of element is module, but owners of classes are packages? So should I care about output location of calls files or can I just use StandardLocation.CLASS_OUTPUT? Kind regards, Rado Smogura From jjg at openjdk.java.net Thu Sep 17 17:25:15 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 17 Sep 2020 17:25:15 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: > doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the > `-Xdoclint` family of options. > When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the > code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. > This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to > javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service > binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: > the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the > service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to > cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, > this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on > the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no > longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its > requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local > enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller > disturbance to the `JavadocFormatter` class. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - Merge - move doclint to jdk.javadoc module - add DocTrees.getCharacters(EntityTree) ------------- Changes: https://git.openjdk.java.net/jdk/pull/133/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=01 Stats: 605 lines in 104 files changed: 49 ins; 413 del; 143 mod Patch: https://git.openjdk.java.net/jdk/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk/pull/133 From jlahoda at openjdk.java.net Thu Sep 17 17:59:00 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 17 Sep 2020 17:59:00 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: References: Message-ID: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements > across all modules in the module graph, and only return a value when they find exactly one element. This is > troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from > any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that > these unqualified methods would first look for elements visible from the root modules, and would search the internals > of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: > https://bugs.openjdk.java.net/browse/JDK-8253168. Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/200/files - new: https://git.openjdk.java.net/jdk/pull/200/files/f685a41b..3eb2c0bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=00-01 Stats: 36 lines in 2 files changed: 22 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk/pull/200 From jlahoda at openjdk.java.net Thu Sep 17 18:02:05 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 17 Sep 2020 18:02:05 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:37:16 GMT, Vicente Romero wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. > > I have also made some small edits to the CSR and added myself as reviewer @vicente-romero-oracle thanks for the comments! I've updated the patch and CSR based on the comments. > src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 237: > >> 235: return Optional.empty(); >> 236: } else { >> 237: //not found, try another option > > probably this else {} can be removed right? It could be removed, but I added it intentionally to make it clear the "else" option has been considered, and is intentional. I can remove it, if you strongly prefer, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From vromero at openjdk.java.net Thu Sep 17 21:39:19 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 17 Sep 2020 21:39:19 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> References: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> Message-ID: On Thu, 17 Sep 2020 17:59:00 GMT, Jan Lahoda wrote: >> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements >> across all modules in the module graph, and only return a value when they find exactly one element. This is >> troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from >> any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that >> these unqualified methods would first look for elements visible from the root modules, and would search the internals >> of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: >> https://bugs.openjdk.java.net/browse/JDK-8253168. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From vromero at openjdk.java.net Thu Sep 17 21:39:19 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 17 Sep 2020 21:39:19 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 17:58:34 GMT, Jan Lahoda wrote: >> I have also made some small edits to the CSR and added myself as reviewer > > @vicente-romero-oracle thanks for the comments! I've updated the patch and CSR based on the comments. I'm OK with the second iteration, thanks for doing the changes! approved Vicente ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From smarks at openjdk.java.net Fri Sep 18 02:50:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Sep 2020 02:50:45 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 18 11:07:46 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 18 Sep 2020 11:07:46 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <668fR1wEZWaC0TDCyRIeOZ4AddXZXnKQhyHQdXtOab8=.6cb419cb-632b-4524-980e-18a6e06958e8@github.com> On Fri, 18 Sep 2020 02:48:15 GMT, Stuart Marks wrote: >> Our local Santuario maintainer says: >> >> In general, changes to Apache Santuario should also be made at Apache so we stay in sync. > > Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made > earlier in this PR, >> I have in mind dozens of improvements all over the code like this one. > > It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and > sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source > bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... > so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to > code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything > outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and > sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. > There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some > code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is > definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd > like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. @stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on `java.base` when I have some free time. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From hannesw at openjdk.java.net Mon Sep 21 10:47:40 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Mon, 21 Sep 2020 10:47:40 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] 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 incrementally with three additional commits since the last revision: - 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/2aed84f8..6d659ae3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=00-01 Stats: 2007 lines in 9 files changed: 308 ins; 1698 del; 1 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 vromero at openjdk.java.net Mon Sep 21 21:39:18 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 21:39:18 GMT Subject: RFR: 8246774: Record Classes (final) implementation Message-ID: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@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 ------------- Commit messages: - 8246774: Record Classes (final) implementation Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8246774 Stats: 495 lines in 95 files changed: 23 ins; 362 del; 110 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 Mon Sep 21 21:39:18 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 21:39:18 GMT Subject: RFR: 8246774: Record Classes (final) implementation 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: > 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 Please review the fix for [1]. The intention of this patch is to make records final removing the need to use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code compiled from record classes, Thanks [1] https://bugs.openjdk.java.net/browse/JDK-8246774 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From darcy at openjdk.java.net Mon Sep 21 21:56:01 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Sep 2020 21:56:01 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:36:39 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 > > Please review the fix for [1]. The intention of this patch is to make records final removing the need to > use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code > compiled from record classes, Thanks > > [1] https://bugs.openjdk.java.net/browse/JDK-8246774 Hi Vicente, Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. Thanks, -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Mon Sep 21 23:24:57 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 23:24:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v2] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <_6qw2pA7HDrTWsZPIpQOAjSE14-9iULneDMN_o9ixNw=.0a72cfba-bb8c-454e-bfc7-44553f11bbe1@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: removing the javax.lang.model related code to be moved to a separate bug ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/9eedb3ab..543e5054 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=00-01 Stats: 134 lines in 12 files changed: 130 ins; 0 del; 4 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 Mon Sep 21 23:24:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 23:24:58 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:53:05 GMT, Joe Darcy wrote: >> Please review the fix for [1]. The intention of this patch is to make records final removing the need to >> use --enable-preview in order to be able to include a record declaration in a source or for the VM to execute code >> compiled from record classes, Thanks >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8246774 > > Hi Vicente, > Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. > Thanks, > -Joe note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Mon Sep 21 23:38:02 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 21 Sep 2020 23:38:02 GMT Subject: RFR: 8253455: Record Classes (final) javax.lang.model changes Message-ID: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@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 ------------- Commit messages: - 8253455: Record Classes (final) javax.lang.model changes Changes: https://git.openjdk.java.net/jdk/pull/291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253455 Stats: 134 lines in 12 files changed: 0 ins; 130 del; 4 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 chegar at openjdk.java.net Tue Sep 22 09:51:59 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 22 Sep 2020 09:51:59 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: >> Hi Vicente, >> Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. >> Thanks, >> -Joe > > note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See https://github.com/vicente-romero-oracle/jdk/pull/1 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From hannesw at openjdk.java.net Tue Sep 22 11:36:20 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 22 Sep 2020 11:36:20 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 17:25:15 GMT, Jonathan Gibbons wrote: >> doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the >> `-Xdoclint` family of options. >> When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the >> code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. >> This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to >> javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service >> binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: >> the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the >> service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to >> cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, >> this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on >> the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no >> longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its >> requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local >> enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller >> disturbance to the `JavadocFormatter` class. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge master > - Merge > - move doclint to jdk.javadoc module > - add DocTrees.getCharacters(EntityTree) Changes look good apart from minor issues addressed in extra comments. src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java line 1: > 1: package com.sun.tools.doclint; Why is there no copyright header in this file? src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java line 127: > 125: } > 126: > 127: enum HtmlTag { What was the criterion for choosing this subset of HtmlTag values? It seems the only ones actually used by this class are HTML, TABLE, TH, and LI. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1265: > 1263: > 1264: if (name != null) { > 1265: jdk.javadoc.internal.doclint.HtmlTag htmlTag = jdk.javadoc.internal.doclint.HtmlTag.get(name); Is there a reason not to import the HtmlTag class? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 2: > 1: /* > 2: * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. Copyright year should be updated ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From pravin at zensoftech.co.in Tue Sep 22 05:39:18 2020 From: pravin at zensoftech.co.in (Pravin Jain) Date: Tue, 22 Sep 2020 11:09:18 +0530 Subject: Identifier Ignorable characters in keywords and literals Message-ID: Hello, The following code compiles and executes successfully. public cl\u0001ass Identifier\u0002Ignorable { public sta\u0003tic vo\u0004id ma\u0005in(String[] args) { System.out.println("Hello world"); } } The JLS mentions about the use of Identifier-Ignorable characters being allowed in an Identifier, but using those in a keyword, or literal has not been mentioned. From the specification, one does not gather that these characters will be ignored when used inside a keyword or a literal. Is this error of compiler or the JLS has missed to clarify this point? Thanks and Regards, Pravin Jain +91-94260 54269 From jjg at openjdk.java.net Tue Sep 22 17:37:03 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 17:37:03 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Mon, 21 Sep 2020 10:47:40 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 > > Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: > > - 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. Generally excellent. Some feedback inline. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 350: > 348: > 349: doclet.usage.excludedocfilessubdir.parameters=\ > 350: :.. 3 dots for ellipsis? 2 dots is "parent directory" src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 384: > 382: > 383: doclet.usage.no-platform-link.description=\ > 384: Do not generate links to platform documentation Suggest: Do not generate links to the platform documentation src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 194: > 192: > 193: /** > 194: * Argument for command-line option {@code --no-platform-link}. minor: would "--no-platform-links" (plural) be a better name for the option? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 435: > 433: }, > 434: > 435: new Option(resources, "--no-platform-link") { Repeating preceding comment: would `--no-platform-links` (plural) be a better name? src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 236: > 234: * @param linkPlatformProperties path or URL to properties file containing > 235: * platform documentation URLs, or null > 236: * @param reporter The {@code DocErrorReporter} used to report errors. (pedantic) param descriptions are typically phrases (no initial capital, no trailing period) In this case, your two `@param` descriptions are inconsistent src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 323: > 321: props.load(inputStream); > 322: } > 323: url = props.getProperty("doclet.platform.docs." + version); Similar to other file-or-url arguments: good! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 340: > 338: private int getSourceVersionNumber() { > 339: SourceVersion sourceVersion = configuration.docEnv.getSourceVersion(); > 340: // TODO it would be nice if this was provided by SourceVersion File an RFE for `SourceVersion` test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java line 49: > 47: javadoc("-d", "out-1", > 48: "-sourcepath", testSrc, > 49: "--no-platform-link", I see lots of instances of `no-platform-link` in this and subsequent tests. `JavadocTester` does have the concept of default options, although that may be more for the behavior after executing javadoc and not for the options given to javadoc itself. Is it worth supporting default javadoc options, since that the default can be disabled for specific tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From jjg at openjdk.java.net Tue Sep 22 17:37:03 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 17:37:03 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 22 Sep 2020 17:24:19 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: >> >> - 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. > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 323: > >> 321: props.load(inputStream); >> 322: } >> 323: url = props.getProperty("doclet.platform.docs." + version); > > Similar to other file-or-url arguments: good! As a possibly-later cleanup, should we have a single utility method somewhere (in this class) to open a stream on a file-or-url? ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From alex.buckley at oracle.com Tue Sep 22 17:41:37 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Sep 2020 10:41:37 -0700 Subject: Identifier Ignorable characters in keywords and literals In-Reply-To: References: Message-ID: <087b829b-7568-6845-7d5c-64bf4d5fd064@oracle.com> // Adding Dan explicitly On 9/21/2020 10:39 PM, Pravin Jain wrote: > The following code compiles and executes successfully. > > public cl\u0001ass Identifier\u0002Ignorable { > public sta\u0003tic vo\u0004id ma\u0005in(String[] args) { > System.out.println("Hello world"); > } > } > > The JLS mentions about the use of Identifier-Ignorable characters > being allowed in an Identifier, but using those in a keyword, or > literal has not been mentioned. From the specification, one does not > gather that these characters will be ignored when used inside a > keyword or a literal.y Is this error of compiler or the JLS has missed > to clarify this point? It would be legitimate for JLS 3.3 to acknowledge that some `\uxxxx` Unicode escapes represent UTF-16 code units which denote "ignorable" code points; such UTF-16 code units are _not_ included in the sequence of Unicode input characters resulting from this translation step. Dan, is it possible to make this small clarification in the JLS ch.3 update for contextual keywords? The text in 3.8 -- "Two identifiers are the same only if, after ignoring characters that are ignorable, the identifiers have the same Unicode character for each letter or digit." -- would be slightly redundant in calling out ignorable characters, but it should not be changed because it states a clear, easy-to-understand rule for Java programmers looking to go beyond ASCII in their identifiers. Alex From gdub at openjdk.java.net Tue Sep 22 18:03:37 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Tue, 22 Sep 2020 18:03:37 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. Gilles Duboscq 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 six new commits since the last revision: - Move LambdaEagerInitTest to test/jdk/java/lang/invoke/lambda - Include capturing case test, use jdk.test.lib.Assert - Remove disableEagerInitialization concerns from BridgeMethod.java - Remove extra field test from LambdaTest6 - Wrap long lines - Add dedicated test in the jdk tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/93/files - new: https://git.openjdk.java.net/jdk/pull/93/files/625feb94..5525f217 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=93&range=02-03 Stats: 164 lines in 2 files changed: 91 ins; 73 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/93.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/93/head:pull/93 PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Tue Sep 22 18:20:22 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 18:20:22 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:03:37 GMT, Gilles Duboscq wrote: >> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the >> jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda >> classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the >> context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of >> non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas >> are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely >> _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and >> ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance >> behaviour of lambdas in either direction. > > Gilles Duboscq 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. Looks good. Thanks for the update. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/93 From gdub at openjdk.java.net Tue Sep 22 18:26:31 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Tue, 22 Sep 2020 18:26:31 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:17:49 GMT, Mandy Chung wrote: >> Gilles Duboscq 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 six new commits since >> the last revision: >> - Move LambdaEagerInitTest to test/jdk/java/lang/invoke/lambda >> - Include capturing case test, use jdk.test.lib.Assert >> - Remove disableEagerInitialization concerns from BridgeMethod.java >> - Remove extra field test from LambdaTest6 >> - Wrap long lines >> - Add dedicated test in the jdk tests > > Looks good. Thanks for the update. Thanks @mlchung. Do I need a second review? ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From mchung at openjdk.java.net Tue Sep 22 18:39:49 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 18:39:49 GMT Subject: RFR: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode [v4] In-Reply-To: References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Tue, 22 Sep 2020 18:24:02 GMT, Gilles Duboscq wrote: > Thanks @mlchung. Do I need a second review? No need. You can integrate once you run the regression tests (I usually run tier1-tier3). ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From jjg at openjdk.java.net Tue Sep 22 20:18:41 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 20:18:41 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 10:03:17 GMT, Hannes Walln?fer wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains four commits: >> - Merge master >> - Merge >> - move doclint to jdk.javadoc module >> - add DocTrees.getCharacters(EntityTree) > > src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java line 127: > >> 125: } >> 126: >> 127: enum HtmlTag { > > What was the criterion for choosing this subset of HtmlTag values? It seems the only ones actually used by this class > are HTML, TABLE, TH, and LI. See the `startElement` method, starting at about line269. The intent is that this enum is minimal, just for the needs of this class. ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From jjg at openjdk.java.net Tue Sep 22 20:34:15 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Sep 2020 20:34:15 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:28:04 GMT, Hannes Walln?fer wrote: >> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains four commits: >> - Merge master >> - Merge >> - move doclint to jdk.javadoc module >> - add DocTrees.getCharacters(EntityTree) > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1265: > >> 1263: >> 1264: if (name != null) { >> 1265: jdk.javadoc.internal.doclint.HtmlTag htmlTag = jdk.javadoc.internal.doclint.HtmlTag.get(name); > > Is there a reason not to import the HtmlTag class? There is (have always been) two different versions of `HtmlTag`, albeit for different purposes, and up to now, in different modules. The one in `doclint` is more for input, the one in `doclets/formats/html/markup` is more focussed on output. Use sites like this are where the two domains meet and so both need to be in scope. Hence at least one needs to be fully-qualified and not imported. IIRC, the policy is that the `doclets/formats/html/markup` version is more widely used throughout the standard docket and gets to be important, leaving the `doclint` one to be fully-qualified. At least now they both in the same module, which increases the chance of reducing them to one copy, perhaps by replacing some of the enum-member methods with separate switch-based utility methods that locally provide the requisite functionality. That being said, I still don't see a good way to merge them, meaning, I don't see a good place to put a merged copy. One possibility I have been thinking about is moving the HTML-only parts of `doclets/formats/html/markup` to a separate sharable package such as `jdk.javadoc.internal.html` where it could be used by both doclint and the standard docket. IIRC, the one outlier in `formats.html.markup` is the `Links` class, which I would migrate up to `doclets.formats.html` (i.e. out of the `markup` subpackage.) Separate but somewhat related, the `formats/html/markup` classes have been a good pattern for other tools that generate HTML, such as doccheck and similar reporting tools. > src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java line 1: > >> 1: package com.sun.tools.doclint; > > Why is there no copyright header in this file? Oops, will fix! > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 2: > >> 1: /* >> 2: * Copyright (c) 2012, 2019, Oracle and/or its affiliates. All rights reserved. > > Copyright year should be updated I'll try and get into a new habit of updating copyrights earlier. Personally, I think these updates are unnecessary noise in a review, and I would usually update files after the review but before pushing the changes. I guess that is not so easy anymore, since I don't want to affect "Reviewed" status by committing copyright year changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From pravin at zensoftech.co.in Tue Sep 22 23:07:27 2020 From: pravin at zensoftech.co.in (Pravin Jain) Date: Wed, 23 Sep 2020 04:37:27 +0530 Subject: Identifier Ignorable characters in keywords and literals In-Reply-To: <087b829b-7568-6845-7d5c-64bf4d5fd064@oracle.com> References: <087b829b-7568-6845-7d5c-64bf4d5fd064@oracle.com> Message-ID: Thanks for the clarifications. But let me point out that the Identifier Ignorable characters are ignored not only in keywords but also in the three literals "true", "false" and "null" Thanks and Regards, Pravin On Tue, Sep 22, 2020 at 11:11 PM Alex Buckley wrote: > > // Adding Dan explicitly > > On 9/21/2020 10:39 PM, Pravin Jain wrote: > > The following code compiles and executes successfully. > > > > public cl\u0001ass Identifier\u0002Ignorable { > > public sta\u0003tic vo\u0004id ma\u0005in(String[] args) { > > System.out.println("Hello world"); > > } > > } > > > > The JLS mentions about the use of Identifier-Ignorable characters > > being allowed in an Identifier, but using those in a keyword, or > > literal has not been mentioned. From the specification, one does not > > gather that these characters will be ignored when used inside a > > keyword or a literal.y Is this error of compiler or the JLS has missed > > to clarify this point? > > It would be legitimate for JLS 3.3 to acknowledge that some `\uxxxx` > Unicode escapes represent UTF-16 code units which denote "ignorable" > code points; such UTF-16 code units are _not_ included in the sequence > of Unicode input characters resulting from this translation step. > > Dan, is it possible to make this small clarification in the JLS ch.3 > update for contextual keywords? > > The text in 3.8 -- "Two identifiers are the same only if, after ignoring > characters that are ignorable, the identifiers have the same Unicode > character for each letter or digit." -- would be slightly redundant in > calling out ignorable characters, but it should not be changed because > it states a clear, easy-to-understand rule for Java programmers looking > to go beyond ASCII in their identifiers. > > Alex -- Pravin Jain (M)+91-9426054269 From jjg at openjdk.java.net Wed Sep 23 00:09:54 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 00:09:54 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v3] In-Reply-To: References: Message-ID: > doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the > `-Xdoclint` family of options. > When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the > code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. > This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to > javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service > binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: > the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the > service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to > cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, > this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on > the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no > longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its > requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local > enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller > disturbance to the `JavadocFormatter` class. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Address comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/133/files - new: https://git.openjdk.java.net/jdk/pull/133/files/f1dd503f..512b6ba2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=01-02 Stats: 26 lines in 2 files changed: 25 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk/pull/133 From alex.buckley at oracle.com Wed Sep 23 00:10:11 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Sep 2020 17:10:11 -0700 Subject: Identifier Ignorable characters in keywords and literals In-Reply-To: References: <087b829b-7568-6845-7d5c-64bf4d5fd064@oracle.com> Message-ID: An ignorable Unicode escape such as `\u0001` is a legitimate character in a character literal, string literal, or text block, so javac accepts and translates it there. In contrast, it seems that javac accepts _and discards_ an ignorable Unicode escape: 1. in the body of a comment; 2. as a Java-letter-or-digit in an identifier (i.e., not as the first character of an identifier, but as any subsequent character); 3. in a position to the right of a non-ignorable character within a keyword (thus allowing for appearance at the end of a keyword, and for consecutive ignorable escapes: `class\u0001\u0001`); 4. in a position to the right of a non-ignorable character within a boolean literal or null literal. 1 and 2 are to spec. 3 and 4 are new to the spec. There seems to be a connection between 2 and 3+4: javac is expecting keywords to follow the same Java-letter-followed-by-Java-letters-or-digits format as identifiers. Alex On 9/22/2020 4:07 PM, Pravin Jain wrote: > Thanks for the clarifications. > But let me point out that the Identifier Ignorable characters are > ignored not only in keywords but also in the three literals "true", > "false" and "null" > > Thanks and Regards, > Pravin > > On Tue, Sep 22, 2020 at 11:11 PM Alex Buckley wrote: >> >> // Adding Dan explicitly >> >> On 9/21/2020 10:39 PM, Pravin Jain wrote: >>> The following code compiles and executes successfully. >>> >>> public cl\u0001ass Identifier\u0002Ignorable { >>> public sta\u0003tic vo\u0004id ma\u0005in(String[] args) { >>> System.out.println("Hello world"); >>> } >>> } >>> >>> The JLS mentions about the use of Identifier-Ignorable characters >>> being allowed in an Identifier, but using those in a keyword, or >>> literal has not been mentioned. From the specification, one does not >>> gather that these characters will be ignored when used inside a >>> keyword or a literal.y Is this error of compiler or the JLS has missed >>> to clarify this point? >> >> It would be legitimate for JLS 3.3 to acknowledge that some `\uxxxx` >> Unicode escapes represent UTF-16 code units which denote "ignorable" >> code points; such UTF-16 code units are _not_ included in the sequence >> of Unicode input characters resulting from this translation step. >> >> Dan, is it possible to make this small clarification in the JLS ch.3 >> update for contextual keywords? >> >> The text in 3.8 -- "Two identifiers are the same only if, after ignoring >> characters that are ignorable, the identifiers have the same Unicode >> character for each letter or digit." -- would be slightly redundant in >> calling out ignorable characters, but it should not be changed because >> it states a clear, easy-to-understand rule for Java programmers looking >> to go beyond ASCII in their identifiers. >> >> Alex > > > From darcy at openjdk.java.net Wed Sep 23 02:35:23 2020 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Sep 2020 02:35:23 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> References: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> Message-ID: <-47nRGIapv-HMACTNXfIZ5ec414XoC0zkUH6KxQDtg8=.f3b75456-976d-4e6b-9c41-8945021941b3@github.com> On Thu, 17 Sep 2020 17:59:00 GMT, Jan Lahoda wrote: >> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements >> across all modules in the module graph, and only return a value when they find exactly one element. This is >> troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from >> any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that >> these unqualified methods would first look for elements visible from the root modules, and would search the internals >> of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: >> https://bugs.openjdk.java.net/browse/JDK-8253168. > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 62: > 60: *
  • find non-empty packages with the given name returned by > 61: * {@link #getPackageElement(ModuleElement, CharSequence)}, > 62: * where the provided ModuleSymbol is any root module, Does "root module" mean one of the modules in the result of Elements.getAllModuleElements? If so, I suggest making "root module" a link to the method. ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From vicente.romero at oracle.com Wed Sep 23 03:30:13 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Tue, 22 Sep 2020 23:30:13 -0400 Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: good catch Chris, thanks for the patch, Vicente On 9/22/20 5:51 AM, Chris Hegarty wrote: > On Mon, 21 Sep 2020 23:21:18 GMT, Vicente Romero wrote: > >>> Hi Vicente, >>> Please file a separate subtask for the javax.lang.model changes. This helps with the JSR 269 MR paperwork. >>> Thanks, >>> -Joe >> note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR > @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and > ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See > https://github.com/vicente-romero-oracle/jdk/pull/1 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 23 03:34:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 23 Sep 2020 03:34:29 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 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 three additional commits since the last revision: - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/543e5054..26b80775 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=01-02 Stats: 95 lines in 21 files changed: 0 ins; 35 del; 60 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 hannesw at openjdk.java.net Wed Sep 23 10:43:32 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 10:43:32 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 00:09:54 GMT, Jonathan Gibbons wrote: >> doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the >> `-Xdoclint` family of options. >> When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the >> code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. >> This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to >> javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service >> binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: >> the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the >> service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to >> cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, >> this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on >> the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no >> longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its >> requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local >> enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller >> disturbance to the `JavadocFormatter` class. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address comments Marked as reviewed by hannesw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From hannesw at openjdk.java.net Wed Sep 23 10:43:33 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 10:43:33 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 20:28:49 GMT, Jonathan Gibbons wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1265: >> >>> 1263: >>> 1264: if (name != null) { >>> 1265: jdk.javadoc.internal.doclint.HtmlTag htmlTag = jdk.javadoc.internal.doclint.HtmlTag.get(name); >> >> Is there a reason not to import the HtmlTag class? > > There is (have always been) two different versions of `HtmlTag`, albeit for different purposes, and up to now, in > different modules. The one in `doclint` is more for input, the one in `doclets/formats/html/markup` is more focussed on > output. Use sites like this are where the two domains meet and so both need to be in scope. Hence at least one needs to > be fully-qualified and not imported. IIRC, the policy is that the `doclets/formats/html/markup` version is more widely > used throughout the standard docket and gets to be important, leaving the `doclint` one to be fully-qualified. At > least now they both in the same module, which increases the chance of reducing them to one copy, perhaps by replacing > some of the enum-member methods with separate switch-based utility methods that locally provide the requisite > functionality. That being said, I still don't see a good way to merge them, meaning, I don't see a good place to put a > merged copy. One possibility I have been thinking about is moving the HTML-only parts of `doclets/formats/html/markup` > to a separate sharable package such as `jdk.javadoc.internal.html` where it could be used by both doclint and the > standard docket. IIRC, the one outlier in `formats.html.markup` is the `Links` class, which I would migrate up to > `doclets.formats.html` (i.e. out of the `markup` subpackage.) Separate but somewhat related, the `formats/html/markup` > classes have been a good pattern for other tools that generate HTML, such as doccheck and similar reporting tools. The HtmlTag in `doclets/formats/html/markup` seems to have gone. Maybe it has been renamed? >> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java line 127: >> >>> 125: } >>> 126: >>> 127: enum HtmlTag { >> >> What was the criterion for choosing this subset of HtmlTag values? It seems the only ones actually used by this class >> are HTML, TABLE, TH, and LI. > > See the `startElement` method, starting at about line 269. > The intent is that this enum is minimal, just for the needs of this class. Oops, not sure how I missed that. ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From hannesw at openjdk.java.net Wed Sep 23 11:06:50 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 11:06:50 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v2] In-Reply-To: References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: On Tue, 22 Sep 2020 17:30:19 GMT, Jonathan Gibbons wrote: >> Hannes Walln?fer has updated the pull request incrementally with three additional commits since the last revision: >> >> - 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. > > test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java line 49: > >> 47: javadoc("-d", "out-1", >> 48: "-sourcepath", testSrc, >> 49: "--no-platform-link", > > I see lots of instances of `no-platform-link` in this and subsequent tests. `JavadocTester` does have the concept of > default options, although that may be more for the behavior after executing javadoc and not for the options given to > javadoc itself. Is it worth supporting default javadoc options, since that the default can be disabled for specific > tests? I can't really find how `JavadocTester` uses or supports default options. My concern with this would be that it would make JavadocTester less transparent and intuitive to use, as you'd have to be aware what the default options are. ------------- PR: https://git.openjdk.java.net/jdk/pull/171 From jlahoda at openjdk.java.net Wed Sep 23 11:38:33 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 23 Sep 2020 11:38:33 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v3] In-Reply-To: References: Message-ID: > Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements > across all modules in the module graph, and only return a value when they find exactly one element. This is > troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from > any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that > these unqualified methods would first look for elements visible from the root modules, and would search the internals > of other modules only if nothing would be found in the first round. The draft of the corresponding CSR is here: > https://bugs.openjdk.java.net/browse/JDK-8253168. 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 four additional commits since the last revision: - Linking to root and all modules definition. - Merge branch 'master' into JDK-8236842 - Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/200/files - new: https://git.openjdk.java.net/jdk/pull/200/files/3eb2c0bd..33ca56ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=200&range=01-02 Stats: 12332 lines in 424 files changed: 6792 ins; 4409 del; 1131 mod Patch: https://git.openjdk.java.net/jdk/pull/200.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200 PR: https://git.openjdk.java.net/jdk/pull/200 From jlahoda at openjdk.java.net Wed Sep 23 11:45:04 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 23 Sep 2020 11:45:04 GMT Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release [v2] In-Reply-To: <-47nRGIapv-HMACTNXfIZ5ec414XoC0zkUH6KxQDtg8=.f3b75456-976d-4e6b-9c41-8945021941b3@github.com> References: <3GADCQt6iTp29t9XUAsAge_5ePwsI6W0lI_Vc2abfQo=.68369e62-fb3a-481c-a586-6ec1bdfb6b98@github.com> <-47nRGIapv-HMACTNXfIZ5ec414XoC0zkUH6KxQDtg8=.f3b75456-976d-4e6b-9c41-8945021941b3@github.com> Message-ID: On Wed, 23 Sep 2020 02:32:46 GMT, Joe Darcy wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched. > > src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 62: > >> 60: *
  • find non-empty packages with the given name returned by >> 61: * {@link #getPackageElement(ModuleElement, CharSequence)}, >> 62: * where the provided ModuleSymbol is any root module, > > Does "root module" mean one of the modules in the result of Elements.getAllModuleElements? If so, I suggest making > "root module" a link to the method. Root module is meant in the java.lang.module sense, i.e. the set of modules that are being compiled. In a new revision, I added a link to the appropriate package javadoc in java.lang.module; and a link to getAllModules for "all modules" in the next point. Does this make sense? I've generated the javadoc for convenience here: http://cr.openjdk.java.net/~jlahoda/8236842/docsv2/api/java.compiler/javax/lang/model/util/Elements.html#getTypeElement(java.lang.CharSequence) http://cr.openjdk.java.net/~jlahoda/8236842/docsv2/api/java.compiler/javax/lang/model/util/Elements.html#getPackageElement(java.lang.CharSequence) ------------- PR: https://git.openjdk.java.net/jdk/pull/200 From hannesw at openjdk.java.net Wed Sep 23 14:20:12 2020 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 23 Sep 2020 14:20:12 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v3] In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> Message-ID: <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> > 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 incrementally with one additional commit since the last revision: Rename --no-platform-link option plus minor cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/171/files - new: https://git.openjdk.java.net/jdk/pull/171/files/6d659ae3..6009dd70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=171&range=01-02 Stats: 73 lines in 38 files changed: 0 ins; 0 del; 73 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 weijun at openjdk.java.net Wed Sep 23 14:49:26 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Sep 2020 14:49:26 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA 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 ------------- Commit messages: - 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=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242068 Stats: 1641 lines in 20 files changed: 930 ins; 548 del; 163 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 jjg at openjdk.java.net Wed Sep 23 17:57:04 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 17:57:04 GMT Subject: RFR: 8216497: javadoc should auto-link to platform classes [v3] In-Reply-To: <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com> <1KT8mUPZcjXK-MHKDlrStvUvwJFt36fi4zq_HFwZQQc=.676ec735-6d55-4440-b040-8cdbe3fc0d4d@github.com> Message-ID: On Wed, 23 Sep 2020 14:20:12 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 > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Rename --no-platform-link option plus minor cleanup I agree with the judgement call to _not_ introduce default javadoc options. It was just a suggestion to consider, and I agree it would make the calls less intuitively obvious, for the short term gain of editing fewer tests here. It also helped to realize that the support default platform links does _not_ involve any network access. FWIW, the precedent in JavadocTester that I was referrng to is `setAutomaticCheckLinks`, `setAutomaticCheckAccessibility`, but those are about default actions after javadoc has been run, and not about default methods. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/171 From jjg at openjdk.java.net Wed Sep 23 18:04:43 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 18:04:43 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v2] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 10:39:46 GMT, Hannes Walln?fer wrote: >> There is (have always been) two different versions of `HtmlTag`, albeit for different purposes, and up to now, in >> different modules. The one in `doclint` is more for input, the one in `doclets/formats/html/markup` is more focussed on >> output. Use sites like this are where the two domains meet and so both need to be in scope. Hence at least one needs to >> be fully-qualified and not imported. IIRC, the policy is that the `doclets/formats/html/markup` version is more widely >> used throughout the standard docket and gets to be important, leaving the `doclint` one to be fully-qualified. At >> least now they both in the same module, which increases the chance of reducing them to one copy, perhaps by replacing >> some of the enum-member methods with separate switch-based utility methods that locally provide the requisite >> functionality. That being said, I still don't see a good way to merge them, meaning, I don't see a good place to put a >> merged copy. One possibility I have been thinking about is moving the HTML-only parts of `doclets/formats/html/markup` >> to a separate sharable package such as `jdk.javadoc.internal.html` where it could be used by both doclint and the >> standard docket. IIRC, the one outlier in `formats.html.markup` is the `Links` class, which I would migrate up to >> `doclets.formats.html` (i.e. out of the `markup` subpackage.) Separate but somewhat related, the `formats/html/markup` >> classes have been a good pattern for other tools that generate HTML, such as doccheck and similar reporting tools. > > The HtmlTag in `doclets/formats/html/markup` seems to have gone. Maybe it has been renamed? Ooops: good catch. In `formats/html/markup` it got renamed a while back to `TagName`, which is some of the cleanup I was describing above (moving methods out of the enum). We could do the same thing in doclint, but for now, I'll just fix the fully-qualified name with an import. doclint cleanup is a separate exercise: e.g. when we remove HTML4 support. ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From jjg at openjdk.java.net Wed Sep 23 18:32:38 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 18:32:38 GMT Subject: RFR: JDK-8252712: move doclint to jdk.javadoc module [v4] In-Reply-To: References: Message-ID: > doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the > `-Xdoclint` family of options. > When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the > code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. > This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to > javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service > binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: > the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the > service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to > cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, > this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on > the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no > longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its > requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local > enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller > disturbance to the `JavadocFormatter` class. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: fix use of fully-qualified name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/133/files - new: https://git.openjdk.java.net/jdk/pull/133/files/512b6ba2..34894848 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=133&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/133.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/133/head:pull/133 PR: https://git.openjdk.java.net/jdk/pull/133 From jjg at openjdk.java.net Wed Sep 23 19:58:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 23 Sep 2020 19:58:29 GMT Subject: Integrated: JDK-8252712: move doclint to jdk.javadoc module In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 17:11:51 GMT, Jonathan Gibbons wrote: > doclint is a component that can check documentation comments, that can be invoked from either javac or javadoc, via the > `-Xdoclint` family of options. > When JDK was modularized in JDK9, doclint was left in the `jdk.compiler` module because of direct references to the > code from javac, even though functionally the code more naturally belongs in the `jdk.javadoc` module. > This change moves the code into the `jdk.javadoc`, using a service/provider API to make the functionality available to > javac. This should be completely transparent, as long as the `jdk.javadoc` module is available when performing service > binding. If it is not available, a default no-op implementation is automatically used instead. One minor complication: > the old code used static methods on the `DocLint` class to validate options. This is no longer possible when using the > service provider mechanism. Instead, the methods are changed to instance methods. The javac `Option` enum has no way to > cleanly cache an instance of the service provider class, and so a new instance is created for each option. However, > this is a relatively lightweight operation, and can reasonably be done for the typically few doclint-related options on > the command line. Note: JShell has been making minor use of an internal doclint class enum `HtmlTag`, which is no > longer easily available. A minimal local enum is left behind in JShell's `JavadocFomatter` class, sufficient to its > requirements. Since the dominant use of the enum is in `switch` statements, an alternative solution, avoiding the local > enum, would be to use strings and _switch on string_ instead. However, the use of the local enum is a smaller > disturbance to the `JavadocFormatter` class. This pull request has now been integrated. Changeset: f765a7f5 Author: Jonathan Gibbons URL: https://git.openjdk.java.net/jdk/commit/f765a7f5 Stats: 580 lines in 104 files changed: 47 ins; 384 del; 149 mod 8252712: move doclint to jdk.javadoc module Reviewed-by: hannesw ------------- PR: https://git.openjdk.java.net/jdk/pull/133 From mchung at openjdk.java.net Thu Sep 24 00:26:11 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 00:26:11 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 22 Sep 2020 09:49:12 GMT, Chris Hegarty wrote: >> note: I have removed from the original patch the code related to javax.lang.model, I will publish them in a separate PR > > @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and > ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See > https://github.com/vicente-romero-oracle/jdk/pull/1 What is the policy of `@since` release value when a preview API becomes final. I would expect `@since` should be updated from 14 to 16 because 16 is the Java SE release these APIs are added?? ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From alex.buckley at oracle.com Thu Sep 24 00:40:11 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 23 Sep 2020 17:40:11 -0700 Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <495cc1e9-41ad-3f9a-c91d-93b0d0d6c3f9@oracle.com> On 9/23/2020 5:26 PM, Mandy Chung wrote: > What is the policy of `@since` release value when a preview API > becomes final. I would expect `@since` should be updated from 14 > to 16 because 16 is the Java SE release these APIs are added?? Yes. Per http://openjdk.java.net/jeps/12#Specifications-of-Preview-Features : In particular, all elements of a preview API must have the following tags: ... An @since tag that indicates the release when [the API element] was first added. *If the API element is eventually made final and permanent in Java SE $N, then the @since tag must be changed to indicate the $N release (the element's history prior to $N is not of long-term interest).* Alex From mchung at openjdk.java.net Thu Sep 24 00:55:22 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 00:55:22 GMT Subject: RFR: 8246774: Record Classes (final) implementation In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Thu, 24 Sep 2020 00:23:13 GMT, Mandy Chung wrote: >> @vicente-romero-oracle I noticed that we can also remove the preview args from the record serialization tests and >> ObjectMethodsTest. I opened a PR against the branch in your fork. You should be able to just merge in the changes. See >> https://github.com/vicente-romero-oracle/jdk/pull/1 > > What is the policy of `@since` release value when a preview API becomes final. I would expect `@since` should be > updated from 14 to 16 because 16 is the Java SE release these APIs are added?? Thanks Alex. @vicente-romero-oracle `@since` needs to be changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From bsrbnd at gmail.com Thu Sep 24 09:34:42 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 24 Sep 2020 11:34:42 +0200 Subject: [records] Is serialVersionUID warning for records redundant? Message-ID: [CC to compiler-dev] Hi, I'd like to suggest the following straightforward fix to suppress the serial lint warning for records (based on jdk14u), any feedback is welcome! Then, if you need it quickly, feel free to push it on my behalf at the right place since I'm currently not up-to-date with the new git work-flow (or maybe add it to JDK-8246774 [1]). Thanks, Bernard [1] https://git.openjdk.java.net/jdk/pull/290.diff diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java @@ -5220,8 +5220,8 @@ } if (svuid == null) { - log.warning(LintCategory.SERIAL, - tree.pos(), Warnings.MissingSVUID(c)); + if (!c.isRecord()) + log.warning(LintCategory.SERIAL, tree.pos(), Warnings.MissingSVUID(c)); return; } > From: chris.hegarty at oracle.com (Chris Hegarty) > Date: Tue, 4 Aug 2020 08:48:36 +0100 > >> On 3 Aug 2020, at 08:30, Tagir Valeev wrote: >> >> Hello! >> >> I believe, explicit specification of serialVersionUID in records >> rarely makes sense and should be discouraged. Still javac issues a >> lint warning if it's absent: > > Yeah, this is a bug. We already have an issue in JIRA tracking this: > > 8241151: "Incorrect lint warning for no definition of serialVersionUID in a record? [1] > > -Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8241151 From jlahoda at openjdk.java.net Thu Sep 24 10:42:42 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Thu, 24 Sep 2020 10:42:42 GMT Subject: RFR: 8253584: Redunant errors for partial member selects Message-ID: For code like: package t; class Test { void t() { if (true) { s(). } else { } } String s() { return null; } } (note the missing member name after `s().`), javac will produce a number of compile-time errors: $ javac /tmp/Test.java s(). ^ s(). ^ } else { ^ } else { ^ String s() { ^ } ^ 6 errors The reason is that after not seeing an identifier after the `.` javac will skip the token that follows the dot. This was done to improve errors in https://bugs.openjdk.java.net/browse/JDK-8081769 . But here, reading the next token will skip the closing `}`, and the parser will de-synchronize with the braces, leading to the follow-up errors. The proposal here is to handle incorrect `.class` specially, and avoid reading the next token when an identifier is no specified in a member select, except when the next token is `class`. The errors with this patch are: $ javac /tmp/Test.java s(). ^ s(). ^ 2 errors This seems much better. ------------- Commit messages: - 8253584: Redunant errors for partial member selects Changes: https://git.openjdk.java.net/jdk/pull/333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253584 Stats: 51 lines in 2 files changed: 48 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/333/head:pull/333 PR: https://git.openjdk.java.net/jdk/pull/333 From coleenp at openjdk.java.net Thu Sep 24 12:27:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:27:14 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 23 Sep 2020 03:34:29 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 three additional commits since the last revision: > > - Merge pull request #1 from ChrisHegarty/record-serial-tests > > Remove preview args from JDK tests > - Remove preview args from ObjectMethodsTest > - Remove preview args from record serialization tests The classfile parser changes look good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Sep 24 15:49:52 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:49:52 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v4] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 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: modifiying @since from 14 to 16 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/26b80775..514b0a80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=02-03 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 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 Sep 24 15:49:52 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:49:52 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> On Thu, 24 Sep 2020 12:23:13 GMT, Coleen Phillimore wrote: >> Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from ChrisHegarty/record-serial-tests >> >> Remove preview args from JDK tests >> - Remove preview args from ObjectMethodsTest >> - Remove preview args from record serialization tests > > The classfile parser changes look good to me. I have modified the `@since`: 14 -> 16 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Sep 24 15:54:57 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 24 Sep 2020 15:54:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v5] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <1mJrr-6f-CRtIrhQqH7VlpzuNZdR0dzdDiLnacBx32I=.a0823203-fc37-4fc7-a104-6031c580fd21@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 with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8246774 - modifiying @since from 14 to 16 - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - 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=04 Stats: 464 lines in 104 files changed: 23 ins; 267 del; 174 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 Fri Sep 25 00:41:47 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 00:41:47 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v6] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 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: adding missing changes to some tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/89f7cc54..915b67e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=04-05 Stats: 71 lines in 5 files changed: 9 ins; 11 del; 51 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 Fri Sep 25 02:40:47 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 02:40:47 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Thu, 24 Sep 2020 15:45:22 GMT, Vicente Romero wrote: >> The classfile parser changes look good to me. > > I have modified the `@since`: 14 -> 16 [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vicente.romero at oracle.com Fri Sep 25 02:45:44 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 24 Sep 2020 22:45:44 -0400 Subject: RFR: JDK-8246774: Record Classes (final) implementation Message-ID: Hi, Please review the PR at [1] which is the fix for [2] to make Records Classes a final feature in Java, Thanks, Vicente [1] https://github.com/openjdk/jdk/pull/290 [2] https://bugs.openjdk.java.net/browse/JDK-8246774 From gdub at openjdk.java.net Fri Sep 25 10:13:23 2020 From: gdub at openjdk.java.net (Gilles Duboscq) Date: Fri, 25 Sep 2020 10:13:23 GMT Subject: Integrated: 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode In-Reply-To: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> References: <5y5FB4GGYWpMVxx5L_eysMLAFKvTc8JKhGA8BAjJSqs=.b99cd031-9b5c-4fff-be6a-4765b16358da@github.com> Message-ID: On Wed, 9 Sep 2020 08:18:11 GMT, Gilles Duboscq wrote: > [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the > jdk.internal.lambda.disableEagerInitialization system property to be able to disable eager initialization of lambda > classes. This was necessary to prevent side effects of class initializers triggered by such initialization in the > context of the GraalVM native image tool. However, the change as it is implemented means that the behaviour of > non-capturing lambdas depends on the value of `disableEagerInitialization`: when it is false (the default) such lambdas > are actually a singleton while when it is true, a fresh instance is returned every time. Programs should definitely > _not_ rely on reference equality since the Java spec does not guarantee it. However, in order to separate concern and > ease debugging such bad programs, `disableEagerInitialization` shouldn't influence the singleton vs. fresh instance > behaviour of lambdas in either direction. This pull request has now been integrated. Changeset: 1b79326c Author: Gilles Duboscq URL: https://git.openjdk.java.net/jdk/commit/1b79326c Stats: 194 lines in 4 files changed: 137 ins; 29 del; 28 mod 8242451: ensure semantics of non-capturing lambdas are preserved independent of execution mode Reviewed-by: mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/93 From vromero at openjdk.java.net Fri Sep 25 14:07:33 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 14:07:33 GMT Subject: RFR: 8253584: Redunant errors for partial member selects In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:33:55 GMT, Jan Lahoda wrote: > For code like: > package t; > > class Test { > > void t() { > if (true) { > s(). > } else { > } > } > > String s() { > return null; > } > } > > (note the missing member name after `s().`), javac will produce a number of compile-time errors: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > > } else { > ^ > > } else { > ^ > > String s() { > ^ > > } > ^ > 6 errors > > The reason is that after not seeing an identifier after the `.` javac will skip the token that follows the dot. This > was done to improve errors in https://bugs.openjdk.java.net/browse/JDK-8081769 . But here, reading the next token will > skip the closing `}`, and the parser will de-synchronize with the braces, leading to the follow-up errors. The > proposal here is to handle incorrect `.class` specially, and avoid reading the next token when an identifier is no > specified in a member select, except when the next token is `class`. The errors with this patch are: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > 2 errors > > This seems much better. looks good to me ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/333 From vicente.romero at oracle.com Fri Sep 25 14:55:38 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 25 Sep 2020 10:55:38 -0400 Subject: [records] Is serialVersionUID warning for records redundant? In-Reply-To: References: Message-ID: <65a0897f-d639-ac95-7429-f576778a6cc0@oracle.com> Hi Bernard, Thanks for the patch I will start a review in git, Vicente On 9/24/20 5:34 AM, B. Blaser wrote: > [CC to compiler-dev] > > Hi, > > I'd like to suggest the following straightforward fix to suppress the > serial lint warning for records (based on jdk14u), any feedback is > welcome! Then, if you need it quickly, feel free to push it on my > behalf at the right place since I'm currently not up-to-date with the > new git work-flow (or maybe add it to JDK-8246774 [1]). > > Thanks, > Bernard > > [1] https://git.openjdk.java.net/jdk/pull/290.diff > > diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java > @@ -5220,8 +5220,8 @@ > } > > if (svuid == null) { > - log.warning(LintCategory.SERIAL, > - tree.pos(), Warnings.MissingSVUID(c)); > + if (!c.isRecord()) > + log.warning(LintCategory.SERIAL, tree.pos(), > Warnings.MissingSVUID(c)); > return; > } > >> From: chris.hegarty at oracle.com (Chris Hegarty) >> Date: Tue, 4 Aug 2020 08:48:36 +0100 >> >>> On 3 Aug 2020, at 08:30, Tagir Valeev wrote: >>> >>> Hello! >>> >>> I believe, explicit specification of serialVersionUID in records >>> rarely makes sense and should be discouraged. Still javac issues a >>> lint warning if it's absent: >> Yeah, this is a bug. We already have an issue in JIRA tracking this: >> >> 8241151: "Incorrect lint warning for no definition of serialVersionUID in a record? [1] >> >> -Chris >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8241151 From plevart at openjdk.java.net Fri Sep 25 15:50:48 2020 From: plevart at openjdk.java.net (Peter Levart) Date: Fri, 25 Sep 2020 15:50:48 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Fri, 25 Sep 2020 02:38:01 GMT, Vicente Romero wrote: >> I have modified the `@since`: 14 -> 16 > > [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) Hi @vicente-romero-oracle , note that besides tests, there is also a JMH benchmark that measures the performance of records deserialization which forced us to modify the build procedure for all benchmarks to include --enable-preview option in JDK 15 and backports (see https://bugs.openjdk.java.net/browse/JDK-8248135). If you undo this change in JDK 16 then also the problem described in https://bugs.openjdk.java.net/browse/JDK-8250669 and https://bugs.openjdk.java.net/browse/JDK-8248429 will disapear. After that, perhaps undoing the same for JDK 15 and backports together with removing the benchmark is also possible to resolve the issues in older releases as most developement will probably happen in JDK 16 then and so the need for performance testing will mostly be needed in there. We still have to figure out how to enable having benchmarks for preview features as in the future the sure will be a need for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Fri Sep 25 18:14:24 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 25 Sep 2020 18:14:24 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record Message-ID: Co-authored-by: Bernard Blaser Co-authored-by: Vicente Romero ------------- Commit messages: - 8241151: Incorrect lint warning for no definition of serialVersionUID in a record Changes: https://git.openjdk.java.net/jdk/pull/363/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=363&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241151 Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/363.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/363/head:pull/363 PR: https://git.openjdk.java.net/jdk/pull/363 From bsrbnd at gmail.com Sat Sep 26 13:16:46 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 26 Sep 2020 15:16:46 +0200 Subject: [records] Is serialVersionUID warning for records redundant? In-Reply-To: <65a0897f-d639-ac95-7429-f576778a6cc0@oracle.com> References: <65a0897f-d639-ac95-7429-f576778a6cc0@oracle.com> Message-ID: Thanks Vicente, the pull request [1] looks good to me! Ciao, Bernard [1] https://git.openjdk.java.net/jdk/pull/363 On Fri, 25 Sep 2020 at 16:56, Vicente Romero wrote: > > Hi Bernard, > > Thanks for the patch I will start a review in git, > > Vicente From jjg at openjdk.java.net Mon Sep 28 19:54:24 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 28 Sep 2020 19:54:24 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record In-Reply-To: References: Message-ID: <9CJLvVkIvDfQKcfxZaYjSYu4QdhGfE1BA27kepo3XoE=.f26f3f59-7b14-4eaa-b275-1427903ac1f9@github.com> On Fri, 25 Sep 2020 17:45:10 GMT, Vicente Romero wrote: > Co-authored-by: Bernard Blaser > Co-authored-by: Vicente Romero You should add a bug number to the test. test/langtools/tools/javac/records/RecordCompilationTests.java line 151: > 149: > 150: public RecordCompilationTests() { > 151: useAP = System.getProperty("useAP") == null ? false : System.getProperty("useAP").equals("true"); I know this is unrelated to your change, but this line could be improved with useAP = System.getProperty("useAP", "false").equals("true") ------------- Changes requested by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/363 From vromero at openjdk.java.net Mon Sep 28 21:00:08 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 28 Sep 2020 21:00:08 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: References: Message-ID: > Co-authored-by: Bernard Blaser > Co-authored-by: Vicente Romero Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: adding bug number to test and updating code as per review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/363/files - new: https://git.openjdk.java.net/jdk/pull/363/files/7b762449..4479315d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=363&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=363&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/363.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/363/head:pull/363 PR: https://git.openjdk.java.net/jdk/pull/363 From jjg at openjdk.java.net Mon Sep 28 21:07:34 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 28 Sep 2020 21:07:34 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:00:08 GMT, Vicente Romero wrote: >> Co-authored-by: Bernard Blaser >> Co-authored-by: Vicente Romero > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding bug number to test and updating code as per review comments Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/363 From vromero at openjdk.java.net Mon Sep 28 21:27:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 28 Sep 2020 21:27:16 GMT Subject: Integrated: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record In-Reply-To: References: Message-ID: <6QicSlUwS3eiP0jpTz_ea-EoYBQAv_-YhvdLyEynNKE=.ea0b75bc-7dfe-486e-81c2-b89e990d4a3a@github.com> On Fri, 25 Sep 2020 17:45:10 GMT, Vicente Romero wrote: > Co-authored-by: Bernard Blaser > Co-authored-by: Vicente Romero This pull request has now been integrated. Changeset: ac15d644 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/ac15d644 Stats: 22 lines in 2 files changed: 18 ins; 0 del; 4 mod 8241151: Incorrect lint warning for no definition of serialVersionUID in a record Co-authored-by: Bernard Blaser Co-authored-by: Vicente Romero Reviewed-by: jjg ------------- PR: https://git.openjdk.java.net/jdk/pull/363 From github.com+7693005+JarvisCraft at openjdk.java.net Tue Sep 29 00:08:04 2020 From: github.com+7693005+JarvisCraft at openjdk.java.net (PROgrm_JARvis) Date: Tue, 29 Sep 2020 00:08:04 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:00:08 GMT, Vicente Romero wrote: >> Co-authored-by: Bernard Blaser >> Co-authored-by: Vicente Romero > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > adding bug number to test and updating code as per review comments test/langtools/tools/javac/records/RecordCompilationTests.java line 151: > 149: > 150: public RecordCompilationTests() { > 151: useAP = System.getProperty("useAP", "false").equals("true"); Can't `Boolean.getBoolean("useAP")` be used here instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/363 From cstein at openjdk.java.net Tue Sep 29 05:45:10 2020 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 29 Sep 2020 05:45:10 GMT Subject: RFR: 8253761: Fix URI syntax of jar --describe-module Message-ID: 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 ------------- Commit messages: - 8253761: Fix URI syntax of jar --describe-module Changes: https://git.openjdk.java.net/jdk/pull/393/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=393&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253761 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/393.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/393/head:pull/393 PR: https://git.openjdk.java.net/jdk/pull/393 From jlahoda at openjdk.java.net Tue Sep 29 06:52:22 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 06:52:22 GMT Subject: RFR: 8253584: Redunant errors for partial member selects [v2] In-Reply-To: References: Message-ID: <39F2-VV4u2Qjv0dDo5A4oKq4njwYOfbaa1qs-Gx6YIY=.8131dc22-1a49-42c7-a2a7-3a1260de95b6@github.com> > For code like: > package t; > > class Test { > > void t() { > if (true) { > s(). > } else { > } > } > > String s() { > return null; > } > } > > (note the missing member name after `s().`), javac will produce a number of compile-time errors: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > > } else { > ^ > > } else { > ^ > > String s() { > ^ > > } > ^ > 6 errors > > The reason is that after not seeing an identifier after the `.` javac will skip the token that follows the dot. This > was done to improve errors in https://bugs.openjdk.java.net/browse/JDK-8081769 . But here, reading the next token will > skip the closing `}`, and the parser will de-synchronize with the braces, leading to the follow-up errors. The > proposal here is to handle incorrect `.class` specially, and avoid reading the next token when an identifier is no > specified in a member select, except when the next token is `class`. The errors with this patch are: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > 2 errors > > This seems much better. 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8253584 - 8253584: Redunant errors for partial member selects ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/333/files - new: https://git.openjdk.java.net/jdk/pull/333/files/914c9fde..9bc235ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=333&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=333&range=00-01 Stats: 28156 lines in 596 files changed: 4818 ins; 21874 del; 1464 mod Patch: https://git.openjdk.java.net/jdk/pull/333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/333/head:pull/333 PR: https://git.openjdk.java.net/jdk/pull/333 From jlahoda at openjdk.java.net Tue Sep 29 10:14:02 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 10:14:02 GMT Subject: Integrated: 8253584: Redunant errors for partial member selects In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:33:55 GMT, Jan Lahoda wrote: > For code like: > package t; > > class Test { > > void t() { > if (true) { > s(). > } else { > } > } > > String s() { > return null; > } > } > > (note the missing member name after `s().`), javac will produce a number of compile-time errors: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > > } else { > ^ > > } else { > ^ > > String s() { > ^ > > } > ^ > 6 errors > > The reason is that after not seeing an identifier after the `.` javac will skip the token that follows the dot. This > was done to improve errors in https://bugs.openjdk.java.net/browse/JDK-8081769 . But here, reading the next token will > skip the closing `}`, and the parser will de-synchronize with the braces, leading to the follow-up errors. The > proposal here is to handle incorrect `.class` specially, and avoid reading the next token when an identifier is no > specified in a member select, except when the next token is `class`. The errors with this patch are: > $ javac /tmp/Test.java > > s(). > ^ > > s(). > ^ > 2 errors > > This seems much better. This pull request has now been integrated. Changeset: 86491a5f Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/86491a5f Stats: 51 lines in 2 files changed: 48 ins; 0 del; 3 mod 8253584: Redunant errors for partial member selects Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/333 From jlahoda at openjdk.java.net Tue Sep 29 11:51:17 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 11:51:17 GMT Subject: RFR: 8253770: Test tools/javac/parser/JavacParserTest.java fails on =?UTF-8?B?V2luZG934oCm?= Message-ID: ?s after JDK-8253584 The issue is (again) not normalized line endings for the test output - fixed in by normalizing the line endings in the actual output. ------------- Commit messages: - 8253770: Test tools/javac/parser/JavacParserTest.java fails on Windows after JDK-8253584 Changes: https://git.openjdk.java.net/jdk/pull/399/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=399&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253770 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/399.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/399/head:pull/399 PR: https://git.openjdk.java.net/jdk/pull/399 From vromero at openjdk.java.net Tue Sep 29 13:13:48 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 13:13:48 GMT Subject: RFR: 8253770: Test tools/javac/parser/JavacParserTest.java fails on =?UTF-8?B?V2luZG934oCm?= In-Reply-To: References: Message-ID: <04ZyBybp4Q4KT9SzN0NV1tWEAVqbYoRcUDpJGuYg80c=.58d196d8-0a58-461f-8b10-65155d230e21@github.com> On Tue, 29 Sep 2020 11:44:27 GMT, Jan Lahoda wrote: > ?s after JDK-8253584 > > The issue is (again) not normalized line endings for the test output - fixed in by normalizing the line endings in the > actual output. Marked as reviewed by vromero (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/399 From jlahoda at openjdk.java.net Tue Sep 29 14:07:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 14:07:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Fri, 25 Sep 2020 00:41:47 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: > > adding missing changes to some tests Marked as reviewed by jlahoda (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From jlahoda at openjdk.java.net Tue Sep 29 14:07:57 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 14:07:57 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0H-sMIm0mwGW2f2OxwAwMGBtxDf2BUf7ds3tGEgYXrc=.849aab2b-4cf3-49f7-8e49-ad1df75cb0bb@github.com> Message-ID: On Fri, 25 Sep 2020 15:47:30 GMT, Peter Levart wrote: >> [CSR: Record Classes](https://bugs.openjdk.java.net/browse/JDK-8253605) > > Hi @vicente-romero-oracle , note that besides tests, there is also a JMH benchmark that measures the performance of > records deserialization (org.openjdk.bench.java.io.RecordDeserialization) which forced us to modify the build procedure > for all benchmarks to include --enable-preview option in JDK 15 and backports (see > https://bugs.openjdk.java.net/browse/JDK-8248135). If you undo this change in JDK 16 then also the problem described in > https://bugs.openjdk.java.net/browse/JDK-8250669 and https://bugs.openjdk.java.net/browse/JDK-8248429 will disapear. > After that, perhaps undoing the same for JDK 15 and backports together with removing the benchmark is also possible to > resolve the issues in older releases as most developement will probably happen in JDK 16 then and so the need for > performance testing will mostly be needed in there. We still have to figure out how to enable having benchmarks for > preview features as in the future there most probably will be a need for that. Langtools code looks good to me. We probably can also remove the RECORDS entry from PreviewFeature.Feature. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From jlahoda at openjdk.java.net Tue Sep 29 14:33:04 2020 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Tue, 29 Sep 2020 14:33:04 GMT Subject: Integrated: 8253770: Test tools/javac/parser/JavacParserTest.java fails on Windows after JDK-8253584 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 11:44:27 GMT, Jan Lahoda wrote: > ?s after JDK-8253584 > > The issue is (again) not normalized line endings for the test output - fixed in by normalizing the line endings in the > actual output. This pull request has now been integrated. Changeset: d5be8294 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk/commit/d5be8294 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253770: Test tools/javac/parser/JavacParserTest.java fails on Windows after JDK-8253584 Reviewed-by: vromero ------------- PR: https://git.openjdk.java.net/jdk/pull/399 From vromero at openjdk.java.net Tue Sep 29 16:06:15 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 16:06:15 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 00:05:25 GMT, PROgrm_JARvis wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> adding bug number to test and updating code as per review comments > > test/langtools/tools/javac/records/RecordCompilationTests.java line 151: > >> 149: >> 150: public RecordCompilationTests() { >> 151: useAP = System.getProperty("useAP", "false").equals("true"); > > Can't `Boolean.getBoolean("useAP")` be used here instead? it could be used, but the test could potentially be executed from command line too and there is no guarantee that the system property will be there if executed from the command line ------------- PR: https://git.openjdk.java.net/jdk/pull/363 From vromero at openjdk.java.net Tue Sep 29 16:49:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 16:49:36 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v7] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'JDK-8246774' of https://github.com/vicente-romero-oracle/jdk into JDK-8246774 - adding missing changes to some tests - Merge branch 'master' into JDK-8246774 - modifiying @since from 14 to 16 - Merge pull request #1 from ChrisHegarty/record-serial-tests Remove preview args from JDK tests - 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 - adding missing changes to some tests - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d5be8294...482fedec ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=06 Stats: 535 lines in 109 files changed: 32 ins; 278 del; 225 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 Tue Sep 29 17:10:34 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 17:10:34 GMT Subject: RFR: 8253455: Record Classes (final) javax.lang.model changes [v2] 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - adding reminder to remove RECORDS from PreviewFeature - Merge branch 'JDK-8253455' of https://github.com/vicente-romero-oracle/jdk into JDK-8253455 - 8253455: Record Classes (final) javax.lang.model changes Co-authored-by: Vicente Romero Co-authored-by: Joe Darcy - 8253455: Record Classes (final) javax.lang.model changes Co-authored-by: Vicente Romero Co-authored-by: Joe Darcy ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/4814f9e9..9b24af7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=00-01 Stats: 34575 lines in 777 files changed: 7972 ins; 24236 del; 2367 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 Tue Sep 29 18:27:50 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 18:27:50 GMT Subject: RFR: 8253455: Record Classes (final) javax.lang.model changes [v3] 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: <-AXqi1M883qgcJBJWxgsnsJwUYNWyVEI9h80oGdy1wA=.67c5c8f8-d8ba-4aab-9e70-5dbdeb578efb@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 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: adding reminder to remove RECORDS from PreviewFeature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/9b24af7d..f0845f6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 Tue Sep 29 18:34:07 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 18:34:07 GMT Subject: RFR: 8246774: Record Classes (final) implementation [v8] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 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 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/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/482fedec..76e3d278 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=06-07 Stats: 0 lines in 0 files changed: 0 ins; 0 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 jjg at openjdk.java.net Tue Sep 29 21:06:40 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 29 Sep 2020 21:06:40 GMT Subject: RFR: 8253736: Cleanup some of WorkArounds and usage thereof. Message-ID: 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. ------------- Commit messages: - Adjust for DocLint move - Merge master - Cleanup some of WorkArounds and usage thereof. Changes: https://git.openjdk.java.net/jdk/pull/412/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=412&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253736 Stats: 427 lines in 12 files changed: 190 ins; 155 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/412.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/412/head:pull/412 PR: https://git.openjdk.java.net/jdk/pull/412 From vromero at openjdk.java.net Tue Sep 29 21:18:33 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 21:18:33 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v4] 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: this test will be fixed in the patch for JDK-8246774 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/f0845f6f..aeb799ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=02-03 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 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 Tue Sep 29 21:37:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Sep 2020 21:37:58 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] 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: adding a comment to PreviewFeature.Feature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/291/files - new: https://git.openjdk.java.net/jdk/pull/291/files/aeb799ff..f5682fc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=03-04 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 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 github.com+7693005+JarvisCraft at openjdk.java.net Tue Sep 29 22:16:24 2020 From: github.com+7693005+JarvisCraft at openjdk.java.net (PROgrm_JARvis) Date: Tue, 29 Sep 2020 22:16:24 GMT Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: References: Message-ID: <-D4-0UODjaPQNPY1VFYWUfklorn8ou11qKUS-_ahNmE=.83bfebfb-b519-4bdf-92f4-aa14afc9558b@github.com> On Tue, 29 Sep 2020 16:03:37 GMT, Vicente Romero wrote: >> test/langtools/tools/javac/records/RecordCompilationTests.java line 151: >> >>> 149: >>> 150: public RecordCompilationTests() { >>> 151: useAP = System.getProperty("useAP", "false").equals("true"); >> >> Can't `Boolean.getBoolean("useAP")` be used here instead? > > it could be used, but the test could potentially be executed from command line too and there is no guarantee that the > system property will be there if executed from the command line As I understand, call to `Boolean.getBoolean("useAP")` is identical to your variant as it also relies on `System#getProperty(String)` so I cannot see any different behaviour if using it: https://github.com/openjdk/jdk/blob/8df3e72cea9217a7a10e2ac4bf4d1501a7fad43c/src/java.base/share/classes/java/lang/Boolean.java#L272-L279 ------------- PR: https://git.openjdk.java.net/jdk/pull/363 From jonathan.gibbons at oracle.com Tue Sep 29 22:29:01 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 29 Sep 2020 15:29:01 -0700 Subject: RFR: 8241151: Incorrect lint warning for no definition of serialVersionUID in a record [v2] In-Reply-To: <-D4-0UODjaPQNPY1VFYWUfklorn8ou11qKUS-_ahNmE=.83bfebfb-b519-4bdf-92f4-aa14afc9558b@github.com> References: <-D4-0UODjaPQNPY1VFYWUfklorn8ou11qKUS-_ahNmE=.83bfebfb-b519-4bdf-92f4-aa14afc9558b@github.com> Message-ID: Yes, Boolean.getBoolean could have been used, but to be accurate, the behavior is not identical, and given this is just test code that has already been integrated, I don't see the point in changing it. -- Jon On 9/29/20 3:16 PM, PROgrm_JARvis wrote: > On Tue, 29 Sep 2020 16:03:37 GMT, Vicente Romero wrote: > >>> test/langtools/tools/javac/records/RecordCompilationTests.java line 151: >>> >>>> 149: >>>> 150: public RecordCompilationTests() { >>>> 151: useAP = System.getProperty("useAP", "false").equals("true"); >>> Can't `Boolean.getBoolean("useAP")` be used here instead? >> it could be used, but the test could potentially be executed from command line too and there is no guarantee that the >> system property will be there if executed from the command line > As I understand, call to `Boolean.getBoolean("useAP")` is identical to your variant as it also relies on > `System#getProperty(String)` so I cannot see any different behaviour if using it: > https://github.com/openjdk/jdk/blob/8df3e72cea9217a7a10e2ac4bf4d1501a7fad43c/src/java.base/share/classes/java/lang/Boolean.java#L272-L279 > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/363 From sspitsyn at openjdk.java.net Wed Sep 30 00:08:44 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 30 Sep 2020 00:08:44 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 29 Sep 2020 14:05:27 GMT, Jan Lahoda wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> adding missing changes to some tests > > Marked as reviewed by jlahoda (Reviewer). The instrument tests update looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 30 00:21:20 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 00:21:20 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 30 Sep 2020 00:06:19 GMT, Serguei Spitsyn wrote: >> Marked as reviewed by jlahoda (Reviewer). > > The instrument tests update looks good to me. @sspitsyn thanks for the review. Please add yourself as a reviewer ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Wed Sep 30 00:24:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 00:24:29 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v6] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <9lpq7-8Hjtvui3jtyOxfKKRCGa1yObk5po4zn92Waog=.93761bb3-a0cc-4cd6-95a5-28d95c11012d@github.com> On Wed, 30 Sep 2020 00:18:17 GMT, Vicente Romero wrote: >> The instrument tests update looks good to me. > > @sspitsyn thanks for the review. Please add yourself as a reviewer @plevart interesting, but I think that I prefer to update those benchmarks in a follow-up patch in order to keep this patch as simple as possible. I will file a follow-up issue in JIRA and link it to JDK-8246774 ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From sspitsyn at openjdk.java.net Wed Sep 30 00:30:49 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 30 Sep 2020 00:30:49 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v8] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Tue, 29 Sep 2020 18:34:07 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 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. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Wed Sep 30 08:56:38 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 08:56:38 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, 23 Sep 2020 08:54:57 GMT, Chris Hegarty wrote: >> Vicente Romero has updated the pull request incrementally with three additional commits since the last revision: >> >> - Merge pull request #1 from ChrisHegarty/record-serial-tests >> >> Remove preview args from JDK tests >> - Remove preview args from ObjectMethodsTest >> - Remove preview args from record serialization tests > > 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 ) ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Wed Sep 30 08:56:37 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 08:56:37 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, 23 Sep 2020 03:34:29 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 three additional commits since the last revision: > > - Merge pull request #1 from ChrisHegarty/record-serial-tests > > Remove preview args from JDK tests > - Remove preview args from ObjectMethodsTest > - Remove preview args from record serialization tests Marked as reviewed by chegar (Reviewer). 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From chegar at openjdk.java.net Wed Sep 30 09:00:06 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 30 Sep 2020 09:00:06 GMT Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: On Tue, 29 Sep 2020 21:37:58 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: > > adding a comment to PreviewFeature.Feature src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 114: > 112: /** > 113: * A record type. > 114: * @since 14 The `@since` tags will all need to be updated to `16`, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/291 From anna.kozlova at jetbrains.com Wed Sep 30 09:50:09 2020 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Wed, 30 Sep 2020 11:50:09 +0200 Subject: switch expression type with 'null' return expression Message-ID: 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 Wed Sep 30 14:28:55 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 30 Sep 2020 14:28:55 GMT Subject: RFR: 8224225: Tokenizer improvements Message-ID: <07jiajCn1Z_J62in2U3gr4BevcvWZnkHfWXv0UTRmro=.dcfd51ad-df49-4f6d-8d15-d800bc42f147@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 ------------- Commit messages: - 8224225: Tokenizer improvements Changes: https://git.openjdk.java.net/jdk/pull/435/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=435&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8224225 Stats: 2353 lines in 18 files changed: 1119 ins; 603 del; 631 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 jlaskey at openjdk.java.net Wed Sep 30 14:28:55 2020 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 30 Sep 2020 14:28:55 GMT Subject: RFR: 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 @lahodaj @vicente-romero-oracle @mcimadamore Please review. No changes since last time. ------------- PR: https://git.openjdk.java.net/jdk/pull/435 From vromero at openjdk.java.net Wed Sep 30 14:50:40 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Sep 2020 14:50:40 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: <3HQG1K8tFl8GYpUnm_gbEH8MqTKMQ17fONGeb0m1RnE=.c74d767c-e371-471a-b963-944460e468f7@github.com> 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 ) yep u are right it could be removed, I will check all the instances of this, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From pravin at zensoftech.co.in Wed Sep 30 15:45:13 2020 From: pravin at zensoftech.co.in (Pravin Jain) Date: Wed, 30 Sep 2020 21:15:13 +0530 Subject: related to compile error in preview feature 'record' Message-ID: Dear sir, In the following code, I have commented the error. This error seems to be unnecessary, could have been a warning instead. In the constructor of record access to instance variable before explicit initialization, giving error, whereas same access is available by invoking a method. public record TestRecord(int low, int high) { public TestRecord { System.out.println(low); // System.out.println(this.low); // error, variable not initialized m1(); // but this works, why? } public void m1() { System.out.println(this.low); } public static void main(String[] args) { TestRecord r1 = new TestRecord(7,12); } } -- Pravin Jain (M)+91-9426054269 From alex.buckley at oracle.com Wed Sep 30 16:50:22 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Sep 2020 09:50:22 -0700 Subject: related to compile error in preview feature 'record' In-Reply-To: References: Message-ID: <5ac0af92-a3f3-7a3a-e6aa-0c29dbb025cb@oracle.com> In the compact constructor below, `low` refers to an implicit parameter of the constructor, whereas `this.low` refers to a field corresponding to the record component `low`. IIRC, the field is not definitely assigned before the end of the constructor body, so referring to `this.low` anywhere in the constructor body is an error by the traditional rule at the beginning of JLS ch.16. There is no interprocedural analysis in ch.16, so m1's independent reference to a field via `this.low` is allowed on the basis that the field was definitely assigned by the end of every constructor body.' In an ordinary class, a constructor body that calls m1() but forgets to explicitly initialize the field would cause a compile-time error. There is no corresponding compile-time error here because the compact constructor body implicitly initializes the field. Alex On 9/30/2020 8:45 AM, Pravin Jain wrote: > Dear sir, > In the following code, I have commented the error. > This error seems to be unnecessary, could have been a warning instead. > In the constructor of record access to instance variable before > explicit initialization, giving error, whereas same access is > available by invoking a method. > > public record TestRecord(int low, int high) { > public TestRecord { > System.out.println(low); > // System.out.println(this.low); // error, variable not initialized > m1(); // but this works, why? > } > public void m1() { > System.out.println(this.low); > } > public static void main(String[] args) { > TestRecord r1 = new TestRecord(7,12); > } > } > > From joe.darcy at oracle.com Wed Sep 30 21:29:49 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Sep 2020 14:29:49 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> Message-ID: <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> On 9/30/2020 2:00 AM, Chris Hegarty wrote: > On Tue, 29 Sep 2020 21:37:58 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: >> >> adding a comment to PreviewFeature.Feature > src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 114: > >> 112: /** >> 113: * A record type. >> 114: * @since 14 > The `@since` tags will all need to be updated to `16`, right? While I acknowledge that is what the current version of the JEP directs to happen in this situation, the API elements in question really are present in 14 and 15 so I don't think saying they are "since 16" is necessarily clearer. -Joe From alex.buckley at oracle.com Wed Sep 30 22:57:35 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Sep 2020 15:57:35 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> Message-ID: On 9/30/2020 2:29 PM, Joe Darcy wrote: >>> Vicente Romero has updated the pull request incrementally with one >>> additional commit since the last revision: >>> >>> ?? adding a comment to PreviewFeature.Feature >> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java >> line 114: >> >>> 112:???? /** >>> 113:????? * A record type. >>> 114:????? * @since 14 >> The `@since` tags will all need to be updated to `16`, right? > > While I acknowledge that is what the current version of the JEP directs > to happen in this situation, the API elements in question really are > present in 14 and 15 so I don't think saying they are "since 16" is > necessarily clearer. The reason that JEP 12 says to have @since reflect the final-and-permanent release rather than a preview release is to provide a JEP owner with a simple rule that applies regardless of whether an API element evolves between preview and permanent status. Just because an API element exists in 14 and 15 (as preview) and 16 (as permanent) doesn't mean it has exactly the same semantics in 16 as in 14 or 15 -- previewing is the one avenue by which an element can materially change its behavior between 14 and 15 and 16. Also, where API elements are previewed over time, the choice to have some elements be @since 14 while others are @since 15 or @since 16 would cause confusion in future -- "Are the 14 and 15-era elements associated with records considered to be final, given that records weren't finalized until 16? Might the 14 and 15-era elements be removed one day?" -- so I think it's best to focus @since consistently on the release where a feature becomes final-and-permanent. Alex From joe.darcy at oracle.com Wed Sep 30 23:48:32 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Sep 2020 16:48:32 -0700 Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5] In-Reply-To: References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com> <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com> Message-ID: <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com> On 9/30/2020 3:57 PM, Alex Buckley wrote: > On 9/30/2020 2:29 PM, Joe Darcy wrote: >>>> Vicente Romero has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? adding a comment to PreviewFeature.Feature >>> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java >>> line 114: >>> >>>> 112:???? /** >>>> 113:????? * A record type. >>>> 114:????? * @since 14 >>> The `@since` tags will all need to be updated to `16`, right? >> >> While I acknowledge that is what the current version of the JEP >> directs to happen in this situation, the API elements in question >> really are present in 14 and 15 so I don't think saying they are >> "since 16" is necessarily clearer. > > The reason that JEP 12 says to have @since reflect the > final-and-permanent release rather than a preview release is to > provide a JEP owner with a simple rule that applies regardless of > whether an API element evolves between preview and permanent status. > Just because an API element exists in 14 and 15 (as preview) and 16 > (as permanent) doesn't mean it has exactly the same semantics in 16 as > in 14 or 15 -- previewing is the one avenue by which an element can > materially change its behavior between 14 and 15 and 16. 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. > Also, where API elements are previewed over time, the choice to have > some elements be @since 14 while others are @since 15 or @since 16 > would cause confusion in future -- "Are the 14 and 15-era elements > associated with records considered to be final, given that records > weren't finalized until 16? Might the 14 and 15-era elements be > removed one day?" -- so I think it's best to focus @since consistently > on the release where a feature becomes final-and-permanent. > Another kind of consistency would be "use the @since tag for the release the API element was first added." For readers, it would be a simple rule that non-preview and not-deprecated-for-removal API elements can be assumed to be present in the next release. -Joe