... · expression

That will trigger a doccheck warning for a redundant  tag.

Since you're improving the doc comments for the DocTree nodes, it would 
be nice to use ... or (better) ,,, around the 
variables in the templates. For example:

34 * 
35 * @author name-text
36 * 
   37  *

DocRootTree:

I think you need {@literal ...} on line 33.

DocTypeTree:
As an enhancement, given that the tools only support HTML 5 these days, 
It might be helpful to give the specific text for an HTML 5 document

32 *    33  *    <!doctype text>
34 * 

 ??? + * For HTML5 documents, the correct form is? {@code }.

EntityTree:
Maybe remove the "misleading" spaces in the examples?

General:

Thinking aloud, for a future update when we have the `{@spec}` tag. In 
the introductory sentence for each tag, replace the use of `{@code}` by 
`{@spec}` linking to the right place in the doc-comment tag 
specification. I guess for many, it's not necessary, but the idea came 
to mind reading IndexTree, where more information may be helpful. That 
being said, additional info belongs in the tag spec, not the tree node spec.

DocSourcePositions:57,89
replace `CompilationUnit` with `compilation unit`

DocTreeFactory:112
We are inconsistent about whether to use `{..}` for inline tags, which 
will be worse when we add our first bimodal standard tag, `@return`, but 
using `{...}` for `{@deprecated}` is definitely wrong

General: (question)
Does a trailing space inside `{@code something }` cause extra whitespace 
in the rendered HTML?

DocTreePath:37,96,98,99
More un-code-d type names. Follow existing conventions for either using 
`{@code...}` or the descriptive equivalent (e.g. "tree path")

Trees:239,240
replace "The" by "the"
remove package name from TypeMirror, and use @code for that and ErrorType

DocCommentParser:
avoid Latin abbreviations; use "for example, such as"
1103: another candidate for `{@spec}` !!

Pretty: removing import
In general, this is a dangerous edit; throughout javac, you will see 
imports of javac.util.List in preference to java.util.List. I assume you 
have compiled and run the tests, to validate this change.

WriterFactory:135
Trailing period.

BaseTaglet
Yay for removing redundant doc comments from overridden methods!

toolkit/taglets/Taglet.java
41,143:
If you think "tag" refers to instances in doc comments, the original was 
correct
If you think "tag" refers to the class of the instances, the new text 
should use "the block tag"
142: consider remove "all" from end of line

-- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From maurizio.cimadamore at oracle.com  Fri Aug 14 17:42:09 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2020 18:42:09 +0100
Subject: RFR: JDK-8224225 - Tokenizer improvements
In-Reply-To: <721293C9-C990-4AB2-808A-D3C9A973DC88@oracle.com>
References: <721293C9-C990-4AB2-808A-D3C9A973DC88@oracle.com>
Message-ID: <546987cc-7db0-0bd5-6b47-6745212f2d5d@oracle.com>

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 james.laskey at oracle.com  Fri Aug 14 18:09:30 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Fri, 14 Aug 2020 15:09:30 -0300
Subject: RFR: JDK-8224225 - Tokenizer improvements
In-Reply-To: <546987cc-7db0-0bd5-6b47-6745212f2d5d@oracle.com>
References: <721293C9-C990-4AB2-808A-D3C9A973DC88@oracle.com>
 <546987cc-7db0-0bd5-6b47-6745212f2d5d@oracle.com>
Message-ID: <2570DC5F-0534-41C1-9D07-A9C73178D560@oracle.com>

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 maurizio.cimadamore at oracle.com  Fri Aug 14 21:20:05 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 14 Aug 2020 22:20:05 +0100
Subject: RFR: JDK-8224225 - Tokenizer improvements
In-Reply-To: <2570DC5F-0534-41C1-9D07-A9C73178D560@oracle.com>
References: <721293C9-C990-4AB2-808A-D3C9A973DC88@oracle.com>
 <546987cc-7db0-0bd5-6b47-6745212f2d5d@oracle.com>
 <2570DC5F-0534-41C1-9D07-A9C73178D560@oracle.com>
Message-ID: <9b6ec13b-0919-1fe6-5cac-5ae900e33f58@oracle.com>


On 14/08/2020 19:09, 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.)
:-D
>
> This patch is to remove that newline. Note that jcheck doesn't check 
> tests for missing last newline.

Very interesting - thanks for the explanation!

Maurizio

>
> 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 jonathan.gibbons at oracle.com  Fri Aug 14 21:30:01 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 14 Aug 2020 14:30:01 -0700
Subject: RFR: JDK-8224225 - Tokenizer improvements
In-Reply-To: <2570DC5F-0534-41C1-9D07-A9C73178D560@oracle.com>
References: <721293C9-C990-4AB2-808A-D3C9A973DC88@oracle.com>
 <546987cc-7db0-0bd5-6b47-6745212f2d5d@oracle.com>
 <2570DC5F-0534-41C1-9D07-A9C73178D560@oracle.com>
Message-ID: <5e91df74-0469-fa73-2295-ef3f65c49240@oracle.com>

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 james.laskey at oracle.com  Fri Aug 14 22:05:19 2020
From: james.laskey at oracle.com (James Laskey)
Date: Fri, 14 Aug 2020 19:05:19 -0300
Subject: RFR: JDK-8224225 - Tokenizer improvements
In-Reply-To: <5e91df74-0469-fa73-2295-ef3f65c49240@oracle.com>
References: <5e91df74-0469-fa73-2295-ef3f65c49240@oracle.com>
Message-ID: 

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 joe.darcy at oracle.com  Sat Aug 15 17:18:23 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 15 Aug 2020 10:18:23 -0700
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
Message-ID: <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>

On 8/13/2020 5:44 PM, Maurizio Cimadamore wrote:
> I personally like this suggestion a lot.
>
> I now realize that my main beef with "exposing" was that, by the time 
> I got to it, I half-forgot what caused the "exposing". This more 
> succint version rectifies that.
>
> Maurizio
>
> On 12/08/2020 19:14, Alex Buckley wrote:
>> compiler.warn.missing-explicit-ctor=\
>> class {0} declares no explicit constructors, exposing a default 
>> constructor to clients of module {2} 


How about

class {0} of exported package {1} declares no explicit constructors, 
exposing a default constructor to clients of module {2}

This more fully conveys the set of criteria necessary for the warning to 
be triggered.

As discussed earlier in the thread, I think it is best to keep command 
line help succinct:

javac.opt.Xlint.desc.missing-declared-ctor=\
 ??? Warn about missing declared constructors in public classes in 
exported packages.

I like to get new warning pushed in the near future; always an 
opportunity for new instances to occur in the code base until the 
warning is enabled :-)

Thanks,

-Joe


From fw at deneb.enyo.de  Sun Aug 16 15:03:39 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 16 Aug 2020 17:03:39 +0200
Subject: Partial module builds create unusable modules
Message-ID: <87sgcmiqes.fsf@mid.deneb.enyo.de>

When using --module-source-path, the compiler picks up dependencies
along the module search path and rebuilds missing classes, for modules
not listed under --module.

Unfortunately, that can produce modules that cannot even be discovered
at run time.  One case I encountered is when the module exports a
package, but the modules listed under --module do not reference any
classes in the package.  As a result, the package is not part of the
partial build, and the module cannot be discovered because it is
deemed malformed: ?java.lang.module.InvalidModuleDescriptorException:
Package ? not found in module?, followed by
?java.lang.module.FindException: Error reading module: ??.

Is this is the expected behavior?  I can see why things are the way
they are, but it's still a bit confusing.

Sorry if my terminology is a bit off; I'm new to this stuff.

From jonathan.gibbons at oracle.com  Sun Aug 16 22:20:57 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Sun, 16 Aug 2020 15:20:57 -0700
Subject: Partial module builds create unusable modules
In-Reply-To: <87sgcmiqes.fsf@mid.deneb.enyo.de>
References: <87sgcmiqes.fsf@mid.deneb.enyo.de>
Message-ID: <008a6910-06b2-7097-41e1-19e73961d47d@oracle.com>


On 8/16/20 8:03 AM, Florian Weimer wrote:
> When using --module-source-path, the compiler picks up dependencies
> along the module search path and rebuilds missing classes, for modules
> not listed under --module.
>
> Unfortunately, that can produce modules that cannot even be discovered
> at run time.  One case I encountered is when the module exports a
> package, but the modules listed under --module do not reference any
> classes in the package.  As a result, the package is not part of the
> partial build, and the module cannot be discovered because it is
> deemed malformed: ?java.lang.module.InvalidModuleDescriptorException:
> Package ? not found in module?, followed by
> ?java.lang.module.FindException: Error reading module: ??.
>
> Is this is the expected behavior?  I can see why things are the way
> they are, but it's still a bit confusing.
>
> Sorry if my terminology is a bit off; I'm new to this stuff.
It's not the defined, expected behavior.? Agreed it is confusing.
That being said, javac has always had issues when compiling
additional classes, but this does seem to be a more egregious
case of doing something bad as a result.

-- Jon


From pavel.rappo at oracle.com  Mon Aug 17 12:30:47 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 17 Aug 2020 13:30:47 +0100
Subject: RFR [16] 8251550: Clean up jdk.javadoc and the related parts of
 jdk.compiler
In-Reply-To: 
References: <680444AC-6DD8-49CF-9B3D-D71A2AD6B4C1@oracle.com>
 
Message-ID: <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>

Thanks for having a good look at it, Jon. My replies are inline.

> On 14 Aug 2020, at 17:49, Jonathan Gibbons  wrote:
> 
> Good cleanup.
> 
> Some systemic changes needed. Details below.
> 
> -- Jon
> 
> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>> Hello,
>> 
>> Please review the below change for 
>> https://bugs.openjdk.java.net/browse/JDK-8251550
>> 
>> 
>>   
>> http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
>> 
>> 
>> This represents squashed commits that have accumulated in my git branch. Since the changeset has started to look dangerously big, I decided not to wait until we finish the migration to Git and GitHub, and push it sooner. The less the others have to merge, the better.
>> 
>> -Pavel
>> 
>> 
> 
> 
> Some of the doctree changes contain this sequence:
> 
>     
>     
> 
> That will trigger a doccheck warning for a redundant  tag.

Fixed.

> Since you're improving the doc comments for the DocTree nodes, it would be nice to use ... or (better) ,,, around the variables in the templates.  For example:
> 
>   34  * 
>   35  *    @author name-text
>   36  * 
> 
>   37  *

Understood. However, for now I would prefer consistency (with the interfaces of the com.sun.source.tree package) over further improvement.

> DocRootTree:
> 
> I think you need {@literal ...} on line 33.

Why? The doc comment uses an HTML entity, not a naked "@" symbol:

    * 
    * 
    *    {@docroot}
    * 

Are you looking at the actual *diff* rather than at a *view* of the webrev? Webrev is infamous for producing a certain type of illusions.

> DocTypeTree:
> As an enhancement, given that the tools only support HTML 5 these days, It might be helpful to give the specific text for an HTML 5 document
> 
>   32  * > 
>   33  *    <!doctype text>
> 
>   34  * 
>     + * For HTML5 documents, the correct form is  {@code }.

Added the proposed line.

> EntityTree:
> Maybe remove the "misleading" spaces in the examples?

Removed the spaces.

> General:
> 
> Thinking aloud, for a future update when we have the `{@spec}` tag. In the introductory sentence for each tag, replace the use of `{@code}` by `{@spec}` linking to the right place in the doc-comment tag specification. I guess for many, it's not necessary, but the idea came to mind reading IndexTree, where more information may be helpful. That being said, additional info belongs in the tag spec, not the tree node spec.

Agreed.

> DocSourcePositions:57,89
> replace `CompilationUnit` with `compilation unit`

Replaced.

> DocTreeFactory:112
> We are inconsistent about whether to use `{..}` for inline tags, which will be worse when we add our first bimodal standard tag, `@return`, but using `{...}` for `{@deprecated}` is definitely wrong

Yes, I have that thought too. I fixed "@deprecated" along with other block tags in DocTreeFactory.java. On the other hand, I added missing curly braces around "@summary".

> General: (question)
> Does a trailing space inside `{@code something }` cause extra whitespace in the rendered HTML?

Yes, it does. I removed those *outer* trailing whitespace characters.

> DocTreePath:37,96,98,99
> More un-code-d type names. Follow existing conventions for either using `{@code...}` or the descriptive equivalent (e.g. "tree path")

@code-d those and some others.

> Trees:239,240
> replace "The" by "the"

Replaced there and in one other place.

> remove package name from TypeMirror, and use @code for that and ErrorType

Removed the package, but will NOT do the rest: it would be completely inconsistent with everything else in that file.

> DocCommentParser:
> avoid Latin abbreviations; use "for example, such as"

Fixed. Although, I don't get the rationale behind this piece of advice. One reason not to use any abbreviations would be the period characters: periods interfere with detecting first sentences in doc comments.

> 1103: another candidate for `{@spec}` !!

Yes. I just felt I have to provide something more fresh and immediately accessible.

> Pretty: removing import
> In general, this is a dangerous edit; throughout javac, you will see imports of javac.util.List in preference to java.util.List. I assume you have compiled and run the tests, to validate this change.

Correct, before posting the initial webrev I ran the tiers 1 through 3 in our CI. It was fine.

> WriterFactory:135
> Trailing period.

Removed there and in some other places.

> BaseTaglet
> Yay for removing redundant doc comments from overridden methods!
> 
> toolkit/taglets/Taglet.java
> 41,143: 
> If you think "tag" refers to instances in doc comments, the original was correct
> If you think "tag" refers to the class of the instances, the new text should use "the block tag"

Those terms have to be better defined in the spec.

> 142: consider remove "all" from end of line

Removed.

-Pavel

> -- Jon
> 


From pavel.rappo at oracle.com  Mon Aug 17 13:01:23 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 17 Aug 2020 14:01:23 +0100
Subject: RFR [16] 8251550: Clean up jdk.javadoc and the related parts of
 jdk.compiler
In-Reply-To: <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
References: <680444AC-6DD8-49CF-9B3D-D71A2AD6B4C1@oracle.com>
 
 <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
Message-ID: <93487E20-58B5-4487-89B6-4D76975156A5@oracle.com>

I forgot to add the link to the new webrev. Here it is:

    http://cr.openjdk.java.net/~prappo/8251550/webrev.01/

> On 17 Aug 2020, at 13:30, Pavel Rappo  wrote:
> 
> Thanks for having a good look at it, Jon. My replies are inline.
> 
>> On 14 Aug 2020, at 17:49, Jonathan Gibbons  wrote:
>> 
>> Good cleanup.
>> 
>> Some systemic changes needed. Details below.
>> 
>> -- Jon
>> 
>> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>>> Hello,
>>> 
>>> Please review the below change for 
>>> https://bugs.openjdk.java.net/browse/JDK-8251550
>>> 
>>> 
>>> 
>>> http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
>>> 
>>> 
>>> This represents squashed commits that have accumulated in my git branch. Since the changeset has started to look dangerously big, I decided not to wait until we finish the migration to Git and GitHub, and push it sooner. The less the others have to merge, the better.
>>> 
>>> -Pavel
>>> 
>>> 
>> 
>> 
>> Some of the doctree changes contain this sequence:
>> 
>>    
>>    
>> 
>> That will trigger a doccheck warning for a redundant  tag.
> 
> Fixed.
> 
>> Since you're improving the doc comments for the DocTree nodes, it would be nice to use ... or (better) ,,, around the variables in the templates.  For example:
>> 
>>  34  * 
>>  35  *    @author name-text
>>  36  * 
>> 
>>  37  *
> 
> Understood. However, for now I would prefer consistency (with the interfaces of the com.sun.source.tree package) over further improvement.
> 
>> DocRootTree:
>> 
>> I think you need {@literal ...} on line 33.
> 
> Why? The doc comment uses an HTML entity, not a naked "@" symbol:
> 
>    * 
>    * 
>    *    {@docroot}
>    * 
> 
> Are you looking at the actual *diff* rather than at a *view* of the webrev? Webrev is infamous for producing a certain type of illusions.
> 
>> DocTypeTree:
>> As an enhancement, given that the tools only support HTML 5 these days, It might be helpful to give the specific text for an HTML 5 document
>> 
>>  32  * >> 
>>  33  *    <!doctype text>
>> 
>>  34  * 
>>    + * For HTML5 documents, the correct form is  {@code }.
> 
> Added the proposed line.
> 
>> EntityTree:
>> Maybe remove the "misleading" spaces in the examples?
> 
> Removed the spaces.
> 
>> General:
>> 
>> Thinking aloud, for a future update when we have the `{@spec}` tag. In the introductory sentence for each tag, replace the use of `{@code}` by `{@spec}` linking to the right place in the doc-comment tag specification. I guess for many, it's not necessary, but the idea came to mind reading IndexTree, where more information may be helpful. That being said, additional info belongs in the tag spec, not the tree node spec.
> 
> Agreed.
> 
>> DocSourcePositions:57,89
>> replace `CompilationUnit` with `compilation unit`
> 
> Replaced.
> 
>> DocTreeFactory:112
>> We are inconsistent about whether to use `{..}` for inline tags, which will be worse when we add our first bimodal standard tag, `@return`, but using `{...}` for `{@deprecated}` is definitely wrong
> 
> Yes, I have that thought too. I fixed "@deprecated" along with other block tags in DocTreeFactory.java. On the other hand, I added missing curly braces around "@summary".
> 
>> General: (question)
>> Does a trailing space inside `{@code something }` cause extra whitespace in the rendered HTML?
> 
> Yes, it does. I removed those *outer* trailing whitespace characters.
> 
>> DocTreePath:37,96,98,99
>> More un-code-d type names. Follow existing conventions for either using `{@code...}` or the descriptive equivalent (e.g. "tree path")
> 
> @code-d those and some others.
> 
>> Trees:239,240
>> replace "The" by "the"
> 
> Replaced there and in one other place.
> 
>> remove package name from TypeMirror, and use @code for that and ErrorType
> 
> Removed the package, but will NOT do the rest: it would be completely inconsistent with everything else in that file.
> 
>> DocCommentParser:
>> avoid Latin abbreviations; use "for example, such as"
> 
> Fixed. Although, I don't get the rationale behind this piece of advice. One reason not to use any abbreviations would be the period characters: periods interfere with detecting first sentences in doc comments.
> 
>> 1103: another candidate for `{@spec}` !!
> 
> Yes. I just felt I have to provide something more fresh and immediately accessible.
> 
>> Pretty: removing import
>> In general, this is a dangerous edit; throughout javac, you will see imports of javac.util.List in preference to java.util.List. I assume you have compiled and run the tests, to validate this change.
> 
> Correct, before posting the initial webrev I ran the tiers 1 through 3 in our CI. It was fine.
> 
>> WriterFactory:135
>> Trailing period.
> 
> Removed there and in some other places.
> 
>> BaseTaglet
>> Yay for removing redundant doc comments from overridden methods!
>> 
>> toolkit/taglets/Taglet.java
>> 41,143: 
>> If you think "tag" refers to instances in doc comments, the original was correct
>> If you think "tag" refers to the class of the instances, the new text should use "the block tag"
> 
> Those terms have to be better defined in the spec.
> 
>> 142: consider remove "all" from end of line
> 
> Removed.
> 
> -Pavel
> 
>> -- Jon


From jan.lahoda at oracle.com  Mon Aug 17 14:25:56 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 17 Aug 2020 16:25:56 +0200
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <637ac11d-78a1-bdea-b908-98d3f6e54d11@oracle.com>
References: 
 <8cc0e6f9-3642-aac4-19b9-fb1451de6734@oracle.com>
 <8a20dcea-3349-1381-d18e-785d82a28cf5@oracle.com>
 <637ac11d-78a1-bdea-b908-98d3f6e54d11@oracle.com>
Message-ID: <443c1c5c-cfdd-0622-c102-cdfd3f783fb8@oracle.com>

Hi,

This looks good to me. The login in Check.checkDefaultConstructor could 
still be simplified, but doesn't have to.

Jan

On 12. 08. 20 18:43, Joe Darcy wrote:
> Hello,
> 
> Following the guidance of Jon and Jan, next iteration of the webrev is at:
> 
>  ???? http://cr.openjdk.java.net/~darcy/8071961.10
> 
> In this version, the checkDefaultConstructor method uses the 
> deferredLintHandler so that the annotation suppression can be done 
> properly, which is checked for by the tests.
> 
> The implementation checks 
> lint.isEnabled(LintCategory.MISSING_DECLARED_CTOR) at the top-level as 
> well as passing that condition into the lambda for the 
> deferredLintHandler. The first call checks if the warning is enabled at 
> all and the second if it is enabled AND hasn't been suppressed an an 
> annotation. (The annotation information is not available during the 
> compile phase when the first check is run.) It would be functionally 
> correct to just do the deferred check in the lambda, but I estimated the 
> outer check would be inexpensive screening.
> 
> Following the model from the existing test file, I wrote 
> DefaultCtorWarningToolBox.java to generate the seven small files 
> previously stored separately. Since I started by copying the existing 
> file, I kept its copyright date as the starting date.
> 
> Thanks,
> 
> -Joe
> 
> On 7/30/2020 10:21 PM, Joe Darcy wrote:
>> Hi Jan,
>>
>> Thanks for the review. The next iteration is at:
>>
>> ??? http://cr.openjdk.java.net/~darcy/8071961.6
>>
>> At least one more iteration will be needed on the engineering front; a 
>> few comments and questions below.
>>
>> On 7/30/2020 3:27 AM, Jan Lahoda wrote:
>>> Hi Joe,
>>>
>>> Thanks for this addition! A few comments for your consideration:
>>> -the logic in checkDefaultConstructor could probably be simplified - 
>>> going from "c" the symbol, and as long as the symbol being check is a 
>>> TYP and PUBLIC, go to its owner. E.g. like:
>>> ??????? if (lint.isEnabled(Lint.LintCategory.DEFAULT_CTOR) &&
>>> ??????????? Feature.MODULES.allowedInSource(source)) {
>>> ??????????? Symbol test = c;
>>> ??????????? while (test.kind == TYP && (test.flags() & PUBLIC) != 0) {
>>> ??????????????? test = test.owner;
>>> ??????????? }
>>> ??????????? if (test.kind != PCK) {
>>> ??????????????? return ;
>>> ??????????? }
>>>
>>> -not sure if the check for unnamed package is needed, but it would be 
>>> nice to have a test verifying proper behavior for unnamed packages, 
>>> unnamed module and in non-module mode (i.e. JDK 8 mode).
>>
>> Adding
>>
>> test/langtools/tools/javac/warnings/DefaultCtor/NoWarningCases.java
>> (http://cr.openjdk.java.net/~darcy/8071961.6/test/langtools/tools/javac/warnings/DefaultCtor/NoWarningCases.java.html) 
>>
>>
>> test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java
>> (http://cr.openjdk.java.net/~darcy/8071961.6/test/langtools/tools/javac/warnings/DefaultCtor/NoWarningRecord.java.html) 
>>
>>
>>>
>>> -should the warning be suppressable? We would need to defer the 
>>> warning using deferredLintHandler and check if it was already 
>>> suppressed.
>>
>> Yes; it should be suppressable. I changed the starting series of 
>> checks to
>>
>> 3835???????? if (lint.isEnabled(LintCategory.MISSING_DECLARED_CTOR) &&
>> 3836 !lint.isSuppressed(LintCategory.MISSING_DECLARED_CTOR) &&
>>
>> but it isn't having the desired effect; perhaps we could discuss how 
>> to resolve this off-line.
>>
>> I also added a check for records:
>>
>> 3837???????????? ((c.flags() & (ENUM? |RECORD)) == 0) &&
>>
>>>
>>> -should protected classes (classes with effectively protected access) 
>>> be covered as well?
>>
>> Hmm. I'm judging that as not necessary, for now.
>>
>>
>>>
>>> -for tests like this, I would suggest to consider using TestRunner, 
>>> ModuleTestBase or another framework we use for programmatic tests, to 
>>> avoid adding many small files for testcases, but I don't mind those 
>>> too much. See e.g.:
>>> test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java
>>
>> Thanks for the pointer; I'll take a look. (I wrote the tests in the 
>> old style I was familiar with.)
>>
>> Cheers,
>>
>> -Joe
>>
>>

From jonathan.gibbons at oracle.com  Mon Aug 17 14:28:00 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Aug 2020 07:28:00 -0700
Subject: RFR [16] 8251550: Clean up jdk.javadoc and the related parts of
 jdk.compiler
In-Reply-To: <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
References: <680444AC-6DD8-49CF-9B3D-D71A2AD6B4C1@oracle.com>
 
 <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
Message-ID: <0d4fde30-28c2-5897-9d73-26be31f99bdb@oracle.com>

I've read your responses, which all look OK.

I'll give the webrev a look as well.

-- Jon

On 8/17/20 5:30 AM, Pavel Rappo wrote:
> Thanks for having a good look at it, Jon. My replies are inline.
>
>> On 14 Aug 2020, at 17:49, Jonathan Gibbons  wrote:
>>
>> Good cleanup.
>>
>> Some systemic changes needed. Details below.
>>
>> -- Jon
>>
>> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>>> Hello,
>>>
>>> Please review the below change for
>>> https://bugs.openjdk.java.net/browse/JDK-8251550
>>>
>>>
>>>    
>>> http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
>>>
>>>
>>> This represents squashed commits that have accumulated in my git branch. Since the changeset has started to look dangerously big, I decided not to wait until we finish the migration to Git and GitHub, and push it sooner. The less the others have to merge, the better.
>>>
>>> -Pavel
>>>
>>>
>>
>> Some of the doctree changes contain this sequence:
>>
>>      
>>      
>>
>> That will trigger a doccheck warning for a redundant  tag.
> Fixed.
>
>> Since you're improving the doc comments for the DocTree nodes, it would be nice to use ... or (better) ,,, around the variables in the templates.  For example:
>>
>>    34  * 
>>    35  *    @author name-text
>>    36  * 
>>
>>    37  *
> Understood. However, for now I would prefer consistency (with the interfaces of the com.sun.source.tree package) over further improvement.
>
>> DocRootTree:
>>
>> I think you need {@literal ...} on line 33.
> Why? The doc comment uses an HTML entity, not a naked "@" symbol:
>
>      * 
>      * 
>      *    {@docroot}
>      * 
>
> Are you looking at the actual *diff* rather than at a *view* of the webrev? Webrev is infamous for producing a certain type of illusions.
>
>> DocTypeTree:
>> As an enhancement, given that the tools only support HTML 5 these days, It might be helpful to give the specific text for an HTML 5 document
>>
>>    32  * >>
>>    33  *    <!doctype text>
>>
>>    34  * 
>>      + * For HTML5 documents, the correct form is  {@code }.
> Added the proposed line.
>
>> EntityTree:
>> Maybe remove the "misleading" spaces in the examples?
> Removed the spaces.
>
>> General:
>>
>> Thinking aloud, for a future update when we have the `{@spec}` tag. In the introductory sentence for each tag, replace the use of `{@code}` by `{@spec}` linking to the right place in the doc-comment tag specification. I guess for many, it's not necessary, but the idea came to mind reading IndexTree, where more information may be helpful. That being said, additional info belongs in the tag spec, not the tree node spec.
> Agreed.
>
>> DocSourcePositions:57,89
>> replace `CompilationUnit` with `compilation unit`
> Replaced.
>
>> DocTreeFactory:112
>> We are inconsistent about whether to use `{..}` for inline tags, which will be worse when we add our first bimodal standard tag, `@return`, but using `{...}` for `{@deprecated}` is definitely wrong
> Yes, I have that thought too. I fixed "@deprecated" along with other block tags in DocTreeFactory.java. On the other hand, I added missing curly braces around "@summary".
>
>> General: (question)
>> Does a trailing space inside `{@code something }` cause extra whitespace in the rendered HTML?
> Yes, it does. I removed those *outer* trailing whitespace characters.
>
>> DocTreePath:37,96,98,99
>> More un-code-d type names. Follow existing conventions for either using `{@code...}` or the descriptive equivalent (e.g. "tree path")
> @code-d those and some others.
>
>> Trees:239,240
>> replace "The" by "the"
> Replaced there and in one other place.
>
>> remove package name from TypeMirror, and use @code for that and ErrorType
> Removed the package, but will NOT do the rest: it would be completely inconsistent with everything else in that file.
>
>> DocCommentParser:
>> avoid Latin abbreviations; use "for example, such as"
> Fixed. Although, I don't get the rationale behind this piece of advice. One reason not to use any abbreviations would be the period characters: periods interfere with detecting first sentences in doc comments.
>
>> 1103: another candidate for `{@spec}` !!
> Yes. I just felt I have to provide something more fresh and immediately accessible.
>
>> Pretty: removing import
>> In general, this is a dangerous edit; throughout javac, you will see imports of javac.util.List in preference to java.util.List. I assume you have compiled and run the tests, to validate this change.
> Correct, before posting the initial webrev I ran the tiers 1 through 3 in our CI. It was fine.
>
>> WriterFactory:135
>> Trailing period.
> Removed there and in some other places.
>
>> BaseTaglet
>> Yay for removing redundant doc comments from overridden methods!
>>
>> toolkit/taglets/Taglet.java
>> 41,143:
>> If you think "tag" refers to instances in doc comments, the original was correct
>> If you think "tag" refers to the class of the instances, the new text should use "the block tag"
> Those terms have to be better defined in the spec.
>
>> 142: consider remove "all" from end of line
> Removed.
>
> -Pavel
>
>> -- Jon
>>

From pavel.rappo at oracle.com  Mon Aug 17 15:17:10 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 17 Aug 2020 16:17:10 +0100
Subject: RFR [16] 8251550: Clean up jdk.javadoc and the related parts of
 jdk.compiler
In-Reply-To: <0d4fde30-28c2-5897-9d73-26be31f99bdb@oracle.com>
References: <680444AC-6DD8-49CF-9B3D-D71A2AD6B4C1@oracle.com>
 
 <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
 <0d4fde30-28c2-5897-9d73-26be31f99bdb@oracle.com>
Message-ID: <8D6F82E2-205B-4EB5-98D1-72A680B66377@oracle.com>

Thanks Jon. I will wait for you to revert back to me.

Separately, here's one more typo:

@@ -90,7 +90,7 @@ public interface DocSourcePositions extends SourcePositions {
      * @param comment the comment tree that encloses the tree for which the
      *                position is being sought
      * @param tree tree for which a position is sought
-     * @return the start position of tree
+     * @return the end position of tree
      */
     long getEndPosition(CompilationUnitTree file, DocCommentTree comment, DocTree tree);

I'll add that to the patch.

-Pavel

> On 17 Aug 2020, at 15:28, Jonathan Gibbons  wrote:
> 
> I've read your responses, which all look OK.
> 
> I'll give the webrev a look as well.
> 
> -- Jon
> 
> On 8/17/20 5:30 AM, Pavel Rappo wrote:
>> Thanks for having a good look at it, Jon. My replies are inline.
>> 
>>> On 14 Aug 2020, at 17:49, Jonathan Gibbons  wrote:
>>> 
>>> Good cleanup.
>>> 
>>> Some systemic changes needed. Details below.
>>> 
>>> -- Jon
>>> 
>>> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>>>> Hello,
>>>> 
>>>> Please review the below change for
>>>> https://bugs.openjdk.java.net/browse/JDK-8251550
>>>> 
>>>> 
>>>>   http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
>>>> 
>>>> 
>>>> This represents squashed commits that have accumulated in my git branch. Since the changeset has started to look dangerously big, I decided not to wait until we finish the migration to Git and GitHub, and push it sooner. The less the others have to merge, the better.
>>>> 
>>>> -Pavel
>>>> 
>>>> 
>>> 
>>> Some of the doctree changes contain this sequence:
>>> 
>>>     
>>>     
>>> 
>>> That will trigger a doccheck warning for a redundant  tag.
>> Fixed.
>> 
>>> Since you're improving the doc comments for the DocTree nodes, it would be nice to use ... or (better) ,,, around the variables in the templates.  For example:
>>> 
>>>   34  * 
>>>   35  *    @author name-text
>>>   36  * 
>>> 
>>>   37  *
>> Understood. However, for now I would prefer consistency (with the interfaces of the com.sun.source.tree package) over further improvement.
>> 
>>> DocRootTree:
>>> 
>>> I think you need {@literal ...} on line 33.
>> Why? The doc comment uses an HTML entity, not a naked "@" symbol:
>> 
>>     * 
>>     * 
>>     *    {@docroot}
>>     * 
>> 
>> Are you looking at the actual *diff* rather than at a *view* of the webrev? Webrev is infamous for producing a certain type of illusions.
>> 
>>> DocTypeTree:
>>> As an enhancement, given that the tools only support HTML 5 these days, It might be helpful to give the specific text for an HTML 5 document
>>> 
>>>   32  * >>> 
>>>   33  *    <!doctype text>
>>> 
>>>   34  * 
>>>     + * For HTML5 documents, the correct form is  {@code }.
>> Added the proposed line.
>> 
>>> EntityTree:
>>> Maybe remove the "misleading" spaces in the examples?
>> Removed the spaces.
>> 
>>> General:
>>> 
>>> Thinking aloud, for a future update when we have the `{@spec}` tag. In the introductory sentence for each tag, replace the use of `{@code}` by `{@spec}` linking to the right place in the doc-comment tag specification. I guess for many, it's not necessary, but the idea came to mind reading IndexTree, where more information may be helpful. That being said, additional info belongs in the tag spec, not the tree node spec.
>> Agreed.
>> 
>>> DocSourcePositions:57,89
>>> replace `CompilationUnit` with `compilation unit`
>> Replaced.
>> 
>>> DocTreeFactory:112
>>> We are inconsistent about whether to use `{..}` for inline tags, which will be worse when we add our first bimodal standard tag, `@return`, but using `{...}` for `{@deprecated}` is definitely wrong
>> Yes, I have that thought too. I fixed "@deprecated" along with other block tags in DocTreeFactory.java. On the other hand, I added missing curly braces around "@summary".
>> 
>>> General: (question)
>>> Does a trailing space inside `{@code something }` cause extra whitespace in the rendered HTML?
>> Yes, it does. I removed those *outer* trailing whitespace characters.
>> 
>>> DocTreePath:37,96,98,99
>>> More un-code-d type names. Follow existing conventions for either using `{@code...}` or the descriptive equivalent (e.g. "tree path")
>> @code-d those and some others.
>> 
>>> Trees:239,240
>>> replace "The" by "the"
>> Replaced there and in one other place.
>> 
>>> remove package name from TypeMirror, and use @code for that and ErrorType
>> Removed the package, but will NOT do the rest: it would be completely inconsistent with everything else in that file.
>> 
>>> DocCommentParser:
>>> avoid Latin abbreviations; use "for example, such as"
>> Fixed. Although, I don't get the rationale behind this piece of advice. One reason not to use any abbreviations would be the period characters: periods interfere with detecting first sentences in doc comments.
>> 
>>> 1103: another candidate for `{@spec}` !!
>> Yes. I just felt I have to provide something more fresh and immediately accessible.
>> 
>>> Pretty: removing import
>>> In general, this is a dangerous edit; throughout javac, you will see imports of javac.util.List in preference to java.util.List. I assume you have compiled and run the tests, to validate this change.
>> Correct, before posting the initial webrev I ran the tiers 1 through 3 in our CI. It was fine.
>> 
>>> WriterFactory:135
>>> Trailing period.
>> Removed there and in some other places.
>> 
>>> BaseTaglet
>>> Yay for removing redundant doc comments from overridden methods!
>>> 
>>> toolkit/taglets/Taglet.java
>>> 41,143:
>>> If you think "tag" refers to instances in doc comments, the original was correct
>>> If you think "tag" refers to the class of the instances, the new text should use "the block tag"
>> Those terms have to be better defined in the spec.
>> 
>>> 142: consider remove "all" from end of line
>> Removed.
>> 
>> -Pavel
>> 
>>> -- Jon
>>> 


From maurizio.cimadamore at oracle.com  Mon Aug 17 16:01:16 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Aug 2020 17:01:16 +0100
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
 <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
Message-ID: 


On 15/08/2020 18:18, Joe Darcy wrote:
> On 8/13/2020 5:44 PM, Maurizio Cimadamore wrote:
>> I personally like this suggestion a lot.
>>
>> I now realize that my main beef with "exposing" was that, by the time 
>> I got to it, I half-forgot what caused the "exposing". This more 
>> succint version rectifies that.
>>
>> Maurizio
>>
>> On 12/08/2020 19:14, Alex Buckley wrote:
>>> compiler.warn.missing-explicit-ctor=\
>>> class {0} declares no explicit constructors, exposing a default 
>>> constructor to clients of module {2} 
>
>
> How about
>
> class {0} of exported package {1} declares no explicit constructors, 
> exposing a default constructor to clients of module {2}
Looks good to me - not 100% about use of the word "of" vs. "in" (e.g. 
class of exported package, vs. class in exported package)
>
> This more fully conveys the set of criteria necessary for the warning 
> to be triggered.
>
> As discussed earlier in the thread, I think it is best to keep command 
> line help succinct:
>
> javac.opt.Xlint.desc.missing-declared-ctor=\
> ??? Warn about missing declared constructors in public classes in 
> exported packages.

I agree this has to be succint - in sync with other help messages.

Maurizio

>
> I like to get new warning pushed in the near future; always an 
> opportunity for new instances to occur in the code base until the 
> warning is enabled :-)
>
> Thanks,
>
> -Joe
>

From alex.buckley at oracle.com  Mon Aug 17 16:29:33 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 17 Aug 2020 09:29:33 -0700
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
 <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
Message-ID: 

On 8/15/2020 10:18 AM, Joe Darcy wrote:
> How about
> 
> class {0} of exported package {1} declares no explicit constructors, 
> exposing a default constructor to clients of module {2}

> javac.opt.Xlint.desc.missing-declared-ctor=\
>  ??? Warn about missing declared constructors in public classes in 
> exported packages.

The warning mentions "explicit" constructors, the help mentions 
"declared" constructors. "declared" is the wrong factoring -- there is 
*always* a constructor declared (either explicitly or implicitly), and 
we want to focus on the omission of an explicit declaration. Saying 
"explicit" sets up the constrast with "implicit", which some people will 
want to use, such as Daniel Fuchs today: "that's what Joe Darcy used to 
document public implicit constructors in abstract classes...". Saying 
"explicit" also allows the contrast with "default"; much better than 
"declared" versus "default".

Recommend:

compiler.warn.missing-explicit-ctor=\
class {0} in exported package {1} declares no explicit constructors, 
exposing a default constructor to clients of module {2}

e.g.
class LineMetrics in exported package java.awt.font declared no explicit 
constructors, exposing a default constructor to clients of module 
java.desktop

javac.opt.Xlint.desc.missing-explicit-ctor=\
Warn about missing explicit constructors in public classes in exported 
packages.

Alex

From vicente.romero at oracle.com  Mon Aug 17 18:42:29 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 17 Aug 2020 14:42:29 -0400
Subject: RFR: JDK-8249902:
 tools/javac/records/mandated_members/read_resolve_method/CheckReadResolveMethodTest.java
 uses @ignore w/o bug-id
Message-ID: <4a559cc8-ba84-89ca-c749-32d599ad5e1d@oracle.com>

Hi,

Please review this fix for [1] at [2].? The patch is removing test 
CheckReadResolveMethodTest.java which is a left over of previous design 
ideas before the records spec settled down.? The test makes no sense 
anymore as `readResolve` didn't make it to be a mandated member of records,

Thanks,
Vicente

https://bugs.openjdk.java.net/browse/JDK-8249902
http://cr.openjdk.java.net/~vromero/8249902/webrev.00/

From jonathan.gibbons at oracle.com  Mon Aug 17 21:18:38 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Aug 2020 14:18:38 -0700
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: 
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
 <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
 
Message-ID: <963d8fb9-6272-65a9-e981-db3402f3e8a3@oracle.com>


On 8/17/20 9:29 AM, Alex Buckley wrote:
>
> compiler.warn.missing-explicit-ctor=\
> class {0} in exported package {1} declares no explicit constructors, 
> exposing a default constructor to clients of module {2} 

Is it just me, or does "declares no explicit constructors" sound weirdly 
stilted, as compared to something like "does not declare any explicit 
constructors" or "does not explicitly declare any constructors".

I'm not suggesting to change the meaning of what is being suggested; I'm 
just trying to find a better phrasing that sounds more natural.

-- Jon


From alex.buckley at oracle.com  Mon Aug 17 22:24:16 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 17 Aug 2020 15:24:16 -0700
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <963d8fb9-6272-65a9-e981-db3402f3e8a3@oracle.com>
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
 <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
 
 <963d8fb9-6272-65a9-e981-db3402f3e8a3@oracle.com>
Message-ID: <78247afd-b92e-6bcf-0498-3e50cbf2319c@oracle.com>

On 8/17/2020 2:18 PM, Jonathan Gibbons wrote> On 8/17/20 9:29 AM, Alex 
Buckley wrote:
>>
>> compiler.warn.missing-explicit-ctor=\
>> class {0} in exported package {1} declares no explicit constructors, 
>> exposing a default constructor to clients of module {2} 
> 
> Is it just me, or does "declares no explicit constructors" sound weirdly 
> stilted, as compared to something like "does not declare any explicit 
> constructors" or "does not explicitly declare any constructors".

I know what you mean. If the message was an independent clause (stopping 
at the comma), then I'd agree that "class ... does not explicitly 
declare any constructors" is best. However, the message tacks on a 
dependent clause to suggest an untoward effect on clients. The advantage 
of "declares no ...", besides using fewer words, is that it has the same 
positive phrasing as "exposing a ...", so the cause and effect is 
clearer: class ... declares X, exposing Y. All that said, I have no 
problem with Joe phrasing it with more words, as long as "explicit" 
ctors are front and center.

Alex

From joe.darcy at oracle.com  Mon Aug 17 22:51:43 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 17 Aug 2020 15:51:43 -0700
Subject: JDK 16 RFR of JDK-8071961: Add javac lint warning when a default
 constructor is created
In-Reply-To: <78247afd-b92e-6bcf-0498-3e50cbf2319c@oracle.com>
References: 
 <2e75dfcc-0cb8-0dae-a302-cf7bb3225131@oracle.com>
 
 
 <5ceba1a1-e774-91c2-75af-92d4324dfcdb@oracle.com>
 
 <0bccefa4-ebae-c91a-3d42-68abc74d9ceb@oracle.com>
 <5c3dcd00-01e4-5090-6c89-eb043525a876@oracle.com>
 
 <2458bec4-2247-8250-0575-d11f7a5a52c3@oracle.com>
 <28afc2b2-3bc2-e0df-f555-5aedb86f89e6@oracle.com>
 
 <7e4f88b2-fbec-474e-dc1d-88c1d91b57c7@oracle.com>
 <312c66d3-b5d2-04b7-34b3-e285fb99d4c6@oracle.com>
 <6d62fbe4-db1f-2a1e-9696-8566e4311ba4@oracle.com>
 
 <963d8fb9-6272-65a9-e981-db3402f3e8a3@oracle.com>
 <78247afd-b92e-6bcf-0498-3e50cbf2319c@oracle.com>
Message-ID: <807cbcd0-35d3-6b26-4c97-e9810857cb6b@oracle.com>

On 8/17/2020 3:24 PM, Alex Buckley wrote:
> On 8/17/2020 2:18 PM, Jonathan Gibbons wrote> On 8/17/20 9:29 AM, Alex 
> Buckley wrote:
>>>
>>> compiler.warn.missing-explicit-ctor=\
>>> class {0} in exported package {1} declares no explicit constructors, 
>>> exposing a default constructor to clients of module {2} 
>>
>> Is it just me, or does "declares no explicit constructors" sound 
>> weirdly stilted, as compared to something like "does not declare any 
>> explicit constructors" or "does not explicitly declare any 
>> constructors".
>
> I know what you mean. If the message was an independent clause 
> (stopping at the comma), then I'd agree that "class ... does not 
> explicitly declare any constructors" is best. However, the message 
> tacks on a dependent clause to suggest an untoward effect on clients. 
> The advantage of "declares no ...", besides using fewer words, is that 
> it has the same positive phrasing as "exposing a ...", so the cause 
> and effect is clearer: class ... declares X, exposing Y. All that 
> said, I have no problem with Joe phrasing it with more words, as long 
> as "explicit" ctors are front and center.
>
Going once, going twice:

class {0} in exported package {1} does not declare any explicit 
constructors, exposing a default constructor to clients of module {2}

-Joe


From jonathan.gibbons at oracle.com  Tue Aug 18 04:09:25 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 17 Aug 2020 21:09:25 -0700
Subject: RFR [16] 8251550: Clean up jdk.javadoc and the related parts of
 jdk.compiler
In-Reply-To: <0d4fde30-28c2-5897-9d73-26be31f99bdb@oracle.com>
References: <680444AC-6DD8-49CF-9B3D-D71A2AD6B4C1@oracle.com>
 
 <006C3BFB-A553-45B8-828E-190F1A39D46F@oracle.com>
 <0d4fde30-28c2-5897-9d73-26be31f99bdb@oracle.com>
Message-ID: 

ErroreousTree:32
delete "a" before "malformed text"

This is good; thanks for doing this.? I still see places where we don't 
use {@code} around type names, or are inconsistent in the HTML 
typography around variables names, arising from the general tension of 
whether to make the presented form more consistent or the source code 
easier to read. But that's a different bikeshed half way down a 
different slippery slope that can wait until another day.

-- Jon

On 8/17/20 7:28 AM, Jonathan Gibbons wrote:
> I've read your responses, which all look OK.
>
> I'll give the webrev a look as well.
>
> -- Jon
>
> On 8/17/20 5:30 AM, Pavel Rappo wrote:
>> Thanks for having a good look at it, Jon. My replies are inline.
>>
>>> On 14 Aug 2020, at 17:49, Jonathan Gibbons 
>>>  wrote:
>>>
>>> Good cleanup.
>>>
>>> Some systemic changes needed. Details below.
>>>
>>> -- Jon
>>>
>>> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>>>> Hello,
>>>>
>>>> Please review the below change for
>>>> https://bugs.openjdk.java.net/browse/JDK-8251550
>>>>
>>>>
>>>> ?? http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
>>>>
>>>>
>>>> This represents squashed commits that have accumulated in my git 
>>>> branch. Since the changeset has started to look dangerously big, I 
>>>> decided not to wait until we finish the migration to Git and 
>>>> GitHub, and push it sooner. The less the others have to merge, the 
>>>> better.
>>>>
>>>> -Pavel
>>>>
>>>>
>>>
>>> Some of the doctree changes contain this sequence:
>>>
>>> ???? 
>>> ???? 
>>>
>>> That will trigger a doccheck warning for a redundant  tag.
>> Fixed.
>>
>>> Since you're improving the doc comments for the DocTree nodes, it 
>>> would be nice to use ... or (better) ,,, around 
>>> the variables in the templates.? For example:
>>>
>>> ?? 34? * 
>>> ?? 35? *??? @author name-text
>>> ?? 36? * 
>>>
>>> ?? 37? *
>> Understood. However, for now I would prefer consistency (with the 
>> interfaces of the com.sun.source.tree package) over further improvement.
>>
>>> DocRootTree:
>>>
>>> I think you need {@literal ...} on line 33.
>> Why? The doc comment uses an HTML entity, not a naked "@" symbol:
>>
>> ???? * 
>> ???? * 
>> ???? *??? {@docroot}
>> ???? * 
>>
>> Are you looking at the actual *diff* rather than at a *view* of the 
>> webrev? Webrev is infamous for producing a certain type of illusions.
>>
>>> DocTypeTree:
>>> As an enhancement, given that the tools only support HTML 5 these 
>>> days, It might be helpful to give the specific text for an HTML 5 
>>> document
>>>
>>> ?? 32? * >>>
>>> ?? 33? *??? <!doctype text>
>>>
>>> ?? 34? * 
>>> ???? + * For HTML5 documents, the correct form is? {@code >> html>}.
>> Added the proposed line.
>>
>>> EntityTree:
>>> Maybe remove the "misleading" spaces in the examples?
>> Removed the spaces.
>>
>>> General:
>>>
>>> Thinking aloud, for a future update when we have the `{@spec}` tag. 
>>> In the introductory sentence for each tag, replace the use of 
>>> `{@code}` by `{@spec}` linking to the right place in the doc-comment 
>>> tag specification. I guess for many, it's not necessary, but the 
>>> idea came to mind reading IndexTree, where more information may be 
>>> helpful. That being said, additional info belongs in the tag spec, 
>>> not the tree node spec.
>> Agreed.
>>
>>> DocSourcePositions:57,89
>>> replace `CompilationUnit` with `compilation unit`
>> Replaced.
>>
>>> DocTreeFactory:112
>>> We are inconsistent about whether to use `{..}` for inline tags, 
>>> which will be worse when we add our first bimodal standard tag, 
>>> `@return`, but using `{...}` for `{@deprecated}` is definitely wrong
>> Yes, I have that thought too. I fixed "@deprecated" along with other 
>> block tags in DocTreeFactory.java. On the other hand, I added missing 
>> curly braces around "@summary".
>>
>>> General: (question)
>>> Does a trailing space inside `{@code something }` cause extra 
>>> whitespace in the rendered HTML?
>> Yes, it does. I removed those *outer* trailing whitespace characters.
>>
>>> DocTreePath:37,96,98,99
>>> More un-code-d type names. Follow existing conventions for either 
>>> using `{@code...}` or the descriptive equivalent (e.g. "tree path")
>> @code-d those and some others.
>>
>>> Trees:239,240
>>> replace "The" by "the"
>> Replaced there and in one other place.
>>
>>> remove package name from TypeMirror, and use @code for that and 
>>> ErrorType
>> Removed the package, but will NOT do the rest: it would be completely 
>> inconsistent with everything else in that file.
>>
>>> DocCommentParser:
>>> avoid Latin abbreviations; use "for example, such as"
>> Fixed. Although, I don't get the rationale behind this piece of 
>> advice. One reason not to use any abbreviations would be the period 
>> characters: periods interfere with detecting first sentences in doc 
>> comments.
>>
>>> 1103: another candidate for `{@spec}` !!
>> Yes. I just felt I have to provide something more fresh and 
>> immediately accessible.
>>
>>> Pretty: removing import
>>> In general, this is a dangerous edit; throughout javac, you will see 
>>> imports of javac.util.List in preference to java.util.List. I assume 
>>> you have compiled and run the tests, to validate this change.
>> Correct, before posting the initial webrev I ran the tiers 1 through 
>> 3 in our CI. It was fine.
>>
>>> WriterFactory:135
>>> Trailing period.
>> Removed there and in some other places.
>>
>>> BaseTaglet
>>> Yay for removing redundant doc comments from overridden methods!
>>>
>>> toolkit/taglets/Taglet.java
>>> 41,143:
>>> If you think "tag" refers to instances in doc comments, the original 
>>> was correct
>>> If you think "tag" refers to the class of the instances, the new 
>>> text should use "the block tag"
>> Those terms have to be better defined in the spec.
>>
>>> 142: consider remove "all" from end of line
>> Removed.
>>
>> -Pavel
>>
>>> -- Jon
>>>

From fw at deneb.enyo.de  Tue Aug 18 07:29:29 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 18 Aug 2020 09:29:29 +0200
Subject: Partial module builds create unusable modules
In-Reply-To: <008a6910-06b2-7097-41e1-19e73961d47d@oracle.com> (Jonathan
 Gibbons's message of "Sun, 16 Aug 2020 15:20:57 -0700")
References: <87sgcmiqes.fsf@mid.deneb.enyo.de>
 <008a6910-06b2-7097-41e1-19e73961d47d@oracle.com>
Message-ID: <87ft8kfm3q.fsf@mid.deneb.enyo.de>

* Jonathan Gibbons:

> On 8/16/20 8:03 AM, Florian Weimer wrote:
>> When using --module-source-path, the compiler picks up dependencies
>> along the module search path and rebuilds missing classes, for modules
>> not listed under --module.
>>
>> Unfortunately, that can produce modules that cannot even be discovered
>> at run time.  One case I encountered is when the module exports a
>> package, but the modules listed under --module do not reference any
>> classes in the package.  As a result, the package is not part of the
>> partial build, and the module cannot be discovered because it is
>> deemed malformed: ?java.lang.module.InvalidModuleDescriptorException:
>> Package ? not found in module?, followed by
>> ?java.lang.module.FindException: Error reading module: ??.
>>
>> Is this is the expected behavior?  I can see why things are the way
>> they are, but it's still a bit confusing.

> It's not the defined, expected behavior.? Agreed it is confusing.
> That being said, javac has always had issues when compiling
> additional classes, but this does seem to be a more egregious
> case of doing something bad as a result.

Maybe for modular builds, it would be possible not to do any partial
rebuilds at all?

I guess it would also help to solve the issue of of classes lingering
behind whose sources have been deleted (because javac would have a
complete view of the expected module content).

From pavel.rappo at oracle.com  Tue Aug 18 11:03:35 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 18 Aug 2020 12:03:35 +0100
Subject: RFR [16] 8251939: Fix copy-paste issues and address TODOs
Message-ID: <79A8B70F-32BA-4468-9E0E-F566216E2532@oracle.com>

Hello,

Please review the below inline patch for https://bugs.openjdk.java.net/browse/JDK-8251939. Although this patch modifies the wording of two public APIs, I don't think it requires a CSR for either of them.

Thanks,
-Pavel

diff --git a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
index ae82c72b4a3..181d0495774 100644
--- a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
+++ b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
@@ -1,12 +1,12 @@
 /*
- * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 only, as
  * published by the Free Software Foundation.  Oracle designates this
  * particular file as subject to the "Classpath" exception as provided
  * by Oracle in the LICENSE file that accompanied this code.
  *
  * This code is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -26,21 +26,21 @@
 package com.sun.source.tree;
 
 /**
  * A tree node for a {@code yield} statement.
  *
  * For example:
  *   *   yield expression ;
  * 
  *
- * @jls section TODO
+ * @jls 14.21 The yield Statement
  *
  * @since 13
  */
 public interface YieldTree extends StatementTree {
 
     /**
      * Returns the expression for this {@code yield} statement.
      *
      * @return the expression
      */
diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
index 631bac627e0..0ed59fe31b4 100644
--- a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
+++ b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
@@ -268,21 +268,21 @@ public class DocTreeScanner implements DocTreeVisitor {
      * @param node  {@inheritDoc}
      * @param p  {@inheritDoc}
      * @return the result of scanning
      */
     @Override
     public R visitIdentifier(IdentifierTree node, P p) {
         return null;
     }
 
     /**
-     * {@inheritDoc} This implementation returns {@code null}.
+     * {@inheritDoc} This implementation scans the children in left to right order.
      *
      * @param node  {@inheritDoc}
      * @param p  {@inheritDoc}
      * @return the result of scanning
      */
     @Override
     public R visitIndex(IndexTree node, P p) {
         R r = scan(node.getSearchTerm(), p);
         r = scanAndReduce(node.getDescription(), p, r);
         return r;
diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
index 46d173f5ba2..e7cff68e384 100644
--- a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
+++ b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
@@ -943,21 +943,21 @@ public class TreeScanner implements TreeVisitor {
      * @param node  {@inheritDoc}
      * @param p  {@inheritDoc}
      * @return the result of scanning
      */
     @Override
     public R visitErroneous(ErroneousTree node, P p) {
         return null;
     }
 
     /**
-     * {@inheritDoc} This implementation returns {@code null}.
+     * {@inheritDoc} This implementation scans the children in left to right order.
      *
      * @param node  {@inheritDoc}
      * @param p  {@inheritDoc}
      * @return the result of scanning
      */
     @Override
     public R visitYield(YieldTree node, P p) {
         return scan(node.getValue(), p);
     }
 }


From pavel.rappo at oracle.com  Tue Aug 18 14:38:46 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 18 Aug 2020 07:38:46 -0700 (PDT)
Subject: RFR [16] 8251939: Fix copy-paste issues and address TODOs
In-Reply-To: <79A8B70F-32BA-4468-9E0E-F566216E2532@oracle.com>
References: <79A8B70F-32BA-4468-9E0E-F566216E2532@oracle.com>
Message-ID: 

Please consider one more copy-paste kind of issue:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
index 0374e8e0eec..bfff486ad51 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
@@ -31,6 +31,7 @@ import java.util.Map;
 import com.sun.source.doctree.AttributeTree.ValueKind;
 import com.sun.source.doctree.ErroneousTree;
 import com.sun.source.doctree.UnknownBlockTagTree;
+import com.sun.source.doctree.UnknownInlineTagTree;
 import com.sun.tools.javac.parser.Tokens.Comment;
 import com.sun.tools.javac.tree.DCTree;
 import com.sun.tools.javac.tree.DCTree.DCAttribute;
@@ -303,7 +304,7 @@ public class DocCommentParser {
     /**
      * Read a single inline tag, including its content.
      * Standard tags parse their content appropriately.
-     * Non-standard tags are represented by {@link UnknownBlockTagTree}.
+     * Non-standard tags are represented by {@link UnknownInlineTagTree}.
      * Malformed tags may be returned as {@link ErroneousTree}.
      */
     protected DCTree inlineTag() {

> On 18 Aug 2020, at 12:03, Pavel Rappo  wrote:
> 
> Hello,
> 
> Please review the below inline patch for https://bugs.openjdk.java.net/browse/JDK-8251939. Although this patch modifies the wording of two public APIs, I don't think it requires a CSR for either of them.
> 
> Thanks,
> -Pavel
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
> index ae82c72b4a3..181d0495774 100644
> --- a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
> +++ b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
> @@ -1,12 +1,12 @@
> /*
> - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.  Oracle designates this
>  * particular file as subject to the "Classpath" exception as provided
>  * by Oracle in the LICENSE file that accompanied this code.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> @@ -26,21 +26,21 @@
> package com.sun.source.tree;
> 
> /**
>  * A tree node for a {@code yield} statement.
>  *
>  * For example:
>  * >  *   yield expression ;
>  * 
>  *
> - * @jls section TODO
> + * @jls 14.21 The yield Statement
>  *
>  * @since 13
>  */
> public interface YieldTree extends StatementTree {
> 
>     /**
>      * Returns the expression for this {@code yield} statement.
>      *
>      * @return the expression
>      */
> diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
> index 631bac627e0..0ed59fe31b4 100644
> --- a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
> +++ b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
> @@ -268,21 +268,21 @@ public class DocTreeScanner implements DocTreeVisitor {
>      * @param node  {@inheritDoc}
>      * @param p  {@inheritDoc}
>      * @return the result of scanning
>      */
>     @Override
>     public R visitIdentifier(IdentifierTree node, P p) {
>         return null;
>     }
> 
>     /**
> -     * {@inheritDoc} This implementation returns {@code null}.
> +     * {@inheritDoc} This implementation scans the children in left to right order.
>      *
>      * @param node  {@inheritDoc}
>      * @param p  {@inheritDoc}
>      * @return the result of scanning
>      */
>     @Override
>     public R visitIndex(IndexTree node, P p) {
>         R r = scan(node.getSearchTerm(), p);
>         r = scanAndReduce(node.getDescription(), p, r);
>         return r;
> diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
> index 46d173f5ba2..e7cff68e384 100644
> --- a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
> +++ b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
> @@ -943,21 +943,21 @@ public class TreeScanner implements TreeVisitor {
>      * @param node  {@inheritDoc}
>      * @param p  {@inheritDoc}
>      * @return the result of scanning
>      */
>     @Override
>     public R visitErroneous(ErroneousTree node, P p) {
>         return null;
>     }
> 
>     /**
> -     * {@inheritDoc} This implementation returns {@code null}.
> +     * {@inheritDoc} This implementation scans the children in left to right order.
>      *
>      * @param node  {@inheritDoc}
>      * @param p  {@inheritDoc}
>      * @return the result of scanning
>      */
>     @Override
>     public R visitYield(YieldTree node, P p) {
>         return scan(node.getValue(), p);
>     }
> }
> 


From jonathan.gibbons at oracle.com  Tue Aug 18 15:02:31 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Aug 2020 08:02:31 -0700
Subject: RFR [16] 8251939: Fix copy-paste issues and address TODOs
In-Reply-To: 
References: <79A8B70F-32BA-4468-9E0E-F566216E2532@oracle.com>
 
Message-ID: <168f7041-55bd-50ed-9a35-ba0ad414fb7d@oracle.com>

+1

-- Jon

On 8/18/20 7:38 AM, Pavel Rappo wrote:
> Please consider one more copy-paste kind of issue:
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
> index 0374e8e0eec..bfff486ad51 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
> @@ -31,6 +31,7 @@ import java.util.Map;
>   import com.sun.source.doctree.AttributeTree.ValueKind;
>   import com.sun.source.doctree.ErroneousTree;
>   import com.sun.source.doctree.UnknownBlockTagTree;
> +import com.sun.source.doctree.UnknownInlineTagTree;
>   import com.sun.tools.javac.parser.Tokens.Comment;
>   import com.sun.tools.javac.tree.DCTree;
>   import com.sun.tools.javac.tree.DCTree.DCAttribute;
> @@ -303,7 +304,7 @@ public class DocCommentParser {
>       /**
>        * Read a single inline tag, including its content.
>        * Standard tags parse their content appropriately.
> -     * Non-standard tags are represented by {@link UnknownBlockTagTree}.
> +     * Non-standard tags are represented by {@link UnknownInlineTagTree}.
>        * Malformed tags may be returned as {@link ErroneousTree}.
>        */
>       protected DCTree inlineTag() {
>
>> On 18 Aug 2020, at 12:03, Pavel Rappo  wrote:
>>
>> Hello,
>>
>> Please review the below inline patch for https://bugs.openjdk.java.net/browse/JDK-8251939. Although this patch modifies the wording of two public APIs, I don't think it requires a CSR for either of them.
>>
>> Thanks,
>> -Pavel
>>
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
>> index ae82c72b4a3..181d0495774 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/source/tree/YieldTree.java
>> @@ -1,12 +1,12 @@
>> /*
>> - * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2019, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>>   * under the terms of the GNU General Public License version 2 only, as
>>   * published by the Free Software Foundation.  Oracle designates this
>>   * particular file as subject to the "Classpath" exception as provided
>>   * by Oracle in the LICENSE file that accompanied this code.
>>   *
>>   * This code is distributed in the hope that it will be useful, but WITHOUT
>>   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> @@ -26,21 +26,21 @@
>> package com.sun.source.tree;
>>
>> /**
>>   * A tree node for a {@code yield} statement.
>>   *
>>   * For example:
>>   * >>   *   yield expression ;
>>   * 
>>   *
>> - * @jls section TODO
>> + * @jls 14.21 The yield Statement
>>   *
>>   * @since 13
>>   */
>> public interface YieldTree extends StatementTree {
>>
>>      /**
>>       * Returns the expression for this {@code yield} statement.
>>       *
>>       * @return the expression
>>       */
>> diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
>> index 631bac627e0..0ed59fe31b4 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/source/util/DocTreeScanner.java
>> @@ -268,21 +268,21 @@ public class DocTreeScanner implements DocTreeVisitor {
>>       * @param node  {@inheritDoc}
>>       * @param p  {@inheritDoc}
>>       * @return the result of scanning
>>       */
>>      @Override
>>      public R visitIdentifier(IdentifierTree node, P p) {
>>          return null;
>>      }
>>
>>      /**
>> -     * {@inheritDoc} This implementation returns {@code null}.
>> +     * {@inheritDoc} This implementation scans the children in left to right order.
>>       *
>>       * @param node  {@inheritDoc}
>>       * @param p  {@inheritDoc}
>>       * @return the result of scanning
>>       */
>>      @Override
>>      public R visitIndex(IndexTree node, P p) {
>>          R r = scan(node.getSearchTerm(), p);
>>          r = scanAndReduce(node.getDescription(), p, r);
>>          return r;
>> diff --git a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
>> index 46d173f5ba2..e7cff68e384 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
>> @@ -943,21 +943,21 @@ public class TreeScanner implements TreeVisitor {
>>       * @param node  {@inheritDoc}
>>       * @param p  {@inheritDoc}
>>       * @return the result of scanning
>>       */
>>      @Override
>>      public R visitErroneous(ErroneousTree node, P p) {
>>          return null;
>>      }
>>
>>      /**
>> -     * {@inheritDoc} This implementation returns {@code null}.
>> +     * {@inheritDoc} This implementation scans the children in left to right order.
>>       *
>>       * @param node  {@inheritDoc}
>>       * @param p  {@inheritDoc}
>>       * @return the result of scanning
>>       */
>>      @Override
>>      public R visitYield(YieldTree node, P p) {
>>          return scan(node.getValue(), p);
>>      }
>> }
>>

From pavel.rappo at oracle.com  Tue Aug 18 17:15:21 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 18 Aug 2020 18:15:21 +0100
Subject: RFR [16] 8251454: Wrong "self type" in DCTree.DCEndElement
Message-ID: <25FBBC39-4B82-4105-9AD9-C5107D5E081A@oracle.com>

Please review the below inline patch for https://bugs.openjdk.java.net/browse/JDK-8251454

Thanks,
-Pavel


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
index 5295ac38788..78b63c6c578 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -326,7 +326,7 @@ public abstract class DCTree implements DocTree {
         }
     }
 
-    public static class DCEndElement extends DCEndPosTree implements EndElementTree {
+    public static class DCEndElement extends DCEndPosTree implements EndElementTree {
         public final Name name;
 
         DCEndElement(Name name) {


From pavel.rappo at oracle.com  Tue Aug 18 17:21:24 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 18 Aug 2020 18:21:24 +0100
Subject: RFR [16] 8251357: [DocCommentParser] Infinite loop while looking for
 the end of a preamble
Message-ID: <03A03D54-7451-4156-B045-CB335F6B1D47@oracle.com>

Hello,

Please review the below change for https://bugs.openjdk.java.net/browse/JDK-8251357

  http://cr.openjdk.java.net/~prappo/8251357/webrev.00/

Thanks,
-Pavel


From jonathan.gibbons at oracle.com  Tue Aug 18 23:19:01 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 18 Aug 2020 16:19:01 -0700
Subject: RFR: JDK-8249902:
 tools/javac/records/mandated_members/read_resolve_method/CheckReadResolveMethodTest.java
 uses @ignore w/o bug-id
In-Reply-To: <4a559cc8-ba84-89ca-c749-32d599ad5e1d@oracle.com>
References: <4a559cc8-ba84-89ca-c749-32d599ad5e1d@oracle.com>
Message-ID: 

+1

On 8/17/20 11:42 AM, Vicente Romero wrote:
> Hi,
>
> Please review this fix for [1] at [2].? The patch is removing test 
> CheckReadResolveMethodTest.java which is a left over of previous 
> design ideas before the records spec settled down.? The test makes no 
> sense anymore as `readResolve` didn't make it to be a mandated member 
> of records,
>
> Thanks,
> Vicente
>
> https://bugs.openjdk.java.net/browse/JDK-8249902
> http://cr.openjdk.java.net/~vromero/8249902/webrev.00/

From TOSHIONA at jp.ibm.com  Wed Aug 19 09:11:22 2020
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Wed, 19 Aug 2020 18:11:22 +0900
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
Message-ID: 


Hi,

I'd like to backport 8233829 to 11u.
Original patch does not apply cleanly to 11u, because the target file was
reworked. The logic of the fix is same.

Original bug:
https://bugs.openjdk.java.net/browse/JDK-8233829
https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75

11u webrev:
http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00

Testing: tier1 and tier2

Thanks,
Toshio Nakamura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jan.lahoda at oracle.com  Wed Aug 19 12:42:10 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 19 Aug 2020 14:42:10 +0200
Subject: RFR: JDK-8252031: --patch-module java.base= may fail with "cyclic
 inheritance involving Object"
Message-ID: <10f81aea-d12d-13f5-7e03-b90ce2f2c604@oracle.com>

Hi,

When running javac with --patch-module java.base=, where  
contains a copy of java/lang, the compilation may (depending on exact 
circumstances) incorrectly fail with:
error: cyclic inheritance involving Object

The reason is that Types.asSuper is setting Flags.LOCKED on Symbols to 
detect cycles. But it also completes some of the Symbols, and if it 
tries to complete a Symbol that originates in source, cycle detection in 
for that Symbol is triggered using Check.checkNonCyclic. And that cycle 
detection is also using the LOCKED flag to detect cycles. So there may 
be interference between these two uses, leading to the false error.

The proposal is to avoid using the flag in asSuper, and use a simple Set 
to detect the cycles.

Possible alternative solutions include using a different flag (which is 
troublesome due to the limited supply of flags), or carefully avoid the 
unwanted interference by not completing while the flag is set (which is 
somewhat fragile).

Proposed webrev:
http://cr.openjdk.java.net/~jlahoda/8252031/webrev.00/index.html

JBS: https://bugs.openjdk.java.net/browse/JDK-8252031

What do you think?

Thanks,
     Jan

From jonathan.gibbons at oracle.com  Wed Aug 19 16:22:14 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Aug 2020 09:22:14 -0700
Subject: RFR [16] 8251454: Wrong "self type" in DCTree.DCEndElement
In-Reply-To: <25FBBC39-4B82-4105-9AD9-C5107D5E081A@oracle.com>
References: <25FBBC39-4B82-4105-9AD9-C5107D5E081A@oracle.com>
Message-ID: <5700805c-4c62-b029-bc65-3bcf24d11acd@oracle.com>

@self: Doh!

+1

-- Jon

On 8/18/20 10:15 AM, Pavel Rappo wrote:
> Please review the below inline patch for https://bugs.openjdk.java.net/browse/JDK-8251454
>
> Thanks,
> -Pavel
>
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
> index 5295ac38788..78b63c6c578 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -326,7 +326,7 @@ public abstract class DCTree implements DocTree {
>           }
>       }
>   
> -    public static class DCEndElement extends DCEndPosTree implements EndElementTree {
> +    public static class DCEndElement extends DCEndPosTree implements EndElementTree {
>           public final Name name;
>   
>           DCEndElement(Name name) {
>

From jonathan.gibbons at oracle.com  Wed Aug 19 16:23:13 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Aug 2020 09:23:13 -0700
Subject: RFR [16] 8251357: [DocCommentParser] Infinite loop while looking
 for the end of a preamble
In-Reply-To: <03A03D54-7451-4156-B045-CB335F6B1D47@oracle.com>
References: <03A03D54-7451-4156-B045-CB335F6B1D47@oracle.com>
Message-ID: <103caa3d-5486-ac65-6058-9eb007eb8a46@oracle.com>

+1

Thanks for fixing

-- Jon

On 8/18/20 10:21 AM, Pavel Rappo wrote:
> Hello,
>
> Please review the below change for https://bugs.openjdk.java.net/browse/JDK-8251357
>
>    http://cr.openjdk.java.net/~prappo/8251357/webrev.00/
>
> Thanks,
> -Pavel
>

From jonathan.gibbons at oracle.com  Wed Aug 19 22:08:29 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Aug 2020 15:08:29 -0700
Subject: RFR: JDK-8252031: --patch-module java.base= may fail with "cyclic
 inheritance involving Object"
In-Reply-To: <10f81aea-d12d-13f5-7e03-b90ce2f2c604@oracle.com>
References: <10f81aea-d12d-13f5-7e03-b90ce2f2c604@oracle.com>
Message-ID: <33934dc1-c542-fa52-7cf3-ecc10b9d7a89@oracle.com>

+1

I also confirm this patch fixes the situation where this issue was 
originally observed.

-- Jon

On 8/19/20 5:42 AM, Jan Lahoda wrote:
> Hi,
>
> When running javac with --patch-module java.base=, where  
> contains a copy of java/lang, the compilation may (depending on exact 
> circumstances) incorrectly fail with:
> error: cyclic inheritance involving Object
>
> The reason is that Types.asSuper is setting Flags.LOCKED on Symbols to 
> detect cycles. But it also completes some of the Symbols, and if it 
> tries to complete a Symbol that originates in source, cycle detection 
> in for that Symbol is triggered using Check.checkNonCyclic. And that 
> cycle detection is also using the LOCKED flag to detect cycles. So 
> there may be interference between these two uses, leading to the false 
> error.
>
> The proposal is to avoid using the flag in asSuper, and use a simple 
> Set to detect the cycles.
>
> Possible alternative solutions include using a different flag (which 
> is troublesome due to the limited supply of flags), or carefully avoid 
> the unwanted interference by not completing while the flag is set 
> (which is somewhat fragile).
>
> Proposed webrev:
> http://cr.openjdk.java.net/~jlahoda/8252031/webrev.00/index.html
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8252031
>
> What do you think?
>
> Thanks,
> ??? Jan

From vicente.romero at oracle.com  Thu Aug 20 00:24:56 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 19 Aug 2020 20:24:56 -0400
Subject: RFR: JDK-8230918: j.l.NASE in javap
Message-ID: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>

Please review fix for [1] at [2]. The fix is making javac fail with an 
error message if an attribute has a length too big to be processed.

Thanks,
Vicente

https://bugs.openjdk.java.net/browse/JDK-8230918
http://cr.openjdk.java.net/~vromero/8230918/webrev.00/

From jonathan.gibbons at oracle.com  Thu Aug 20 00:49:54 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 19 Aug 2020 17:49:54 -0700
Subject: RFR: JDK-8230918: j.l.NASE in javap
In-Reply-To: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>
References: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>
Message-ID: <2964f4aa-a55d-41f6-60d6-8f80ccabb8b5@oracle.com>

Hi Vicente,

It seems wrong to hijack an existing exception for an unrelated use.? 
There's no IO condition that warrants the use of `java.io.IOException`. 
The problem is that for better or worse, javap cannot handle this 
probably-malformed class file. That deserves some appropriate exception, 
and a new one if there is nothing appropriate that is already available 
to use.

-- Jon

On 8/19/20 5:24 PM, Vicente Romero wrote:
> Please review fix for [1] at [2]. The fix is making javac fail with an 
> error message if an attribute has a length too big to be processed.
>
> Thanks,
> Vicente
>
> https://bugs.openjdk.java.net/browse/JDK-8230918
> http://cr.openjdk.java.net/~vromero/8230918/webrev.00/

From jan.lahoda at oracle.com  Thu Aug 20 12:21:40 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 20 Aug 2020 14:21:40 +0200
Subject: RFR: JDK-8237041: AssertionError while parsing unclosed class
 declarations
Message-ID: 

Hi,

Consider a simplified testcase from the report (the code is obviously 
erroneous):
---
class T {
      String.class,
      String.class,
      //String.class, repeated many times
}

This crashes the parser in a safety code that is intended to prevent 
infinite loops in the parser. This code crashes the parser when there is 
too many errors reported on the same point in the source code.

There are two somewhat independent problematic parts in the code:
-first, consider code like this:
---
class T {
     class C1 {
          class C2 {
          //many more nested classes
//but no closing '}'
---

This is triggering the safety code, as it reports an "premature EOF" 
error for each of the classes, when it cannot find the closing brace. 
The proposed fix for this is to disable the safety code when the token 
that is being handled is an EOF token. (An alternative would be to 
remove the safety check altogether.)

-for code like this:
---
class T {
      class
      class
      class
}
---

the parser will parse this code like:
---
class T {
      class {
          class {
              class {
...
---

I.e. the AST nodes for the classes will be nested. That does not seem 
ideal, as there are no opening braces for the classes. It seems it would 
be better to parse like:
---
class T {
      class {}
      class {}
      class {}
---

The second proposed change in JavacParser attempts to do that, i.e. 
rather return an empty "class" body than continue parsing the class 
content if there is no opening brace. This required some tweaks to 
expected outputs for some tests.

The proposed patch is here:
http://cr.openjdk.java.net/~jlahoda/8237041/webrev.00/index.html

JBS:
https://bugs.openjdk.java.net/browse/JDK-8237041

How does this look?

Thanks,
      Jan

From vicente.romero at oracle.com  Thu Aug 20 21:30:13 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 20 Aug 2020 17:30:13 -0400
Subject: RFR: JDK-8230918: j.l.NASE in javap
In-Reply-To: <2964f4aa-a55d-41f6-60d6-8f80ccabb8b5@oracle.com>
References: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>
 <2964f4aa-a55d-41f6-60d6-8f80ccabb8b5@oracle.com>
Message-ID: 

Hi Jon,

Thanks for the review, I have updated the review to [1] to address your 
comments,

Vicente

[1] http://cr.openjdk.java.net/~vromero/8230918/webrev.01/



On 8/19/20 8:49 PM, Jonathan Gibbons wrote:
> Hi Vicente,
>
> It seems wrong to hijack an existing exception for an unrelated use.? 
> There's no IO condition that warrants the use of 
> `java.io.IOException`. The problem is that for better or worse, javap 
> cannot handle this probably-malformed class file. That deserves some 
> appropriate exception, and a new one if there is nothing appropriate 
> that is already available to use.
>
> -- Jon
>
> On 8/19/20 5:24 PM, Vicente Romero wrote:
>> Please review fix for [1] at [2]. The fix is making javac fail with 
>> an error message if an attribute has a length too big to be processed.
>>
>> Thanks,
>> Vicente
>>
>> https://bugs.openjdk.java.net/browse/JDK-8230918
>> http://cr.openjdk.java.net/~vromero/8230918/webrev.00/


From vicente.romero at oracle.com  Mon Aug 24 19:11:34 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 24 Aug 2020 15:11:34 -0400
Subject: RFR: JDK-8237041: AssertionError while parsing unclosed class
 declarations
In-Reply-To: 
References: 
Message-ID: <6164b8af-3ffe-e0f9-e103-cb4df2090ce7@oracle.com>

Hi Jan,

I'm curious that the user commented that the issue was only reproducible 
when APs were present. Wouldn't that mean that there is some data that 
is not being cleaned up after AP iterations?

Thanks,
Vicente

On 8/20/20 8:21 AM, Jan Lahoda wrote:
> Hi,
>
> Consider a simplified testcase from the report (the code is obviously 
> erroneous):
> ---
> class T {
> ???? String.class,
> ???? String.class,
> ???? //String.class, repeated many times
> }
>
> This crashes the parser in a safety code that is intended to prevent 
> infinite loops in the parser. This code crashes the parser when there 
> is too many errors reported on the same point in the source code.
>
> There are two somewhat independent problematic parts in the code:
> -first, consider code like this:
> ---
> class T {
> ??? class C1 {
> ???????? class C2 {
> ???????? //many more nested classes
> //but no closing '}'
> ---
>
> This is triggering the safety code, as it reports an "premature EOF" 
> error for each of the classes, when it cannot find the closing brace. 
> The proposed fix for this is to disable the safety code when the token 
> that is being handled is an EOF token. (An alternative would be to 
> remove the safety check altogether.)
>
> -for code like this:
> ---
> class T {
> ???? class
> ???? class
> ???? class
> }
> ---
>
> the parser will parse this code like:
> ---
> class T {
> ???? class {
> ???????? class {
> ???????????? class {
> ...
> ---
>
> I.e. the AST nodes for the classes will be nested. That does not seem 
> ideal, as there are no opening braces for the classes. It seems it 
> would be better to parse like:
> ---
> class T {
> ???? class {}
> ???? class {}
> ???? class {}
> ---
>
> The second proposed change in JavacParser attempts to do that, i.e. 
> rather return an empty "class" body than continue parsing the class 
> content if there is no opening brace. This required some tweaks to 
> expected outputs for some tests.
>
> The proposed patch is here:
> http://cr.openjdk.java.net/~jlahoda/8237041/webrev.00/index.html
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8237041
>
> How does this look?
>
> Thanks,
> ???? Jan


From vicente.romero at oracle.com  Mon Aug 24 19:47:29 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 24 Aug 2020 15:47:29 -0400
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
In-Reply-To: 
References: 
Message-ID: 

looks good to me,
Vicente

On 8/19/20 5:11 AM, Toshio 5 Nakamura wrote:
> Hi,
>
> I'd like to backport 8233829 to 11u.
> Original patch does not apply cleanly to 11u, because the target file was
> reworked. The logic of the fix is same.
>
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8233829
> https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75
>
> 11u webrev:
> http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00
>
> Testing: tier1 and tier2
>
> Thanks,
> Toshio Nakamura


From TOSHIONA at jp.ibm.com  Tue Aug 25 02:00:29 2020
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 25 Aug 2020 11:00:29 +0900
Subject: [11u] RFR 8233829: javac cannot find non-ASCII module name under
 non-UTF8 env
In-Reply-To: 
References: 
 
Message-ID: 


Hi Vicente,

Thank you for the review. I'll add a tag for requesting approval.

Thanks,
Toshio

Vicente Romero  wrote on 2020/08/25 04:47:29:

> From: Vicente Romero 
> To: Toshio 5 Nakamura ,
jdk-updates-dev at openjdk.java.net
> Cc: compiler-dev at openjdk.java.net
> Date: 2020/08/25 04:47
> Subject: [EXTERNAL] Re: [11u] RFR 8233829: javac cannot find non-
> ASCII module name under non-UTF8 env
>
> looks good to me,
> Vicente
>
> On 8/19/20 5:11 AM, Toshio 5 Nakamura wrote:
> > Hi,
> >
> > I'd like to backport 8233829 to 11u.
> > Original patch does not apply cleanly to 11u, because the target file
was
> > reworked. The logic of the fix is same.
> >
> > Original bug:
> >
https://bugs.openjdk.java.net/browse/JDK-8233829

> >
https://hg.openjdk.java.net/jdk/jdk/rev/25551ba96f75

> >
> > 11u webrev:
> >
http://cr.openjdk.java.net/~tnakamura/8233829-11u/webrev.00

> >
> > Testing: tier1 and tier2
> >
> > Thanks,
> > Toshio Nakamura
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jiefu at tencent.com  Tue Aug 25 04:50:04 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Tue, 25 Aug 2020 04:50:04 +0000
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to compile
In-Reply-To: <37F84883-F565-403A-A4C7-FD6A813DA6A3@tencent.com>
References: <37F84883-F565-403A-A4C7-FD6A813DA6A3@tencent.com>
Message-ID: <8347F2AB-62D4-41E4-825B-13577935557C@tencent.com>

Hi all,

May I get reviews for this fix?

JBS:    https://bugs.openjdk.java.net/browse/JDK-8252264
Webrev: http://cr.openjdk.java.net/~jiefu/8252264/webrev.00/

Thanks.
Best regards,
Jie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jan.lahoda at oracle.com  Tue Aug 25 07:57:28 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 25 Aug 2020 09:57:28 +0200
Subject: RFR: JDK-8237041: AssertionError while parsing unclosed class
 declarations
In-Reply-To: <6164b8af-3ffe-e0f9-e103-cb4df2090ce7@oracle.com>
References: 
 <6164b8af-3ffe-e0f9-e103-cb4df2090ce7@oracle.com>
Message-ID: <51fdf1d3-0d40-d563-bd9d-718c87bdd6f6@oracle.com>

On 24. 08. 20 21:11, Vicente Romero wrote:
> Hi Jan,
> 
> I'm curious that the user commented that the issue was only reproducible 
> when APs were present. Wouldn't that mean that there is some data that 
> is not being cleaned up after AP iterations?

It happens even without an annotation processor, but without an 
annotation processor, the errors are reported immediately and the 
exception is concealed from the user by:
https://github.com/openjdk/jdk/blob/4895a19dd195ff01cc67411e1f113ce77ddfe418/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L348

When annotation processors are used, the errors are stashed on side, and 
then the parser crashes before the errors are actually reported, and 
hence the error is shown to the user.

Jan

> 
> Thanks,
> Vicente
> 
> On 8/20/20 8:21 AM, Jan Lahoda wrote:
>> Hi,
>>
>> Consider a simplified testcase from the report (the code is obviously 
>> erroneous):
>> ---
>> class T {
>> ???? String.class,
>> ???? String.class,
>> ???? //String.class, repeated many times
>> }
>>
>> This crashes the parser in a safety code that is intended to prevent 
>> infinite loops in the parser. This code crashes the parser when there 
>> is too many errors reported on the same point in the source code.
>>
>> There are two somewhat independent problematic parts in the code:
>> -first, consider code like this:
>> ---
>> class T {
>> ??? class C1 {
>> ???????? class C2 {
>> ???????? //many more nested classes
>> //but no closing '}'
>> ---
>>
>> This is triggering the safety code, as it reports an "premature EOF" 
>> error for each of the classes, when it cannot find the closing brace. 
>> The proposed fix for this is to disable the safety code when the token 
>> that is being handled is an EOF token. (An alternative would be to 
>> remove the safety check altogether.)
>>
>> -for code like this:
>> ---
>> class T {
>> ???? class
>> ???? class
>> ???? class
>> }
>> ---
>>
>> the parser will parse this code like:
>> ---
>> class T {
>> ???? class {
>> ???????? class {
>> ???????????? class {
>> ...
>> ---
>>
>> I.e. the AST nodes for the classes will be nested. That does not seem 
>> ideal, as there are no opening braces for the classes. It seems it 
>> would be better to parse like:
>> ---
>> class T {
>> ???? class {}
>> ???? class {}
>> ???? class {}
>> ---
>>
>> The second proposed change in JavacParser attempts to do that, i.e. 
>> rather return an empty "class" body than continue parsing the class 
>> content if there is no opening brace. This required some tweaks to 
>> expected outputs for some tests.
>>
>> The proposed patch is here:
>> http://cr.openjdk.java.net/~jlahoda/8237041/webrev.00/index.html
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8237041
>>
>> How does this look?
>>
>> Thanks,
>> ???? Jan
> 

From vicente.romero at oracle.com  Tue Aug 25 15:48:57 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 25 Aug 2020 11:48:57 -0400
Subject: RFR: JDK-8237041: AssertionError while parsing unclosed class
 declarations
In-Reply-To: <51fdf1d3-0d40-d563-bd9d-718c87bdd6f6@oracle.com>
References: 
 <6164b8af-3ffe-e0f9-e103-cb4df2090ce7@oracle.com>
 <51fdf1d3-0d40-d563-bd9d-718c87bdd6f6@oracle.com>
Message-ID: <1fb04852-bb71-e7cf-6e76-9d2a643706ae@oracle.com>

I see, thanks for the clarification, looks good to me,

Vicente

On 8/25/20 3:57 AM, Jan Lahoda wrote:
> On 24. 08. 20 21:11, Vicente Romero wrote:
>> Hi Jan,
>>
>> I'm curious that the user commented that the issue was only 
>> reproducible when APs were present. Wouldn't that mean that there is 
>> some data that is not being cleaned up after AP iterations?
>
> It happens even without an annotation processor, but without an 
> annotation processor, the errors are reported immediately and the 
> exception is concealed from the user by:
> https://github.com/openjdk/jdk/blob/4895a19dd195ff01cc67411e1f113ce77ddfe418/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L348 
>
>
> When annotation processors are used, the errors are stashed on side, 
> and then the parser crashes before the errors are actually reported, 
> and hence the error is shown to the user.
>
> Jan
>
>>
>> Thanks,
>> Vicente
>>
>> On 8/20/20 8:21 AM, Jan Lahoda wrote:
>>> Hi,
>>>
>>> Consider a simplified testcase from the report (the code is 
>>> obviously erroneous):
>>> ---
>>> class T {
>>> ???? String.class,
>>> ???? String.class,
>>> ???? //String.class, repeated many times
>>> }
>>>
>>> This crashes the parser in a safety code that is intended to prevent 
>>> infinite loops in the parser. This code crashes the parser when 
>>> there is too many errors reported on the same point in the source code.
>>>
>>> There are two somewhat independent problematic parts in the code:
>>> -first, consider code like this:
>>> ---
>>> class T {
>>> ??? class C1 {
>>> ???????? class C2 {
>>> ???????? //many more nested classes
>>> //but no closing '}'
>>> ---
>>>
>>> This is triggering the safety code, as it reports an "premature EOF" 
>>> error for each of the classes, when it cannot find the closing 
>>> brace. The proposed fix for this is to disable the safety code when 
>>> the token that is being handled is an EOF token. (An alternative 
>>> would be to remove the safety check altogether.)
>>>
>>> -for code like this:
>>> ---
>>> class T {
>>> ???? class
>>> ???? class
>>> ???? class
>>> }
>>> ---
>>>
>>> the parser will parse this code like:
>>> ---
>>> class T {
>>> ???? class {
>>> ???????? class {
>>> ???????????? class {
>>> ...
>>> ---
>>>
>>> I.e. the AST nodes for the classes will be nested. That does not 
>>> seem ideal, as there are no opening braces for the classes. It seems 
>>> it would be better to parse like:
>>> ---
>>> class T {
>>> ???? class {}
>>> ???? class {}
>>> ???? class {}
>>> ---
>>>
>>> The second proposed change in JavacParser attempts to do that, i.e. 
>>> rather return an empty "class" body than continue parsing the class 
>>> content if there is no opening brace. This required some tweaks to 
>>> expected outputs for some tests.
>>>
>>> The proposed patch is here:
>>> http://cr.openjdk.java.net/~jlahoda/8237041/webrev.00/index.html
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8237041
>>>
>>> How does this look?
>>>
>>> Thanks,
>>> ???? Jan
>>


From vicente.romero at oracle.com  Tue Aug 25 17:23:06 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 25 Aug 2020 13:23:06 -0400
Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec
Message-ID: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>

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 vicente.romero at oracle.com  Tue Aug 25 17:54:37 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 25 Aug 2020 13:54:37 -0400
Subject: RFR: JDK-8230918: j.l.NASE in javap
In-Reply-To: 
References: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>
 <2964f4aa-a55d-41f6-60d6-8f80ccabb8b5@oracle.com>
 
Message-ID: 

ping

On 8/20/20 5:30 PM, Vicente Romero wrote:
> Hi Jon,
>
> Thanks for the review, I have updated the review to [1] to address 
> your comments,
>
> Vicente
>
> [1] http://cr.openjdk.java.net/~vromero/8230918/webrev.01/
>
>
>
> On 8/19/20 8:49 PM, Jonathan Gibbons wrote:
>> Hi Vicente,
>>
>> It seems wrong to hijack an existing exception for an unrelated use.? 
>> There's no IO condition that warrants the use of 
>> `java.io.IOException`. The problem is that for better or worse, javap 
>> cannot handle this probably-malformed class file. That deserves some 
>> appropriate exception, and a new one if there is nothing appropriate 
>> that is already available to use.
>>
>> -- Jon
>>
>> On 8/19/20 5:24 PM, Vicente Romero wrote:
>>> Please review fix for [1] at [2]. The fix is making javac fail with 
>>> an error message if an attribute has a length too big to be processed.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8230918
>>> http://cr.openjdk.java.net/~vromero/8230918/webrev.00/
>


From joe.darcy at oracle.com  Tue Aug 25 23:31:24 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 25 Aug 2020 16:31:24 -0700
Subject: JDK 16 RFR of JDK-8251921: Expand default constructor warning to
 cover more cases
Message-ID: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>

Hello,

As a follow-up to JDK-8071961: "Add javac lint warning when a default 
constructor is created," Phil observed that there are cases in the JDK 
where a *protected* class has a default constructor appearing in the 
JDK. Please review the changes and CSR to augment the warning to cover 
both public and protected classes. For nested classes, the enclosing 
types must be either public or protected all the way up for the warning 
to be issued.

 ??? JDK-8251921: Expand default constructor warning to cover more cases
 ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8252348
 ??? webrev: http://cr.openjdk.java.net/~darcy/8251921.0/

Patch below. Clean langtools test run with this change.

Thanks,

-Joe

--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
2020-08-25 15:04:59.413000000 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
2020-08-25 15:04:58.685000000 -0700
@@ -3835,7 +3835,7 @@
 ???????? if (lint.isEnabled(LintCategory.MISSING_EXPLICIT_CTOR) &&
 ???????????? ((c.flags() & (ENUM | RECORD)) == 0) &&
 ???????????? !c.isAnonymous() &&
-??????????? ((c.flags() & PUBLIC) != 0) &&
+??????????? ((c.flags() & (PUBLIC | PROTECTED)) != 0) &&
 ???????????? Feature.MODULES.allowedInSource(source)) {
 ???????????? NestingKind nestingKind = c.getNestingKind();
 ???????????? switch (nestingKind) {
@@ -3844,10 +3844,10 @@
 ???????????????? case TOP_LEVEL -> {;} // No additional checks needed
 ???????????????? case MEMBER -> {
 ???????????????????? // For nested member classes, all the enclosing
-??????????????????? // classes must be public.
+??????????????????? // classes must be public or protected.
 ???????????????????? Symbol owner = c.owner;
 ???????????????????? while (owner != null && owner.kind == TYP) {
-??????????????????????? if ((owner.flags() & PUBLIC) == 0)
+??????????????????????? if ((owner.flags() & (PUBLIC | PROTECTED)) == 0)
 ???????????????????????????? return;
 ???????????????????????? owner = owner.owner;
 ???????????????????? }
--- 
old/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties 
2020-08-25 15:05:01.037000000 -0700
+++ 
new/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties 
2020-08-25 15:05:00.189000000 -0700
@@ -183,7 +183,7 @@
 ???? Warn about issues related to classfile contents.

 ?javac.opt.Xlint.desc.missing-explicit-ctor=\
-??? Warn about missing explicit constructors in public classes in 
exported packages.
+??? Warn about missing explicit constructors in public and protected 
classes in exported packages.

 ?javac.opt.Xlint.desc.deprecation=\
 ???? Warn about use of deprecated items.
--- 
old/test/langtools/tools/javac/warnings/DefaultCtor/DefaultCtorWarningToolBox.java 
2020-08-25 15:05:02.313000000 -0700
+++ 
new/test/langtools/tools/javac/warnings/DefaultCtor/DefaultCtorWarningToolBox.java 
2020-08-25 15:05:01.597000000 -0700
@@ -97,7 +97,9 @@
 ???????????? List.of("Foo.java:4:8: 
compiler.warn.missing-explicit-ctor: pkg1.Foo, pkg1, mod",
 ???????????????????? "Foo.java:12:12: 
compiler.warn.missing-explicit-ctor: pkg1.Foo.FooNest, pkg1, mod",
 ???????????????????? "Foo.java:16:19: 
compiler.warn.missing-explicit-ctor: pkg1.Foo.StaticFooNest, pkg1, mod",
-??????????????????? "3 warnings");
+??? ??? ??? "Foo.java:25:15: compiler.warn.missing-explicit-ctor: 
pkg1.Foo.ProtectedFooNest, pkg1, mod",
+??? ??? ??? "Foo.java:27:19: compiler.warn.missing-explicit-ctor: 
pkg1.Foo.ProtectedFooNest.ProtectedFooNestNest, pkg1, mod",
+??????????????????? "5 warnings");

 ???????? // Warning enable,
 ???????? log = new JavacTask(tb)
@@ -137,30 +139,34 @@
 ???????? class Bar {

 ???????????? // No explicit constructor; use a default.
-??????????? public class FooNest {
+??????????? public class BarNest {
 ???????????? }

 ???????????? // No explicit constructor; use a default.
-??????????? public static class StaticFooNest {
+??????????? public static class StaticBaryNest {
+??????????? }
+
+??????????? // No explicit constructor; use a default.
+??????????? protected class ProtectedBarNest {
 ???????????? }

 ???????????? // Package-access classes

 ???????????? // No explicit constructor; use a default.
-??????????? /*package*/ class PkgFooNest {
+??????????? /*package*/ class PkgBarNest {
 ???????????? }

 ???????????? // No explicit constructor; use a default.
-??????????? /*package*/ static class PkgStaticFooNest {
+??????????? /*package*/ static class PkgStaticBarNest {
 ???????????? }
 ???????????? // Private classes

 ???????????? // No explicit constructor; use a default.
-??????????? private class PrvFooNest {
+??????????? private class PrvBarNest {
 ???????????? }

 ???????????? // No explicit constructor; use a default.
-??????????? private static class PrvStaticFooNest {
+??????????? private static class PrvStaticBarNest {
 ???????????? }
 ???????? }
 ???????? """;
@@ -190,10 +196,18 @@
 ???????????? public static class SuppressedStaticFooNest {
 ???????????? }

+??????????? // No explicit constructor; use a default.
+??????????? protected class ProtectedFooNest {
+??????????????? // No explicit constructor; use a default.
+??????????????? protected class ProtectedFooNestNest {}
+??????????? }
+
 ???????????? // Package-access classes

 ???????????? // No explicit constructor; use a default.
 ???????????? /*package*/ class PkgFooNest {
+??????????????? // No explicit constructor; use a default.
+??????????????? protected class PkgFooNestNest {}
 ???????????? }

 ???????????? // No explicit constructor; use a default.
@@ -203,6 +217,8 @@

 ???????????? // No explicit constructor; use a default.
 ???????????? private class PrvFooNest {
+??????????????? // No explicit constructor; use a default.
+??????????????? protected class PrvFooNestNest {}
 ???????????? }

 ???????????? // No explicit constructor; use a default.


From vicente.romero at oracle.com  Wed Aug 26 00:04:50 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 25 Aug 2020 20:04:50 -0400
Subject: RFR: JDK-8231311: javac throws NPE in TransTypes.retype
Message-ID: <6ec04507-e797-8129-02b0-7abac5f08fcb@oracle.com>

Please review fix for [1] at [2]. The fix is ending the compilation at 
TransTypes if after erasing the type of a method symbol, its type is not 
a method type and thus there is no way for the compilation to continue.

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8231311
[2] http://cr.openjdk.java.net/~vromero/8231311/webrev.00/

From alex.buckley at oracle.com  Wed Aug 26 00:08:49 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 25 Aug 2020 17:08:49 -0700
Subject: JDK 16 RFR of JDK-8251921: Expand default constructor warning to
 cover more cases
In-Reply-To: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>
References: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>
Message-ID: 

CSR looks good.

I note that no change is needed to the compiler message which was 
ultimately chosen for this lint warning -- "class {0} in exported 
package {1} declares no explicit constructors, thereby exposing a 
default constructor to clients of module {2}" 
(http://hg.openjdk.java.net/jdk/jdk/rev/f74d10596242#l5.8)

Alex

On 8/25/2020 4:31 PM, Joe Darcy wrote:
> Hello,
> 
> As a follow-up to JDK-8071961: "Add javac lint warning when a default 
> constructor is created," Phil observed that there are cases in the JDK 
> where a *protected* class has a default constructor appearing in the 
> JDK. Please review the changes and CSR to augment the warning to cover 
> both public and protected classes. For nested classes, the enclosing 
> types must be either public or protected all the way up for the warning 
> to be issued.
> 
>  ??? JDK-8251921: Expand default constructor warning to cover more cases
>  ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8252348
>  ??? webrev: http://cr.openjdk.java.net/~darcy/8251921.0/
> 
> Patch below. Clean langtools test run with this change.
> 
> Thanks,
> 
> -Joe

From jan.lahoda at oracle.com  Wed Aug 26 08:26:25 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 26 Aug 2020 10:26:25 +0200
Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec
In-Reply-To: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>
References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>
Message-ID: 

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 Aug 26 14:40:48 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 26 Aug 2020 16:40:48 +0200
Subject: RFR: JDK-8235229: Compilation against a modular, multi-release JAR
 erroneous with --release
Message-ID: <4eb2c807-f81b-8d7d-aa1d-7463a99e578a@oracle.com>

Hi,

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.

Proposed webrev:
http://cr.openjdk.java.net/~jlahoda/8235229/webrev.00/

JBS:
https://bugs.openjdk.java.net/browse/JDK-8235229

How does this look?

Thanks,
     Jan

From jiefu at tencent.com  Wed Aug 26 15:45:50 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Wed, 26 Aug 2020 15:45:50 +0000
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to compile
In-Reply-To: <8347F2AB-62D4-41E4-825B-13577935557C@tencent.com>
References: <37F84883-F565-403A-A4C7-FD6A813DA6A3@tencent.com>
 <8347F2AB-62D4-41E4-825B-13577935557C@tencent.com>
Message-ID: <8DEF8AD6-A622-4731-87C7-934DFBF66E2D@tencent.com>

CC to Jan, the author of the code.

Please review it.

Thanks.
Best regards,
Jie

From: "jiefu(??)" 
Date: Tuesday, August 25, 2020 at 12:51 PM
To: "compiler-dev at openjdk.java.net" 
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to compile

Hi all,

May I get reviews for this fix?

JBS:    https://bugs.openjdk.java.net/browse/JDK-8252264
Webrev: http://cr.openjdk.java.net/~jiefu/8252264/webrev.00/

Thanks.
Best regards,
Jie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jonathan.gibbons at oracle.com  Wed Aug 26 16:51:44 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Aug 2020 09:51:44 -0700
Subject: RFR: JDK-8230918: j.l.NASE in javap
In-Reply-To: 
References: <44d101d5-3639-edef-7f3f-0ac9ac950e07@oracle.com>
 <2964f4aa-a55d-41f6-60d6-8f80ccabb8b5@oracle.com>
 
 
Message-ID: <45d344a4-2b0f-6dc2-bbd9-82d8742eb530@oracle.com>

+1

-- Jon

On 8/25/20 10:54 AM, Vicente Romero wrote:
> ping
>
> On 8/20/20 5:30 PM, Vicente Romero wrote:
>> Hi Jon,
>>
>> Thanks for the review, I have updated the review to [1] to address 
>> your comments,
>>
>> Vicente
>>
>> [1] http://cr.openjdk.java.net/~vromero/8230918/webrev.01/
>>
>>
>>
>> On 8/19/20 8:49 PM, Jonathan Gibbons wrote:
>>> Hi Vicente,
>>>
>>> It seems wrong to hijack an existing exception for an unrelated 
>>> use.? There's no IO condition that warrants the use of 
>>> `java.io.IOException`. The problem is that for better or worse, 
>>> javap cannot handle this probably-malformed class file. That 
>>> deserves some appropriate exception, and a new one if there is 
>>> nothing appropriate that is already available to use.
>>>
>>> -- Jon
>>>
>>> On 8/19/20 5:24 PM, Vicente Romero wrote:
>>>> Please review fix for [1] at [2]. The fix is making javac fail with 
>>>> an error message if an attribute has a length too big to be processed.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8230918
>>>> http://cr.openjdk.java.net/~vromero/8230918/webrev.00/
>>
>

From lahoda at gmail.com  Wed Aug 26 17:10:12 2020
From: lahoda at gmail.com (Jan Lahoda)
Date: Wed, 26 Aug 2020 19:10:12 +0200
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to
 compile
In-Reply-To: <8DEF8AD6-A622-4731-87C7-934DFBF66E2D@tencent.com>
References: <37F84883-F565-403A-A4C7-FD6A813DA6A3@tencent.com>
 <8347F2AB-62D4-41E4-825B-13577935557C@tencent.com>
 <8DEF8AD6-A622-4731-87C7-934DFBF66E2D@tencent.com>
Message-ID: <3FA16B36-E76E-47C0-8EAF-85AF698AC128@gmail.com>

Looks good, sorry for trouble.

Jan


26. srpna 2020 17:45:50 SEL?, "jiefu(??)"  napsal:
>CC to Jan, the author of the code.
>
>Please review it.
>
>Thanks.
>Best regards,
>Jie
>
>From: "jiefu(??)" 
>Date: Tuesday, August 25, 2020 at 12:51 PM
>To: "compiler-dev at openjdk.java.net" 
>Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to
>compile
>
>Hi all,
>
>May I get reviews for this fix?
>
>JBS:    https://bugs.openjdk.java.net/browse/JDK-8252264
>Webrev: http://cr.openjdk.java.net/~jiefu/8252264/webrev.00/
>
>Thanks.
>Best regards,
>Jie

-- 
Odesl?no aplikac? K-9 Mail ze syst?mu Android. Omluvte pros?m moji stru?nost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mandy.chung at oracle.com  Wed Aug 26 21:25:08 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 26 Aug 2020 14:25:08 -0700
Subject: RFR: JDK-8242451 : ensure semantics of non-capturing lambdas are
 preserved independent of execution mode
In-Reply-To: 
References: 
 <71c26ec5-7512-e5e0-349f-a488357677f1@oracle.com>
 
 
 
Message-ID: <1fd04e0e-b2df-7c4a-bc53-600e2fc2b281@oracle.com>



On 8/26/20 10:16 AM, Gilles Duboscq wrote:
> Hi Mandy,
>
> Thanks for your review.
> I have added a test as you suggested and switched to 
> `.descriptorString()`.
>
> https://cr.openjdk.java.net/~gdub/8242451/webrev.2/

Looks fine.??? This test is a javac test.? I'm including compiler-dev if 
anyone has any comment on it.

Mandy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jiefu at tencent.com  Wed Aug 26 23:16:42 2020
From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=)
Date: Wed, 26 Aug 2020 23:16:42 +0000
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to
 compile
Message-ID: 

Thanks Jan for your review.
Will push it later.

Best regards,
Jie

From: Jan Lahoda 
Date: Thursday, August 27, 2020 at 1:10 AM
To: "compiler-dev at openjdk.java.net" , "jiefu(??)" 
Cc: "jan.lahoda at oracle.com" 
Subject: Re: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to compile(Internet mail)

Looks good, sorry for trouble.

Jan

26. srpna 2020 17:45:50 SEL?, "jiefu(??)"  napsal:
CC to Jan, the author of the code.

Please review it.

Thanks.
Best regards,
Jie

From: "jiefu(??)" 
Date: Tuesday, August 25, 2020 at 12:51 PM
To: "compiler-dev at openjdk.java.net" 
Subject: RFR: 8252264: tools/javac/flags/LockedFlagClash.java fails to compile

Hi all,

May I get reviews for this fix?

JBS:    https://bugs.openjdk.java.net/browse/JDK-8252264
Webrev: http://cr.openjdk.java.net/~jiefu/8252264/webrev.00/

Thanks.
Best regards,
Jie

--
Odesl?no aplikac? K-9 Mail ze syst?mu Android. Omluvte pros?m moji stru?nost.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From joe.darcy at oracle.com  Wed Aug 26 23:40:47 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 26 Aug 2020 16:40:47 -0700
Subject: JDK 16 RFR of JDK-8251921: Expand default constructor warning to
 cover more cases
In-Reply-To: 
References: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>
 
Message-ID: <1ad2dc8d-ed0f-b9af-47ec-15612134d8a6@oracle.com>

On 8/25/2020 5:08 PM, Alex Buckley wrote:
> CSR looks good.

Added you as a reviewer.

>
> I note that no change is needed to the compiler message which was 
> ultimately chosen for this lint warning -- "class {0} in exported 
> package {1} declares no explicit constructors, thereby exposing a 
> default constructor to clients of module {2}" 
> (http://hg.openjdk.java.net/jdk/jdk/rev/f74d10596242#l5.8)

I concur the other message does not need to be updated; I checked that 
before sending out the review, but didn't note it.

Thanks for the thorough review,

-Joe


>
> Alex
>
> On 8/25/2020 4:31 PM, Joe Darcy wrote:
>> Hello,
>>
>> As a follow-up to JDK-8071961: "Add javac lint warning when a default 
>> constructor is created," Phil observed that there are cases in the 
>> JDK where a *protected* class has a default constructor appearing in 
>> the JDK. Please review the changes and CSR to augment the warning to 
>> cover both public and protected classes. For nested classes, the 
>> enclosing types must be either public or protected all the way up for 
>> the warning to be issued.
>>
>> ???? JDK-8251921: Expand default constructor warning to cover more cases
>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8252348
>> ???? webrev: http://cr.openjdk.java.net/~darcy/8251921.0/
>>
>> Patch below. Clean langtools test run with this change.
>>
>> Thanks,
>>
>> -Joe

From jan.lahoda at oracle.com  Thu Aug 27 15:36:47 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 27 Aug 2020 17:36:47 +0200
Subject: RFR: JDK-8252458: Test tools/javac/parser/JavacParserTest.java fails
 on Windows after JDK-8237041
Message-ID: <0f8f86f0-b66c-33ef-c05d-d9dc4f103d32@oracle.com>

Hi,

In the test for a recently committed JDK-8237041, the result of 
JCTree.toString() is compared with the expected output. But the 
JCTree.toString() uses platform-specific newlines, and the test is not 
compensating that, and fails.

The proposed solution is to normalize the output of JCTree.toString(), 
as other sub-tests of JavacParserTest do.

Proposed webrev:
http://cr.openjdk.java.net/~jlahoda/8252458/webrev.00/

JBS:
https://bugs.openjdk.java.net/browse/JDK-8252458

Thanks for any comments!

Jan

From vicente.romero at oracle.com  Thu Aug 27 16:19:51 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 27 Aug 2020 12:19:51 -0400
Subject: RFR: JDK-8252458: Test tools/javac/parser/JavacParserTest.java
 fails on Windows after JDK-8237041
In-Reply-To: <0f8f86f0-b66c-33ef-c05d-d9dc4f103d32@oracle.com>
References: <0f8f86f0-b66c-33ef-c05d-d9dc4f103d32@oracle.com>
Message-ID: <30da31b9-ce47-b73c-884e-3bd19106d3e7@oracle.com>

looks good,
Vicente

On 8/27/20 11:36 AM, Jan Lahoda wrote:
> Hi,
>
> In the test for a recently committed JDK-8237041, the result of 
> JCTree.toString() is compared with the expected output. But the 
> JCTree.toString() uses platform-specific newlines, and the test is not 
> compensating that, and fails.
>
> The proposed solution is to normalize the output of JCTree.toString(), 
> as other sub-tests of JavacParserTest do.
>
> Proposed webrev:
> http://cr.openjdk.java.net/~jlahoda/8252458/webrev.00/
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8252458
>
> Thanks for any comments!
>
> Jan


From jonathan.gibbons at oracle.com  Thu Aug 27 17:46:33 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 27 Aug 2020 10:46:33 -0700
Subject: JDK 16 RFR of JDK-8251921: Expand default constructor warning to
 cover more cases
In-Reply-To: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>
References: <7be01f2b-1495-35e0-e125-224b0a1d5bac@oracle.com>
Message-ID: <6d9b5591-4c8b-838c-ecd9-8ba361c8f4f5@oracle.com>

There's a possible minor typo:

146 public static class StaticBaryNest {

The extra "y" looks incorrect.

Otherwise OK,

-- Jon

On 8/25/20 4:31 PM, Joe Darcy wrote:
> Hello,
>
> As a follow-up to JDK-8071961: "Add javac lint warning when a default 
> constructor is created," Phil observed that there are cases in the JDK 
> where a *protected* class has a default constructor appearing in the 
> JDK. Please review the changes and CSR to augment the warning to cover 
> both public and protected classes. For nested classes, the enclosing 
> types must be either public or protected all the way up for the 
> warning to be issued.
>
> ??? JDK-8251921: Expand default constructor warning to cover more cases
> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8252348
> ??? webrev: http://cr.openjdk.java.net/~darcy/8251921.0/
>
> Patch below. Clean langtools test run with this change.
>
> Thanks,
>
> -Joe
>
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
> 2020-08-25 15:04:59.413000000 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
> 2020-08-25 15:04:58.685000000 -0700
> @@ -3835,7 +3835,7 @@
> ???????? if (lint.isEnabled(LintCategory.MISSING_EXPLICIT_CTOR) &&
> ???????????? ((c.flags() & (ENUM | RECORD)) == 0) &&
> ???????????? !c.isAnonymous() &&
> -??????????? ((c.flags() & PUBLIC) != 0) &&
> +??????????? ((c.flags() & (PUBLIC | PROTECTED)) != 0) &&
> ???????????? Feature.MODULES.allowedInSource(source)) {
> ???????????? NestingKind nestingKind = c.getNestingKind();
> ???????????? switch (nestingKind) {
> @@ -3844,10 +3844,10 @@
> ???????????????? case TOP_LEVEL -> {;} // No additional checks needed
> ???????????????? case MEMBER -> {
> ???????????????????? // For nested member classes, all the enclosing
> -??????????????????? // classes must be public.
> +??????????????????? // classes must be public or protected.
> ???????????????????? Symbol owner = c.owner;
> ???????????????????? while (owner != null && owner.kind == TYP) {
> -??????????????????????? if ((owner.flags() & PUBLIC) == 0)
> +??????????????????????? if ((owner.flags() & (PUBLIC | PROTECTED)) == 0)
> ???????????????????????????? return;
> ???????????????????????? owner = owner.owner;
> ???????????????????? }
> --- 
> old/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties 
> 2020-08-25 15:05:01.037000000 -0700
> +++ 
> new/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties 
> 2020-08-25 15:05:00.189000000 -0700
> @@ -183,7 +183,7 @@
> ???? Warn about issues related to classfile contents.
>
> ?javac.opt.Xlint.desc.missing-explicit-ctor=\
> -??? Warn about missing explicit constructors in public classes in 
> exported packages.
> +??? Warn about missing explicit constructors in public and protected 
> classes in exported packages.
>
> ?javac.opt.Xlint.desc.deprecation=\
> ???? Warn about use of deprecated items.
> --- 
> old/test/langtools/tools/javac/warnings/DefaultCtor/DefaultCtorWarningToolBox.java 
> 2020-08-25 15:05:02.313000000 -0700
> +++ 
> new/test/langtools/tools/javac/warnings/DefaultCtor/DefaultCtorWarningToolBox.java 
> 2020-08-25 15:05:01.597000000 -0700
> @@ -97,7 +97,9 @@
> ???????????? List.of("Foo.java:4:8: 
> compiler.warn.missing-explicit-ctor: pkg1.Foo, pkg1, mod",
> ???????????????????? "Foo.java:12:12: 
> compiler.warn.missing-explicit-ctor: pkg1.Foo.FooNest, pkg1, mod",
> ???????????????????? "Foo.java:16:19: 
> compiler.warn.missing-explicit-ctor: pkg1.Foo.StaticFooNest, pkg1, mod",
> -??????????????????? "3 warnings");
> +??? ??? ??? "Foo.java:25:15: compiler.warn.missing-explicit-ctor: 
> pkg1.Foo.ProtectedFooNest, pkg1, mod",
> +??? ??? ??? "Foo.java:27:19: compiler.warn.missing-explicit-ctor: 
> pkg1.Foo.ProtectedFooNest.ProtectedFooNestNest, pkg1, mod",
> +??????????????????? "5 warnings");
>
> ???????? // Warning enable,
> ???????? log = new JavacTask(tb)
> @@ -137,30 +139,34 @@
> ???????? class Bar {
>
> ???????????? // No explicit constructor; use a default.
> -??????????? public class FooNest {
> +??????????? public class BarNest {
> ???????????? }
>
> ???????????? // No explicit constructor; use a default.
> -??????????? public static class StaticFooNest {
> +??????????? public static class StaticBaryNest {
> +??????????? }
> +
> +??????????? // No explicit constructor; use a default.
> +??????????? protected class ProtectedBarNest {
> ???????????? }
>
> ???????????? // Package-access classes
>
> ???????????? // No explicit constructor; use a default.
> -??????????? /*package*/ class PkgFooNest {
> +??????????? /*package*/ class PkgBarNest {
> ???????????? }
>
> ???????????? // No explicit constructor; use a default.
> -??????????? /*package*/ static class PkgStaticFooNest {
> +??????????? /*package*/ static class PkgStaticBarNest {
> ???????????? }
> ???????????? // Private classes
>
> ???????????? // No explicit constructor; use a default.
> -??????????? private class PrvFooNest {
> +??????????? private class PrvBarNest {
> ???????????? }
>
> ???????????? // No explicit constructor; use a default.
> -??????????? private static class PrvStaticFooNest {
> +??????????? private static class PrvStaticBarNest {
> ???????????? }
> ???????? }
> ???????? """;
> @@ -190,10 +196,18 @@
> ???????????? public static class SuppressedStaticFooNest {
> ???????????? }
>
> +??????????? // No explicit constructor; use a default.
> +??????????? protected class ProtectedFooNest {
> +??????????????? // No explicit constructor; use a default.
> +??????????????? protected class ProtectedFooNestNest {}
> +??????????? }
> +
> ???????????? // Package-access classes
>
> ???????????? // No explicit constructor; use a default.
> ???????????? /*package*/ class PkgFooNest {
> +??????????????? // No explicit constructor; use a default.
> +??????????????? protected class PkgFooNestNest {}
> ???????????? }
>
> ???????????? // No explicit constructor; use a default.
> @@ -203,6 +217,8 @@
>
> ???????????? // No explicit constructor; use a default.
> ???????????? private class PrvFooNest {
> +??????????????? // No explicit constructor; use a default.
> +??????????????? protected class PrvFooNestNest {}
> ???????????? }
>
> ???????????? // No explicit constructor; use a default.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vicente.romero at oracle.com  Thu Aug 27 22:01:59 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 27 Aug 2020 18:01:59 -0400
Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec
In-Reply-To: 
References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>
 
Message-ID: <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com>

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 pavel.rappo at oracle.com  Fri Aug 28 09:31:53 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 28 Aug 2020 10:31:53 +0100
Subject: RFR [16] 8252172: Improve prettiness of printing HTML attributes by
 DocPretty
Message-ID: <18D7A315-6293-4B1E-B4F9-93D30465AD33@oracle.com>

Hello,

Please review the below change for https://bugs.openjdk.java.net/browse/JDK-8252172

  http://cr.openjdk.java.net/~prappo/8252172/webrev.00/

The crux of the change is this:

@@ -497,7 +492,7 @@ public class DocPretty implements DocTreeVisitor {
             List attrs = node.getAttributes();
             if (!attrs.isEmpty()) {
                 print(" ");
-                print(attrs);
+                print(attrs, " ");
                 DocTree last = node.getAttributes().get(attrs.size() - 1);
                 if (node.isSelfClosing() && last instanceof AttributeTree
                         && ((AttributeTree) last).getValueKind() == ValueKind.UNQUOTED)

That fixes printing out HTML attributes, which were otherwise squeezed together: for example, a=b c=d e=f was printed out as a=bc=de=f.
The rest of the change consists of a test for that and some opportunistic cleanup.

Thanks,
-Pavel


From jan.lahoda at oracle.com  Fri Aug 28 13:57:23 2020
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 28 Aug 2020 15:57:23 +0200
Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec
In-Reply-To: <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com>
References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>
 
 <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com>
Message-ID: <3448c708-c675-b844-18cf-31bb83447d06@oracle.com>

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 jonathan.gibbons at oracle.com  Fri Aug 28 14:20:58 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 28 Aug 2020 07:20:58 -0700
Subject: RFR [16] 8252172: Improve prettiness of printing HTML attributes
 by DocPretty
In-Reply-To: <18D7A315-6293-4B1E-B4F9-93D30465AD33@oracle.com>
References: <18D7A315-6293-4B1E-B4F9-93D30465AD33@oracle.com>
Message-ID: 

Looks good.

-- Jon

On 8/28/20 2:31 AM, Pavel Rappo wrote:
> Hello,
>
> Please review the below change for https://bugs.openjdk.java.net/browse/JDK-8252172
>
>    http://cr.openjdk.java.net/~prappo/8252172/webrev.00/
>
> The crux of the change is this:
>
> @@ -497,7 +492,7 @@ public class DocPretty implements DocTreeVisitor {
>               List attrs = node.getAttributes();
>               if (!attrs.isEmpty()) {
>                   print(" ");
> -                print(attrs);
> +                print(attrs, " ");
>                   DocTree last = node.getAttributes().get(attrs.size() - 1);
>                   if (node.isSelfClosing() && last instanceof AttributeTree
>                           && ((AttributeTree) last).getValueKind() == ValueKind.UNQUOTED)
>
> That fixes printing out HTML attributes, which were otherwise squeezed together: for example, a=b c=d e=f was printed out as a=bc=de=f.
> The rest of the change consists of a test for that and some opportunistic cleanup.
>
> Thanks,
> -Pavel
>

From vicente.romero at oracle.com  Fri Aug 28 16:20:04 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 28 Aug 2020 12:20:04 -0400
Subject: RFR: JDK-8230776: Javac throws AssertionError in jvm.Gen.visitExec
In-Reply-To: <3448c708-c675-b844-18cf-31bb83447d06@oracle.com>
References: <7908154d-6b7f-a3f9-5dca-02a6ab8db553@oracle.com>
 
 <383add9b-2a38-d93a-6a29-33fc84f48a2a@oracle.com>
 <3448c708-c675-b844-18cf-31bb83447d06@oracle.com>
Message-ID: <89c5f00b-b871-8bc8-16fe-f73c7638ad4f@oracle.com>

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 vicente.romero at oracle.com  Mon Aug 31 17:10:24 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 31 Aug 2020 13:10:24 -0400
Subject: RFR: JDK-8252307: javac rejects code with annotation applicable to
 fields
Message-ID: 

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/

