From prappo at openjdk.org  Fri Sep  1 09:22:39 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Sep 2023 09:22:39 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
Message-ID: <GLZKu6dTg0--f1INUQLIInxZQ4tRQPmelHwY_T-7xdU=.693ebf55-c684-4c59-834d-a5b88c275f4c@github.com>

On Thu, 31 Aug 2023 22:53:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is a bit terse. I'd suggest to split it in two lines, the first containing a statement of fact. (`An unknown tag has been reported.`), and the second containing a more complete helpful sentence, such as "Did you mistype it, or forget to add a custom tag, or register a taglet?"

Maybe terse is okay? Also, while JavaDoc/DocLint messages are not very consistent stylistically, they don't normally use "you". The only exception is for the suggestion to file a bug against the javadoc.

Another aspect is roles. Do you remember javadoc roles: author, user, reader? The tool is run by the user. Just like it would be strange to ask the author "forget to add a custom tag, or register a taglet?", it would be strange to ask the user "Did you mistype it?", unless of course they are the same person.

> I know I suggested posting the message early, but if you post it at the end, it could be more of a summary, such as "5 different tags were reported 105 times; did you ..."

Okay, I'll revert the position.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312792119

From prappo at openjdk.org  Fri Sep  1 09:25:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Sep 2023 09:25:38 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
Message-ID: <ancUmS3FdJsZKNHKzAiDfahdXC1Y0O1qM59lHWKmJgo=.13e0f451-f0c9-47eb-8db9-a7ce7cdeb20d@github.com>

On Thu, 31 Aug 2023 22:55:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
>> 
>> Before:
>> 
>> 
>> MyClass.java:4: warning: no main description
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: linkpain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> After:
>> 
>> 
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
>> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
>> 
>> For details, see the actual change.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 380:
> 
>> 378: 
>> 379:     public static List<String> suggestSimilar(Collection<String> knownTags, String unknownTag) {
>> 380:         final double MIN_SIMILARITY = 2.0 / 3;
> 
> Is there significance in `2.0 / 3` as compared to `0.667` etc

No. I can change it if you want me to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312795253

From prappo at openjdk.org  Fri Sep  1 09:34:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Sep 2023 09:34:38 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
Message-ID: <JDKy6-xl0UcV9E2lAid3OQS1KTtw44t7Y5UcIuEiM7w=.ecd82add-8157-4bbf-a0e1-01778c7783a3@github.com>

On Thu, 31 Aug 2023 22:59:57 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
>> 
>> Before:
>> 
>> 
>> MyClass.java:4: warning: no main description
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: linkpain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> After:
>> 
>> 
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
>> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
>> 
>> For details, see the actual change.
>
> test/langtools/jdk/javadoc/doclet/testUknownTags/TestUnknownTags.java line 125:
> 
>> 123:                 package x;
>> 124: 
>> 125:                 /**
> 
> :-) I bet the spelling checker in the IDE loves this :-)

Initially, I added a snarky code comment, but then removed it before publishing the PR. Something along the lines: pinch your nose and calm down your IDE.

FWIW, I note two things. Firstly, those tags in test come from these three sources:

 - actual typos in OpenJDK mainline
 - actual typos in codebase before it was open-sourced
 - made-up typos

Secondly, the significant portion of those tags are actual typos.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1312803934

From abimpoudis at openjdk.org  Fri Sep  1 10:12:10 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 10:12:10 GMT
Subject: RFR: 8314632: Intra-case dominance check fails in the presence of
 a guard [v2]
In-Reply-To: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
References: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
Message-ID: <zvSt3uI47PCgfaWYNl9FmVJSpfDw1bg3dwPGmIJ05qg=.bb64c8df-8486-4520-8dce-64c3736d0944@github.com>

> Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15515/files
  - new: https://git.openjdk.org/jdk/pull/15515/files/d3a194cf..b98fdea8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15515&range=00-01

  Stats: 23 lines in 1 file changed: 0 ins; 22 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15515/head:pull/15515

PR: https://git.openjdk.org/jdk/pull/15515

From abimpoudis at openjdk.org  Fri Sep  1 10:32:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 10:32:00 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
Message-ID: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>

The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:


switch (obj) {
   case Integer _ when ((Integer) obj) > 0:
   case String _ when !((String) obj).isEmpty():
      return 1;
   default:
      return -1;
}


This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).

Previously the code was translated into:


switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
    case 0:
        Integer _;
        if (!(true && ((Integer)obj) > 0)) {
            index$1 = 1;
            continue;
        }

    case 1 when !((String)obj).isEmpty():
        return 1;

    default:
        return -1;
}


This PR adjusts the translation into:


switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
case 0:
    Integer _;
    if (!(true && ((Integer)obj) > 0)) {
        index$1 = 1;
        continue;
    }
    return 1;

case 1:
    String _;
    if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
        index$1 = 2;
        continue;
    }
    return 1;
}

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

Commit messages:
 - 8314226: Series of colon-style fallthrough switch cases with guards compiled incorrectly

Changes: https://git.openjdk.org/jdk/pull/15532/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314226
  Stats: 105 lines in 2 files changed: 96 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From mcimadamore at openjdk.org  Fri Sep  1 10:53:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 10:53:37 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>

On Fri, 1 Sep 2023 10:02:20 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

So, as we discussed offline, type tests are normally enforced in the switch bootstrap. The first time we hit the test, we know we have some object and that the first label expects an Integer, so we test for that. But if the `when` clause fails, javac tells us to try again from the second label. Now, while the proposed code to the generated code looks ok - I wonder if this condition shouldn't instead be detected by the switch bootstrap: e.g. we're asking it to start again from a `case` which expects a `String`, but we really have some other Object on our hands, so that label index should never be returned by the switch bootstrap, which should either pick another applicable label index (if it exists) or just pick the default.

This would allow us to keep the generated code as is, and avoid introducing coupling between cases in the generated code.

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1702557839

From mcimadamore at openjdk.org  Fri Sep  1 10:58:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 10:58:39 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
In-Reply-To: <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>
Message-ID: <Zpuzl9kuHPhadGN2fXKSjhCUP1KUuvrZXYcOmts6QHo=.7f93fbf8-570b-46e2-9ebf-33816b795354@github.com>

On Fri, 1 Sep 2023 10:51:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> So, as we discussed offline, type tests are normally enforced in the switch bootstrap. The first time we hit the test, we know we have some object and that the first label expects an Integer, so we test for that. But if the `when` clause fails, javac tells us to try again from the second label. Now, while the proposed code to the generated code looks ok - I wonder if this condition shouldn't instead be detected by the switch bootstrap: e.g. we're asking it to start again from a `case` which expects a `String`, but we really have some other Object on our hands, so that label index should never be returned by the switch bootstrap, which should either pick another applicable label index (if it exists) or just pick the default.
> 
> This would allow us to keep the generated code as is, and avoid introducing coupling between cases in the generated code.

Btw, looking at the comment in SwitchBootstraps::createRepeatIndexSwitch, it seems that's already the case:


/*
     * Construct test chains for labels inside switch, to handle switch repeats:
     * switch (idx) {
     *     case 0 -> if (selector matches label[0]) return 0; else if (selector matches label[1]) return 1; else ...
     *     case 1 -> if (selector matches label[1]) return 1; else ...
     *     ...
     * }
     */

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1702563195

From mcimadamore at openjdk.org  Fri Sep  1 11:09:40 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 11:09:40 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
In-Reply-To: <Zpuzl9kuHPhadGN2fXKSjhCUP1KUuvrZXYcOmts6QHo=.7f93fbf8-570b-46e2-9ebf-33816b795354@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>
 <Zpuzl9kuHPhadGN2fXKSjhCUP1KUuvrZXYcOmts6QHo=.7f93fbf8-570b-46e2-9ebf-33816b795354@github.com>
Message-ID: <lcpDHaHsWE7UnyTqFJHh9GPXWXIcAFyaC38_CKw_ZJI=.f02c01a5-daa0-4c72-98ca-86442b2f3e71@github.com>

On Fri, 1 Sep 2023 10:55:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > So, as we discussed offline, type tests are normally enforced in the switch bootstrap. The first time we hit the test, we know we have some object and that the first label expects an Integer, so we test for that. But if the `when` clause fails, javac tells us to try again from the second label. Now, while the proposed code to the generated code looks ok - I wonder if this condition shouldn't instead be detected by the switch bootstrap: e.g. we're asking it to start again from a `case` which expects a `String`, but we really have some other Object on our hands, so that label index should never be returned by the switch bootstrap, which should either pick another applicable label index (if it exists) or just pick the default.
> > This would allow us to keep the generated code as is, and avoid introducing coupling between cases in the generated code.
> 
> Btw, looking at the comment in SwitchBootstraps::createRepeatIndexSwitch, it seems that's already the case:
> 
> ```
> /*
>      * Construct test chains for labels inside switch, to handle switch repeats:
>      * switch (idx) {
>      *     case 0 -> if (selector matches label[0]) return 0; else if (selector matches label[1]) return 1; else ...
>      *     case 1 -> if (selector matches label[1]) return 1; else ...
>      *     ...
>      * }
>      */
> ```

Also, in the original test here:
https://bugs.openjdk.org/browse/JDK-8314226

It seems to me that the problem is slightly different - e.g. the client is passing a String, but the `when` clause doesn't seem to be applied by javac. Which seems to conflict with the original generated code you report above: if javac currently generates this:


 case 1 when !((String)obj).isEmpty():
        return 1;


How can javac go ahead with this case, considering that the provided string (in the original test) is empty?

I wonder if the real issue is that there is no real `when` guard emitted for the second `case` (because of javac getting confused with cascading).

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1702573452

From mcimadamore at openjdk.org  Fri Sep  1 11:09:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 11:09:41 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
In-Reply-To: <lcpDHaHsWE7UnyTqFJHh9GPXWXIcAFyaC38_CKw_ZJI=.f02c01a5-daa0-4c72-98ca-86442b2f3e71@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>
 <Zpuzl9kuHPhadGN2fXKSjhCUP1KUuvrZXYcOmts6QHo=.7f93fbf8-570b-46e2-9ebf-33816b795354@github.com>
 <lcpDHaHsWE7UnyTqFJHh9GPXWXIcAFyaC38_CKw_ZJI=.f02c01a5-daa0-4c72-98ca-86442b2f3e71@github.com>
Message-ID: <JIHwOc4QdGgIwo4a_XWG70ofVXPTC4AzB-fOYw7Nm8E=.9bffd4e5-f756-47d4-a70e-2cc31a417dc5@github.com>

On Fri, 1 Sep 2023 11:04:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I wonder if the real issue is that there is no real `when` guard emitted for the second `case` (because of javac getting confused with cascading).

To be clear, IMHO the generated code should be:


switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
case 0:
    Integer _;
    if (!(true && ((Integer)obj) > 0)) {
        index$1 = 1;
        continue;
    }
    return 1;

case 1:
    String _;
    if (!(true && !((String)obj).isEmpty())) {
        index$1 = 2;
        continue;
    }
    return 1;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1702575831

From abimpoudis at openjdk.org  Fri Sep  1 11:33:32 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 11:33:32 GMT
Subject: RFR: 8314632: Intra-case dominance check fails in the presence of
 a guard [v3]
In-Reply-To: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
References: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
Message-ID: <Y5IcrWo0ngO8yGMZgol4ipu48U1PdsyEuXjVO3Px_Qw=.021f124f-18b3-42b6-939c-30eada5d6edd@github.com>

> Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Adjust out file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15515/files
  - new: https://git.openjdk.org/jdk/pull/15515/files/b98fdea8..8e8de824

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15515&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15515&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15515/head:pull/15515

PR: https://git.openjdk.org/jdk/pull/15515

From josiahnoel at gmail.com  Fri Sep  1 12:00:00 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 1 Sep 2023 08:00:00 -0400
Subject: [External] : Re: ModuleElement doesn't work with generated
 provides classes?
In-Reply-To: <CAJ_t5UY9wKV0NhSzdbv=yZK3UQ2uQ5isx03-dGNdUo1_FzDZRQ@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
 <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
 <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>
 <19baec94-8b9a-5824-7887-5ff2534a8892@oracle.com>
 <CAJ_t5UY9wKV0NhSzdbv=yZK3UQ2uQ5isx03-dGNdUo1_FzDZRQ@mail.gmail.com>
Message-ID: <CAJ_t5UagpwTT_yCgdhS11w-FoT=g9kf-ins8ijij+voFzn6goA@mail.gmail.com>

Or else if it's truly impossible to prevent the compilation error, a
warning should be added to getDirectives so that people know it has a
chance of breaking someone else's build in certain situations. I maintain a
couple of processors that generate service implementations in the last
round, so if people use one of them with another processor that uses
getDirectives it will break their build with this cryptic(to them) error.

On Mon, Aug 28, 2023 at 2:48?PM Josiah Noel <josiahnoel at gmail.com> wrote:

> I see it has been partially fixed in a later version, and that the problem
> only occurs if the service impl is generated in the last round. I can
> tolerate not being able to explicitly see the `provides` statements, but
> it's still a problem if merely calling `ModuleElement.getDirectives` causes
> compilation to fail if services are generated in the last round. Is there a
> way that we can make the behavior the same except not failing compilation?
> (Currently I can see the requires just fine but the compilation is doomed
> to fail)
>
> On Mon, Aug 28, 2023 at 2:05?PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> https://bugs.openjdk.org/browse/JDK-8315125
>>
>> -- Jon
>> On 8/28/23 8:50 AM, Jonathan Gibbons wrote:
>>
>> I'll file a JBS issue to track this further.
>>
>> -- Jon
>>
>>
>> On 8/28/23 8:35 AM, Josiah Noel wrote:
>>
>> Just tried explicitly adding a default constructor, but I still receive
>> the same error.
>>
>> On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> The following error message seems relevant:
>>>
>>> /M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41] the service implementation does not have
>>> a default constructor: io.avaje.modules.example.GeneratedProvider
>>>
>>> -- Jon
>>>
>>>
>>> On 8/26/23 1:04 PM, Josiah Noel wrote:
>>>
>>> As requested, I have created a simple example to replicate this issue. SentryMan/module-directive-bug:
>>> showcase annotation processing bug (github.com)
>>> <https://urldefense.com/v3/__https://github.com/SentryMan/module-directive-bug/tree/master__;!!ACWV5N9M2RV99hQ!O3CMUWVsFHaaU7b9D1x_-4ByzBUrMMF0KeTPmtdnqOC1hRhhZCBO0dODJwf1rZsapQpTYmYktzo5W_0TwANTUZuu$>
>>>
>>> On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com>
>>> wrote:
>>>
>>>> Say I got this module
>>>>
>>>> ```
>>>>
>>>> module nima.example {
>>>>
>>>> requires io.avaje.http.client;
>>>>
>>>> requires io.avaje.http.api;
>>>>
>>>> provides io.avaje.http.client.HttpClient.GeneratedComponent with
>>>>
>>>> com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>>>
>>>> }
>>>> ```
>>>> and I generate com.jojo.helidon.api.client.httpclient.
>>>> GeneratedHttpComponent in the last round of processing. When I get the
>>>> module element during normal processing and so much as call
>>>> `ModuleElement#getDirectives` and do nothing else, the processor will
>>>> correctly generate, but compilation will still fail.(if I take out the
>>>> module-info from the project it works though) I'm pretty sure it might have
>>>> to do with the fact that GeneratedHttpComponent is created in the last
>>>> round. Even so, not sure why it fails the compilation.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230901/bcfd0855/attachment-0001.htm>

From abimpoudis at openjdk.org  Fri Sep  1 12:24:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 12:24:40 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v2]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <Hty5dmlm0H8ZGVQwIJaC93bCcBBKhryHpxyB0vkHY9w=.30b85449-8227-4fb8-b033-ebdac9d65a15@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/09db2c7b..18f52d17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From abimpoudis at openjdk.org  Fri Sep  1 12:24:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 12:24:42 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly
In-Reply-To: <JIHwOc4QdGgIwo4a_XWG70ofVXPTC4AzB-fOYw7Nm8E=.9bffd4e5-f756-47d4-a70e-2cc31a417dc5@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <yoWK4ZxR0fhHNs6Aa_cdBskEwUpGcSkBr8M3jw8wA_E=.075541d9-0bb5-4fc2-942c-3ed13516f7e4@github.com>
 <Zpuzl9kuHPhadGN2fXKSjhCUP1KUuvrZXYcOmts6QHo=.7f93fbf8-570b-46e2-9ebf-33816b795354@github.com>
 <lcpDHaHsWE7UnyTqFJHh9GPXWXIcAFyaC38_CKw_ZJI=.f02c01a5-daa0-4c72-98ca-86442b2f3e71@github.com>
 <JIHwOc4QdGgIwo4a_XWG70ofVXPTC4AzB-fOYw7Nm8E=.9bffd4e5-f756-47d4-a70e-2cc31a417dc5@github.com>
Message-ID: <wSoLyvGKuUWOD0OYmfgYEb8NUo2kZZRroTOr4ox6YLA=.68827b6d-95e7-4dfc-9df2-4246c40c0fb4@github.com>

On Fri, 1 Sep 2023 11:06:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> > So, as we discussed offline, type tests are normally enforced in the switch bootstrap. The first time we hit the test, we know we have some object and that the first label expects an Integer, so we test for that. But if the `when` clause fails, javac tells us to try again from the second label. Now, while the proposed code to the generated code looks ok - I wonder if this condition shouldn't instead be detected by the switch bootstrap: e.g. we're asking it to start again from a `case` which expects a `String`, but we really have some other Object on our hands, so that label index should never be returned by the switch bootstrap, which should either pick another applicable label index (if it exists) or just pick the default.
>>> > This would allow us to keep the generated code as is, and avoid introducing coupling between cases in the generated code.
>>> 
>>> Btw, looking at the comment in SwitchBootstraps::createRepeatIndexSwitch, it seems that's already the case:
>>> 
>>> ```
>>> /*
>>>      * Construct test chains for labels inside switch, to handle switch repeats:
>>>      * switch (idx) {
>>>      *     case 0 -> if (selector matches label[0]) return 0; else if (selector matches label[1]) return 1; else ...
>>>      *     case 1 -> if (selector matches label[1]) return 1; else ...
>>>      *     ...
>>>      * }
>>>      */
>>> ```
>> 
>> Also, in the original test here:
>> https://bugs.openjdk.org/browse/JDK-8314226
>> 
>> It seems to me that the problem is slightly different - e.g. the client is passing a String, but the `when` clause doesn't seem to be applied by javac. Which seems to conflict with the original generated code you report above: if javac currently generates this:
>> 
>> 
>>  case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>> 
>> How can javac go ahead with this case, considering that the provided string (in the original test) is empty?
>> 
>> I wonder if the real issue is that there is no real `when` guard emitted for the second `case` (because of javac getting confused with cascading).
>
>> I wonder if the real issue is that there is no real `when` guard emitted for the second `case` (because of javac getting confused with cascading).
> 
> To be clear, IMHO the generated code should be:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!(true && !((String)obj).isEmpty())) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

I think you are right @mcimadamore. We do not need to generate the extraneous condition in the `if`. Removed and updated the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1702657415

From mcimadamore at openjdk.org  Fri Sep  1 12:58:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 12:58:41 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v2]
In-Reply-To: <Hty5dmlm0H8ZGVQwIJaC93bCcBBKhryHpxyB0vkHY9w=.30b85449-8227-4fb8-b033-ebdac9d65a15@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <Hty5dmlm0H8ZGVQwIJaC93bCcBBKhryHpxyB0vkHY9w=.30b85449-8227-4fb8-b033-ebdac9d65a15@github.com>
Message-ID: <ZcpfVWSEfDsxnTRBCn2Pc0aJMcYvVrwCmHkbrlESV4w=.be3aeec8-f0cc-47d7-99cd-d4a6730cac60@github.com>

On Fri, 1 Sep 2023 12:24:40 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 578:

> 576:                         }
> 577: 
> 578:                         boolean hasGuard = c.guard != null;

Can this declaration occur before the enclosing `if` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 590:

> 588:                         continueSwitch.target = tree;
> 589: 
> 590:                         if (previousC != null && hasGuard && previousCompletesNormally) {

What happens if there are three of them?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1312992491
PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1312992174

From abimpoudis at openjdk.org  Fri Sep  1 15:12:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 15:12:24 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v3]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <wGUbEo2mGFqX--31oXAlgmPNhFXfT-dgmEeBsNnE7UY=.220c25e3-955c-4264-9777-873fd3f397ad@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Perform patching in reverse order separately from the main loop in `handleSwitch`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/18f52d17..358f3deb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=01-02

  Stats: 82 lines in 2 files changed: 65 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From abimpoudis at openjdk.org  Fri Sep  1 15:12:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 15:12:30 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v2]
In-Reply-To: <ZcpfVWSEfDsxnTRBCn2Pc0aJMcYvVrwCmHkbrlESV4w=.be3aeec8-f0cc-47d7-99cd-d4a6730cac60@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <Hty5dmlm0H8ZGVQwIJaC93bCcBBKhryHpxyB0vkHY9w=.30b85449-8227-4fb8-b033-ebdac9d65a15@github.com>
 <ZcpfVWSEfDsxnTRBCn2Pc0aJMcYvVrwCmHkbrlESV4w=.be3aeec8-f0cc-47d7-99cd-d4a6730cac60@github.com>
Message-ID: <DCEbJQrkbXKbYv1Wq1w4JnhMlALiwpvMxIowDzjjGKs=.f386b2f1-89d6-452e-bdaf-83da10f44cc6@github.com>

On Fri, 1 Sep 2023 12:55:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 578:
> 
>> 576:                         }
>> 577: 
>> 578:                         boolean hasGuard = c.guard != null;
> 
> Can this declaration occur before the enclosing `if` ?

Extracted the inlined code in a separate step.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 590:
> 
>> 588:                         continueSwitch.target = tree;
>> 589: 
>> 590:                         if (previousC != null && hasGuard && previousCompletesNormally) {
> 
> What happens if there are three of them?

Correct. I refactored and extracted the code in a separate step.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1313160057
PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1313159596

From abimpoudis at openjdk.org  Fri Sep  1 15:17:15 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 15:17:15 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v4]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <dnQWkjNXd9V5I7iYgreB6uDcUlp45NPeMVzdVSi9h9A=.f4bb32af-5809-4476-a779-4007aaffd569@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/358f3deb..5b0bf6c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=02-03

  Stats: 15 lines in 1 file changed: 6 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From mcimadamore at openjdk.org  Fri Sep  1 15:44:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 15:44:41 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v4]
In-Reply-To: <dnQWkjNXd9V5I7iYgreB6uDcUlp45NPeMVzdVSi9h9A=.f4bb32af-5809-4476-a779-4007aaffd569@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <dnQWkjNXd9V5I7iYgreB6uDcUlp45NPeMVzdVSi9h9A=.f4bb32af-5809-4476-a779-4007aaffd569@github.com>
Message-ID: <dnb2k9JXQ55tkyd_INXEh8EhzO6pORLnGI0d64W-KwE=.83233071-a195-47b2-b4c8-e6a85f4c9bb1@github.com>

On Fri, 1 Sep 2023 15:17:15 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 546:

> 544:                 }
> 545: 
> 546:                 if (validCaseLabelList && !previousCompletesNormally || c.guard != null) {

I'd personally add parenthesis to make it obvious which test has priority

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 682:

> 680:     // }
> 681:     private static List<JCCase> patchCompletingNormallyCases(List<JCCase> cases) {
> 682:         ListBuffer<JCCase> newCases = new ListBuffer<>();

Do you need to create a new buffer? Isn't this method just side-effecting the various cases?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1313196920
PR Review Comment: https://git.openjdk.org/jdk/pull/15532#discussion_r1313195008

From jlahoda at openjdk.org  Fri Sep  1 15:52:01 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 1 Sep 2023 15:52:01 GMT
Subject: RFR: 8315534: Incorrect warnings about implicit annotation processing
Message-ID: <SRn8K7FnKyzh6Ba1CshJQwisLQPoLXtDj7dPnv-F6gE=.9832bede-156c-44d5-826b-af2724847791@github.com>

When the API client sets annotation processors using `CompilationTask.setProcessors` and then uses `JavacTask` to drive the compiler using the `analyze()` method, the `compiler.note.implicit.annotation.processing` note is printed even though the annotation processing is explicit.

This patch is attempting to solve that by marking all processing with explicit processors as explicit.

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

Commit messages:
 - 8315534: Incorrect warnings about implicit annotation processing

Changes: https://git.openjdk.org/jdk/pull/15540/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315534
  Stats: 102 lines in 2 files changed: 95 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15540/head:pull/15540

PR: https://git.openjdk.org/jdk/pull/15540

From abimpoudis at openjdk.org  Fri Sep  1 16:00:33 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 1 Sep 2023 16:00:33 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v5]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Make patchCompletingNormallyCases void returning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/5b0bf6c6..c46952b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=03-04

  Stats: 8 lines in 1 file changed: 1 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From mcimadamore at openjdk.org  Fri Sep  1 16:04:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 1 Sep 2023 16:04:46 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v5]
In-Reply-To: <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
Message-ID: <3WQAIvnB2NOarE0UGg2BXshZKnCaif0xY5rus7uEu5c=.f519e694-487b-4eff-8bdb-473514d05527@github.com>

On Fri, 1 Sep 2023 16:00:33 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make patchCompletingNormallyCases void returning

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15532#pullrequestreview-1607231677

From darcy at openjdk.org  Fri Sep  1 16:36:38 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 1 Sep 2023 16:36:38 GMT
Subject: RFR: 8315534: Incorrect warnings about implicit annotation
 processing
In-Reply-To: <SRn8K7FnKyzh6Ba1CshJQwisLQPoLXtDj7dPnv-F6gE=.9832bede-156c-44d5-826b-af2724847791@github.com>
References: <SRn8K7FnKyzh6Ba1CshJQwisLQPoLXtDj7dPnv-F6gE=.9832bede-156c-44d5-826b-af2724847791@github.com>
Message-ID: <jMCmI98DRqYP5NQzwZGOA4SYkNsiF53BVVS7mxRXLww=.326e6ee8-77ea-4fca-bc7d-8fe790e0423d@github.com>

On Fri, 1 Sep 2023 15:44:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When the API client sets annotation processors using `CompilationTask.setProcessors` and then uses `JavacTask` to drive the compiler using the `analyze()` method, the `compiler.note.implicit.annotation.processing` note is printed even though the annotation processing is explicit.
> 
> This patch is attempting to solve that by marking all processing with explicit processors as explicit.

Marked as reviewed by darcy (Reviewer).

Thanks for fixing this @lahodaj ; looks fine. I think this issue would be good to backport to 21u as well.

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

PR Review: https://git.openjdk.org/jdk/pull/15540#pullrequestreview-1607303339
PR Comment: https://git.openjdk.org/jdk/pull/15540#issuecomment-1703019401

From vromero at openjdk.org  Fri Sep  1 17:21:42 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Sep 2023 17:21:42 GMT
Subject: RFR: 8315452: Erroneous AST missing modifiers for partial input
In-Reply-To: <MwFsK7_HiGixnwbQDVdzAzLBWmjIc0nY4SmfxCFdiOU=.1360bc70-379d-46a7-8041-be30167e5e15@github.com>
References: <MwFsK7_HiGixnwbQDVdzAzLBWmjIc0nY4SmfxCFdiOU=.1360bc70-379d-46a7-8041-be30167e5e15@github.com>
Message-ID: <eqWR53ZumdFnpaKLTC6KBRzyFv48dfngVgjDHPfl-fk=.723f6d1e-fa8e-44be-a1ae-13475897c11a@github.com>

On Thu, 31 Aug 2023 14:25:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package test;
> public
> 
> 
> Before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), this was producing an AST which included the package clause + an ErroneousTree, which contained the `public` as partial modifiers.
> 
> After [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), the `public` is no longer included in the AST, and hence it is invisible for tools that operate on the AST.
> 
> My proposal is to return the `public` back to the AST. Seems that the problem from [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671) can be solved by breaking out of the outter loop, instead of inner loop, as it was before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), without affecting non-eof situations.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15517#pullrequestreview-1607374701

From vromero at openjdk.org  Fri Sep  1 17:38:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 1 Sep 2023 17:38:38 GMT
Subject: RFR: 8313323: javac -g on a java file which uses unnamed variable
 leads to ClassFormatError when launching that class
In-Reply-To: <br-nxJW7FzbxPvGl6V_5KTdhF6EsWUyexSbrn64birs=.bedda06e-0140-489b-90e3-4cb38d554409@github.com>
References: <br-nxJW7FzbxPvGl6V_5KTdhF6EsWUyexSbrn64birs=.bedda06e-0140-489b-90e3-4cb38d554409@github.com>
Message-ID: <J2wqrTKlKTxZLTsuJRHJvUouYrApIEZ8pJBR-yjN_7A=.8f3b5588-dc37-448f-9c40-6eb54c472034@github.com>

On Mon, 31 Jul 2023 06:52:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When unnamed (`_`) variables are present, and javac emits the `LocalVariableTable` (and potentially the `LocalVariableTypeTable`), it includes the unnamed variable in the table. As the variable does not have a name, the table contains an empty name, which is not allowed by the spec, see [1], [2], [3].
> 
> The proposed solution is to simply not include the unnamed variables in these tables, by not adding them to the internal `Code.varBuffer`.
> 
> [1] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.2.2
> [2] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.13
> [3] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.14

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15083#pullrequestreview-1607394800

From duke at openjdk.org  Sat Sep  2 17:55:59 2023
From: duke at openjdk.org (duke)
Date: Sat, 2 Sep 2023 17:55:59 GMT
Subject: Withdrawn: JDK-8264488: Improve warning for module names ending with
 digits
In-Reply-To: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
References: <2USP3dbkpNV93xz_MNy_y5SOZ9dq5oxBhtfGLXDQyS8=.e69f8446-d258-4f12-8cff-38c54656aa4e@github.com>
Message-ID: <mqqyIxWIvCsvp5PyddYiuMQEQ1-zlkCssIfl4E9sQgw=.6dae0bb0-d1a7-4db5-ad56-62e1bb25af73@github.com>

On Tue, 23 May 2023 12:25:07 GMT, Sebastian Stenzel <duke at openjdk.org> wrote:

> Since this is a rather trivial change, I didn't start a new discussion, as I deem this sufficiently discussed [back in early 2021](https://mail.openjdk.org/pipermail/discuss/2021-March/005779.html).

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14099

From jlahoda at openjdk.org  Mon Sep  4 07:20:57 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Sep 2023 07:20:57 GMT
Subject: Integrated: 8313323: javac -g on a java file which uses unnamed
 variable leads to ClassFormatError when launching that class
In-Reply-To: <br-nxJW7FzbxPvGl6V_5KTdhF6EsWUyexSbrn64birs=.bedda06e-0140-489b-90e3-4cb38d554409@github.com>
References: <br-nxJW7FzbxPvGl6V_5KTdhF6EsWUyexSbrn64birs=.bedda06e-0140-489b-90e3-4cb38d554409@github.com>
Message-ID: <KfrslB9eLsjFz3l7ZxrtGdn1ERKF2V8Io3atx6DlpG4=.eb3f3829-33fd-4caf-b54e-4c117ea187e0@github.com>

On Mon, 31 Jul 2023 06:52:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When unnamed (`_`) variables are present, and javac emits the `LocalVariableTable` (and potentially the `LocalVariableTypeTable`), it includes the unnamed variable in the table. As the variable does not have a name, the table contains an empty name, which is not allowed by the spec, see [1], [2], [3].
> 
> The proposed solution is to simply not include the unnamed variables in these tables, by not adding them to the internal `Code.varBuffer`.
> 
> [1] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.2.2
> [2] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.13
> [3] https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.14

This pull request has now been integrated.

Changeset: adfc1d6c
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/adfc1d6cd29181c729030d4cbafc8ecf349abab9
Stats:     51 lines in 2 files changed: 51 ins; 0 del; 0 mod

8313323: javac -g on a java file which uses unnamed variable leads to ClassFormatError when launching that class

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15083

From jlahoda at openjdk.org  Mon Sep  4 09:17:49 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Sep 2023 09:17:49 GMT
Subject: Integrated: 8315452: Erroneous AST missing modifiers for partial input
In-Reply-To: <MwFsK7_HiGixnwbQDVdzAzLBWmjIc0nY4SmfxCFdiOU=.1360bc70-379d-46a7-8041-be30167e5e15@github.com>
References: <MwFsK7_HiGixnwbQDVdzAzLBWmjIc0nY4SmfxCFdiOU=.1360bc70-379d-46a7-8041-be30167e5e15@github.com>
Message-ID: <IsSNpIHd-lPdwhxBs5et-FboZhKNjC-vPwEwh1b2DjY=.60a7cbfd-a63d-43dd-8f39-2238639ac28a@github.com>

On Thu, 31 Aug 2023 14:25:43 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package test;
> public
> 
> 
> Before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), this was producing an AST which included the package clause + an ErroneousTree, which contained the `public` as partial modifiers.
> 
> After [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), the `public` is no longer included in the AST, and hence it is invisible for tools that operate on the AST.
> 
> My proposal is to return the `public` back to the AST. Seems that the problem from [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671) can be solved by breaking out of the outter loop, instead of inner loop, as it was before [JDK-8305671](https://bugs.openjdk.org/browse/JDK-8305671), without affecting non-eof situations.

This pull request has now been integrated.

Changeset: 84425a62
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84425a62904f84601affc9710eefece88665374a
Stats:     64 lines in 2 files changed: 60 ins; 0 del; 4 mod

8315452: Erroneous AST missing modifiers for partial input

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15517

From jlahoda at openjdk.org  Mon Sep  4 10:09:47 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 4 Sep 2023 10:09:47 GMT
Subject: Integrated: 8315534: Incorrect warnings about implicit annotation
 processing
In-Reply-To: <SRn8K7FnKyzh6Ba1CshJQwisLQPoLXtDj7dPnv-F6gE=.9832bede-156c-44d5-826b-af2724847791@github.com>
References: <SRn8K7FnKyzh6Ba1CshJQwisLQPoLXtDj7dPnv-F6gE=.9832bede-156c-44d5-826b-af2724847791@github.com>
Message-ID: <qa-5ijXYxhkbfCCv5gCBuNwZlZWmg1-xw6hQEfgWn7s=.76144839-3d84-4752-b674-a3575b29ee4e@github.com>

On Fri, 1 Sep 2023 15:44:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When the API client sets annotation processors using `CompilationTask.setProcessors` and then uses `JavacTask` to drive the compiler using the `analyze()` method, the `compiler.note.implicit.annotation.processing` note is printed even though the annotation processing is explicit.
> 
> This patch is attempting to solve that by marking all processing with explicit processors as explicit.

This pull request has now been integrated.

Changeset: 94a74a0a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/94a74a0a450cad6080302bc1db15a1a564940bdd
Stats:     102 lines in 2 files changed: 95 ins; 2 del; 5 mod

8315534: Incorrect warnings about implicit annotation processing

Reviewed-by: darcy

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

PR: https://git.openjdk.org/jdk/pull/15540

From prappo at openjdk.org  Tue Sep  5 09:19:34 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 5 Sep 2023 09:19:34 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v2]
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <BOqXTRTNkw88IN4ja1Hdvh1oAukCa7bvjKmMmgEJ5LU=.2a8a8baa-aa33-4ee2-a156-b3a6c8001d6e@github.com>

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Shorten messages and simplify diagnostics
 - Merge branch 'master' into 8288660
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15494/files
  - new: https://git.openjdk.org/jdk/pull/15494/files/8b51f1ba..8d4724ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=00-01

  Stats: 4446 lines in 153 files changed: 3324 ins; 618 del; 504 mod
  Patch: https://git.openjdk.org/jdk/pull/15494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15494/head:pull/15494

PR: https://git.openjdk.org/jdk/pull/15494

From prappo at openjdk.org  Tue Sep  5 09:19:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 5 Sep 2023 09:19:36 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <tO0uQM5-oRPr7kYaeXXDtmNDjpDxFLM6M_rSVLZ1LTY=.f662083f-b0aa-40f4-8fac-c15e7d752b45@github.com>

On Wed, 30 Aug 2023 16:34:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

Full disclosure. Below is the test output. Note that some tags are not recognized as similar enough, and that's fine. Catering for them would complicate the code. 


testSimilarTags/src/x/MyClass.java:4: error: unknown tag. Mistyped @code or an unregistered custom tag?
 * {@cod}
   ^
testSimilarTags/src/x/MyClass.java:5: error: unknown tag. Unregistered custom tag?
 * {@codejdk.net.hosts.file}
   ^
testSimilarTags/src/x/MyClass.java:6: error: unknown tag. Mistyped @code or an unregistered custom tag?
 * {@coe}
   ^
testSimilarTags/src/x/MyClass.java:7: error: unknown tag. Mistyped @code or an unregistered custom tag?
 * {@cpde}
   ^
testSimilarTags/src/x/MyClass.java:8: error: unknown tag. Mistyped @code or an unregistered custom tag?
 * {@ocde}
   ^
testSimilarTags/src/x/MyClass.java:9: error: unknown tag. Mistyped @code or an unregistered custom tag?
 * {@ode}
   ^
testSimilarTags/src/x/MyClass.java:11: error: unknown tag. Mistyped @author or an unregistered custom tag?
 * @auther
   ^
testSimilarTags/src/x/MyClass.java:13: error: unknown tag. Mistyped @deprecated or an unregistered custom tag?
 * @Depricated
   ^
testSimilarTags/src/x/MyClass.java:14: error: unknown tag. Mistyped @deprecated or an unregistered custom tag?
 * @deprecation
   ^
testSimilarTags/src/x/MyClass.java:16: error: unknown tag. Mistyped @docRoot or an unregistered custom tag?
 * @DocRoot
   ^
testSimilarTags/src/x/MyClass.java:17: error: unknown tag. Mistyped @docRoot or an unregistered custom tag?
 * @dccRoot
   ^
testSimilarTags/src/x/MyClass.java:18: error: unknown tag. Mistyped @docRoot or an unregistered custom tag?
 * @docroot
   ^
testSimilarTags/src/x/MyClass.java:20: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @ecception
   ^
testSimilarTags/src/x/MyClass.java:21: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @excception
   ^
testSimilarTags/src/x/MyClass.java:22: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @exceptbion
   ^
testSimilarTags/src/x/MyClass.java:23: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @exceptino
   ^
testSimilarTags/src/x/MyClass.java:24: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @exceptions
   ^
testSimilarTags/src/x/MyClass.java:25: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @exceptoin
   ^
testSimilarTags/src/x/MyClass.java:26: error: unknown tag. Mistyped @exception or an unregistered custom tag?
 * @execption
   ^
testSimilarTags/src/x/MyClass.java:28: error: unknown tag. Mistyped @implNote or an unregistered custom tag?
 * @implnote
   ^
testSimilarTags/src/x/MyClass.java:30: error: unknown tag. Mistyped @inheritDoc or an unregistered custom tag?
 * @inheritdoc
   ^
testSimilarTags/src/x/MyClass.java:31: error: unknown tag. Mistyped @inheritDoc or an unregistered custom tag?
 * @inherotDoc
   ^
testSimilarTags/src/x/MyClass.java:32: error: unknown tag. Mistyped @inheritDoc or an unregistered custom tag?
 * @inheretdoc
   ^
testSimilarTags/src/x/MyClass.java:33: error: unknown tag. Mistyped @inheritDoc or an unregistered custom tag?
 * @inhertitDoc
   ^
testSimilarTags/src/x/MyClass.java:35: error: unknown tag. Mistyped @jvms or an unregistered custom tag?
 * @jvm
   ^
testSimilarTags/src/x/MyClass.java:36: error: unknown tag. Mistyped @jvms or an unregistered custom tag?
 * @jmvs
   ^
testSimilarTags/src/x/MyClass.java:38: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @Link
   ^
testSimilarTags/src/x/MyClass.java:39: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @linK
   ^
testSimilarTags/src/x/MyClass.java:40: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @linbk
   ^
testSimilarTags/src/x/MyClass.java:41: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @lini
   ^
testSimilarTags/src/x/MyClass.java:42: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @linke
   ^
testSimilarTags/src/x/MyClass.java:43: error: unknown tag. Mistyped @link or an unregistered custom tag?
 * @linked
   ^
testSimilarTags/src/x/MyClass.java:45: error: unknown tag. Mistyped @linkplain or an unregistered custom tag?
 * @linkplan
   ^
testSimilarTags/src/x/MyClass.java:47: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @params
   ^
testSimilarTags/src/x/MyClass.java:48: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @pararm
   ^
testSimilarTags/src/x/MyClass.java:49: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @parasm
   ^
testSimilarTags/src/x/MyClass.java:50: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @parem
   ^
testSimilarTags/src/x/MyClass.java:51: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @parm
   ^
testSimilarTags/src/x/MyClass.java:52: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @parma
   ^
testSimilarTags/src/x/MyClass.java:53: error: unknown tag. Mistyped @param or an unregistered custom tag?
 * @praam
   ^
testSimilarTags/src/x/MyClass.java:54: error: unknown tag. Unregistered custom tag?
 * @prarm
   ^
testSimilarTags/src/x/MyClass.java:56: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @Return
   ^
testSimilarTags/src/x/MyClass.java:57: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @eturn
   ^
testSimilarTags/src/x/MyClass.java:58: error: unknown tag. Unregistered custom tag?
 * @result
   ^
testSimilarTags/src/x/MyClass.java:59: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retrun
   ^
testSimilarTags/src/x/MyClass.java:60: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retuen
   ^
testSimilarTags/src/x/MyClass.java:61: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retun
   ^
testSimilarTags/src/x/MyClass.java:62: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retunr
   ^
testSimilarTags/src/x/MyClass.java:63: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retur
   ^
testSimilarTags/src/x/MyClass.java:64: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @returns
   ^
testSimilarTags/src/x/MyClass.java:65: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @returnss
   ^
testSimilarTags/src/x/MyClass.java:66: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @retursn
   ^
testSimilarTags/src/x/MyClass.java:67: error: unknown tag. Mistyped @return or an unregistered custom tag?
 * @rturn
   ^
testSimilarTags/src/x/MyClass.java:69: error: unknown tag. Mistyped @see or an unregistered custom tag?
 * @See
   ^
testSimilarTags/src/x/MyClass.java:70: error: unknown tag. Mistyped @see or an unregistered custom tag?
 * @gsee
   ^
testSimilarTags/src/x/MyClass.java:72: error: unknown tag. Mistyped @serialData or an unregistered custom tag?
 * @serialdata
   ^
testSimilarTags/src/x/MyClass.java:74: error: unknown tag. Mistyped @since or an unregistered custom tag?
 * @sinc
   ^
testSimilarTags/src/x/MyClass.java:75: error: unknown tag. Mistyped @since or an unregistered custom tag?
 * @sine
   ^
testSimilarTags/src/x/MyClass.java:77: error: unknown tag. Mistyped @systemProperty or an unregistered custom tag?
 * @systemproperty
   ^
testSimilarTags/src/x/MyClass.java:79: error: unknown tag. Mistyped @throws or an unregistered custom tag?
 * @thows
   ^
testSimilarTags/src/x/MyClass.java:80: error: unknown tag. Mistyped @throws or an unregistered custom tag?
 * @thrown
   ^
testSimilarTags/src/x/MyClass.java:81: error: unknown tag. Mistyped @throws or an unregistered custom tag?
 * @throwss
   ^

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

PR Comment: https://git.openjdk.org/jdk/pull/15494#issuecomment-1706242946

From jjg at openjdk.org  Tue Sep  5 18:16:43 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 5 Sep 2023 18:16:43 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v2]
In-Reply-To: <BOqXTRTNkw88IN4ja1Hdvh1oAukCa7bvjKmMmgEJ5LU=.2a8a8baa-aa33-4ee2-a156-b3a6c8001d6e@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <BOqXTRTNkw88IN4ja1Hdvh1oAukCa7bvjKmMmgEJ5LU=.2a8a8baa-aa33-4ee2-a156-b3a6c8001d6e@github.com>
Message-ID: <LMbgzdp0ldvo9udSBzvlG9Y4RSeUtcamzSugiQjTcLU=.228df9df-f9c8-46d6-b984-d6a533ed7427@github.com>

On Tue, 5 Sep 2023 09:19:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
>> 
>> Before:
>> 
>> 
>> MyClass.java:4: warning: no main description
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: linkpain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> After:
>> 
>> 
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
>> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
>> 
>> For details, see the actual change.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Shorten messages and simplify diagnostics
>  - Merge branch 'master' into 8288660
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 88:

> 86: dc.tag.start.unmatched = end tag missing: </{0}>
> 87: dc.tag.unknown = unknown tag. Unregistered custom tag?
> 88: dc.tag.unknown.with.hint = unknown tag. Mistyped @{0} or an unregistered custom tag?

"one of these days", we will come up with a general style guide for diagnostic messages, and the (mixed) use of phrases and sentences!

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

PR Review: https://git.openjdk.org/jdk/pull/15494#pullrequestreview-1611662596
PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1316235262

From jjg at openjdk.org  Tue Sep  5 18:16:44 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 5 Sep 2023 18:16:44 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v2]
In-Reply-To: <ancUmS3FdJsZKNHKzAiDfahdXC1Y0O1qM59lHWKmJgo=.13e0f451-f0c9-47eb-8db9-a7ce7cdeb20d@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <8_G5gpcVht07JAN_rgR2gNYrTJUtgmpsYKmLqsqlXJo=.7578edf6-119b-48e4-8e87-eb2dfd526433@github.com>
 <ancUmS3FdJsZKNHKzAiDfahdXC1Y0O1qM59lHWKmJgo=.13e0f451-f0c9-47eb-8db9-a7ce7cdeb20d@github.com>
Message-ID: <aOn5wP_zLgSZOKlBsP1ZfuCAb4dy4uRT8fmA1U2NkH0=.0df7fec2-8a5b-454b-9e29-bf0df30334fc@github.com>

On Fri, 1 Sep 2023 09:23:11 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 380:
>> 
>>> 378: 
>>> 379:     public static List<String> suggestSimilar(Collection<String> knownTags, String unknownTag) {
>>> 380:         final double MIN_SIMILARITY = 2.0 / 3;
>> 
>> Is there significance in `2.0 / 3` as compared to `0.667` etc
>
> No. I can change it if you want me to.

no biggie, except that the code makes you wonder at the implied specific precision here, as compared to a "simple" floating point number like `0.5` or even `0.75`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15494#discussion_r1316232957

From prappo at openjdk.org  Tue Sep  5 22:04:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 5 Sep 2023 22:04:08 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v3]
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <5voNLg_UY44sNw6miEOdLbSM19xWD7Gg_MoJ-eXmuIE=.800f1a7e-af8b-49b8-a336-36f84b0bb832@github.com>

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing tests
  
   - Uses different (locale-specific) resources for HTML and JavaDoc tags
   - Updates hardcoded test strings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15494/files
  - new: https://git.openjdk.org/jdk/pull/15494/files/8d4724ae..45b5aa4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=01-02

  Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15494/head:pull/15494

PR: https://git.openjdk.org/jdk/pull/15494

From prappo at openjdk.org  Tue Sep  5 22:21:26 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 5 Sep 2023 22:21:26 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v4]
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <UzLiKaHum84AtretqcT04JLHCgGt2K0DhAouyPElcg0=.f3525c65-0ca9-42e1-ad52-7885cab3e862@github.com>

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Name locale-specific resources better

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15494/files
  - new: https://git.openjdk.org/jdk/pull/15494/files/45b5aa4a..a07ecfda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15494&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/15494

From jjg at openjdk.org  Tue Sep  5 22:21:27 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 5 Sep 2023 22:21:27 GMT
Subject: RFR: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag [v4]
In-Reply-To: <UzLiKaHum84AtretqcT04JLHCgGt2K0DhAouyPElcg0=.f3525c65-0ca9-42e1-ad52-7885cab3e862@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
 <UzLiKaHum84AtretqcT04JLHCgGt2K0DhAouyPElcg0=.f3525c65-0ca9-42e1-ad52-7885cab3e862@github.com>
Message-ID: <W-SJXxOVLgICmI0JNnhTTblo06y9EXXEOq2TnHPHh4Y=.91198ec5-9b5f-49ae-97cc-2e37c24257a0@github.com>

On Tue, 5 Sep 2023 22:15:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
>> 
>> Before:
>> 
>> 
>> MyClass.java:4: warning: no main description
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: linkpain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> After:
>> 
>> 
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>>  * @implSpite {@linkpain Object#hashCode}}
>>    ^
>> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
>> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>>  * @implSpite {@linkpain Object#hashCode}}
>>               ^
>> MyClass.java:5: error: unknown tag: danger
>>  * @danger
>>    ^
>> 
>> 
>> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
>> 
>> For details, see the actual change.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Name locale-specific resources better

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15494#pullrequestreview-1612020741

From prappo at openjdk.org  Wed Sep  6 07:54:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 6 Sep 2023 07:54:53 GMT
Subject: Integrated: 8288660: JavaDoc should be more helpful if it doesn't
 recognize a tag
In-Reply-To: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
References: <yek7D-sIzrj5OOQ9n5qjyY_gjnNjziO89LS24Cn1QUk=.ad008e11-d8fd-43cb-86b1-77d71310f8fc@github.com>
Message-ID: <vHKHjUEU3uNryfQLoRX97IGNcQJNzKaT23krHgI2D3g=.20f20f5a-d205-4d17-a8d4-fd99687338e2@github.com>

On Wed, 30 Aug 2023 16:34:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR makes JavaDoc and DocLint produce more helpful diagnostic output when encounter an unknown tag.
> 
> Before:
> 
> 
> MyClass.java:4: warning: no main description
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: linkpain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> After:
> 
> 
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> MyClass.java:4: error: unknown tag: implSpite; the most similar tags are: implSpec, implNote
>  * @implSpite {@linkpain Object#hashCode}}
>    ^
> Note: An unknown tag has been reported. Mistyped? Forgot to add a custom tag or register a taglet?
> MyClass.java:4: error: unknown tag: linkpain; the most similar tags are: linkplain
>  * @implSpite {@linkpain Object#hashCode}}
>               ^
> MyClass.java:5: error: unknown tag: danger
>  * @danger
>    ^
> 
> 
> As you can see, the output has changed in two ways. Firstly, the tags that are similar to the unknown tag might be suggested. Secondly, an auxiliary note to help troubleshoot the unknown tag is provided. That note is provided once, close to the first reported unknown tag. This is done to not clutter the output in case multiple tags are reported.
> 
> For details, see the actual change.

This pull request has now been integrated.

Changeset: a01b3fb8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a01b3fb8e912eadd309e7036995656dd609629b2
Stats:     223 lines in 12 files changed: 191 ins; 10 del; 22 mod

8288660: JavaDoc should be more helpful if it doesn't recognize a tag

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk/pull/15494

From jlahoda at openjdk.org  Wed Sep  6 08:37:10 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 08:37:10 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with synchronized
 block
Message-ID: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>

Having code like:

    public static void main(String... args) {
        int i1 = 0 + switch (args.length) {
            default -> {
                synchronized (args) {
                    yield 1;
                }
            }
        };
    }


fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.

(When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

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

Commit messages:
 - 8315735: VerifyError when switch statement used with synchronized block

Changes: https://git.openjdk.org/jdk/pull/15584/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315735
  Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15584/head:pull/15584

PR: https://git.openjdk.org/jdk/pull/15584

From forax at openjdk.org  Wed Sep  6 09:40:40 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 6 Sep 2023 09:40:40 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block
In-Reply-To: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
Message-ID: <wWpA5Z5HotS8FQjtPa-piqInyN3HiXShHkX5WIXP8n0=.060ac1b6-645b-4fd8-b797-c9eecca33d73@github.com>

On Wed, 6 Sep 2023 08:29:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

Technically, the stack is not empty, you have the exception on top of the stack.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1292:

> 1290:                     hasTry[0] = true;
> 1291:                 }
> 1292: 

You can make this code slightly more efficient by using the fact that 'var' is enable to reference the type of an anonymous class.


private boolean hasTry(JCSwitchExpression tree) {
            var treeScanner = new TreeScanner() {
                private boolean hasTry;                
 
                @Override
                public void visitTry(JCTry tree) {
                    hasTry = true;
                }

                @Override
                public void visitSynchronized(JCSynchronized tree) {
                    hasTry = true;
                }

                @Override
                public void visitClassDef(JCClassDecl tree) {
                }
                @Override
                public void visitLambda(JCLambda tree) {
                }
            };
            treeScanner.scan(tree);
            return treeScanner.hasTry;
        }

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

PR Comment: https://git.openjdk.org/jdk/pull/15584#issuecomment-1708007664
PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317019442

From jlahoda at openjdk.org  Wed Sep  6 09:58:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 09:58:37 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block
In-Reply-To: <wWpA5Z5HotS8FQjtPa-piqInyN3HiXShHkX5WIXP8n0=.060ac1b6-645b-4fd8-b797-c9eecca33d73@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <wWpA5Z5HotS8FQjtPa-piqInyN3HiXShHkX5WIXP8n0=.060ac1b6-645b-4fd8-b797-c9eecca33d73@github.com>
Message-ID: <hbXjXPk2rJjhkLq2UYl7_htrquU5ii_dDIh5T5vyd_A=.ba0f9611-0324-4598-ab4d-95feecc91eff@github.com>

On Wed, 6 Sep 2023 09:37:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

> > (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)
> 
> Technically, the stack is not empty, you have the exception on top of the stack.

Right, I meant items that are on stack at the time the exception occurs are cleared.

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

PR Comment: https://git.openjdk.org/jdk/pull/15584#issuecomment-1708034631

From jlahoda at openjdk.org  Wed Sep  6 12:10:42 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 12:10:42 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v4]
In-Reply-To: <eUqIp_qMx2ADClBF1a5iDq-Gzp7ZiV_5N2TfUcDMeRE=.9ce80910-aa90-4328-b259-ea235a1d0b33@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <BomW5xzY94oong2efxwFr6i7LM-RD3BriiP1aYSityg=.fbeda4d4-fa31-4e58-a0a0-ef8c7a88a69e@github.com>
 <eUqIp_qMx2ADClBF1a5iDq-Gzp7ZiV_5N2TfUcDMeRE=.9ce80910-aa90-4328-b259-ea235a1d0b33@github.com>
Message-ID: <KaNlTch9OewkOSw4Oy7_DL_J6Dx7vlKHJqC8xmXdrXs=.de26b5fa-6ff2-4d9a-bb1d-a9ed2687995d@github.com>

On Thu, 24 Aug 2023 18:03:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorder javadoc tags.
>
> test/langtools/tools/javac/processing/model/util/elements/TestGetEnumConstantBody.java line 64:
> 
>> 62: 
>> 63:             for (TypeElement typeElt : ElementFilter.typesIn(typeRoot.getEnclosedElements()) ) {
>> 64:                 System.out.println("Testing type " + typeElt);
> 
> should the `println` invocations be removed?

This may be a matter of style, but logs like this inside tests may help to determine where is the problem when the test fails on a CI server.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14939#discussion_r1317181285

From vromero at openjdk.org  Wed Sep  6 15:06:44 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 15:06:44 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v5]
In-Reply-To: <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
 <5WtmPFDVRuC5FispF983wCv3IHI78xyScZXBFV7MJcc=.a87e550b-2af3-4760-b272-fc2b531496be@github.com>
Message-ID: <QOHbMe4zENYWdRO2FlYNceSS4QPexQd7YhcG1rJQRnU=.962e8cbb-c130-4870-8e2f-9e087b864874@github.com>

On Thu, 24 Aug 2023 20:08:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial implementation to get feedback on the proposed API.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor as suggested by jjg.

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14939#pullrequestreview-1613578233

From duke at openjdk.org  Wed Sep  6 15:44:34 2023
From: duke at openjdk.org (Qing Xiao)
Date: Wed, 6 Sep 2023 15:44:34 GMT
Subject: RFR: 8313422: test/langtools/tools/javac 147 test classes uses
 com.sun.tools.classfile library
Message-ID: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>

There are 147 tests to convert to the new Class-File API.

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

Commit messages:
 - Modified driver and util class in test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos
 - Migrated test/langtools/tools/javac/MethodParametersTest.java to use the new classfile API
 - Modified 2 test files
 - Modified 2 test files
 - Modified test files under test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos
 - Modified two test files
 - Modified all tests undertest/langtools/tools/javac/options
 - Modified some separate test files
 - Modified some separate test files
 - Modified some separate test files
 - ... and 21 more: https://git.openjdk.org/jdk/compare/8c9d091f...8a5f4c11

Changes: https://git.openjdk.org/jdk/pull/15112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313422
  Stats: 3695 lines in 144 files changed: 938 ins; 957 del; 1800 mod
  Patch: https://git.openjdk.org/jdk/pull/15112.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15112/head:pull/15112

PR: https://git.openjdk.org/jdk/pull/15112

From asotona at openjdk.org  Wed Sep  6 15:44:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Sep 2023 15:44:41 GMT
Subject: RFR: 8313422: test/langtools/tools/javac 147 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
References: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
Message-ID: <0h0iVyc81tJHlVe0x6Ukxw-7cQFJHhxCG3ZG8TDWtw0=.741f2823-96d6-459b-bf76-4f960fb97294@github.com>

On Tue, 1 Aug 2023 21:01:51 GMT, Qing Xiao <duke at openjdk.org> wrote:

> There are 147 tests to convert to the new Class-File API.

It is huge piece of work and it looks good.
Thanks!

test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java line 201:

> 199:                     table.add(TypeAnnotation.LocalVarTargetInfo.of(null, null, d.lvarIndex()[idx]));
> 200:                 p = TypeAnnotation.TargetInfo.ofResourceVariable(table);
> 201:             }

Filling missing labels with null is not ideal.
All such unsupported cases should directly throw an exception to indicate invalid state of the test.
BTW silent acceptance of null labels by TypeAnnotation.TargetInfo factory methods is a bug.

test/langtools/tools/javac/diags/CheckResourceKeys.java line 501:

> 499:             ClassModel cm = Classfile.of().parse(in.readAllBytes());
> 500:             for (int i = 1; i < cm.constantPool().entryCount(); ++i) {
> 501:                 if (cm.constantPool().entryByIndex(i) instanceof Utf8Entry entry) {

The same iteration issue as in the RecordCompilationTests

test/langtools/tools/javac/modules/IncubatingTest.java line 276:

> 274:             }
> 275:             cb.with(res);
> 276:         });

This is the same transformation pattern (dropping and then end handler).

test/langtools/tools/javac/modules/JavaBaseTest.java line 249:

> 247:             }
> 248:             cb.with(modAttr2);
> 249:         });

The same case as in OpenModulesTest

test/langtools/tools/javac/modules/OpenModulesTest.java line 257:

> 255:             }
> 256:             classBuilder.with(newModule);
> 257:         });

FYI: this pattern can replaced with:

Classfile.of().transform(miClass, ClassTransform.dropping(ce -> ce instanceof ModuleAttribute).andThen(ClassTransform.endHandler(classBuilder -> classBuilder.with(newModule))));

Positive impact is re-used constant pool from the original classfile and so other attributes are not expanded. However we are missing `Classfile::transformTo` method in the API.

test/langtools/tools/javac/records/RecordCompilationTests.java line 1280:

> 1278:                     ClassModel classFile = Classfile.of().parse(fileEntry.toPath());
> 1279:                     for (int i = 1; i < classFile.constantPool().entryCount(); ++i) {
> 1280:                         if (classFile.constantPool().entryByIndex(i) instanceof FieldRefEntry fieldRefEntry) {

I've identified iteration over CP entries is problematic in the Classfile API yet, see:
https://mail.openjdk.org/pipermail/classfile-api-dev/2023-August/000399.html

Here the int i must be incremented by the entry::width or the iteration will fail on double-slot entries (long and double).

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

PR Comment: https://git.openjdk.org/jdk/pull/15112#issuecomment-1702760128
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1313007137
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1291109139
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1291120151
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1288215435
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1288212904
PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1291100895

From asotona at openjdk.org  Wed Sep  6 15:44:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 6 Sep 2023 15:44:42 GMT
Subject: RFR: 8313422: test/langtools/tools/javac 147 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <0h0iVyc81tJHlVe0x6Ukxw-7cQFJHhxCG3ZG8TDWtw0=.741f2823-96d6-459b-bf76-4f960fb97294@github.com>
References: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
 <0h0iVyc81tJHlVe0x6Ukxw-7cQFJHhxCG3ZG8TDWtw0=.741f2823-96d6-459b-bf76-4f960fb97294@github.com>
Message-ID: <DgI6dAljbC3ZpmW_taRI1iVA6RjM2LY5PoqveqP3qDA=.8ca3badf-6c49-4108-b283-6c212b8c9f68@github.com>

On Fri, 1 Sep 2023 13:09:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are 147 tests to convert to the new Class-File API.
>
> test/langtools/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java line 201:
> 
>> 199:                     table.add(TypeAnnotation.LocalVarTargetInfo.of(null, null, d.lvarIndex()[idx]));
>> 200:                 p = TypeAnnotation.TargetInfo.ofResourceVariable(table);
>> 201:             }
> 
> Filling missing labels with null is not ideal.
> All such unsupported cases should directly throw an exception to indicate invalid state of the test.
> BTW silent acceptance of null labels by TypeAnnotation.TargetInfo factory methods is a bug.

FYI: I've filled [bug #8315541](https://bugs.openjdk.org/browse/JDK-8315541)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1313033243

From duke at openjdk.org  Wed Sep  6 15:44:44 2023
From: duke at openjdk.org (Qing Xiao)
Date: Wed, 6 Sep 2023 15:44:44 GMT
Subject: RFR: 8313422: test/langtools/tools/javac 147 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <0h0iVyc81tJHlVe0x6Ukxw-7cQFJHhxCG3ZG8TDWtw0=.741f2823-96d6-459b-bf76-4f960fb97294@github.com>
References: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
 <0h0iVyc81tJHlVe0x6Ukxw-7cQFJHhxCG3ZG8TDWtw0=.741f2823-96d6-459b-bf76-4f960fb97294@github.com>
Message-ID: <jWIrK5d__EIYOW8hkNEjil4E0c9BqxvC0TzQ5mYJMc4=.174c7ddd-677f-414b-8344-793a11a5543b@github.com>

On Wed, 9 Aug 2023 09:30:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> There are 147 tests to convert to the new Class-File API.
>
> test/langtools/tools/javac/modules/OpenModulesTest.java line 257:
> 
>> 255:             }
>> 256:             classBuilder.with(newModule);
>> 257:         });
> 
> FYI: this pattern can replaced with:
> 
> Classfile.of().transform(miClass, ClassTransform.dropping(ce -> ce instanceof ModuleAttribute).andThen(ClassTransform.endHandler(classBuilder -> classBuilder.with(newModule))));
> 
> Positive impact is re-used constant pool from the original classfile and so other attributes are not expanded. However we are missing `Classfile::transformTo` method in the API.

You are right. Will update in the next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15112#discussion_r1290240010

From vromero at openjdk.org  Wed Sep  6 18:46:37 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 18:46:37 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block
In-Reply-To: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
Message-ID: <zJZw14d4Sno03IeD2E9FRSrjxAo7Ih7sLPBnRVkL2jo=.d97a78b3-77d9-4198-a4ee-72671527cd8f@github.com>

On Wed, 6 Sep 2023 08:29:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Having code like:
> 
>     public static void main(String... args) {
>         int i1 = 0 + switch (args.length) {
>             default -> {
>                 synchronized (args) {
>                     yield 1;
>                 }
>             }
>         };
>     }
> 
> 
> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
> 
> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

looks good, please consider Remi's suggestion, seems like a nice refactoring

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15584#pullrequestreview-1613992684

From vromero at openjdk.org  Wed Sep  6 18:46:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 18:46:40 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block
In-Reply-To: <wWpA5Z5HotS8FQjtPa-piqInyN3HiXShHkX5WIXP8n0=.060ac1b6-645b-4fd8-b797-c9eecca33d73@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <wWpA5Z5HotS8FQjtPa-piqInyN3HiXShHkX5WIXP8n0=.060ac1b6-645b-4fd8-b797-c9eecca33d73@github.com>
Message-ID: <nh6csRFAWpihRS1JixThKB8P0XjgPJTi3cwo1zZG_2Y=.99b04164-fbb5-4194-9cc5-cc2906e1f9b7@github.com>

On Wed, 6 Sep 2023 09:36:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Having code like:
>> 
>>     public static void main(String... args) {
>>         int i1 = 0 + switch (args.length) {
>>             default -> {
>>                 synchronized (args) {
>>                     yield 1;
>>                 }
>>             }
>>         };
>>     }
>> 
>> 
>> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
>> 
>> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1292:
> 
>> 1290:                     hasTry[0] = true;
>> 1291:                 }
>> 1292: 
> 
> You can make this code slightly more efficient by using the fact that 'var' is enable to reference the type of an anonymous class.
> 
> 
> private boolean hasTry(JCSwitchExpression tree) {
>             var treeScanner = new TreeScanner() {
>                 private boolean hasTry;                
>  
>                 @Override
>                 public void visitTry(JCTry tree) {
>                     hasTry = true;
>                 }
> 
>                 @Override
>                 public void visitSynchronized(JCSynchronized tree) {
>                     hasTry = true;
>                 }
> 
>                 @Override
>                 public void visitClassDef(JCClassDecl tree) {
>                 }
>                 @Override
>                 public void visitLambda(JCLambda tree) {
>                 }
>             };
>             treeScanner.scan(tree);
>             return treeScanner.hasTry;
>         }

nice suggestion

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317686885

From jlahoda at openjdk.org  Wed Sep  6 18:58:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 18:58:19 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
Message-ID: <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>

> Having code like:
> 
>     public static void main(String... args) {
>         int i1 = 0 + switch (args.length) {
>             default -> {
>                 synchronized (args) {
>                     yield 1;
>                 }
>             }
>         };
>     }
> 
> 
> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
> 
> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15584/files
  - new: https://git.openjdk.org/jdk/pull/15584/files/44d6563f..26e29fe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15584&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15584&range=00-01

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15584/head:pull/15584

PR: https://git.openjdk.org/jdk/pull/15584

From duke at openjdk.org  Wed Sep  6 19:19:45 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 6 Sep 2023 19:19:45 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
Message-ID: <NzDGpE4FxbJuAyqqWsK_sSUajWRKyyeBfxxZh3aDuUM=.47685516-6d21-49c7-9937-bfa07759ec74@github.com>

On Wed, 6 Sep 2023 18:58:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Having code like:
>> 
>>     public static void main(String... args) {
>>         int i1 = 0 + switch (args.length) {
>>             default -> {
>>                 synchronized (args) {
>>                     yield 1;
>>                 }
>>             }
>>         };
>>     }
>> 
>> 
>> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
>> 
>> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1281:

> 1279:     //where:
> 1280:         private boolean hasTry(JCSwitchExpression tree) {
> 1281:             var scan = new TreeScanner() {

I?think `scanner` might?be a?better?name for?this:
Suggestion:

            var scanner = new TreeScanner() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317721431

From forax at openjdk.org  Wed Sep  6 19:50:42 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 6 Sep 2023 19:50:42 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <NzDGpE4FxbJuAyqqWsK_sSUajWRKyyeBfxxZh3aDuUM=.47685516-6d21-49c7-9937-bfa07759ec74@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
 <NzDGpE4FxbJuAyqqWsK_sSUajWRKyyeBfxxZh3aDuUM=.47685516-6d21-49c7-9937-bfa07759ec74@github.com>
Message-ID: <OOlLuZQ-wZzLyf6w9_VvcICHcvcpcwzX7fOT5aRwsgQ=.263e4f61-16b0-49bc-8137-10cf3a808484@github.com>

On Wed, 6 Sep 2023 19:16:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1281:
> 
>> 1279:     //where:
>> 1280:         private boolean hasTry(JCSwitchExpression tree) {
>> 1281:             var scan = new TreeScanner() {
> 
> I?think `scanner` might?be a?better?name for?this:
> Suggestion:
> 
>             var scanner = new TreeScanner() {

I agree, the first guideline of the excellent guide written by Stuart Marks about the usage of 'var' is "Choose variable names that provide useful information [1].

[1] https://openjdk.org/projects/amber/guides/lvti-style-guide#G1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317750801

From vromero at openjdk.org  Wed Sep  6 20:00:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 20:00:51 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

src/jdk.jdeps/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java line 134:

> 132:     private ClassWriter classWriter;
> 133:     private Map<Integer, List<Note>> pcMap;
> 134:     private CodeAttribute lr;

nit: name `lr` doesn't relate much to the type of the field

test/langtools/tools/javap/8260403/T8260403.java line 42:

> 40:                 new String[]{"-c", System.getProperty("test.classes") + "/InvalidSignature.class"},
> 41:                 new PrintWriter(sw));
> 42:         System.out.println(sw);

is this for debug purpose only?

test/langtools/tools/javap/malformed/MalformedTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

isn't this test testing the same as: `test/langtools/tools/javap/8260403/T8260403.java`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317756417
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317759719
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317761623

From vromero at openjdk.org  Wed Sep  6 20:04:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 20:04:40 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
Message-ID: <mgaF9UwHQbzc4oHuSXNbOswX4YhnXAMAzEPMYMZZJkE=.5a73596d-0739-4930-bc9e-b47db7b6a1cd@github.com>

On Wed, 6 Sep 2023 18:58:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Having code like:
>> 
>>     public static void main(String... args) {
>>         int i1 = 0 + switch (args.length) {
>>             default -> {
>>                 synchronized (args) {
>>                     yield 1;
>>                 }
>>             }
>>         };
>>     }
>> 
>> 
>> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
>> 
>> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15584#pullrequestreview-1614120200

From jlahoda at openjdk.org  Wed Sep  6 20:35:18 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 20:35:18 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v3]
In-Reply-To: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
Message-ID: <SfAAr2xkXUhjQcRh8Fotae6c16cP-zY7AzVOoshRzfY=.cec7397b-8049-465b-9984-c121fcc46df4@github.com>

> Having code like:
> 
>     public static void main(String... args) {
>         int i1 = 0 + switch (args.length) {
>             default -> {
>                 synchronized (args) {
>                     yield 1;
>                 }
>             }
>         };
>     }
> 
> 
> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
> 
> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Improving readability by improving naming.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15584/files
  - new: https://git.openjdk.org/jdk/pull/15584/files/26e29fe0..b1a04495

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15584&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15584&range=01-02

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15584/head:pull/15584

PR: https://git.openjdk.org/jdk/pull/15584

From jlahoda at openjdk.org  Wed Sep  6 20:35:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 6 Sep 2023 20:35:37 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <OOlLuZQ-wZzLyf6w9_VvcICHcvcpcwzX7fOT5aRwsgQ=.263e4f61-16b0-49bc-8137-10cf3a808484@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
 <NzDGpE4FxbJuAyqqWsK_sSUajWRKyyeBfxxZh3aDuUM=.47685516-6d21-49c7-9937-bfa07759ec74@github.com>
 <OOlLuZQ-wZzLyf6w9_VvcICHcvcpcwzX7fOT5aRwsgQ=.263e4f61-16b0-49bc-8137-10cf3a808484@github.com>
Message-ID: <NFqyVpE_C_BvAYeJUxT5W4OsF28RecxrWFjkZJ5X2CI=.c81b09ba-77fa-4651-a6ba-519c3a88bfd7@github.com>

On Wed, 6 Sep 2023 19:47:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1281:
>> 
>>> 1279:     //where:
>>> 1280:         private boolean hasTry(JCSwitchExpression tree) {
>>> 1281:             var scan = new TreeScanner() {
>> 
>> I?think `scanner` might?be a?better?name for?this:
>> Suggestion:
>> 
>>             var scanner = new TreeScanner() {
>
> I agree, the first guideline of the excellent guide written by Stuart Marks about the usage of 'var' is "Choose variable names that provide useful information [1].
> 
> [1] https://openjdk.org/projects/amber/guides/lvti-style-guide#G1

To be honest, I don't see a big difference between "scan", "scanner" and "treeScanner" - these describe the type of the variable, but not its purpose. So, I've used `hasTryScanner`, which conveys the purpose as well. Not a big reason to use less readable tricks with anonymous and var either - javac normally uses local classes to perform tasks like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317803699

From forax at openjdk.org  Wed Sep  6 21:17:40 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 6 Sep 2023 21:17:40 GMT
Subject: RFR: 8315735: VerifyError when switch statement used with
 synchronized block [v2]
In-Reply-To: <NFqyVpE_C_BvAYeJUxT5W4OsF28RecxrWFjkZJ5X2CI=.c81b09ba-77fa-4651-a6ba-519c3a88bfd7@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
 <KtAH14IvYE6pcPGvtYlBFB8CQ_3UUTzmEqu0Z_Tytv4=.596297bf-e5e4-4024-8728-e435a721a678@github.com>
 <NzDGpE4FxbJuAyqqWsK_sSUajWRKyyeBfxxZh3aDuUM=.47685516-6d21-49c7-9937-bfa07759ec74@github.com>
 <OOlLuZQ-wZzLyf6w9_VvcICHcvcpcwzX7fOT5aRwsgQ=.263e4f61-16b0-49bc-8137-10cf3a808484@github.com>
 <NFqyVpE_C_BvAYeJUxT5W4OsF28RecxrWFjkZJ5X2CI=.c81b09ba-77fa-4651-a6ba-519c3a88bfd7@github.com>
Message-ID: <oHdttkBJyvj3P5T3ewSstkY-qvL1-FZkigNLazyci2c=.d44679c5-6779-4b1f-92f9-c3321fbaf510@github.com>

On Wed, 6 Sep 2023 20:33:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I agree, the first guideline of the excellent guide written by Stuart Marks about the usage of 'var' is "Choose variable names that provide useful information [1].
>> 
>> [1] https://openjdk.org/projects/amber/guides/lvti-style-guide#G1
>
> To be honest, I don't see a big difference between "scan", "scanner" and "treeScanner" - these describe the type of the variable, but not its purpose. So, I've used `hasTryScanner`, which conveys the purpose as well. Not a big reason to use less readable tricks with anonymous and var either - javac normally uses local classes to perform tasks like this.

I agree, that we should not spend too much time on that code.
At the same time, `scan.scan(...)` is not very readable, I believe that `scanner` or `treeScanner` are better names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15584#discussion_r1317840041

From vromero at openjdk.org  Wed Sep  6 23:15:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Sep 2023 23:15:50 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <gKtm-lqFYzIsQOpCDD2s_uu8RgrdYvHtBlt7JbddvvI=.56e8becf-c792-48d6-a084-4ffd11818563@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

src/jdk.jdeps/share/classes/com/sun/tools/javap/CodeWriter.java line 89:

> 87:                 ++n;  // for 'this'
> 88:             argCount = Integer.toString(n);
> 89:         } catch (ConstantPoolException e) {

nice clean-up

src/jdk.jdeps/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java line 46:

> 44:  *  deletion without notice.</b>
> 45:  */
> 46: public class LocalVariableTableWriter extends  InstructionDetailWriter {

nit: two spaces between `extends` and `InstructionDetailWriter`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317835882
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1317915971

From acobbs at openjdk.org  Thu Sep  7 00:29:11 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 7 Sep 2023 00:29:11 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v12]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <NpScev1WYvjPPID_xiRbWFxScNF4nN27BFOK0VvyQJY=.a16938d9-785c-4e88-ade2-c0ee184365c9@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into SuperInit
 - Eliminate "isSelfCall" flag, which is now made obsolete by "ctorPrologue".
 - Merge branch 'master' into SuperInit
 - Create and cache a single instance of the oft-used SuperThisChecker.
 - Add unit test verifying super() can't appear inside a lambda.
 - Use TreeInfo.isConstructor() for detecting constructors.
 - Merge branch 'master' into SuperInit
 - Fix mistake in previous merge commit 80ba6be4.
 - Merge branch 'master' into SuperInit
 - Rename unit test to be consistent with other feature exampless.
 - ... and 21 more: https://git.openjdk.org/jdk/compare/5cbff246...4ff4c5c5

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=11
  Stats: 1500 lines in 27 files changed: 1174 ins; 214 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From acobbs at openjdk.org  Thu Sep  7 00:31:47 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 7 Sep 2023 00:31:47 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v11]
In-Reply-To: <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <RkivlLM6SydVKh0l8QNsytGjsBq19Cur-N1Mds2YMpY=.5c00bdc7-1461-4e57-af92-715db1c1c8d2@github.com>
Message-ID: <Pg3MqSCb9f7h4xVoLIQalfb7-7NlX5Mn-BJSfSLTb4k=.713b85d8-4c9a-44b8-b1f9-5ebeb7287029@github.com>

On Sat, 8 Jul 2023 15:46:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into SuperInit
>  - Create and cache a single instance of the oft-used SuperThisChecker.
>  - Add unit test verifying super() can't appear inside a lambda.
>  - Use TreeInfo.isConstructor() for detecting constructors.
>  - Merge branch 'master' into SuperInit
>  - Fix mistake in previous merge commit 80ba6be4.
>  - Merge branch 'master' into SuperInit
>  - Rename unit test to be consistent with other feature exampless.
>  - Update unit test after merged-in commit eaa80ad08.
>  - Add unit tests with local class decl's prior to super().
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/4a1fcb60...e2f88137

Regarding the latest update: In some cases the compiler was treating code before `super()` differently from code inside `super()` parameter expressions, although they should be exactly the same (the constructor "prologue" rules apply to both). This is fixed by removing some leftover/redundant code.

In summary, the `isSelfCall` flag is made obsolete by the newer, more general flag `ctorPrologue`, so it can be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1709294538

From duke at openjdk.org  Thu Sep  7 07:16:10 2023
From: duke at openjdk.org (Qing Xiao)
Date: Thu, 7 Sep 2023 07:16:10 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests
Message-ID: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>

Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

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

Commit messages:
 - Update test/langtools/lib/combo/TEST.properties
 - Modified years
 - Modified tests which extends tools in /combo/tools/javac/combo. Added DiagnosticPrinter.
 - Modified tests which extends tools in /combo/tools/javac/combo
 - Use JUnit Jupiter API in langtools/lib tests instead of TestNG. (Under /combo/tools/javac/combo/)

Changes: https://git.openjdk.org/jdk/pull/15281/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313613
  Stats: 496 lines in 16 files changed: 242 ins; 42 del; 212 mod
  Patch: https://git.openjdk.org/jdk/pull/15281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15281/head:pull/15281

PR: https://git.openjdk.org/jdk/pull/15281

From cstein at openjdk.org  Thu Sep  7 07:16:10 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 7 Sep 2023 07:16:10 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <7JSUTlI_DD9e169qq3Wqe8PfqlI2DUmZ_FnXQ2hlRAk=.98b9f55a-5b91-4687-bb2a-b895148a1065@github.com>

On Mon, 14 Aug 2023 23:57:08 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

test/langtools/lib/combo/TEST.properties line 1:

> 1: # This file identifies root(s) of the Junit hierarchy.

Suggestion:

# This file identifies root(s) of the JUnit hierarchy.


Captial `U` in JUnit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15281#discussion_r1294618455

From asotona at openjdk.org  Thu Sep  7 08:28:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Sep 2023 08:28:54 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
 <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
Message-ID: <pKE-MlD3o1hSfep3aqa9mehOs4xKLfirjx6lNO9rsSw=.ee34622f-2b55-40cb-a6b2-f81e6b74dd1d@github.com>

On Wed, 6 Sep 2023 19:55:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
>> 
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed code printing and ConstantPoolException reporting indoex
>>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>>  - throwing ConstantPoolException for invalid BSM entry index
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed JavapTask
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b
>
> test/langtools/tools/javap/8260403/T8260403.java line 42:
> 
>> 40:                 new String[]{"-c", System.getProperty("test.classes") + "/InvalidSignature.class"},
>> 41:                 new PrintWriter(sw));
>> 42:         System.out.println(sw);
> 
> is this for debug purpose only?

It is the test fix.
8260403 says "javap should be more robust", however to expect zero exit code for invalid class is wrong.
It suppose to expect non-zero exit code and fail only on fatal errors or unhandled CP errors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318264327

From asotona at openjdk.org  Thu Sep  7 08:34:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Sep 2023 08:34:52 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
 <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
Message-ID: <UF3OFIpWqlycUikB6Zb0Z51fTjjM7ROSYf87RvrxumY=.0e124531-0798-4493-bf07-238cbc8f3bcb@github.com>

On Wed, 6 Sep 2023 19:57:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
>> 
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed code printing and ConstantPoolException reporting indoex
>>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>>  - throwing ConstantPoolException for invalid BSM entry index
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed JavapTask
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b
>
> test/langtools/tools/javap/malformed/MalformedTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> isn't this test testing the same as: `test/langtools/tools/javap/8260403/T8260403.java`?

The principle of the test is the same, but it tests intentionally different class malformations (on a different level).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318272202

From asotona at openjdk.org  Thu Sep  7 08:38:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Sep 2023 08:38:51 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
 <zsYV_hzXeIQiEot-JyCLXCjdjC-T48rpGdDAx0ad4vo=.7628e335-9833-4f48-bd3f-fb86122ca2c4@github.com>
Message-ID: <yowHNqW3-fproeS-cbeCkrSGHIaDadN4n6r4rY4TsYY=.6a3ecd19-c176-4e0e-898e-59fb5322d84a@github.com>

On Wed, 6 Sep 2023 19:53:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
>> 
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed code printing and ConstantPoolException reporting indoex
>>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>>  - throwing ConstantPoolException for invalid BSM entry index
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed JavapTask
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b
>
> src/jdk.jdeps/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java line 134:
> 
>> 132:     private ClassWriter classWriter;
>> 133:     private Map<Integer, List<Note>> pcMap;
>> 134:     private CodeAttribute lr;
> 
> nit: name `lr` doesn't relate much to the type of the field

Right, `lr` historically came from label resolver, I'll fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318277017

From asotona at openjdk.org  Thu Sep  7 09:19:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Sep 2023 09:19:23 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v12]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <-LczHX74gCWta8AmyezcptxGkMWzMbA8ENqE1DVTvAM=.7f9563b6-fc53-4b6e-a417-a9a9d98c5e34@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits:

 - minor patches
 - Merge branch 'master' into JDK-8294969
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
 - throwing ConstantPoolException for invalid BSM entry index
 - Merge branch 'master' into JDK-8294969-javap
 - fixed JavapTask
 - ... and 219 more: https://git.openjdk.org/jdk/compare/9887cd8a...697079f7

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=11
  Stats: 3831 lines in 29 files changed: 1001 ins; 1701 del; 1129 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From jlahoda at openjdk.org  Thu Sep  7 11:11:55 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Sep 2023 11:11:55 GMT
Subject: Integrated: 8315735: VerifyError when switch statement used with
 synchronized block
In-Reply-To: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
References: <DTlFQUvQ2z4vvZidnuGJ1-oiXM3BFrFK2sH62HAB5jE=.89fcc5e8-8d4c-45fe-8c49-a3425bee9201@github.com>
Message-ID: <X7DsydMthj3887AVPZyFF5T6bnXu215ApKv6pz_KoL8=.a12e3522-3015-4290-9e4d-adfdd30197eb@github.com>

On Wed, 6 Sep 2023 08:29:40 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Having code like:
> 
>     public static void main(String... args) {
>         int i1 = 0 + switch (args.length) {
>             default -> {
>                 synchronized (args) {
>                     yield 1;
>                 }
>             }
>         };
>     }
> 
> 
> fails with a verification error at runtime. In the classfile, the synchronized block is basically a try-finally (which has an implicit "catch (any)" block), and so it needs the same handling as ordinary try statements.
> 
> (When there's a try statement inside a switch expression, the pre-existing stack is stored in local variables, and restored at return from the case. This is because catch clauses start with an empty stack.)

This pull request has now been integrated.

Changeset: 726c9c97
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/726c9c977dbaab75a2df4a931e3414ccabb7db44
Stats:     74 lines in 2 files changed: 69 ins; 0 del; 5 mod

8315735: VerifyError when switch statement used with synchronized block

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15584

From asotona at openjdk.org  Thu Sep  7 12:18:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 7 Sep 2023 12:18:41 GMT
Subject: RFR: 8313422: test/langtools/tools/javac 144 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
References: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
Message-ID: <4Tafo3ZBQMRl2lf9m5w5gsq3_zoC8D57_75xa3oa6eE=.2ee431b8-2e6d-4183-9ddb-0681e1e47b23@github.com>

On Tue, 1 Aug 2023 21:01:51 GMT, Qing Xiao <duke at openjdk.org> wrote:

> There are 144 tests to convert to the new Class-File API.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15112#pullrequestreview-1615292905

From abimpoudis at openjdk.org  Thu Sep  7 12:54:52 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 7 Sep 2023 12:54:52 GMT
Subject: Integrated: 8314632: Intra-case dominance check fails in the presence
 of a guard
In-Reply-To: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
References: <3O7YIQwMxsxWEM6B2NlHrAvhkEkKJZT99ROUES_ZNtI=.2180db6a-9ca4-44cf-af59-6f3f1892d932@github.com>
Message-ID: <3jTZJEI00EiehjWxLJPFxRVIP1hMg0qh9TOCFcHYWqU=.230a5b04-f381-407b-bd5d-69689b332d4e@github.com>

On Thu, 31 Aug 2023 12:33:26 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Intra-case domination should be affected by the presence of a guard. A missing check in dominance ensures that requirement.

This pull request has now been integrated.

Changeset: 81f8c57e
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81f8c57e4a14e0186f608cbe5a899322df80fd30
Stats:     47 lines in 3 files changed: 46 ins; 0 del; 1 mod

8314632: Intra-case dominance check fails in the presence of a guard

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15515

From jlahoda at openjdk.org  Thu Sep  7 14:29:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 7 Sep 2023 14:29:40 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v5]
In-Reply-To: <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
Message-ID: <iWrb1TpoS4UKIUZqwCAYknykhuhHiJZhbS0GVFfMDjA=.74b37a36-d08a-483a-8cfd-5ad640a90cde@github.com>

On Fri, 1 Sep 2023 16:00:33 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make patchCompletingNormallyCases void returning

I think I'd like to ask for some more tests. Especially:
- multiple cases with statements where the fall through goes from one to the other, e.g. something like:

   case Integer _ when ((Integer) obj) > 0:
   case String _ when !((String) obj).isEmpty():
       System.err.println(1);
   case null:
       System.err.println(2);
   default:    
       System.err.println(3);

- cases with loop statements with break (and/or continue) to the loop. E.g.:

while (true) {break;}

instead of `System.err.println(2);`

- break/continue, return, yield(?) going outside of the switch (probably one of them would be enough) in the duplicated section.

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1710251904

From duke at openjdk.org  Thu Sep  7 15:40:54 2023
From: duke at openjdk.org (Qing Xiao)
Date: Thu, 7 Sep 2023 15:40:54 GMT
Subject: Integrated: 8313422: test/langtools/tools/javac 144 test classes uses
 com.sun.tools.classfile library
In-Reply-To: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
References: <OeR3rU8btBa_trUiSbhYimaL_QPMgAybuAKtPsijm9U=.ff82b705-53eb-4ade-905e-ca0ca39b3a04@github.com>
Message-ID: <DQxlxBmNoHtl_AYMLkjnEgRGoVsvSJt8cDxs2W2M6XE=.f53667fc-870c-46c5-bfdd-bcfa9dec9ac8@github.com>

On Tue, 1 Aug 2023 21:01:51 GMT, Qing Xiao <duke at openjdk.org> wrote:

> There are 144 tests to convert to the new Class-File API.

This pull request has now been integrated.

Changeset: 8f7e29b2
Author:    Qing Xiao <qing.xiao at oracle.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f7e29b2cd9a049b5e4dd06a9c2b72a6b4ea6593
Stats:     3695 lines in 144 files changed: 938 ins; 957 del; 1800 mod

8313422: test/langtools/tools/javac 144 test classes uses com.sun.tools.classfile library

Reviewed-by: asotona

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

PR: https://git.openjdk.org/jdk/pull/15112

From vromero at openjdk.org  Thu Sep  7 17:18:56 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Sep 2023 17:18:56 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <MfOMi4zdPNpTttMk_zC_7b_HIsMEOx0YLgfhdZxcXMk=.87591b1e-5cae-40dd-a1fe-40c27cb80630@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 226:

> 224: 
> 225:     /**
> 226:      * {@return the field ref entry whose index is given at the specified

I think that `ref` in these APIs should be `reference`

src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 465:

> 463:                 indent(+1);
> 464:                 print("target_platform: #" + attr.targetPlatform().index());
> 465: //ToDo find the spec - can be null???

what about this comment?

src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 549:

> 547:             case SourceIDAttribute attr ->
> 548:                 constantWriter.write(attr.sourceId().index());
> 549: //            case StackMapAttribute ???

I guess this comment can be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318036242
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318069041
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1318070357

From abimpoudis at openjdk.org  Fri Sep  8 07:52:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 8 Sep 2023 07:52:28 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v6]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <0VrHX1NBXdX05Wf30vCzXk6hcqX9Mu5ufOPHHF4WnhI=.d43a5fd4-a81b-4d9c-848a-c40031d57f81@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add new tests and adjustment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/c46952b3..52bf0e3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=04-05

  Stats: 52 lines in 2 files changed: 50 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From abimpoudis at openjdk.org  Fri Sep  8 07:52:31 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 8 Sep 2023 07:52:31 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v5]
In-Reply-To: <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
Message-ID: <frqNZ4HC6lece_T-8zG8rnpvHYb76L0p4GZ1-JijduM=.a579dc08-04f4-46d5-878c-ca2b76101192@github.com>

On Fri, 1 Sep 2023 16:00:33 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make patchCompletingNormallyCases void returning

Thank you Jan. Does `multipleCasesWithReturn` cover your third bullet? Did I understood correctly?

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1711228273

From asotona at openjdk.org  Fri Sep  8 10:15:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Sep 2023 10:15:26 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v13]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <xgJgPyc4uI6hvmoTSp0Oig6pFGuPJOpfRlWW5TrmJQk=.590b14b9-405a-47ea-a972-a25e24e59fb8@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  applied suggested changes from review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/697079f7..27ff5820

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=11-12

  Stats: 14 lines in 2 files changed: 0 ins; 5 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From asotona at openjdk.org  Fri Sep  8 10:22:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 8 Sep 2023 10:22:58 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <MfOMi4zdPNpTttMk_zC_7b_HIsMEOx0YLgfhdZxcXMk=.87591b1e-5cae-40dd-a1fe-40c27cb80630@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
 <MfOMi4zdPNpTttMk_zC_7b_HIsMEOx0YLgfhdZxcXMk=.87591b1e-5cae-40dd-a1fe-40c27cb80630@github.com>
Message-ID: <YDvwyrqONa2-L-pU-nCOdOFFzR-GFFrJDkx4r1Mptaw=.002bd4fb-b360-4e98-8704-798453ddec55@github.com>

On Thu, 7 Sep 2023 03:10:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
>> 
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed code printing and ConstantPoolException reporting indoex
>>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>>  - throwing ConstantPoolException for invalid BSM entry index
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - fixed JavapTask
>>  - Merge branch 'master' into JDK-8294969-javap
>>  - Merge branch 'master' into JDK-8294969-javap
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b
>
> src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 226:
> 
>> 224: 
>> 225:     /**
>> 226:      * {@return the field ref entry whose index is given at the specified
> 
> I think that `ref` in these APIs should be `reference`

fixed, thanks

> src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 465:
> 
>> 463:                 indent(+1);
>> 464:                 print("target_platform: #" + attr.targetPlatform().index());
>> 465: //ToDo find the spec - can be null???
> 
> what about this comment?

removed according to the available spec information

> src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 549:
> 
>> 547:             case SourceIDAttribute attr ->
>> 548:                 constantWriter.write(attr.sourceId().index());
>> 549: //            case StackMapAttribute ???
> 
> I guess this comment can be removed

removed, thanks

> src/jdk.jdeps/share/classes/com/sun/tools/javap/LocalVariableTableWriter.java line 46:
> 
>> 44:  *  deletion without notice.</b>
>> 45:  */
>> 46: public class LocalVariableTableWriter extends  InstructionDetailWriter {
> 
> nit: two spaces between `extends` and `InstructionDetailWriter`

fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319670807
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319669825
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319669976
PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1319671851

From abimpoudis at openjdk.org  Fri Sep  8 20:25:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 8 Sep 2023 20:25:42 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v7]
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <MxHybFUeq87QqlYWp57niC1IMsO3MeLefe_TysbW-dY=.1beeaebb-4118-42d1-ab27-0aea59890a31@github.com>

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Improving the desugared code. (#4)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15532/files
  - new: https://git.openjdk.org/jdk/pull/15532/files/52bf0e3c..d44f2de6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15532&range=05-06

  Stats: 36 lines in 2 files changed: 21 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15532/head:pull/15532

PR: https://git.openjdk.org/jdk/pull/15532

From abimpoudis at openjdk.org  Fri Sep  8 20:25:45 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 8 Sep 2023 20:25:45 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v5]
In-Reply-To: <iWrb1TpoS4UKIUZqwCAYknykhuhHiJZhbS0GVFfMDjA=.74b37a36-d08a-483a-8cfd-5ad640a90cde@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <s2jcc5fCW7i5OQ3Kun-R3hp_6Hn_puPchmhBNRmb6rI=.cca1c9d5-aa4e-41c1-b668-009831575b6a@github.com>
 <iWrb1TpoS4UKIUZqwCAYknykhuhHiJZhbS0GVFfMDjA=.74b37a36-d08a-483a-8cfd-5ad640a90cde@github.com>
Message-ID: <eDrxHXDxCXTEImaEc9ascMBJZp-v6ZvFUVdoZ12ZXyo=.bd136fae-3b0e-49f6-b784-1c242c65f9cf@github.com>

On Thu, 7 Sep 2023 14:26:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make patchCompletingNormallyCases void returning
>
> I think I'd like to ask for some more tests. Especially:
> - multiple cases with statements where the fall through goes from one to the other, e.g. something like:
> 
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>        System.err.println(1);
>    case null:
>        System.err.println(2);
>    default:    
>        System.err.println(3);
> 
> - cases with loop statements with break (and/or continue) to the loop. E.g.:
> 
> while (true) {break;}
> 
> instead of `System.err.println(2);`
> 
> - break/continue, return, yield(?) going outside of the switch (probably one of them would be enough) in the duplicated section.

Thank you @lahodaj for the improvement. This is extremely elegant and reduces the code size!!!

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

PR Comment: https://git.openjdk.org/jdk/pull/15532#issuecomment-1712178630

From darcy at openjdk.org  Fri Sep  8 21:51:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Sep 2023 21:51:23 GMT
Subject: RFR: JDK-8312418: Add Elements.getEnumConstantBody [v6]
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <DP8bbwwEPPHLmX-3JoPu-ct5QDY7fVToV1nhPtl-Xvc=.6da04911-ea51-4a4b-a3cf-a04e0d80d202@github.com>

> Trivial implementation to get feedback on the proposed API.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Update copyright.
 - Merge branch 'master' into JDK-8312418
 - Refactor as suggested by jjg.
 - Reorder javadoc tags.
 - Change policy of default method.
 - Update printing processor.
 - Appease jcheck.
 - Merge in patch from Jan.
 - Merge branch 'master' into JDK-8312418
 - Merge branch 'master' into JDK-8312418
 - ... and 8 more: https://git.openjdk.org/jdk/compare/1ee5589c...0ac5b0cd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14939/files
  - new: https://git.openjdk.org/jdk/pull/14939/files/095eedb6..0ac5b0cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14939&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14939&range=04-05

  Stats: 21570 lines in 609 files changed: 15232 ins; 3321 del; 3017 mod
  Patch: https://git.openjdk.org/jdk/pull/14939.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14939/head:pull/14939

PR: https://git.openjdk.org/jdk/pull/14939

From darcy at openjdk.org  Fri Sep  8 22:09:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Sep 2023 22:09:52 GMT
Subject: Integrated: JDK-8312418: Add Elements.getEnumConstantBody
In-Reply-To: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
References: <d_id6Umy4rXqDnI3GTDTeUxSLd_XldGeWO4OhI6lV6g=.140e7368-c478-4e0a-bd06-c895c7eac943@github.com>
Message-ID: <0JIaC4kWSucwyxTz_idV2l-9-C-tFpna7XFq_Q1BHCo=.182c5b36-6c9e-4eb9-b9a3-5434000b4e5e@github.com>

On Wed, 19 Jul 2023 20:49:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Trivial implementation to get feedback on the proposed API.

This pull request has now been integrated.

Changeset: 578ded46
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/578ded4645a6ef32e9174ae973fe4c3aa6d5baab
Stats:     340 lines in 4 files changed: 339 ins; 0 del; 1 mod

8312418: Add Elements.getEnumConstantBody

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/14939

From darcy at openjdk.org  Sat Sep  9 22:33:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 9 Sep 2023 22:33:14 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <p94fnZZGSzZc2I3wO5CUSTuoDmqYAPdaH9fY51ps8Hc=.7f0653ce-b498-4393-ba0c-1803e7dae02e@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

Keep alive.

With the preparatory work of

8310061: Note if implicit annotation processing is being used

in JDK 21, please review this first cut at removing implicit annotation processing by default.

In this first iteration, I left the javac note in the properties file. In a subsequent iteration, we may decided to keep the old policy or earlier source levels, etc. Depending on the final disposition of that point, the property key should be fully expunged.

Once it is clearer what the eventual policy will be, I'll file the corresponding CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1668821871
PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712653778

From darcy at openjdk.org  Sat Sep  9 22:33:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 9 Sep 2023 22:33:14 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
Message-ID: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>

Change annotation processing to be opt-in rather than opt-out.

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

Commit messages:
 - Updates for a clean test run.
 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - JDK-8306819: Consider disabling the compiler's default active annotation processing

Changes: https://git.openjdk.org/jdk/pull/14432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306819
  Stats: 53 lines in 5 files changed: 17 ins; 8 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14432/head:pull/14432

PR: https://git.openjdk.org/jdk/pull/14432

From duke at openjdk.org  Sun Sep 10 11:16:45 2023
From: duke at openjdk.org (Rob Bygrave)
Date: Sun, 10 Sep 2023 11:16:45 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

> Based on my observations, nowadays annotation processing is hardly used anymore and if it's used it mostly occurs after the actual compilation process in a build tool

Annotation processing use is fundamental to newer frameworks like Quarkus, Micronaut and Spring framework is also adopting more use of annotation processing. This is because it enables frameworks and libraries to move some work from runtime to build time for reduced memory consumption and faster startup (replacing reflection, dynamic proxies etc).

For myself I have annotation processors that:
- Perform Dependency Injection 
- Generate JSON adapters (think Jackson without any runtime reflection, all the fastest JSON libs use annotation processing)
- Generate Rest Http Clients (think JAX-RS Jersey client implemented as source code generation)
- Generate Http Server controllers (think JAX-RS Jersey server implementation as source code generation)
- Generate Validation adapters (think Jakarta Validation implemented as source code generation)
- Generate "Builders" for record types

Its also common to use annotation processing for mapping/adapting between types (e.g. MapStruct)

I'd suggest the use of annotation processing is actually taking off in the last say 5 years as we especially look to deploy applications into cloud hosted environments where we pay money for the amount of CPU and Memory used.  Annotation processing means that a **_LOT_** of libraries can move some or even most of their functionality to build time reducing the CPU required to initialise the library and the total memory consumption.


> Based on my observations, nowadays annotation processing is hardly used anymore

To me I see the exact opposite happening and it's driven by cloud adoption and the desire to move work from runtime to build time.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712674323

From duke at openjdk.org  Sun Sep 10 12:58:41 2023
From: duke at openjdk.org (altrisi)
Date: Sun, 10 Sep 2023 12:58:41 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <NuUn5dyzjPy-L7CCRaEI6bwa6i7V_QERtfddLUSLTvI=.dc0b829a-9d97-48ca-9c47-6ff26b153f74@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

This doesn't remove annotation processors, just disables them running by default with no input from the developer (I assume if they were simply in the compiler classpath, which could happen by accident). As mentioned, it can still be enabled by its flag, and it's likely build systems will set that flag for you if you have declared you use annotation processors for your build.

I also disagree in the hardly used anymore part though, but I have no data.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712807240

From josiahnoel at gmail.com  Sun Sep 10 14:19:14 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Sun, 10 Sep 2023 10:19:14 -0400
Subject: RFR: JDK-8306819: Consider disabling the compiler's default
 active annotation processing
In-Reply-To: <NuUn5dyzjPy-L7CCRaEI6bwa6i7V_QERtfddLUSLTvI=.dc0b829a-9d97-48ca-9c47-6ff26b153f74@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <NuUn5dyzjPy-L7CCRaEI6bwa6i7V_QERtfddLUSLTvI=.dc0b829a-9d97-48ca-9c47-6ff26b153f74@github.com>
Message-ID: <CAJ_t5UbUZEMP0fdnCyDNFFDHd2C-Zh_okBbSbTfHJEwVqJw1QQ@mail.gmail.com>

Is it really such a common thing that people accidentally include unrelated
annotation processor dependencies transitively via maven? Most of the time,
I see processors are explicitly defined with the provided or optional scope
meaning they aren't usually pulled transitively. Perhaps the most used
annotation processor Lombok (even though it breaks the rules, it starts
with annotation processing) tells it's users to add it via provided scope.


On Sun, Sep 10, 2023, 8:58 AM altrisi <duke at openjdk.org> wrote:

> On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
> > Change annotation processing to be opt-in rather than opt-out.
>
> This doesn't remove annotation processors, just disables them running by
> default with no input from the developer (I assume if they were simply in
> the compiler classpath, which could happen by accident). As mentioned, it
> can still be enabled by its flag, and it's likely build systems will set
> that flag for you if you have declared you use annotation processors for
> your build.
>
> I also disagree in the hardly used anymore part though, but I have no data.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712807240
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230910/db1b9a49/attachment.htm>

From liach at openjdk.org  Sun Sep 10 15:35:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Sep 2023 15:35:45 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
Message-ID: <L9f6RG36zl89Hagzn-Nba6sdIOh168DW3IehpbpUBy0=.3e73cb95-ebc1-48cb-993b-f230cf6b9dfa@github.com>

On Sun, 10 Sep 2023 00:52:31 GMT, Rob Bygrave <duke at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
>> Based on my observations, nowadays annotation processing is hardly used anymore and if it's used it mostly occurs after the actual compilation process in a build tool
> 
> Annotation processing use is fundamental to newer frameworks like Quarkus, Micronaut and Spring framework is also adopting more use of annotation processing. This is because it enables frameworks and libraries to move some work from runtime to build time for reduced memory consumption and faster startup (replacing reflection, dynamic proxies etc).
> 
> For myself I have annotation processors that:
> - Perform Dependency Injection 
> - Generate JSON adapters (think Jackson without any runtime reflection, all the fastest JSON libs use annotation processing)
> - Generate Rest Http Clients (think JAX-RS Jersey client implemented as source code generation)
> - Generate Http Server controllers (think JAX-RS Jersey server implementation as source code generation)
> - Generate Validation adapters (think Jakarta Validation implemented as source code generation)
> - Generate "Builders" for record types
> 
> Its also common to use annotation processing for mapping/adapting between types (e.g. MapStruct)
> 
> I'd suggest the use of annotation processing is actually taking off in the last say 5 years as we especially look to deploy applications into cloud hosted environments where we pay money for the amount of CPU and Memory used.  Annotation processing means that a **_LOT_** of libraries can move some or even most of their functionality to build time reducing the CPU required to initialise the library and the total memory consumption.
> 
> 
>> Based on my observations, nowadays annotation processing is hardly used anymore
> 
> To me I see the exact opposite happening and it's driven by cloud adoption and the desire to move work from runtime to build time.

@rbygrave This patch isn't aimed to remove AP. This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run. Such classpath separation have already been promoted by build tools like Gradle.

After all, your build tool should be setting the `-proc` flag for you already, just like setting the classpath flags. You can first upgrade to Java 21, which has patch https://bugs.openjdk.org/browse/JDK-8310061 that warns you about implicit APs, before upgrading to 22 that changes the default behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712844213

From duke at openjdk.org  Sun Sep 10 15:56:45 2023
From: duke at openjdk.org (Josiah Noel)
Date: Sun, 10 Sep 2023 15:56:45 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
Message-ID: <MwsYEl6SFtsbuwMO-H-jbZkrxw0-ZEAcbwFFfcjfq48=.b654a809-9ced-4a5e-9bed-dd01ba0bf7bf@github.com>

On Sun, 10 Sep 2023 00:52:31 GMT, Rob Bygrave <duke at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
>> Based on my observations, nowadays annotation processing is hardly used anymore and if it's used it mostly occurs after the actual compilation process in a build tool
> 
> Annotation processing use is fundamental to newer frameworks like Quarkus, Micronaut and Spring framework is also adopting more use of annotation processing. This is because it enables frameworks and libraries to move some work from runtime to build time for reduced memory consumption and faster startup (replacing reflection, dynamic proxies etc).
> 
> For myself I have annotation processors that:
> - Perform Dependency Injection 
> - Generate JSON adapters (think Jackson without any runtime reflection, all the fastest JSON libs use annotation processing)
> - Generate Rest Http Clients (think JAX-RS Jersey client implemented as source code generation)
> - Generate Http Server controllers (think JAX-RS Jersey server implementation as source code generation)
> - Generate Validation adapters (think Jakarta Validation implemented as source code generation)
> - Generate "Builders" for record types
> 
> Its also common to use annotation processing for mapping/adapting between types (e.g. MapStruct)
> 
> I'd suggest the use of annotation processing is actually taking off in the last say 5 years as we especially look to deploy applications into cloud hosted environments where we pay money for the amount of CPU and Memory used.  Annotation processing means that a **_LOT_** of libraries can move some or even most of their functionality to build time reducing the CPU required to initialise the library and the total memory consumption.
> 
> 
>> Based on my observations, nowadays annotation processing is hardly used anymore
> 
> To me I see the exact opposite happening and it's driven by cloud adoption and the desire to move work from runtime to build time.

> @rbygrave This patch isn't aimed to remove AP. 

Pretty sure he was only speaking against the statement that AP is an unused feature. 

> This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run. 

In practice is this a thing that happens? Most processors I've seen (like Lombok or record builder for example) are typically added as provided or optional scope dependencies. (and so cannot be transitively pulled)

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712848174

From duke at openjdk.org  Mon Sep 11 13:49:44 2023
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 11 Sep 2023 13:49:44 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <7RiQU4PFOouD9qLihjY9YPYWYVm-u-k_K9wpTox04MU=.10a77c51-1097-4f44-b0c7-791858157a02@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

> BUT it has NOT been promoted by Maven. In the bug report and in this PR I do not see any explicit recognition of how this change will impact the community using Maven. I am suggesting that this is a significant proportion of the community.

If this is the new reality I can deal with it, but it would indeed be nice to know that the full gravity of this breaking change was acknowledged and taken into account when making this decision. (The initial proposal seems to make the assertion 
 that annotation processing is a niche tool that isn't used much)

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1713921266

From liach at openjdk.org  Mon Sep 11 14:14:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Sep 2023 14:14:43 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <jFYtB8ZuO8AD48VgKPB-9t3drFWwH4DZP4RWBYoIyGE=.c49783b7-0ea2-4b4b-85c8-1a2eb5307701@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

For whoever wondering about the impact of this breaking change, in JDK 21, the previous release and the previous LTS release, there's a new warning when the default active AP is used: https://github.com/openjdk/jdk/pull/14499 https://bugs.openjdk.org/browse/JDK-8310061

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1713972583

From darcy at openjdk.org  Mon Sep 11 16:39:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Sep 2023 16:39:43 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <htMqDd_LUTbw_spZC07Mu9Al_Wy4dHQATtHOV-nH6JQ=.ea93a28e-e19e-408d-a068-0a7321ece560@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

> For whoever wondering about the impact of this breaking change, in JDK 21, the previous release and the previous LTS release, there's a new warning when the default active AP is used: #14499 https://bugs.openjdk.org/browse/JDK-8310061

To expand on and reiterate points already made by @liach , the goal here is only to change whether or not annotation processing is run implicitly in a case like

`javac -cp $CLASSPATH file`

 Accomplishing this is being broken up over (at least) two releases. In JDK 21, there were two related changes:
 
 [JDK-8308245](https://bugs.openjdk.org/browse/JDK-8308245): Add -proc:full to describe current default annotation processing policy
  [JDK-8310061] (https://bugs.openjdk.org/browse/JDK-8310061): Note if implicit annotation processing is being used

The `-proc:full` option corresponds to the long-standing old default policy on annotation processing. Quoting the note added in the second bug,

    Annotation processing is enabled because one or more processors were found
    on the class path. A future release of javac may disable annotation processing
    unless at least one processor is specified by name (-processor), or a search
    path is specified (--processor-path, --processor-module-path), or annotation
    processing is enabled explicitly (-proc:only, -proc:full).
    Use -Xlint:-options to suppress this message.
    Use -proc:none to disable annotation processing.

The message is a note rather than a waning to avoid tripping up people who run their builds with `-Werror`. Besides a release note in JDK 21, we did extra outreach on the quality discuss alias to publicize this change (https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html).

So, starting in JDK 21, if you want to get the old look-on-the-classpath behavior, it is sufficient to use `-proc:full`. This also will work in JDK 22 after the changes in this PR go back. Breaking the change up over multiple release helps avoid a more disruptive flag day since `-proc:full` can be used before and after to request the desired behavior. HTH

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1714228447

From duke at openjdk.org  Mon Sep 11 17:12:40 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 11 Sep 2023 17:12:40 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <MwsYEl6SFtsbuwMO-H-jbZkrxw0-ZEAcbwFFfcjfq48=.b654a809-9ced-4a5e-9bed-dd01ba0bf7bf@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <MwsYEl6SFtsbuwMO-H-jbZkrxw0-ZEAcbwFFfcjfq48=.b654a809-9ced-4a5e-9bed-dd01ba0bf7bf@github.com>
Message-ID: <v5UKwi61ao4yPTI658ZIPG8XSCTCon1rjzYZPCiM0WQ=.bdc81c29-780d-4062-96db-c5199e1d8a5d@github.com>

On Sun, 10 Sep 2023 15:51:37 GMT, Josiah Noel <duke at openjdk.org> wrote:

> > This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run.
> 
> In practice is this a thing that happens? Most processors I've seen (like Lombok or record builder for example) are typically added as provided or optional scope dependencies. (and so cannot be transitively pulled)

In fact this is a thing that can cause problems. At present, annotation processor authors have to be cautious about including dependencies because commonly used libraries (such as Guava or Eclipse Collections) can conflict with other processors and/or the user's project with surprising (and sometimes subtle) results.

I'm not sure about other build tools, but Maven does supply a means to include an annotation processor on a (relatively) isolated class path, i.e. separately from the application's class path. Though this is somewhat more cumbersome, it is certainly safer.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1714275968

From duke at openjdk.org  Mon Sep 11 18:02:39 2023
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 11 Sep 2023 18:02:39 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <v5UKwi61ao4yPTI658ZIPG8XSCTCon1rjzYZPCiM0WQ=.bdc81c29-780d-4062-96db-c5199e1d8a5d@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <MwsYEl6SFtsbuwMO-H-jbZkrxw0-ZEAcbwFFfcjfq48=.b654a809-9ced-4a5e-9bed-dd01ba0bf7bf@github.com>
 <v5UKwi61ao4yPTI658ZIPG8XSCTCon1rjzYZPCiM0WQ=.bdc81c29-780d-4062-96db-c5199e1d8a5d@github.com>
Message-ID: <kdtaG0KbnAs3-kuVNkoAh-VkmvohUIfaKYKznx-0-j4=.ba3ab7da-84bc-4b47-b4bd-8d8f50987e39@github.com>

On Mon, 11 Sep 2023 17:10:01 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> I'm not sure about other build tools, but Maven does supply a means to include an annotation processor on a (relatively) isolated class path, i.e. separately from the application's class path. Though this is somewhat more cumbersome, it is certainly safer.

Maven's `annotationProcessorPaths` has its own CP issues when compared to using implicit processing. Even now I have code in our processor to check if the processor is [currently running in `annotationProcessorPaths`](https://github.com/avaje/avaje-inject/blob/13ce75156de310d078e1520231fe91cc7d5874b9/inject-generator/src/main/java/io/avaje/inject/generator/ExternalProvider.java#L17-L28) since the cp can get wonky when using it. (especially when dealing with JPMS)

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1714343861

From darcy at openjdk.org  Mon Sep 11 21:25:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 11 Sep 2023 21:25:39 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <v5UKwi61ao4yPTI658ZIPG8XSCTCon1rjzYZPCiM0WQ=.bdc81c29-780d-4062-96db-c5199e1d8a5d@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <MwsYEl6SFtsbuwMO-H-jbZkrxw0-ZEAcbwFFfcjfq48=.b654a809-9ced-4a5e-9bed-dd01ba0bf7bf@github.com>
 <v5UKwi61ao4yPTI658ZIPG8XSCTCon1rjzYZPCiM0WQ=.bdc81c29-780d-4062-96db-c5199e1d8a5d@github.com>
Message-ID: <K8xscA9zy91lW5P5ljzrtMOuNsCYCMNPZ5ykUAdJCFk=.fa36ad1c-5e53-4114-8109-7edc244316cd@github.com>

On Mon, 11 Sep 2023 17:10:01 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> > > This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run.
> > 
> > 
> > In practice is this a thing that happens? Most processors I've seen (like Lombok or record builder for example) are typically added as provided or optional scope dependencies. (and so cannot be transitively pulled)
> 
> In fact this is a thing that can cause problems. At present, annotation processor authors have to be cautious about including dependencies because commonly used libraries (such as Guava or Eclipse Collections) can conflict with other processors and/or the user's project with surprising (and sometimes subtle) results.
> 
> I'm not sure about other build tools, but Maven does supply a means to include an annotation processor on a (relatively) isolated class path, i.e. separately from the application's class path. Though this is somewhat more cumbersome, it is certainly safer.

Yes, in terms of good build hygiene, I recommend separately specifying the path for annotation processors and the path for general compiler dependencies, even if they happen to be the same path.

Likewise,, specifying --release $N is a good practice too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1714598354

From vromero at openjdk.org  Mon Sep 11 22:49:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Sep 2023 22:49:39 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <MmtWJIQyI-aTVr90RSxXCiCUkmOeEPfia7BA9lkVXoM=.359575eb-6182-4d92-8ade-ebc6ca64ddfc@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

test/langtools/tools/javac/6341866/T6341866.java line 70:

> 68:     enum AnnoType {
> 69:         NONE,           // no annotation processing
> 70:      // SERVICE,        // implicit annotation processing, via ServiceLoader

why keeping this if it won't be used?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14432#discussion_r1322146120

From josiahnoel at gmail.com  Tue Sep 12 04:51:51 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 12 Sep 2023 00:51:51 -0400
Subject: Ever thought of a ModuleElement Query function?
Message-ID: <CAJ_t5UZRfxEtzr8_U-o1FzcoP55JD8PgxeL-jfz9HN4RM71X_g@mail.gmail.com>

 Hello there,

I think it would be nice if a sort of query method was added to
ModuleElement such that one can see if a certain module is on its graph.

I want to add functionality to my annotation processor that should check
whether a project's ModuleElement contains a certain dependency. Currently,
I'm thinking I'll need to recursively iterate over the directives to search
the module path. (which naturally gets much slower the more modules are
involved)

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230912/814616cb/attachment.htm>

From jonathan.gibbons at oracle.com  Tue Sep 12 15:13:46 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 12 Sep 2023 08:13:46 -0700
Subject: Ever thought of a ModuleElement Query function?
In-Reply-To: <CAJ_t5UZRfxEtzr8_U-o1FzcoP55JD8PgxeL-jfz9HN4RM71X_g@mail.gmail.com>
References: <CAJ_t5UZRfxEtzr8_U-o1FzcoP55JD8PgxeL-jfz9HN4RM71X_g@mail.gmail.com>
Message-ID: <c2d67975-c625-bdd8-0937-727206773377@oracle.com>

To find whether a project's ModuleElement contains a certain dependency, 
you can (recursively) examine the directives (in particular, the 
RequiresDirective) for the module(s).

https://docs.oracle.com/en/java/javase/20/docs/api/java.compiler/javax/lang/model/element/ModuleElement.html#getDirectives()

-- Jon


On 9/11/23 9:51 PM, Josiah Noel wrote:
> ?Hello there,
>
> I think it would be nice if a sort of query method was added to 
> ModuleElement such that one can see if a certain module is on its graph.
>
> I want to add functionality to my annotation processor that should 
> check whether a project's ModuleElement contains a certain dependency. 
> Currently, I'm thinking I'll need to recursively iterate over the 
> directives to search the module path. (which naturally gets much 
> slower?the more modules are involved)
>
> -- 
> Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230912/233e834b/attachment-0001.htm>

From josiahnoel at gmail.com  Tue Sep 12 18:48:45 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 12 Sep 2023 14:48:45 -0400
Subject: Ever thought of a ModuleElement Query function?
In-Reply-To: <c2d67975-c625-bdd8-0937-727206773377@oracle.com>
References: <CAJ_t5UZRfxEtzr8_U-o1FzcoP55JD8PgxeL-jfz9HN4RM71X_g@mail.gmail.com>
 <c2d67975-c625-bdd8-0937-727206773377@oracle.com>
Message-ID: <CAJ_t5UaOD3v-HRWGa3gOBq0Y2U2udNeHqbOpFi5E+A4nTPCh_g@mail.gmail.com>

I got that, I'm just wondering if there is a more efficient way to go about
it, as that would involve several levels of nested iteration depending on
the project. (since you need to examine the requires directives of every
module and each of their modules and so on)

On Tue, Sep 12, 2023 at 2:24?PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> To find whether a project's ModuleElement contains a certain dependency,
> you can (recursively) examine the directives (in particular, the
> RequiresDirective) for the module(s).
>
>
> https://docs.oracle.com/en/java/javase/20/docs/api/java.compiler/javax/lang/model/element/ModuleElement.html#getDirectives()
>
> -- Jon
>
>
> On 9/11/23 9:51 PM, Josiah Noel wrote:
>
>  Hello there,
>
> I think it would be nice if a sort of query method was added to
> ModuleElement such that one can see if a certain module is on its graph.
>
> I want to add functionality to my annotation processor that should check
> whether a project's ModuleElement contains a certain dependency. Currently,
> I'm thinking I'll need to recursively iterate over the directives to search
> the module path. (which naturally gets much slower the more modules are
> involved)
>
> --
> Cheers, Josiah.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230912/b92346fe/attachment.htm>

From jlu at openjdk.org  Tue Sep 12 22:04:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Sep 2023 22:04:12 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
Message-ID: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>

JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.

This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.

The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)

The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.

If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

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

Commit messages:
 - Update header / copyright for CurrencyFormat
 - Adjust CurrencyFormat test to read in .properties with UTF-8
 - Convert unicode escape sequences to native
 - Add clarifying comment in Bug6204853 for lack of conversion
 - Read JDK properties files in UTF-8 during build process for LRB

Changes: https://git.openjdk.org/jdk/pull/15694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

PR: https://git.openjdk.org/jdk/pull/15694

From liach at openjdk.org  Tue Sep 12 23:16:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Sep 2023 23:16:40 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <J7d2aEX-HZ3icqioTX6_1cIVuqDXsj3oTibvKqMhpXA=.6b496c32-a89c-4ba8-86f4-5b1657f6d378@github.com>

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 227:

> 225:         try (FileInputStream input = new FileInputStream(propertiesPath);
> 226:              // Read in JDK .properties files in UTF-8
> 227:              InputStreamReader streamReader = new InputStreamReader(input, StandardCharsets.UTF_8)

Can we just uses `Files.newBufferedReader(Path.of(propertiesPath))` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1323716978

From darcy at openjdk.org  Wed Sep 13 04:29:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Sep 2023 04:29:53 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v2]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <d87Dsm-R8iWGtUHSi8QxDwNrG_k6VWHDKxQd9wTbIHs=.15b8a6f5-ebe5-459f-9cf8-337ace6bcee4@github.com>

> Change annotation processing to be opt-in rather than opt-out.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8306819
 - Updates for a clean test run.
 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - JDK-8306819: Consider disabling the compiler's default active annotation processing

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

Changes: https://git.openjdk.org/jdk/pull/14432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=01
  Stats: 53 lines in 5 files changed: 17 ins; 8 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14432/head:pull/14432

PR: https://git.openjdk.org/jdk/pull/14432

From vromero at openjdk.org  Wed Sep 13 14:57:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Sep 2023 14:57:43 GMT
Subject: RFR: 8314226: Series of colon-style fallthrough switch cases with
 guards compiled incorrectly [v7]
In-Reply-To: <MxHybFUeq87QqlYWp57niC1IMsO3MeLefe_TysbW-dY=.1beeaebb-4118-42d1-ab27-0aea59890a31@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
 <MxHybFUeq87QqlYWp57niC1IMsO3MeLefe_TysbW-dY=.1beeaebb-4118-42d1-ab27-0aea59890a31@github.com>
Message-ID: <FwZSvZ2z6w1p9DsqD2SmZe0Io3nRZCbI-2wa6qMH4hY=.1cd46942-0a50-4552-9735-dc4da751ad2c@github.com>

On Fri, 8 Sep 2023 20:25:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
>> 
>> 
>> switch (obj) {
>>    case Integer _ when ((Integer) obj) > 0:
>>    case String _ when !((String) obj).isEmpty():
>>       return 1;
>>    default:
>>       return -1;
>> }
>> 
>> 
>> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
>> 
>> Previously the code was translated into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>>     case 0:
>>         Integer _;
>>         if (!(true && ((Integer)obj) > 0)) {
>>             index$1 = 1;
>>             continue;
>>         }
>> 
>>     case 1 when !((String)obj).isEmpty():
>>         return 1;
>> 
>>     default:
>>         return -1;
>> }
>> 
>> 
>> This PR adjusts the translation into:
>> 
>> 
>> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>> case 0:
>>     Integer _;
>>     if (!(true && ((Integer)obj) > 0)) {
>>         index$1 = 1;
>>         continue;
>>     }
>>     return 1;
>> 
>> case 1:
>>     String _;
>>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>>         index$1 = 2;
>>         continue;
>>     }
>>     return 1;
>> }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving the desugared code. (#4)

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15532#pullrequestreview-1624772234

From abimpoudis at openjdk.org  Wed Sep 13 15:12:57 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 13 Sep 2023 15:12:57 GMT
Subject: Integrated: 8314226: Series of colon-style fallthrough switch cases
 with guards compiled incorrectly
In-Reply-To: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
References: <sCV8boync-6OmTeo6MPKxGKqEZP-bBzSNtBY5VOIUGU=.fda4cfa3-8a14-4313-9974-d081fc971101@github.com>
Message-ID: <l26sMKyQM2zH9V8pKLYVhFHL1asmQdivGkwkgM_dWnM=.fc00dabd-560a-48b0-98d8-33271852db02@github.com>

On Fri, 1 Sep 2023 10:02:20 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The `switch` structure is translated in `handleSwitch` where we rewrite pattern matching switches. In some occasions a switch has multiple cases with multiple patterns where the n-th case does not complete normally and falls through to the n+1-st case:
> 
> 
> switch (obj) {
>    case Integer _ when ((Integer) obj) > 0:
>    case String _ when !((String) obj).isEmpty():
>       return 1;
>    default:
>       return -1;
> }
> 
> 
> This PR addresses that by translating the second case correctly and also replicates the body of the latter to the former (which we can do because no bindings are introduced in either statement blocks by the definition of unnamed variables.).
> 
> Previously the code was translated into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
>     case 0:
>         Integer _;
>         if (!(true && ((Integer)obj) > 0)) {
>             index$1 = 1;
>             continue;
>         }
> 
>     case 1 when !((String)obj).isEmpty():
>         return 1;
> 
>     default:
>         return -1;
> }
> 
> 
> This PR adjusts the translation into:
> 
> 
> switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector0$temp, index$1)) {
> case 0:
>     Integer _;
>     if (!(true && ((Integer)obj) > 0)) {
>         index$1 = 1;
>         continue;
>     }
>     return 1;
> 
> case 1:
>     String _;
>     if (!((selector0$temp instanceof String || false) && (true && !((String)obj).isEmpty()))) {
>         index$1 = 2;
>         continue;
>     }
>     return 1;
> }

This pull request has now been integrated.

Changeset: 3b0a6d2a
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b0a6d2a6842962218b8cebcd9c0672cb4ee6720
Stats:     218 lines in 2 files changed: 217 ins; 0 del; 1 mod

8314226: Series of colon-style fallthrough switch cases with guards compiled incorrectly

Reviewed-by: mcimadamore, vromero

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

PR: https://git.openjdk.org/jdk/pull/15532

From jlu at openjdk.org  Wed Sep 13 17:38:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 17:38:28 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Replace InputStreamReader with BufferedReader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15694/files
  - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01

  Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

PR: https://git.openjdk.org/jdk/pull/15694

From naoto at openjdk.org  Wed Sep 13 18:14:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 18:14:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951

From jlu at openjdk.org  Wed Sep 13 18:46:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 18:46:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>
Message-ID: <uMvl3FO1Vazr77Xov1P8ug2TNcA392WhIw_AK24e2B8=.6b6831ab-c30e-4804-9974-84ec0b9f97ae@github.com>

On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test)

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807

From briangoetz at openjdk.org  Thu Sep 14 16:43:50 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 14 Sep 2023 16:43:50 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v13]
In-Reply-To: <xgJgPyc4uI6hvmoTSp0Oig6pFGuPJOpfRlWW5TrmJQk=.590b14b9-405a-47ea-a972-a25e24e59fb8@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <xgJgPyc4uI6hvmoTSp0Oig6pFGuPJOpfRlWW5TrmJQk=.590b14b9-405a-47ea-a972-a25e24e59fb8@github.com>
Message-ID: <AgS4P-gA5FGkrNc3cYDNIhS-FX6P4S0lq213YxZ0C5E=.1b50f512-1c51-40e5-9faf-1b4c5836cb22@github.com>

On Fri, 8 Sep 2023 10:15:26 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   applied suggested changes from review

src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 184:

> 182:      */
> 183:     ConstantValueEntry readConstantValueEntry(int offset);
> 184: 

I'm not sure that all this additional API surface carries its weight in ClassReader, when each of these methods just called readEntry() and casts to the desired type?  I can see two alternate ways here:

 - Ordinary casts at the use site (worse error handling, but ultimately the same result), or
 -  A single method 

<T extends ConstantPoolEntry> T readEntry(int pos, Class<T> t)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1326241987

From asotona at openjdk.org  Thu Sep 14 20:01:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 20:01:52 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v13]
In-Reply-To: <AgS4P-gA5FGkrNc3cYDNIhS-FX6P4S0lq213YxZ0C5E=.1b50f512-1c51-40e5-9faf-1b4c5836cb22@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <xgJgPyc4uI6hvmoTSp0Oig6pFGuPJOpfRlWW5TrmJQk=.590b14b9-405a-47ea-a972-a25e24e59fb8@github.com>
 <AgS4P-gA5FGkrNc3cYDNIhS-FX6P4S0lq213YxZ0C5E=.1b50f512-1c51-40e5-9faf-1b4c5836cb22@github.com>
Message-ID: <BJzdasyZL25QmJK7vxOmvL-t-GfSE_3BSAMAaRimS2A=.0f5ca4b8-7e4b-44a0-91f7-62c38f5970c5@github.com>

On Thu, 14 Sep 2023 16:38:36 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   applied suggested changes from review
>
> src/java.base/share/classes/jdk/internal/classfile/ClassReader.java line 184:
> 
>> 182:      */
>> 183:     ConstantValueEntry readConstantValueEntry(int offset);
>> 184: 
> 
> I'm not sure that all this additional API surface carries its weight in ClassReader, when each of these methods just called readEntry() and casts to the desired type?  I can see two alternate ways here:
> 
>  - Ordinary casts at the use site (worse error handling, but ultimately the same result), or
>  -  A single method 
> 
> <T extends ConstantPoolEntry> T readEntry(int pos, Class<T> t)

We need at least `<T extends PoolEntry> T readEntry(int pos, Class<T> t)` to throw `ConstantPoolException` instead of `ClassCastException` from broken entries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11411#discussion_r1326453583

From asotona at openjdk.org  Thu Sep 14 20:14:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Sep 2023 20:14:33 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v14]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <K0y1GEoZKXjGy1kX9CeWmuYC62v5lYaHxw3W3Kx10jo=.9c21d8bc-6f0f-44f0-b087-2a6fd8f7d61b@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 233 commits:

 - reducing ClassReader API footprint
 - fixed ConstantWriter
 - Merge branch 'master' into JDK-8294969
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
 - applied suggested changes from review
 - minor patches
 - Merge branch 'master' into JDK-8294969
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
 - fixed code printing and ConstantPoolException reporting indoex
 - added DydnamicConstantPoolEntry::bootstrapMethodIndex
   fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
 - ... and 223 more: https://git.openjdk.org/jdk/compare/b2e91060...938571fc

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=13
  Stats: 3756 lines in 29 files changed: 919 ins; 1778 del; 1059 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From jlu at openjdk.org  Thu Sep 14 22:22:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Sep 2023 22:22:50 GMT
Subject: Integrated: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <bMA2JRlOPK5QMgdE1cZJiNTZWJ5DH1Q0XLAY6c9YJ4w=.6476653b-6388-4f25-98ba-7ad80a6947cb@github.com>

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

This pull request has now been integrated.

Changeset: b55e418a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe
Stats:     28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod

8301991: Convert l10n properties resource bundles to UTF-8 native

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/15694

From asotona at openjdk.org  Fri Sep 15 09:42:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Sep 2023 09:42:24 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v15]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <ek2wXi9cNwb65Cm5FHka15U_AnUBmZmz1VrCk-hdQco=.a41bacd9-c745-4235-a033-5a659e706c9c@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  fixed TestClassNameWarning test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/938571fc..ae3b25bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=13-14

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From vromero at openjdk.org  Fri Sep 15 14:45:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Sep 2023 14:45:49 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v15]
In-Reply-To: <ek2wXi9cNwb65Cm5FHka15U_AnUBmZmz1VrCk-hdQco=.a41bacd9-c745-4235-a033-5a659e706c9c@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <ek2wXi9cNwb65Cm5FHka15U_AnUBmZmz1VrCk-hdQco=.a41bacd9-c745-4235-a033-5a659e706c9c@github.com>
Message-ID: <WL16Z2U75LHCF9Tjval3VfZtSyxpvgaEtZtBwgBBSlo=.be7c493d-e4d4-4586-8a28-b061a120b2a2@github.com>

On Fri, 15 Sep 2023 09:42:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed TestClassNameWarning test

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11411#pullrequestreview-1629114888

From asotona at openjdk.org  Fri Sep 15 16:28:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Sep 2023 16:28:44 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v16]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <HDzVm8qz1mdOBSOzFm4o6MkF0kP26FgMAYC6p4zHEKE=.338fba79-9122-4380-b037-60f1feab6784@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

  adding serviceability/sa/ClhsdbDumpclass.java test to problem list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/ae3b25bf..3ae33d48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=14-15

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From darcy at openjdk.org  Fri Sep 15 21:37:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 15 Sep 2023 21:37:39 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v2]
In-Reply-To: <MmtWJIQyI-aTVr90RSxXCiCUkmOeEPfia7BA9lkVXoM=.359575eb-6182-4d92-8ade-ebc6ca64ddfc@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <MmtWJIQyI-aTVr90RSxXCiCUkmOeEPfia7BA9lkVXoM=.359575eb-6182-4d92-8ade-ebc6ca64ddfc@github.com>
Message-ID: <xk_n3vecOuin5wxxnqoAXKEuAa1jQUzYzIcEz4mmc-s=.6edba0d4-c835-46c4-b18e-311b124e257c@github.com>

On Mon, 11 Sep 2023 22:45:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> why keeping this if it won't be used?

Sure; I can delete that before the changeset goes back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14432#discussion_r1327811884

From gliangtao at gmail.com  Fri Sep 15 23:21:50 2023
From: gliangtao at gmail.com (Liangtao)
Date: Fri, 15 Sep 2023 16:21:50 -0700
Subject: tertiary operator error casting Float to Object
Message-ID: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>

The following code always output incorrect casting result:

// BEGIN Bug.java code
public class Bug {
    public static void main(String[] args) {
        float temp = 60.0f;
        boolean isInt = true;
        Object o = isInt ? Integer.valueOf((int)temp) : Float.valueOf(temp);
        System.out.println("isInt " + isInt + ", temp = " + o);
    }
}
// END Bug.java code

Steps to reproduce:
$ javac Bug.java && java Bug

Expected Result:

isInt true, temp = 60.0


Actual Result:

isInt true, temp = 60
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230915/61fb3274/attachment.htm>

From gliangtao at gmail.com  Fri Sep 15 23:23:15 2023
From: gliangtao at gmail.com (Liangtao)
Date: Fri, 15 Sep 2023 16:23:15 -0700
Subject: tertiary operator error casting Float to Object
In-Reply-To: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
References: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
Message-ID: <CAF7EP0DmLf+vnS5A1MUqEaKTTewVvREUsb_5-tH=z1547Xz+Hw@mail.gmail.com>

Sorry for the typo (now fixed)

On Fri, Sep 15, 2023 at 4:21?PM Liangtao <gliangtao at gmail.com> wrote:

> The following code always output incorrect casting result:
>
> // BEGIN Bug.java code
> public class Bug {
>     public static void main(String[] args) {
>         float temp = 60.0f;
>         boolean isInt = true;
>         Object o = isInt ? Integer.valueOf((int)temp) :
> Float.valueOf(temp);
>         System.out.println("isInt " + isInt + ", temp = " + o);
>     }
> }
> // END Bug.java code
>
> Steps to reproduce:
> $ javac Bug.java && java Bug
>
> Actual Result:
>
> isInt true, temp = 60.0
>
>
> Expected Result:
>
> isInt true, temp = 60
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230915/9bdaee24/attachment.htm>

From forax at univ-mlv.fr  Fri Sep 15 23:48:59 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 16 Sep 2023 01:48:59 +0200 (CEST)
Subject: tertiary operator error casting Float to Object
In-Reply-To: <CAF7EP0DmLf+vnS5A1MUqEaKTTewVvREUsb_5-tH=z1547Xz+Hw@mail.gmail.com>
References: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
 <CAF7EP0DmLf+vnS5A1MUqEaKTTewVvREUsb_5-tH=z1547Xz+Hw@mail.gmail.com>
Message-ID: <948094197.40298171.1694821739549.JavaMail.zimbra@univ-eiffel.fr>

> From: "Liangtao" <gliangtao at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Saturday, September 16, 2023 1:23:15 AM
> Subject: Re: tertiary operator error casting Float to Object

> Sorry for the typo (now fixed)

> On Fri, Sep 15, 2023 at 4:21 PM Liangtao < [ mailto:gliangtao at gmail.com |
> gliangtao at gmail.com ] > wrote:

>> The following code always output incorrect casting result:

>> // BEGIN Bug.java code
>> public class Bug {
>> public static void main(String[] args) {
>> float temp = 60.0f;
>> boolean isInt = true;
>> Object o = isInt ? Integer.valueOf((int)temp) : Float.valueOf(temp);
>> System.out.println("isInt " + isInt + ", temp = " + o);
>> }
>> }
>> // END Bug.java code

>> Steps to reproduce:
>> $ javac Bug.java && java Bug

>> Actual Result:

>> isInt true, temp = 60.0

>> Expected Result:

>> isInt true, temp = 60

This is a well known oddities of the Java spec, the result of ?: with an Integer and a Float is a float, 
inside a ?: the wrappers behave like their primitive counterparts, 
see [ https://docs.oracle.com/javase/specs/jls/se20/html/jls-15.html#jls-15.25 | https://docs.oracle.com/javase/specs/jls/se20/html/jls-15.html#jls-15.25 ] 

So your code is equivalent to: 
float o = isInt ? Integer.valueOf((int)temp) : Float.valueOf(temp); 

If you want the wrappers to behave like objects inside a ?:, you have to cast one them as an Object. 

Object o = isInt ? (Object) Integer.valueOf((int)temp) : Float.valueOf(temp); 

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230916/e74f86d0/attachment-0001.htm>

From alex.buckley at oracle.com  Fri Sep 15 23:53:30 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 15 Sep 2023 16:53:30 -0700
Subject: tertiary operator error casting Float to Object
In-Reply-To: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
References: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
Message-ID: <c18de6fc-5a49-410e-b003-a16e5b99c523@oracle.com>

On JDK 17.0.6, for example, I get the expected result (temp = 60.0) 
which is the correct result.

Which JDK version are you using?

(For the record: per JLS 15.25.2 and 5.6, the type of the numeric 
conditional expression `isInt ? ... : ...` is float, which is assignment 
compatible with Object.)

Alex

On 9/15/2023 4:21 PM, Liangtao wrote:
> The following code always output incorrect casting result:
> 
> // BEGIN Bug.java code
> public class Bug {
>  ? ? public static void main(String[] args) {
>  ? ? ? ? float temp = 60.0f;
>  ? ? ? ? boolean isInt = true;
>  ? ? ? ? Object o = isInt ? Integer.valueOf((int)temp) : 
> Float.valueOf(temp);
>  ? ? ? ? System.out.println("isInt " + isInt + ", temp = " + o);
>  ? ? }
> }
> // END Bug.java code
> 
> Steps to reproduce:
> $ javac Bug.java && java Bug
> 
> Expected Result:
> 
> isInt true, temp = 60.0
> 
> 
> Actual Result:
> 
> isInt true, temp = 60
> 
> 

From alex.buckley at oracle.com  Sat Sep 16 00:04:04 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 15 Sep 2023 17:04:04 -0700
Subject: tertiary operator error casting Float to Object
In-Reply-To: <CAF7EP0DmLf+vnS5A1MUqEaKTTewVvREUsb_5-tH=z1547Xz+Hw@mail.gmail.com>
References: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
 <CAF7EP0DmLf+vnS5A1MUqEaKTTewVvREUsb_5-tH=z1547Xz+Hw@mail.gmail.com>
Message-ID: <80351be4-e151-41b7-a404-879e5b34900a@oracle.com>

It would have been helpful to explain what your typo was.

Your original mail:

   Expected Result: isInt true, temp = 60.0
   Actual Result: isInt true, temp = 60

Your updated mail (below):

   Expected Result: isInt true, temp = 60
   Actual Result: isInt true, temp = 60.0

Your updated mail is mistaken about the expected result. The expected 
result is 60.0 because the type of ?Integer:Float is float. If you find 
a JDK that doesn't give 60.0, let us know.

Alex

On 9/15/2023 4:23 PM, Liangtao wrote:
> Sorry for the typo (now fixed)
> 
> On Fri, Sep 15, 2023 at 4:21?PM Liangtao <gliangtao at gmail.com 
> <mailto:gliangtao at gmail.com>> wrote:
> 
>     The following code always output incorrect casting result:
> 
>     // BEGIN Bug.java code
>     public class Bug {
>      ? ? public static void main(String[] args) {
>      ? ? ? ? float temp = 60.0f;
>      ? ? ? ? boolean isInt = true;
>      ? ? ? ? Object o = isInt ? Integer.valueOf((int)temp) :
>     Float.valueOf(temp);
>      ? ? ? ? System.out.println("isInt " + isInt + ", temp = " + o);
>      ? ? }
>     }
>     // END Bug.java code
> 
>     Steps to reproduce:
>     $ javac Bug.java && java Bug
> 
>     Actual Result:
> 
>     isInt true, temp = 60.0
> 
> 
>     Expected Result:
> 
>     isInt true, temp = 60
> 
> 

From gliangtao at gmail.com  Sat Sep 16 02:00:14 2023
From: gliangtao at gmail.com (Liangtao)
Date: Fri, 15 Sep 2023 19:00:14 -0700
Subject: tertiary operator error casting Float to Object
In-Reply-To: <c18de6fc-5a49-410e-b003-a16e5b99c523@oracle.com>
References: <CAF7EP0BzabnQsW93em90dmhdjjcOaP5Ln3NCfvm=YDiUFts6Nw@mail.gmail.com>
 <c18de6fc-5a49-410e-b003-a16e5b99c523@oracle.com>
Message-ID: <CAF7EP0A7X0rKbSxyBV4W9fHuFveDoqCp3KxWR7t8aBPMf+Kk+A@mail.gmail.com>

OpenJDK 17.0.8.1 also gets "60.0".

So it's actually "right" according to JLS. However, as a conservative guy I
lose confidence of using tertiary operator now...

Thanks,
Liangtao

On Fri, Sep 15, 2023 at 6:51?PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> On JDK 17.0.6, for example, I get the expected result (temp = 60.0)
> which is the correct result.
>
> Which JDK version are you using?
>
> (For the record: per JLS 15.25.2 and 5.6, the type of the numeric
> conditional expression `isInt ? ... : ...` is float, which is assignment
> compatible with Object.)
>
> Alex
>
> On 9/15/2023 4:21 PM, Liangtao wrote:
> > The following code always output incorrect casting result:
> >
> > // BEGIN Bug.java code
> > public class Bug {
> >      public static void main(String[] args) {
> >          float temp = 60.0f;
> >          boolean isInt = true;
> >          Object o = isInt ? Integer.valueOf((int)temp) :
> > Float.valueOf(temp);
> >          System.out.println("isInt " + isInt + ", temp = " + o);
> >      }
> > }
> > // END Bug.java code
> >
> > Steps to reproduce:
> > $ javac Bug.java && java Bug
> >
> > Expected Result:
> >
> > isInt true, temp = 60.0
> >
> >
> > Actual Result:
> >
> > isInt true, temp = 60
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230915/87246096/attachment-0001.htm>

From acobbs at openjdk.org  Sat Sep 16 21:52:14 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 16 Sep 2023 21:52:14 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v13]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <Xv4_AUT2yJvNAzO24agtX0Q92lKd6b0xhq7HOyxKraw=.6fd75c23-db59-4328-96a4-08321dcbd40f@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Change the error message to match the applicable spec rule.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/4ff4c5c5..a5510b79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=11-12

  Stats: 13 lines in 3 files changed: 0 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From asotona at openjdk.org  Mon Sep 18 08:39:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 18 Sep 2023 08:39:05 GMT
Subject: Integrated: 8294969: Convert jdk.jdeps javap to use the Classfile API
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <cWlt1fLddBA-MoYBoBcV93feGV2UyLY857NmJ4DERZI=.e2cd2d35-0737-459b-8e53-1884009e2608@github.com>

On Tue, 29 Nov 2022 10:26:31 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 1203e11a
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1203e11a8d9b3ef0695282d980ad411213e6aa6c
Stats:     3755 lines in 29 files changed: 920 ins; 1778 del; 1057 mod

8294969: Convert jdk.jdeps javap to use the Classfile API

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/11411

From darcy at openjdk.org  Mon Sep 18 20:03:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 18 Sep 2023 20:03:54 GMT
Subject: RFR: JDK-8246280: Refine API to model sealed classes and interfaces in
 javax.lang.model
Message-ID: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>

Simple specification clarification.

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

Commit messages:
 - Appease jcheck.
 - JDK-8246280: Refine API to model sealed classes and interfaces in javax.lang.model

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

PR: https://git.openjdk.org/jdk/pull/15795

From vromero at openjdk.org  Mon Sep 18 20:15:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Sep 2023 20:15:39 GMT
Subject: RFR: JDK-8246280: Refine API to model sealed classes and
 interfaces in javax.lang.model
In-Reply-To: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
References: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
Message-ID: <jyIGMgexPxwGkzmce-w3x9t_4g9szFsJuDgNI2N51wE=.6cb569aa-bc94-4fde-ba68-1cff7253e469@github.com>

On Mon, 18 Sep 2023 19:34:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple specification clarification.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15795#pullrequestreview-1631883024

From jjg at openjdk.org  Mon Sep 18 20:38:41 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Sep 2023 20:38:41 GMT
Subject: RFR: JDK-8246280: Refine API to model sealed classes and
 interfaces in javax.lang.model
In-Reply-To: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
References: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
Message-ID: <lzQtet2RQ0X2wRAeV09TFde5rOUKh8MqfxuYNKd9H64=.6ca770eb-0fc9-40f3-9fdb-c9659db8049f@github.com>

On Mon, 18 Sep 2023 19:34:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple specification clarification.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15795#pullrequestreview-1631924045

From darcy at openjdk.org  Mon Sep 18 20:42:51 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 18 Sep 2023 20:42:51 GMT
Subject: Integrated: JDK-8246280: Refine API to model sealed classes and
 interfaces in javax.lang.model
In-Reply-To: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
References: <v5XeOZZGCNZesMOniPXmXRNezF9XeRvJipRzJxp13gU=.76668a14-140f-4a1b-a94d-5fa7d3d954d3@github.com>
Message-ID: <dPfi45m20ldSvqU13q2N1rMFFC5_6RgsOguRrGZgaMc=.ea4eb7fd-50bb-48ed-adfc-8ffb2904e71b@github.com>

On Mon, 18 Sep 2023 19:34:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Simple specification clarification.

This pull request has now been integrated.

Changeset: 5308bbbc
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5308bbbcf8005560478d221d44f00fd2849d44f0
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8246280: Refine API to model sealed classes and interfaces in javax.lang.model

Reviewed-by: vromero, jjg

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

PR: https://git.openjdk.org/jdk/pull/15795

From josiahnoel at gmail.com  Tue Sep 19 23:04:57 2023
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 19 Sep 2023 19:04:57 -0400
Subject: [External] : Re: ModuleElement doesn't work with generated
 provides classes?
In-Reply-To: <CAJ_t5UagpwTT_yCgdhS11w-FoT=g9kf-ins8ijij+voFzn6goA@mail.gmail.com>
References: <CAJ_t5UZkYYg6x4UQXCyijnho1nFXa36k-CYOa7TR0kFWNYhNGw@mail.gmail.com>
 <CAJ_t5UYRFj087CUzWDTUUUYqRWku+Onk1qyetdsEPb8YZhSbTw@mail.gmail.com>
 <339a1558-cfe9-6ccf-cd66-1022b8f2340f@oracle.com>
 <CAJ_t5UZwkZth+PLDmDRfqiKuECZ7fcdpNw=dn2TiKdcbDapDGQ@mail.gmail.com>
 <CAJ_t5Ubw22HvZ_TXC9H7EyVKRsM6jZcp7hbvBtATDqaXzH_yLg@mail.gmail.com>
 <CAJ_t5Ub=WwkG3zazTXxWxUmBv05+LEpvCBh9tYQqxd4SCOtQsQ@mail.gmail.com>
 <447f1d85-4ece-0138-321b-3f3cec9f8b35@oracle.com>
 <CAJ_t5Uab-kWtF+8Pyo=od-JDKYfxw4mHc4=unCJCFjRfQC_eog@mail.gmail.com>
 <c8de83e1-b542-df51-2ec3-9b1104a0f781@oracle.com>
 <19baec94-8b9a-5824-7887-5ff2534a8892@oracle.com>
 <CAJ_t5UY9wKV0NhSzdbv=yZK3UQ2uQ5isx03-dGNdUo1_FzDZRQ@mail.gmail.com>
 <CAJ_t5UagpwTT_yCgdhS11w-FoT=g9kf-ins8ijij+voFzn6goA@mail.gmail.com>
Message-ID: <CAJ_t5UasepPNL=hGcGe8PPrQ8wu_kgxGnuJ4YM7-hTsBnnaApg@mail.gmail.com>

I see that the issue has moved to a resolved state, but I still have some
doubts. The original question was indeed about retrieving the
provides statements, and as the issue explains this is currently not
possible. I accept this.

 My main concern now is that compilation fails when getDirectives is called
for a project's ModuleElement. As expected I can receive everything except
the provides statements for the generated class, and yet compilation still
fails. Can anything be done to resolve this?

On Fri, Sep 1, 2023 at 8:00?AM Josiah Noel <josiahnoel at gmail.com> wrote:

> Or else if it's truly impossible to prevent the compilation error, a
> warning should be added to getDirectives so that people know it has a
> chance of breaking someone else's build in certain situations. I maintain a
> couple of processors that generate service implementations in the last
> round, so if people use one of them with another processor that uses
> getDirectives it will break their build with this cryptic(to them) error.
>
> On Mon, Aug 28, 2023 at 2:48?PM Josiah Noel <josiahnoel at gmail.com> wrote:
>
>> I see it has been partially fixed in a later version, and that the
>> problem only occurs if the service impl is generated in the last round. I
>> can tolerate not being able to explicitly see the `provides` statements,
>> but it's still a problem if merely calling `ModuleElement.getDirectives`
>> causes compilation to fail if services are generated in the last round. Is
>> there a way that we can make the behavior the same except not failing
>> compilation? (Currently I can see the requires just fine but the
>> compilation is doomed to fail)
>>
>> On Mon, Aug 28, 2023 at 2:05?PM Jonathan Gibbons <
>> jonathan.gibbons at oracle.com> wrote:
>>
>>> https://bugs.openjdk.org/browse/JDK-8315125
>>>
>>> -- Jon
>>> On 8/28/23 8:50 AM, Jonathan Gibbons wrote:
>>>
>>> I'll file a JBS issue to track this further.
>>>
>>> -- Jon
>>>
>>>
>>> On 8/28/23 8:35 AM, Josiah Noel wrote:
>>>
>>> Just tried explicitly adding a default constructor, but I still receive
>>> the same error.
>>>
>>> On Mon, Aug 28, 2023 at 11:29?AM Jonathan Gibbons <
>>> jonathan.gibbons at oracle.com> wrote:
>>>
>>>> The following error message seems relevant:
>>>>
>>>> /M:/Dev/module-directive-bug/blackbox-test-module/src/main/java/module-info.java:[6,41] the service implementation does not have
>>>> a default constructor: io.avaje.modules.example.GeneratedProvider
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 8/26/23 1:04 PM, Josiah Noel wrote:
>>>>
>>>> As requested, I have created a simple example to replicate this issue. SentryMan/module-directive-bug:
>>>> showcase annotation processing bug (github.com)
>>>> <https://urldefense.com/v3/__https://github.com/SentryMan/module-directive-bug/tree/master__;!!ACWV5N9M2RV99hQ!O3CMUWVsFHaaU7b9D1x_-4ByzBUrMMF0KeTPmtdnqOC1hRhhZCBO0dODJwf1rZsapQpTYmYktzo5W_0TwANTUZuu$>
>>>>
>>>> On Fri, Aug 25, 2023 at 9:00?PM Josiah Noel <josiahnoel at gmail.com>
>>>> wrote:
>>>>
>>>>> Say I got this module
>>>>>
>>>>> ```
>>>>>
>>>>> module nima.example {
>>>>>
>>>>> requires io.avaje.http.client;
>>>>>
>>>>> requires io.avaje.http.api;
>>>>>
>>>>> provides io.avaje.http.client.HttpClient.GeneratedComponent with
>>>>>
>>>>> com.jojo.helidon.api.client.httpclient.GeneratedHttpComponent;
>>>>>
>>>>> }
>>>>> ```
>>>>> and I generate com.jojo.helidon.api.client.httpclient.
>>>>> GeneratedHttpComponent in the last round of processing. When I get
>>>>> the module element during normal processing and so much as call
>>>>> `ModuleElement#getDirectives` and do nothing else, the processor will
>>>>> correctly generate, but compilation will still fail.(if I take out the
>>>>> module-info from the project it works though) I'm pretty sure it might have
>>>>> to do with the fact that GeneratedHttpComponent is created in the
>>>>> last round. Even so, not sure why it fails the compilation.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230919/3b7a2b54/attachment-0001.htm>

From acobbs at openjdk.org  Fri Sep 22 22:02:04 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 22 Sep 2023 22:02:04 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove obsolete flag "constructorArgs".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/a5510b79..599cf0e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=12-13

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

PR: https://git.openjdk.org/jdk/pull/13656

From liach at openjdk.org  Sat Sep 23 02:02:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Sep 2023 02:02:24 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
Message-ID: <Vz9vau8ydqintO9xugPT1Fp8v76CG0Dr7zPUSt0GrXs=.2dc452f0-9551-46de-b64d-f795ee013bdf@github.com>

On Fri, 22 Sep 2023 22:02:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete flag "constructorArgs".

In the latest update to [JEP 401](https://openjdk.org/jeps/401) [Value Objects](https://bugs.openjdk.org/browse/JDK-8251554), it proposes to reuse the pre-initialization context from here for its "regulated Constructors". However, the regulated context anticipates local classes to be static while our pre-initialization context currently declares local classes non-static (except interfaces, records, and enums, which are implicitly static) and thus cannot be used before super call. Should we make pre-initialization local classes static to ease the compiler implementation for "regulated Constructors" in the future?

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732179148

From acobbs at openjdk.org  Sat Sep 23 03:19:19 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 23 Sep 2023 03:19:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <Vz9vau8ydqintO9xugPT1Fp8v76CG0Dr7zPUSt0GrXs=.2dc452f0-9551-46de-b64d-f795ee013bdf@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Vz9vau8ydqintO9xugPT1Fp8v76CG0Dr7zPUSt0GrXs=.2dc452f0-9551-46de-b64d-f795ee013bdf@github.com>
Message-ID: <aFLgzstPdpqm3vi-IyAyZs714NDFaFCvvuYfSJh_YJc=.64c6edd1-4daa-4271-b625-7d4f728e63c6@github.com>

On Sat, 23 Sep 2023 01:59:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we make pre-initialization local classes static to ease the compiler implementation for "regulated Constructors" in the future?

I could be missing something but I don't see a potential problem.

All of the actions that would be prohibited in regulated constructors will be prohibited in a pre-construction context, so the compiler should already be doing the right thing.

If I understand your question, the particular action you're worried about is "Construction of an inner class with this as an implicit enclosing instance".

But that can't happen in a pre-construction context - you can _declare_ a local class in a pre-construction context, you just can't _instantiate_ it.

Here's an example:

public class Test {

    public int x;

    public Test() {
        class Local {
            { System.out.println(x); }
        }
        //new Local();     // would be illegal
        super();
        new Local();       // this is ok!
    }
}

Note, this is a subtlety that didn't exist before, because there was no way to declare a local class that required an outer instance before `super()` and then instantiate it after `super()`. Therefore, there was no reason to allow even the declaration such a class.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732194677

From liach at openjdk.org  Sat Sep 23 07:01:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Sep 2023 07:01:23 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
Message-ID: <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>

On Fri, 22 Sep 2023 22:02:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete flag "constructorArgs".

I understand what you mean, since you've clarified long ago. Instead, I mean this from JEP 401:
> Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance.

Currently local classes declared in pre-construction context have an enclosing instance, and I wonder if we can make them not require enclosing instances like in a static context. Local classes declared after the super/this delegate constructor call in source code will still have an enclosing instance.

I think there are already similar rules implemented for anonymous classes before this JEP, where the anonymous `Cat$1` (printing "Running") does not require an implicit `Cat` for its constructor while `Cat$2` (printing "Meow") does after compilation:

public class Cat extends Dog {
	public Cat() {
		super(new Runnable() {
			@Override
			public void run() {
				System.out.println("Running");
			}
		});

		new Runnable() {
			public void run() {
				System.out.println("Meow");
			}
		}.run();
	}

	public static void main(String... args) {
		new Cat();
	}
}

class Dog {
	Dog(Runnable action) {
		action.run();
	}
}

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732235419

From acobbs at openjdk.org  Sat Sep 23 15:19:12 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 23 Sep 2023 15:19:12 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
Message-ID: <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>

On Sat, 23 Sep 2023 06:57:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> I understand what you mean, since you've clarified long ago. Instead, I mean this from JEP 401:
> 
> > Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance.
> 
> Currently local classes declared in pre-construction context have an enclosing instance, and I wonder if we can make them not require enclosing instances like in a static context. Local classes declared after the super/this delegate constructor call in source code will still have an enclosing instance.

The problem is that this is not how the compiler currently behaves.

Consider this class:

public class Test {

    public Test(int x) {
    }

    public Test() {
        this(switch (0) {
          default -> {
            class Local {
            }
            yield 0;
          }
        });
    }
}

According to JLS 21 ?15.9.2, class `Local` does not have an enclosing instance.

Yet here is what's actually emitted by the compiler:

$ javap -classpath classes -c Test$1Local
Compiled from "Test.java"
class Test$1Local {
  final Test this$0;

  Test$1Local(Test);
    Code:
       0: aload_0
       1: aload_1
       2: putfield      #1                  // Field this$0:LTest;
       5: aload_0
       6: invokespecial #7                  // Method java/lang/Object."<init>":()V
       9: return
}

An explicit goal of JEP 447 is **any existing program must compile to the same bytecode**. So if we adhere to that goal, local classes declared in pre-construction contexts must have outer instances.

I think this is the most natural behavior anyway. Anonymous classes, with their "immediate enclosing instance with respect to superclass S", and their declare-and-instantiate-all-at-once property, are the oddballs. It's appropriate for them to have a special rule where their implicit outer instance "disappears" in a pre-construction context because it would never be possible to provide one.

So my suggestion is to alter this wording in JEP 401:

> Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error.
> 
> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields.

To this:

> Local classes may be declared, but since they require an enclosing instance, they can't be instantiated. Anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error.
> 
> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields.

Also:

> I think there are already similar rules implemented for anonymous classes before this JEP, where the anonymous `Cat$1` (printing "Running") does not require an implicit `Cat` for its constructor while `Cat$2` (printing "Meow") does after compilation:

As remarked above, anonymous classes are different. It's not possible to declare them in one place and instantiate them in another place, so they indeed will not have enclosing instances when declared in a pre-construction context but will have them otherwise, and this behavior is not changing.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732340240

From liach at openjdk.org  Sat Sep 23 15:30:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 23 Sep 2023 15:30:12 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
Message-ID: <CMJy-aq9JTSzcOjshndnalkz8-whGqH7cJG1AacC9WU=.05fb85fd-5842-4243-837b-e0b56ab3c8c8@github.com>

On Fri, 22 Sep 2023 22:02:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete flag "constructorArgs".

Sounds reasonable. We can always change pre-initialization context local classes in a later patch if Valhalla development deems it necessary, or create other mechanism if Valhalla finds pre-initialization context not a fit.

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

PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732342409

From mcimadamore at openjdk.org  Mon Sep 25 08:53:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 08:53:20 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
Message-ID: <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>

On Fri, 22 Sep 2023 22:02:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove obsolete flag "constructorArgs".

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 485:

> 483:         // Do something with all static or non-static field initializers and initialization blocks.
> 484:         // Note: This method also sends nested class definitions to the handler.
> 485:         protected void forEachInitializer(JCClassDecl classDef, boolean statik, Consumer<? super JCTree> handler) {

Suggestion:

        protected void forEachInitializer(JCClassDecl classDef, boolean isStatic, Consumer<? super JCTree> handler) {

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613:

> 4611:      * early accesses within a constructor prologue.
> 4612:      */
> 4613:     class RefBeforeCtorCalledError extends InvalidSymbolError {

Why doesn't this subclass StaticError?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335582828
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335580983

From duke at openjdk.org  Mon Sep 25 13:07:16 2023
From: duke at openjdk.org (Alex B)
Date: Mon, 25 Sep 2023 13:07:16 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v2]
In-Reply-To: <d87Dsm-R8iWGtUHSi8QxDwNrG_k6VWHDKxQd9wTbIHs=.15b8a6f5-ebe5-459f-9cf8-337ace6bcee4@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <d87Dsm-R8iWGtUHSi8QxDwNrG_k6VWHDKxQd9wTbIHs=.15b8a6f5-ebe5-459f-9cf8-337ace6bcee4@github.com>
Message-ID: <OMeGzM_SEuuM7SM5zlkmXkZmJWQ0YKYLqvjGuTy-bVY=.4040a669-5eaa-4bf0-a9ad-f08e466b5f7b@github.com>

On Wed, 13 Sep 2023 04:29:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8306819
>  - Updates for a clean test run.
>  - Merge branch 'master' into JDK-8306819
>  - Merge branch 'master' into JDK-8306819
>  - JDK-8306819: Consider disabling the compiler's default active annotation processing

Oh there is now a PR for my (bug) report. That's nice to see (although I somehow didn't get the notification for it lol).

Anyway here some additional information from my perspective:
<details><summary>Backstory of this issue</summary>

So a while ago we updated a project to Java 17 and we somehow got this error when using ``records``:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project maven-module-xxx: Compilation failure
[ERROR] D:\REDACTED\src\main\java\xxx\Job.java: Internal compiler error: java.lang.Exception: javax.lang.model.element.UnknownElementException: Unknown element: "de.xxx.Parameters" at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172)
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project maven-module-xxx: Compilation failure
D:\REDACTED\src\main\java\xxx\Job.java: Internal compiler error: java.lang.Exception: javax.lang.model.element.UnknownElementException: Unknown element: "de.xxx.Parameters" at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172)

    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
    at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
D:\REDACTED\src\main\java\xxx\Job.java: Internal compiler error: java.lang.Exception: javax.lang.model.element.UnknownElementException: Unknown element: "de.xxx.Parameters" at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172)

    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1310)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:198)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
    at org.codehaus.classworlds.Launcher.main (Launcher.java:47)


The error was kind of confusing and the only thing hinting to a annotation processor was the ``handleProcessor`` in the stacktrace.

As it later turned out this was caused by [``org.hibernate.validator:hibernate-validator-annotation-processor``](https://mvnrepository.com/artifact/org.hibernate.validator/hibernate-validator-annotation-processor) (? https://hibernate.atlassian.net/browse/HV-1863) which was somehow on the classpath.

So there was an annotation processor that was kind of magically executed with no log output so there was 0 chance of finding out that it was even executed, so that's one of the reasons why I created this issue.

</details>

<details><summary>About your discussion of AP pollutions in classpath</summary>

> > This aims to avoid unintentional AP pollutions in classpath, like if one AP is present in a dependency and thus your classpath but you don't want it to run.
> In practice is this a thing that happens? Most processors I've seen (like Lombok or record builder for example) are typically added as provided or optional scope dependencies. (and so cannot be transitively pulled)

> Is it really such a common thing that people accidentally include unrelated annotation processor dependencies transitively via maven?

I can show a very simple example:
[Log4J2s PluginProcessor](https://github.com/apache/logging-log4j2/blob/c7f0f15dd6d37fc8f23689b975163ec2df80a9ec/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/processor/PluginProcessor.java) (registered via Java Service Loading [here](https://github.com/apache/logging-log4j2/blob/c7f0f15dd6d37fc8f23689b975163ec2df80a9ec/log4j-core/src/main/resources/META-INF/services/javax.annotation.processing.Processor)) is likely included and executed in a lot of projects that don't require and know about it.

> Yes, in terms of good build hygiene, I recommend separately specifying the path for annotation processors and the path for general compiler dependencies, even if they happen to be the same path.

There is 2 problems with this statement:
1. The average developer that compiles with Maven oder Gradle doesn't know about this "good practice" and there is nothing hinting to it. Update: This is (partially) addressed with [JDK-8310061](https://bugs.openjdk.org/browse/JDK-8310061)
2. Even if this is the case and you split it into to separate "paths" there is no way in preventing e.g. Log4J2s PluginProcessor getting into the "general compiler dependencies" because it's inside log4j-core.jar (without this jar logging no longer works)

</details>

I again want to say that my intention was not to remove Annotation processing but simply considering disabling it by default due to the security concerns mentioned in the issue.

Also thank you for your efforts and the progress already done with [JDK-8310061](https://bugs.openjdk.org/browse/JDK-8310061) I think the new message is already a good step into the right direction :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1733668825

From vromero at openjdk.org  Mon Sep 25 13:18:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 25 Sep 2023 13:18:17 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v2]
In-Reply-To: <d87Dsm-R8iWGtUHSi8QxDwNrG_k6VWHDKxQd9wTbIHs=.15b8a6f5-ebe5-459f-9cf8-337ace6bcee4@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <d87Dsm-R8iWGtUHSi8QxDwNrG_k6VWHDKxQd9wTbIHs=.15b8a6f5-ebe5-459f-9cf8-337ace6bcee4@github.com>
Message-ID: <_e3XBjZHmJWDvHtbyWbDSUKhb-RiKsQO6uMdrSfrlMw=.37fe7af2-8a76-4dd0-bd33-09bc4e775551@github.com>

On Wed, 13 Sep 2023 04:29:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8306819
>  - Updates for a clean test run.
>  - Merge branch 'master' into JDK-8306819
>  - Merge branch 'master' into JDK-8306819
>  - JDK-8306819: Consider disabling the compiler's default active annotation processing

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14432#pullrequestreview-1642140535

From acobbs at openjdk.org  Mon Sep 25 13:35:11 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 13:35:11 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v15]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <e-IL_THh1_1arVuPjd3DxW-sKUuyhaKKdlXvxGW1K3I=.4c7ec85e-2211-4f3b-97ea-e8823187b6c4@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Change variable name "statik" -> "isStatic" per review recommendation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/599cf0e5..150d794c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=13-14

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From acobbs at openjdk.org  Mon Sep 25 13:35:15 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 13:35:15 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
Message-ID: <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>

On Mon, 25 Sep 2023 08:50:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove obsolete flag "constructorArgs".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 485:
> 
>> 483:         // Do something with all static or non-static field initializers and initialization blocks.
>> 484:         // Note: This method also sends nested class definitions to the handler.
>> 485:         protected void forEachInitializer(JCClassDecl classDef, boolean statik, Consumer<? super JCTree> handler) {
> 
> Suggestion:
> 
>         protected void forEachInitializer(JCClassDecl classDef, boolean isStatic, Consumer<? super JCTree> handler) {

Fixed in 150d794c1e6, thanks.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613:
> 
>> 4611:      * early accesses within a constructor prologue.
>> 4612:      */
>> 4613:     class RefBeforeCtorCalledError extends InvalidSymbolError {
> 
> Why doesn't this subclass StaticError?

In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335890156
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335887916

From abimpoudis at openjdk.org  Mon Sep 25 13:40:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 25 Sep 2023 13:40:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in patterns, 
 instanceof, and switch (Preview)
Message-ID: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>

This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).

Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

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

Commit messages:
 - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303374
  Stats: 2293 lines in 29 files changed: 2186 ins; 16 del; 91 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From mcimadamore at openjdk.org  Mon Sep 25 13:50:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 13:50:27 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
Message-ID: <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>

On Mon, 25 Sep 2023 13:25:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 4613:
>> 
>>> 4611:      * early accesses within a constructor prologue.
>>> 4612:      */
>>> 4613:     class RefBeforeCtorCalledError extends InvalidSymbolError {
>> 
>> Why doesn't this subclass StaticError?
>
> In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`.

I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335916998

From acobbs at openjdk.org  Mon Sep 25 13:58:17 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 13:58:17 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
 <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
Message-ID: <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>

On Mon, 25 Sep 2023 13:47:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> In the new specification, constructor prologues are no longer considered a static context. Instead they're a pre-construction context (new concept). So emitting an error that says something "cannot be referenced from a static context" would be wrong. The new exception class `RefBeforeCtorCalledError` is intended to be the pre-construction context analogue of `StaticError`.
>
> I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic.

Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335927718

From mcimadamore at openjdk.org  Mon Sep 25 14:06:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 14:06:15 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
 <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
 <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>
Message-ID: <VtKdnvaMHfDEne3iBhbdCbp57JedCYGOr_PTh-rYSy8=.086529f1-d752-4db2-aa46-f7344390bbd4@github.com>

On Mon, 25 Sep 2023 13:55:44 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> I'm aware of that - but I note that the implementation uses a STATIC_ERR under the hood. Hence my comment on using a custom static error with a custom diagnostic.
>
> Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks.

The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.:


final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) {
            return phase.ordinal() > maxPhase.ordinal() ||
                 !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR;
        }


E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335937230

From acobbs at openjdk.org  Mon Sep 25 14:30:20 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 14:30:20 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <VtKdnvaMHfDEne3iBhbdCbp57JedCYGOr_PTh-rYSy8=.086529f1-d752-4db2-aa46-f7344390bbd4@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
 <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
 <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>
 <VtKdnvaMHfDEne3iBhbdCbp57JedCYGOr_PTh-rYSy8=.086529f1-d752-4db2-aa46-f7344390bbd4@github.com>
Message-ID: <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com>

On Mon, 25 Sep 2023 14:02:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Oh I see. Hmm, I'll admit ignorance on how exactly these `Kind` enum error values like `STATICERR`, `HIDDEN`, etc. are used. Is there a better `Kind` choice for this error? Or does this warrant a new `Kind` value? In the latter case, there is a scary warning about ordering of the enum values so any advice appreciated. Thanks.
>
> The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.:
> 
> 
> final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) {
>             return phase.ordinal() > maxPhase.ordinal() ||
>                  !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR;
>         }
> 
> 
> E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery).

OK got it. So what if we did this instead?

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 295bb192a42..4c7c177163f 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -4576,7 +4587,11 @@ JCDiagnostic inaccessiblePackageReason(Env<AttrContext> env, PackageSymbol sym)
     class StaticError extends InvalidSymbolError {
 
         StaticError(Symbol sym) {
-            super(STATICERR, sym, "static error");
+            this(sym, "static error");
+        }
+
+        StaticError(Symbol sym, String debugName) {
+            super(STATICERR, sym, debugName);
         }
 
         @Override
@@ -4595,6 +4610,32 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
         }
     }
 
+    /**
+     * Specialization of {@link InvalidSymbolError} for illegal
+     * early accesses within a constructor prologue.
+     */
+    class RefBeforeCtorCalledError extends StaticError {
+
+        RefBeforeCtorCalledError(Symbol sym) {
+            super(sym, "prologue error");
+        }
+
+        @Override
+        JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
+                DiagnosticPosition pos,
+                Symbol location,
+                Type site,
+                Name name,
+                List<Type> argtypes,
+                List<Type> typeargtypes) {
+            Symbol errSym = ((sym.kind == TYP && sym.type.hasTag(CLASS))
+                ? types.erasure(sym.type).tsym
+                : sym);
+            return diags.create(dkind, log.currentSource(), pos,
+                    "cant.ref.before.ctor.called", errSym);
+        }
+    }
+
     /**
      * InvalidSymbolError error class indicating that a pair of symbols
      * (either methods, constructors or operands) are ambiguous
@@ -4708,7 +4749,7 @@ class BadMethodReferenceError extends StaticError {
         boolean unboundLookup;
 
         public BadMethodReferenceError(Symbol sym, boolean unboundLookup) {
-            super(sym);
+            super(sym, "bad method ref error");
             this.unboundLookup = unboundLookup;
         }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1335969649

From abimpoudis at openjdk.org  Mon Sep 25 15:04:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 25 Sep 2023 15:04:00 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
Message-ID: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>

8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Commit messages:
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

Changes: https://git.openjdk.org/jdk/pull/15649/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315532
  Stats: 176 lines in 34 files changed: 37 ins; 37 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From mcimadamore at openjdk.org  Mon Sep 25 15:10:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 15:10:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
 <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
 <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>
 <VtKdnvaMHfDEne3iBhbdCbp57JedCYGOr_PTh-rYSy8=.086529f1-d752-4db2-aa46-f7344390bbd4@github.com>
 <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com>
Message-ID: <w8TTUQfPmFjuSUT28JiRdb6QfsReiQC2Y6PmwM_udhA=.dbae4469-79f6-4e96-9b78-daa03bd5957f@github.com>

On Mon, 25 Sep 2023 14:27:04 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The kind is used in some other parts of Resolve to determine whether some errors should be skipped in some places, or recovered from. I'd advise against creating a new error kind, which might end up invalidating some existing check which depend on STATICERR. E.g.:
>> 
>> 
>> final boolean shouldStop(Symbol sym, MethodResolutionPhase phase) {
>>             return phase.ordinal() > maxPhase.ordinal() ||
>>                  !sym.kind.isResolutionError() || sym.kind == AMBIGUOUS || sym.kind == STATICERR;
>>         }
>> 
>> 
>> E.g. you don't want overload resolution to try new candidates because you tried to call a method and you don't have a `this` - e.g. the compiler behavior should be similar as to when an instance method is called and no `this` is available (meaning: the found method is correct, and the error should be reported, no attempt should be made at recovery).
>
> OK got it. So what if we did this instead?
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> index 295bb192a42..4c7c177163f 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
> @@ -4576,7 +4587,11 @@ JCDiagnostic inaccessiblePackageReason(Env<AttrContext> env, PackageSymbol sym)
>      class StaticError extends InvalidSymbolError {
>  
>          StaticError(Symbol sym) {
> -            super(STATICERR, sym, "static error");
> +            this(sym, "static error");
> +        }
> +
> +        StaticError(Symbol sym, String debugName) {
> +            super(STATICERR, sym, debugName);
>          }
>  
>          @Override
> @@ -4595,6 +4610,32 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
>          }
>      }
>  
> +    /**
> +     * Specialization of {@link InvalidSymbolError} for illegal
> +     * early accesses within a constructor prologue.
> +     */
> +    class RefBeforeCtorCalledError extends StaticError {
> +
> +        RefBeforeCtorCalledError(Symbol sym) {
> +            super(sym, "prologue error");
> +        }
> +
> +        @Override
> +        JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
> +                DiagnosticPosition pos,
> +                Symbol location,
> +                Type site,
> +                Name name,
> +                List<Type> argtypes,
> +                List<Type> typeargtypes) {
> +            Symbol errSym = ((sym.kind == TYP && sym.type.hasTag(CLASS))
> +                ? types.erasure(sym.type).tsym
> +                : sym);
> +            return diags.create(dkind, log.currentSource(), pos,
> +                    "cant.ref.before.ctor.called", errSym);
> +        }
> +    }
> +
>      /**
>       * InvalidSymbolError error class indicating that a pair of symbols
>       * (either methods, constructors or operands) are ambiguous
> @@ -4708,7 +4749,7 @@ class BadMethodReferenceError extends StaticError {
>          boolean unboundLookup;
>  
>          public BadMethodReferenceError(Symbol sym, boolean unboundLookup) {
> -            super(sym);
> +            super(sym, "bad method ref error");
>              this.unboundLookup = unboundLookup;
>          }

Yes, I think that is what I was referring to. Thanks for the patience.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336028332

From acobbs at openjdk.org  Mon Sep 25 16:04:09 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 16:04:09 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Have RefBeforeCtorCalledError extend StaticError and customize debug strings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/150d794c..3e75e19e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=14-15

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From acobbs at openjdk.org  Mon Sep 25 16:04:12 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 16:04:12 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <w8TTUQfPmFjuSUT28JiRdb6QfsReiQC2Y6PmwM_udhA=.dbae4469-79f6-4e96-9b78-daa03bd5957f@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <VOoa1G_uVMVw_sQ-mPLvbmcmCiy6jlJrhe6lulHoT4s=.3b0f8c90-2251-4fd5-96b7-14cafdac45e7@github.com>
 <aDKahL9hEMPFXS-VKMV0Gg-11uoVqhFeX_gl1TLpROc=.e95db01c-a2cb-46a2-b790-54690ec84e3c@github.com>
 <XyoE1D4iYVyvnEdb8GcUgAYIuZ7nyZXgd87WlP5llwY=.6ce836d2-4072-452c-88d8-1bd3f7ecf964@github.com>
 <8bUJmJFTQDUHBxSL7gPXVdiQ4rqq5H0DgwNhMNgisUk=.2cc0c732-ef69-427b-996f-cefa90d1bf5d@github.com>
 <VtKdnvaMHfDEne3iBhbdCbp57JedCYGOr_PTh-rYSy8=.086529f1-d752-4db2-aa46-f7344390bbd4@github.com>
 <_ovfBS7NlI8s2JxQlQtchzHzbg5VNyfyV-6qmyvGY84=.c3e7ef1a-525f-4b6b-995e-3da3c3b61f67@github.com>
 <w8TTUQfPmFjuSUT28JiRdb6QfsReiQC2Y6PmwM_udhA=.dbae4469-79f6-4e96-9b78-daa03bd5957f@github.com>
Message-ID: <wtDlHukXYNKpwYzZ9KfVzBbHXFBBmvqnemzP7N_gMUE=.9bc339c4-37dd-4f75-87f2-6f7949e2bc79@github.com>

On Mon, 25 Sep 2023 15:06:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> OK got it. So what if we did this instead?
>> 
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
>> index 295bb192a42..4c7c177163f 100644
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
>> @@ -4576,7 +4587,11 @@ JCDiagnostic inaccessiblePackageReason(Env<AttrContext> env, PackageSymbol sym)
>>      class StaticError extends InvalidSymbolError {
>>  
>>          StaticError(Symbol sym) {
>> -            super(STATICERR, sym, "static error");
>> +            this(sym, "static error");
>> +        }
>> +
>> +        StaticError(Symbol sym, String debugName) {
>> +            super(STATICERR, sym, debugName);
>>          }
>>  
>>          @Override
>> @@ -4595,6 +4610,32 @@ JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
>>          }
>>      }
>>  
>> +    /**
>> +     * Specialization of {@link InvalidSymbolError} for illegal
>> +     * early accesses within a constructor prologue.
>> +     */
>> +    class RefBeforeCtorCalledError extends StaticError {
>> +
>> +        RefBeforeCtorCalledError(Symbol sym) {
>> +            super(sym, "prologue error");
>> +        }
>> +
>> +        @Override
>> +        JCDiagnostic getDiagnostic(JCDiagnostic.DiagnosticType dkind,
>> +                DiagnosticPosition pos,
>> +                Symbol location,
>> +                Type site,
>> +                Name name,
>> +                List<Type> argtypes,
>> +                List<Type> typeargtypes) {
>> +            Symbol errSym = ((sym.kind == TYP && sym.type.hasTag(CLASS))
>> +                ? types.erasure(sym.type).tsym
>> +                : sym);
>> +            return diags.create(dkind, log.currentSource(), pos,
>> +                    "cant.ref.before.ctor.called", errSym);
>> +        }
>> +    }
>> +
>>      /**
>>       * InvalidSymbolError error class indicating that a pair of symbols
>>       * (either methods, constructors or operands) are ambiguous
>> @@ -4708,7 +4749,7 @@ class BadMethodReferenceError extends StaticError {
>>          boolean unboundLookup;
>>  
>>          public BadMethodReferenceError(Symbol sym, boolean unboundLookup) {
>> -            super(sym);
>> +            super(sym, "bad method ref error");
>>              this.unboundLookup = unboundLookup;
>>          }
>
> Yes, I think that is what I was referring to. Thanks for the patience.

Great - fixed in 3e75e19e230. Thanks for the mini-lesson :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336094981

From alex.buckley at oracle.com  Mon Sep 25 16:35:25 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 25 Sep 2023 09:35:25 -0700
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
 <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>
Message-ID: <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com>

Hi Archie,

Anything concerning the science of when nested classes have enclosing 
instances is pretty scary, so I'd like to make sure we're all heading in 
the same direction.

On 9/23/2023 8:19 AM, Archie Cobbs wrote:
> public class Test {
>      public Test(int x) {
>      }
> 
>      public Test() {
>          this(switch (0) {
>            default -> {
>              class Local {
>              }
>              yield 0;
>            }
>          });
>      }
> }
> 
> According to JLS 21 ?15.9.2, class `Local` does not have an enclosing instance.
> 
> Yet here is what's actually emitted by the compiler:
> 
> $ javap -classpath classes -c Test$1Local
> Compiled from "Test.java"
> class Test$1Local {
>    final Test this$0;
> 
>    Test$1Local(Test);
>      Code:
>         0: aload_0
>         1: aload_1
>         2: putfield      #1                  // Field this$0:LTest;
>         5: aload_0
>         6: invokespecial #7                  // Method java/lang/Object."<init>":()V
>         9: return
> }

JLS 15.9.2 says what happens when an inner local class is instantiated, 
but does not determine whether Local is declared as inner in the first 
place. JLS 8.1.3 is where we find that Local is specified to be inner 
(because it is not implicitly static). So, javac's emission of 
Test$1Local is in line with the JLS -- great!

> An explicit goal of JEP 447 is **any existing program must compile to
> the same bytecode**. So if we adhere to that goal, local classes
> declared in pre-construction contexts must have outer instances.
I don't see this explicit goal stated in JEP 447. There's a sentence 
about compilation in Testing -- "We will compile all JDK classes using 
the previous and new versions of the compiler and verify that the 
resulting bytecode is identical." -- but that sounds merely like a 
nice-to-have property, and one which holds only for JDK classes.

If 100% class file compatibility for all existing source code is a goal, 
then please say that in the Goals and give an example in the 
Description. ("compiles to same bytecode" is actually a higher bar than 
binary compatibility, which is why I didn't say "100% binary 
compatibility".)

> I think this is the most natural behavior anyway. Anonymous classes,
> with their "immediate enclosing instance with respect to superclass S",
> and their declare-and-instantiate-all-at-once property, are the
> oddballs. It's appropriate for them to have a special rule where their
> implicit outer instance "disappears" in a pre-construction context
> because it would never be possible to provide one.

I'm not, per se, disagreeing with specifying that local classes declared 
in a pre-construction context are inner. It's certainly attractive from 
a compatibility POV to be able to move a local class declaration around 
within a constructor body (maybe before super(..)/this(..), maybe after) 
and observe no class file change because the local class is always inner 
(unless it's a local enum class or local record class of course). On the 
other hand, we have to guarantee that no instantiation of the local 
class is possible before super(..)/this(..) has completed normally. 
Here's a program that tries to instantiate a Local which observes x with 
a value other than 5. What does the JLS say about the program? What does 
javac do?

public class Test {
     public int x = 5;
     public Test(int i) {}

     public Test() {
         class Local {
             { System.out.println(x); }
         }
         try {
             this(switch (0) { default -> throw new Exception(); });
         } finally {
             new Local();  // Legal or illegal?
         }
     }
}

Don't worry about JEP 401 until JEP 447 has thoroughly clarified the 
matter of whether such local classes are inner or not.

Alex

> So my suggestion is to alter this wording in JEP 401:
> 
>> Local and anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error.
>>
>> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields.
> 
> To this:
> 
>> Local classes may be declared, but since they require an enclosing instance, they can't be instantiated. Anonymous classes may be declared, but (as in a static context) they have no enclosing instance. Inner classes may refer to enclosing instances or captured enclosing variables from their own regulated constructors without error.
>>
>> These rules coincide with the restrictions imposed in a pre-construction context, as described by [JEP 447](https://openjdk.org/jeps/447), except that they allow for writes to instance fields.
> 
> Also:
> 
>> I think there are already similar rules implemented for anonymous classes before this JEP, where the anonymous `Cat$1` (printing "Running") does not require an implicit `Cat` for its constructor while `Cat$2` (printing "Meow") does after compilation:
> 
> As remarked above, anonymous classes are different. It's not possible to declare them in one place and instantiate them in another place, so they indeed will not have enclosing instances when declared in a pre-construction context but will have them otherwise, and this behavior is not changing.
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/13656#issuecomment-1732340240

From mcimadamore at openjdk.org  Mon Sep 25 16:53:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 16:53:22 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
Message-ID: <O5ToVHHk8EFlrl0-RflkUxV1vT74ek2ssRkDe0iyYac=.22aa6ad5-c934-49dd-a566-93488ca31ca4@github.com>

On Fri, 7 Jul 2023 18:32:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into SuperInit
>>  - Fix mistake in previous merge commit 80ba6be4.
>>  - Merge branch 'master' into SuperInit
>>  - Rename unit test to be consistent with other feature exampless.
>>  - Update unit test after merged-in commit eaa80ad08.
>>  - Add unit tests with local class decl's prior to super().
>>  - Merge branch 'master' into SuperInit
>>  - Use @enablePreview in tests in preference to explicit command line flags.
>>  - Make "statements before super()" support a preview feature.
>>    
>>    Thanks to Jim Laskey for help with preview logic.
>>  - Small refactoring to avoid redundant test.
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c0aa6bf4...a5f8cc5e
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975:
> 
>> 3973:     }
>> 3974: 
>> 3975:     private class SuperThisChecker extends TreeScanner {
> 
> we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary

Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336156335

From mcimadamore at openjdk.org  Mon Sep 25 17:02:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:02:17 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
Message-ID: <I3KHkQeXJ3b-mWJBT16ZhvH2-SosfZdpa-zmfj8si4Y=.672ab5f3-f0e5-4644-b11a-b39e568158c1@github.com>

On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3971:

> 3969: 
> 3970:         // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation
> 3971:         private static final int MATCH_SCAN_DEPTH = 3;

This logic seems a bit fragile in that it relies on the shape of the AST. Also, in principle you can create something that will overflow the int, and will cause the check to spuriously pass for a very very very large number of nested expressions :-)

That said, I understand that, in order to make this code "tighter", you would need to override al visitors that can "nest" code inside other code, which is also not great.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336166162

From mcimadamore at openjdk.org  Mon Sep 25 17:07:17 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:07:17 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
Message-ID: <aQ3bk7LBZNmSLZLfNyxdugKKPPEmUDxd2XSzZn6euYU=.91a62294-406b-4dfa-8cb2-71179451646e@github.com>

On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1511:

> 1509:                     if (staticOnly)
> 1510:                         return new StaticError(sym);
> 1511:                     if (env1.info.ctorPrologue && (sym.flags_field & SYNTHETIC) == 0)

where does the SYNTHETIC check comes from?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016:

> 2014:                         if (staticOnly)
> 2015:                             return new StaticError(sym);
> 2016:                         if (env1.info.ctorPrologue && env1 == env)

where does `env1 == env` come from?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336170440
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336170745

From jlahoda at openjdk.org  Mon Sep 25 17:13:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 25 Sep 2023 17:13:19 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>

On Sat, 9 Sep 2023 00:02:20 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR finalizes the feature of unnamed variables and patterns.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
> `$ git checkout pull/15649`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/15649` \
> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 15649`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 15649`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/15649.diff">https://git.openjdk.org/jdk/pull/15649.diff</a>
> 
> </details>
> 
> 
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)

Overall, looks reasonable to me. A few comments/suggestions for your consideration inline.

test/langtools/tools/javac/T8314423.java line 5:

> 3:  * @bug 8314423
> 4:  * @summary Multiple patterns without unnamed variables
> 5:  * @compile T8314423.java

I think I would keep the existing `@compile` as well, with `--release 21`, to verify the source level checks are working.

test/langtools/tools/javac/diags/examples/UnderscoreAsIdentifierError.java line 26:

> 24: // key: compiler.err.underscore.as.identifier
> 25: // key: compiler.warn.source.no.system.modules.path
> 26: // options: -source 20

Nit: either `-Xlint:-options -source 21`, or `--release 21`, and drop the `warn.source.no.system.modules.path`.

test/langtools/tools/javac/diags/examples/UnderscoreInLambdaExpression.java line 24:

> 22:  */
> 23: 
> 24: // options: -Xlint:preview

`-Xlint:preview` is probably unnecessary here.

test/langtools/tools/javac/diags/examples/UseOfUnderscoreNotAllowedWithBrackets.java line 25:

> 23: 
> 24: // key: compiler.err.use.of.underscore.not.allowed.with.brackets
> 25: // options: -Xlint:preview

The `-Xlint:preview` is probably unnecessary here.

test/langtools/tools/javac/lambda/IdentifierTest.java line 7:

> 5:  * @summary Test generation of warnings when '_' is used an identifier
> 6:  * @compile/fail/ref=IdentifierTest8.out --release 8 -Werror -XDrawDiagnostics -Xlint:-options IdentifierTest.java
> 7:  * @compile/fail/ref=IdentifierTest9.out -XDrawDiagnostics IdentifierTest.java

Note here we are using `ref=IdentifierTest9.out`, but there's no `--release 9` (or `--release 21`). So, it is the same as the next line. I think it would be useful if one of these lines used `--release 21` - even if the outputs are the same.

test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:

> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed

Note the errors are like:

/home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
        for(String _s : _ ) {
                        ^
  unnamed patterns, local variables, exception parameters or lambda parameters


At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).

Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.

So, maybe something like:


underscore not allowed here
as of release 9, ''_'' is a keyword, and may not be used as an identifier
as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters

?
Just an idea.

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

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1642635025
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336168133
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336173607
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336171867
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336169144
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336171079
PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336165928

From archie.cobbs at gmail.com  Mon Sep 25 17:13:10 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 25 Sep 2023 12:13:10 -0500
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v14]
In-Reply-To: <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
 <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>
 <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com>
Message-ID: <CANSoFxvEZP6Pgw+OXWDLeh-O=zTkx+=seQ2bPVtd6vd-BvRWjQ@mail.gmail.com>

Hi Alex,


> > An explicit goal of JEP 447 is **any existing program must compile to
> > the same bytecode**. So if we adhere to that goal, local classes
> > declared in pre-construction contexts must have outer instances.
> I don't see this explicit goal stated in JEP 447. There's a sentence
> about compilation in Testing -- "We will compile all JDK classes using
> the previous and new versions of the compiler and verify that the
> resulting bytecode is identical." -- but that sounds merely like a
> nice-to-have property, and one which holds only for JDK classes.
>

You're right.. the stated goal is actually "Do not change the behavior of
any existing program."

Making sure the emitted bytecode matches is just one way to accomplish that
goal (and possibly overkill).

> I think this is the most natural behavior anyway. Anonymous classes,
> > with their "immediate enclosing instance with respect to superclass S",
> > and their declare-and-instantiate-all-at-once property, are the
> > oddballs. It's appropriate for them to have a special rule where their
> > implicit outer instance "disappears" in a pre-construction context
> > because it would never be possible to provide one.
>
> I'm not, per se, disagreeing with specifying that local classes declared
> in a pre-construction context are inner. It's certainly attractive from
> a compatibility POV to be able to move a local class declaration around
> within a constructor body (maybe before super(..)/this(..), maybe after)
> and observe no class file change because the local class is always inner
> (unless it's a local enum class or local record class of course).


Agreed.


> On the other hand, we have to guarantee that no instantiation of the local
> class is possible before super(..)/this(..) has completed normally.
>

Yes.. and same thing for non-static member classes, so this is not special
to local classes.

Don't worry about JEP 401 until JEP 447 has thoroughly clarified the
> matter of whether such local classes are inner or not.
>

Thanks - so yes that central question remains... how should we treat local
classes in pre-construction contexts?

The current implementation answers this question "they are inner classes
with outer instances just like they would be in any other non-static
location".

Admittedly that answer was chosen in part because it is the most
conservative change (in particular, it produces the same bytecode).

But OK let's be a little bolder and ask what would be the BEST change?

My latest thinking is we should just allow local classes to be declared
"static".

Then "class Local" gives the current behavior (always having an outer
instance in a non-static context), while "static class Local" gives the
same behavior as a static member class.

You could then declare AND instantiate a static local class in a
pre-construction context - might be handy for doing pre-construction
"housekeeping".

Plus, this simplifies a developer's mental model for the various types of
classes, because now local classes and member classes are the same, except
of course for their lexical location and scope.

This would be the best of both worlds... ?

Here's a program that tries to instantiate a Local which observes x with
> a value other than 5. What does the JLS say about the program?


JLS says this()/super() have to be "top level", so they can't be inside a try
{ } block.


> What does javac do?
>

Test.java:10: error: switch expression does not have any result expressions
             this(switch (0) { default -> throw new Exception(); });
                  ^
Test.java:12: error: cannot reference this before supertype constructor has
been called
             new Local();  // Legal or illegal?
             ^
Test.java:10: error: calls to this() not allowed here
             this(switch (0) { default -> throw new Exception(); });
                 ^
3 errors

(The first error can be worked around by inserting case 1 -> 2; of course).

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230925/4f24a1d2/attachment-0001.htm>

From vromero at openjdk.org  Mon Sep 25 17:23:15 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 25 Sep 2023 17:23:15 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <O5ToVHHk8EFlrl0-RflkUxV1vT74ek2ssRkDe0iyYac=.22aa6ad5-c934-49dd-a566-93488ca31ca4@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
 <O5ToVHHk8EFlrl0-RflkUxV1vT74ek2ssRkDe0iyYac=.22aa6ad5-c934-49dd-a566-93488ca31ca4@github.com>
Message-ID: <qIU09v7p-bCyc-HttG4tG7zXyVesTRoFvaCDIHpl1wo=.22b80bca-c854-49b8-8bf9-6d1f594cb1fe@github.com>

On Mon, 25 Sep 2023 16:50:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3975:
>> 
>>> 3973:     }
>>> 3974: 
>>> 3975:     private class SuperThisChecker extends TreeScanner {
>> 
>> we usually create only one instance of these type of visitors that will be used very often and reuse it whenever necessary
>
> Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ?

yes @mcimadamore I see your point. And after my comments I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code I agree that in this case it could be better to avoid having mutable state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336185385

From mcimadamore at openjdk.org  Mon Sep 25 17:23:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:23:18 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <aQ3bk7LBZNmSLZLfNyxdugKKPPEmUDxd2XSzZn6euYU=.91a62294-406b-4dfa-8cb2-71179451646e@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <aQ3bk7LBZNmSLZLfNyxdugKKPPEmUDxd2XSzZn6euYU=.91a62294-406b-4dfa-8cb2-71179451646e@github.com>
Message-ID: <jgFZaYjg--nLZD87BG6uSSqWDFvvRZNt5opanfUau8A=.c95edaee-2b35-418a-891c-949175ce449a@github.com>

On Mon, 25 Sep 2023 17:04:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016:
> 
>> 2014:                         if (staticOnly)
>> 2015:                             return new StaticError(sym);
>> 2016:                         if (env1.info.ctorPrologue && env1 == env)
> 
> where does `env1 == env` come from?

Should this work?

class Test {
    String s = "Hello";

    void m() {
        System.out.println("Hello");
    }

    class Inner {
        Inner() {
            m();
            super();
        }
    }

    public static void main(String[] args) {
        new Test().new Inner();
    }
}

The proposed changes accept this program. But I can't find supporting text in the JLS changes:
https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336182611

From mcimadamore at openjdk.org  Mon Sep 25 17:40:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:40:24 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <jgFZaYjg--nLZD87BG6uSSqWDFvvRZNt5opanfUau8A=.c95edaee-2b35-418a-891c-949175ce449a@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <aQ3bk7LBZNmSLZLfNyxdugKKPPEmUDxd2XSzZn6euYU=.91a62294-406b-4dfa-8cb2-71179451646e@github.com>
 <jgFZaYjg--nLZD87BG6uSSqWDFvvRZNt5opanfUau8A=.c95edaee-2b35-418a-891c-949175ce449a@github.com>
Message-ID: <pns4PxVK3DWClegPcp_eBxTezhvWhxBRk40HdnH2MIA=.1374d588-fcab-4098-b69e-058a275e86fb@github.com>

On Mon, 25 Sep 2023 17:17:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 2016:
>> 
>>> 2014:                         if (staticOnly)
>>> 2015:                             return new StaticError(sym);
>>> 2016:                         if (env1.info.ctorPrologue && env1 == env)
>> 
>> where does `env1 == env` come from?
>
> Should this work?
> 
> class Test {
>     String s = "Hello";
> 
>     void m() {
>         System.out.println("Hello");
>     }
> 
>     class Inner {
>         Inner() {
>             m();
>             super();
>         }
>     }
> 
>     public static void main(String[] args) {
>         new Test().new Inner();
>     }
> }
> 
> The proposed changes accept this program. But I can't find supporting text in the JLS changes:
> https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html

After some internal discussion, it is good for javac to accept this, as this case can be supported using the `this$0` parameter that is passed into the constructor of `Inner` (no `this` reference is strictly required). But the JLS text supporting this seems ambiguous:


The pre-construction context includes the prologue of the constructor 8.8.7 and the explicit constructor invocation itself. Within a pre-construction context, constructs that refer explicitly or implicitly to the current object are disallowed.


It is not clear to me as to whether `m()` refers to the current object or not - as it seems one would have to have intimate knowledge of how the compiler translates the code in order to answer that question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336196630

From mcimadamore at openjdk.org  Mon Sep 25 17:56:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:56:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
Message-ID: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>

On Mon, 25 Sep 2023 16:04:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This is a first draft of a patch for JEP 447.
>> 
>> Summary of changes:
>> 
>> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
>> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
>> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
>> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
>> 
>> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
>> 
>> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.

Overall, this is a very good patch. Not only it adds a new feature (which I found myself reaching for several times), but it also does so by consolidating a bunch of logic in the compiler code. Well done!

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 238:

> 236: # 0: name
> 237: compiler.err.call.must.only.appear.in.ctor=\
> 238:     calls to {0}() may only appear within constructors

Note that super()/this() in the JLS lingo is called "explicit constructor invocation".

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 245:

> 243: 
> 244: # 0: name
> 245: compiler.err.calls.not.allowed.here=\

The compiler message key seems overly general. maybe `constructor.call.not.allowed.here` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 250:

> 248: # 0: name
> 249: compiler.err.return.before.superclass.initialized=\
> 250:     ''return'' not allowed prior to {0}()

We have no other match in this file for `prior to`, but we do have matches for `before`. I suggest using the latter for a more consistent style.

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

PR Review: https://git.openjdk.org/jdk/pull/13656#pullrequestreview-1642717335
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336211699
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336213538
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336214539

From mcimadamore at openjdk.org  Mon Sep 25 17:56:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:56:24 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
Message-ID: <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>

On Mon, 25 Sep 2023 17:47:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 238:
> 
>> 236: # 0: name
>> 237: compiler.err.call.must.only.appear.in.ctor=\
>> 238:     calls to {0}() may only appear within constructors
> 
> Note that super()/this() in the JLS lingo is called "explicit constructor invocation".

@GavinBierman do you think the compiler message should mention the official JLS terminology?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336212292

From mcimadamore at openjdk.org  Mon Sep 25 17:56:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 17:56:25 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
 <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>
Message-ID: <pV-13lX3dvoRIx7cBWpACVba9m34bVpPCuyGtj-Z5Fg=.adcea474-2908-4ade-9c49-3c907da915d4@github.com>

On Mon, 25 Sep 2023 17:48:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 238:
>> 
>>> 236: # 0: name
>>> 237: compiler.err.call.must.only.appear.in.ctor=\
>>> 238:     calls to {0}() may only appear within constructors
>> 
>> Note that super()/this() in the JLS lingo is called "explicit constructor invocation".
>
> @GavinBierman do you think the compiler message should mention the official JLS terminology?

For instance:


explicit constructor invocation may only appear within constructors



redundant explicit constructor invocation



explicit constructor invocation not allowed here



'return'' not allowed before explicit constructor invocation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336216414

From acobbs at openjdk.org  Mon Sep 25 17:56:23 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 17:56:23 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <I3KHkQeXJ3b-mWJBT16ZhvH2-SosfZdpa-zmfj8si4Y=.672ab5f3-f0e5-4644-b11a-b39e568158c1@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <I3KHkQeXJ3b-mWJBT16ZhvH2-SosfZdpa-zmfj8si4Y=.672ab5f3-f0e5-4644-b11a-b39e568158c1@github.com>
Message-ID: <PHsJ-JHZZ2sL-2eCREAIw8NwyEDjK1idYqqJlAFGm_Y=.9334ea25-ee67-455e-a117-56aead674012@github.com>

On Mon, 25 Sep 2023 16:59:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3971:
> 
>> 3969: 
>> 3970:         // Match this scan stack: 1=JCMethodDecl, 2=JCExpressionStatement, 3=JCMethodInvocation
>> 3971:         private static final int MATCH_SCAN_DEPTH = 3;
> 
> This logic seems a bit fragile in that it relies on the shape of the AST. Also, in principle you can create something that will overflow the int, and will cause the check to spuriously pass for a very very very large number of nested expressions :-)
> 
> That said, I understand that, in order to make this code "tighter", you would need to override al visitors that can "nest" code inside other code, which is also not great.

Agree about this appearing fragile. The thinking was that, well, the JLS rule for this is simply:

> _ConstructorBody:_
>     { [_BlockStatements_] } 
>     { [_BlockStatements_] _ExplicitConstructorInvocation_ [_BlockStatements_] }

So this tries to mirror exactly that in the most direct way. The fragility comes from the possibility of some unexpected change to the AST class model... but at least if that ever did happen, you would probably get a clear warning when a bunch of JDK code stopped compiling :)

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 1511:
> 
>> 1509:                     if (staticOnly)
>> 1510:                         return new StaticError(sym);
>> 1511:                     if (env1.info.ctorPrologue && (sym.flags_field & SYNTHETIC) == 0)
> 
> where does the SYNTHETIC check comes from?

This is related to the previous question... some generated classes contain constructors with extra blocks, and these fail the `JCMethodDecl, JCExpressionStatement, JCMethodInvocation` stack check test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336205773
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336205806

From acobbs at openjdk.org  Mon Sep 25 18:17:26 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 18:17:26 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <pns4PxVK3DWClegPcp_eBxTezhvWhxBRk40HdnH2MIA=.1374d588-fcab-4098-b69e-058a275e86fb@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <aQ3bk7LBZNmSLZLfNyxdugKKPPEmUDxd2XSzZn6euYU=.91a62294-406b-4dfa-8cb2-71179451646e@github.com>
 <jgFZaYjg--nLZD87BG6uSSqWDFvvRZNt5opanfUau8A=.c95edaee-2b35-418a-891c-949175ce449a@github.com>
 <pns4PxVK3DWClegPcp_eBxTezhvWhxBRk40HdnH2MIA=.1374d588-fcab-4098-b69e-058a275e86fb@github.com>
Message-ID: <WIpTnOmIrHuhebLCeCbzdh-n4h59TzyrE89v5GS5erk=.e4951f14-82b9-4b27-9ead-eaaf803fc2e7@github.com>

On Mon, 25 Sep 2023 17:31:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Should this work?
>> 
>> class Test {
>>     String s = "Hello";
>> 
>>     void m() {
>>         System.out.println("Hello");
>>     }
>> 
>>     class Inner {
>>         Inner() {
>>             m();
>>             super();
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         new Test().new Inner();
>>     }
>> }
>> 
>> The proposed changes accept this program. But I can't find supporting text in the JLS changes:
>> https://cr.openjdk.org/~gbierman/jep447/jep447-20230620/specs/statements-before-super-jls.html
>
> After some internal discussion, it is good for javac to accept this, as this case can be supported using the `this$0` parameter that is passed into the constructor of `Inner` (no `this` reference is strictly required). But the JLS text supporting this seems ambiguous:
> 
> 
> The pre-construction context includes the prologue of the constructor 8.8.7 and the explicit constructor invocation itself. Within a pre-construction context, constructs that refer explicitly or implicitly to the current object are disallowed.
> 
> 
> It is not clear to me as to whether `m()` refers to the current object or not - as it seems one would have to have intimate knowledge of how the compiler translates the code in order to answer that question.

> where does env1 == env come from?

To be honest I can't remember. At some point it was needed to make something compile, but I can't come up with an example anymore (if you can, I'll tell you why it was there :)

The thinking must have been: "It can't possibly matter if the AST 'cursor'  is in the pre-construction context of an outer instance class; it only matters if we are in the pre-construction context of the class under construction."

> The proposed changes accept this program. But I can't find supporting text in the JLS changes

The spec is still being finalized ([here's the latest version](https://cr.openjdk.org/~gbierman/jep447/jep447-20230905/specs/statements-before-super-jls.html#jls-8.8)). The newer ?15.12.3 should allow this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336237288

From alex.buckley at oracle.com  Mon Sep 25 18:25:52 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 25 Sep 2023 11:25:52 -0700
Subject: [External] : Re: RFR: 8194743: Compiler implementation for
 Statements before super() [v14]
In-Reply-To: <CANSoFxvEZP6Pgw+OXWDLeh-O=zTkx+=seQ2bPVtd6vd-BvRWjQ@mail.gmail.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
 <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>
 <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com>
 <CANSoFxvEZP6Pgw+OXWDLeh-O=zTkx+=seQ2bPVtd6vd-BvRWjQ@mail.gmail.com>
Message-ID: <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com>

On 9/25/2023 10:13 AM, Archie Cobbs wrote:
>      > An explicit goal of JEP 447 is **any existing program must compile to
>      > the same bytecode**. So if we adhere to that goal, local classes
>      > declared in pre-construction contexts must have outer instances.
>     I don't see this explicit goal stated in JEP 447. There's a sentence
>     about compilation in Testing -- "We will compile all JDK classes using
>     the previous and new versions of the compiler and verify that the
>     resulting bytecode is identical." -- but that sounds merely like a
>     nice-to-have property, and one which holds only for JDK classes.
> 
> You're right.. the stated goal is actually "Do not change the behavior 
> of any existing program."
> 
> Making sure the emitted bytecode matches is just one way to accomplish 
> that goal (and possibly overkill).

Goals: (always the hardest single section of a JEP to write, BTW)

- Re: "In constructors, allow statements that do not access ..." -- this 
Goal basically repeats the Summary in stating the solution. That's not 
quite what a Goal is meant to do. The term "initialization logic" is 
also a bit wonky because it can be read as dealing with initialization 
of the current instance, which is the one thing you can't do before 
super/this. The Goal should be: "Give developers greater freedom in 
expressing the behavior of a constructor, allowing more natural 
placement of logic that currently must be factored into static methods 
or into arguments to super(..)."  I am not sure that 
statements-before-super allow logic which previously was "simply 
impossible to express."

- Drop "Correct an error in the specification which defines constructor 
invocations as a static context."  Spec issues don't drive features.

- Re: "Preserve existing safety and initialization guarantees for 
constructors." -- This sounds good but I bet 99% of readers couldn't 
enumerate an "existing safety guarantee" if you demanded one from them. 
Please spell out if this is about, say, guaranteeing that constructors 
still run in top-down order. Also, please also avoid "initialization", 
because you are not talking about the initialization of a class (see JLS 
12.4) but rather the instantiation of a class.

- Re: "Do not change the behavior of any existing program." -- stated 
more fully, this goal is "Perfect source compatibility: Any existing 
source code, if recompiled, is legal and has unchanged behavior." 
However, that could be a goal of almost any new language feature, so we 
don't usually state it. And if we cast things in terms of bytecode -- 
"Do not change how existing source code is compiled to a class file" -- 
then it sounds pretty esoteric. I'd drop this goal.

> Thanks - so yes that central question remains... how should we treat 
> local classes in pre-construction contexts?
> 
> The current implementation answers this question "they are inner classes 
> with outer instances just like they would be in any other non-static 
> location".
> 
> Admittedly that answer was chosen in part because it is the most 
> conservative change (in particular, it produces the same bytecode).
> 
> But OK let's be a little bolder and ask what would be the BEST change?
> 
> My latest thinking is we should just allow local classes to be declared 
> "static".
> 
> Then "class Local" gives the current behavior (always having an outer 
> instance in a non-static context), while "static class Local" gives the 
> same behavior as a static member class.

This is a big language change that I'm not going to comment on. You 
should review the discussion around JEP 384 about how local record 
classes were made implicitly static, never explicitly static.
>     Here's a program that tries to instantiate a Local which observes x
>     with
>     a value other than 5. What does the JLS say about the program?
> 
> 
> JLS says this()/super() have to be "top level", so they can't be inside 
> a try { } block.
> 
>     What does javac do?
> 
> 
> Test.java:10: error: switch expression does not have any result expressions
>  ? ? ? ? ? ? ?this(switch (0) { default -> throw new Exception(); });
>  ? ? ? ? ? ? ? ? ? ^
> Test.java:12: error: cannot reference this before supertype constructor 
> has been called
>  ? ? ? ? ? ? ?new Local(); ?// Legal or illegal?
>  ? ? ? ? ? ? ?^
> Test.java:10: error: calls to this() not allowed here
>  ? ? ? ? ? ? ?this(switch (0) { default -> throw new Exception(); });
>  ? ? ? ? ? ? ? ? ?^
> 3 errors

Oops, yes. So, can you guarantee, in the JEP, that a non-static local 
class declared in the pre-construction context can never access 
enclosing state?

Alex

From acobbs at openjdk.org  Mon Sep 25 19:25:19 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 19:25:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
Message-ID: <IMM8bIX_lNLYG915jrIInNkcFycRMgjSq_IQe8g35xA=.975a783c-af2e-44fb-84de-643b2e9c2588@github.com>

On Mon, 25 Sep 2023 17:49:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have RefBeforeCtorCalledError extend StaticError and customize debug strings.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 245:
> 
>> 243: 
>> 244: # 0: name
>> 245: compiler.err.calls.not.allowed.here=\
> 
> The compiler message key seems overly general. maybe `constructor.call.not.allowed.here` ?

Agreed - will fix.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 250:
> 
>> 248: # 0: name
>> 249: compiler.err.return.before.superclass.initialized=\
>> 250:     ''return'' not allowed prior to {0}()
> 
> We have no other match in this file for `prior to`, but we do have matches for `before`. I suggest using the latter for a more consistent style.

Agreed - will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336299193
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336299902

From acobbs at openjdk.org  Mon Sep 25 19:35:19 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 19:35:19 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <qIU09v7p-bCyc-HttG4tG7zXyVesTRoFvaCDIHpl1wo=.22b80bca-c854-49b8-8bf9-6d1f594cb1fe@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
 <O5ToVHHk8EFlrl0-RflkUxV1vT74ek2ssRkDe0iyYac=.22aa6ad5-c934-49dd-a566-93488ca31ca4@github.com>
 <qIU09v7p-bCyc-HttG4tG7zXyVesTRoFvaCDIHpl1wo=.22b80bca-c854-49b8-8bf9-6d1f594cb1fe@github.com>
Message-ID: <_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com>

On Mon, 25 Sep 2023 17:20:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Actually, I disagree a bit with the direction here. Having more mutable state is, I believe, not great. In this case the state has to be discarded after a call to `check`, so IMHO having mutable state lying around is a smell. What do you think @vicente-romero-oracle ?
>
> yes @mcimadamore I see your point. And after my comments I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code I agree that in this case it could be better to avoid having mutable state.

I agree with you both, and will revert this back to creating a new instance each time. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336308671

From archie.cobbs at gmail.com  Mon Sep 25 19:45:55 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 25 Sep 2023 14:45:55 -0500
Subject: [External] : Re: RFR: 8194743: Compiler implementation for
 Statements before super() [v14]
In-Reply-To: <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <dbETGAh8eNvmZOVotcESFsxTnZD3myM84sCY7EVf34Q=.3f1928bb-308e-41e4-81f8-3e6a754bcc9c@github.com>
 <Wrnu4QpdirX8_q2Qr09PvrafKpmo59yIfpBlVX0QzO4=.d7aaa6c0-94ce-4d08-a68a-2c6ff4299d77@github.com>
 <dYuEQGzp44RvMHAWEQAlHfX2GsZF3hhlO8aFTEKBLGk=.753f0393-d920-4021-b6e2-88144335a0b4@github.com>
 <22d1ebfb-2e80-4633-8920-bb394c06220e@oracle.com>
 <CANSoFxvEZP6Pgw+OXWDLeh-O=zTkx+=seQ2bPVtd6vd-BvRWjQ@mail.gmail.com>
 <096d6e1e-6daf-4658-a1e5-86581d5f3be2@oracle.com>
Message-ID: <CANSoFxs88M9h95_Zx+KycoOo-kJ8x=XoBADhLMMq7soV8DVe2g@mail.gmail.com>

Hi Alex,

Thanks for the JEP comments, I will get with Gavin (who is managing the
drafts) on these.

On Mon, Sep 25, 2023 at 1:25?PM Alex Buckley <alex.buckley at oracle.com>
wrote:
>
> > Test.java:12: error: cannot reference this before supertype constructor
> > has been called
> >               new Local();  // Legal or illegal?
> >               ^
> > Test.java:10: error: calls to this() not allowed here
> >               this(switch (0) { default -> throw new Exception(); });
> >                   ^
> > 3 errors
>
> Oops, yes. So, can you guarantee, in the JEP, that a non-static local
> class declared in the pre-construction context can never access
> enclosing state?
>

Reading that literally, no that's not guaranteed at all. You are allowed to
declare a (non-static) local class in a pre-construction context and then
instantiate it later, after super(), and access enclosing state.

What you can't do is instantiate it before super(). That's enforced by this
new line in ?15.9.2:

> If the class instance creation expression occurs in the pre-construction
> context of class *K* (8.8.7.1
> <https://cr.openjdk.org/~gbierman/jep447/jep447-20230905/specs/statements-before-super-jls.html#jls-8.8.7.1>)
> and the immediately enclosing instance is also an instance of *K* then a
> compile-time error occurs.
>
Note this language applies to both local classes and member classes.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230925/91e37e0b/attachment.htm>

From acobbs at openjdk.org  Mon Sep 25 20:44:03 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 25 Sep 2023 20:44:03 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v17]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <80Oc_vicOqg_RBKD3xZWf2GTY8u6WBk7E26zFfEoPrQ=.18e552b7-e1ff-455d-bd1c-b12effcc00d5@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - After further review, revert 599d761 to avoid mutable state lying around.
 - Address review comments relating to error messages.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/3e75e19e..2356ac6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=15-16

  Stats: 20 lines in 4 files changed: 0 ins; 13 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From mcimadamore at openjdk.org  Mon Sep 25 20:49:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 25 Sep 2023 20:49:15 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v7]
In-Reply-To: <_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <sCPdoIjpEUwHJXuUpVYVsNtrFgdQKKE7QLBctyEUUpE=.87586eec-b76d-4520-adf5-b5a1259a6a5c@github.com>
 <IICas6P2cDXvh4Xw0-895JIPCp2-EO863Ke2p9MHeyM=.3e4aa9cd-2a8c-457f-a9b8-f24f53267856@github.com>
 <O5ToVHHk8EFlrl0-RflkUxV1vT74ek2ssRkDe0iyYac=.22aa6ad5-c934-49dd-a566-93488ca31ca4@github.com>
 <qIU09v7p-bCyc-HttG4tG7zXyVesTRoFvaCDIHpl1wo=.22b80bca-c854-49b8-8bf9-6d1f594cb1fe@github.com>
 <_grq2ClX4RUA4Bf3zTZAeQ3UuJyB8CwgeRMJW2TnD64=.8ce11d7e-a7ec-4991-b713-ffb3862ddb33@github.com>
Message-ID: <ZeMRQvPzEfPfOcm3SsJWR-4UlWnXj9BxeEEKKjMZXd0=.11c003c7-9d98-4290-9714-f7ecb0ebff24@github.com>

On Mon, 25 Sep 2023 19:32:00 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> yes @mcimadamore I see your point. And after my comment above I think we discussed a similar issue in another bug and we went for the non-mutable state. After revisiting the code here I agree that in this case it could be better to avoid having mutable state.
>
> I agree with you both, and will revert this back to creating a new instance each time. Thanks.

Thanks, and sorry for being late to the party!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1336372248

From asotona at openjdk.org  Tue Sep 26 09:40:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 09:40:26 GMT
Subject: RFR: 8308753: Class-File API transition to Preview
Message-ID: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>

Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
It repackages all uses across JDK and tests and adds lots of missing Javadoc.

This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).

Online javadoc is available at:?
https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html

In addition to the primary transition to preview, this pull request also includes:
- All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
- A new preview feature, `CLASSFILE_API`, has been added.
- Buildsystem tool required a little patch to support annotated modules.
- All JDK modules using the Classfile API are newly participating in the preview.
- All tests that use the Classfile API now have preview enabled.
- A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.

Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.

Please review this pull request to help the Classfile API turn into a preview.

Any comments are welcome.

Thanks,
Adam

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

Commit messages:
 - fixed tests
 - rename of Classfile* to ClassFile*
 - fixed javac tests
 - temporary reverted conversion of tests to Classfile API due incompatibility with enabled preview
 - build and tests fixes
 - Merge branch 'master' into JDK-8308753-preview
 - added jvms link to DynamicConstantPoolEntry
 - fixed EnclosingMethodAttribute javadoc
 - documented constraints of builder and factory methods
 - added package info paragraph "Consistency checks, syntax checks and verification"
 - ... and 310 more: https://git.openjdk.org/jdk/compare/913e43fe...6594ee74

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308753
  Stats: 28985 lines in 760 files changed: 12993 ins; 12505 del; 3487 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From ihse at openjdk.org  Tue Sep 26 09:57:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 26 Sep 2023 09:57:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <9Mzvela_6bk-RbrzuwgtAh8YBykhV8Gso6Lg2oX37qY=.1fd2a73f-9272-497c-814e-9ba690feb147@github.com>

On Wed, 13 Sep 2023 09:48:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Build changes trivially good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1643863419

From mcimadamore at openjdk.org  Tue Sep 26 10:24:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 26 Sep 2023 10:24:21 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns
In-Reply-To: <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
Message-ID: <lrWtk-gpVoX4slOkUaZQRKrRu89tKOryyTMEKjEwHAo=.d161d0ed-b7c9-42b6-9ffd-7712990e75ba@github.com>

On Mon, 25 Sep 2023 16:59:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
>> `$ git checkout pull/15649`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/15649` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 15649`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 15649`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/15649.diff">https://git.openjdk.org/jdk/pull/15649.diff</a>
>> 
>> </details>
>> 
>> 
>> ### Webrev
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)
>
> test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:
> 
>> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
>> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
>> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed
> 
> Note the errors are like:
> 
> /home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
>         for(String _s : _ ) {
>                         ^
>   unnamed patterns, local variables, exception parameters or lambda parameters
> 
> 
> At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).
> 
> Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.
> 
> So, maybe something like:
> 
> 
> underscore not allowed here
> as of release 9, ''_'' is a keyword, and may not be used as an identifier
> as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters
> 
> ?
> Just an idea.

I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1336987040

From asotona at openjdk.org  Tue Sep 26 12:32:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 12:32:37 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

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

  PreviewFeature annotated with JEP 457

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/6594ee74..77631a78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From liach at openjdk.org  Tue Sep 26 13:13:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 26 Sep 2023 13:13:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
Message-ID: <oOwHiwM1ejPmZlrizZvogls9Zu9Em-_n3mrI19hYtkA=.36b32b64-f4ac-4f03-a345-7765c5f04e7b@github.com>

On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeature annotated with JEP 457

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:

> 80:         STRUCTURED_CONCURRENCY,
> 81:         @JEP(number=457, title="ClassFile API", status="Preview")
> 82:         CLASSFILE_API,

Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337183618

From asotona at openjdk.org  Tue Sep 26 13:40:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 26 Sep 2023 13:40:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <oOwHiwM1ejPmZlrizZvogls9Zu9Em-_n3mrI19hYtkA=.36b32b64-f4ac-4f03-a345-7765c5f04e7b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
 <oOwHiwM1ejPmZlrizZvogls9Zu9Em-_n3mrI19hYtkA=.36b32b64-f4ac-4f03-a345-7765c5f04e7b@github.com>
Message-ID: <GndWsvy0Gp6ByhN-PUIeRB19YvjxAkeRAe4MvGDjCfE=.dbb5c314-38cb-45e7-ab9a-ff1cfb15e44c@github.com>

On Tue, 26 Sep 2023 13:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeature annotated with JEP 457
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 82:
> 
>> 80:         STRUCTURED_CONCURRENCY,
>> 81:         @JEP(number=457, title="ClassFile API", status="Preview")
>> 82:         CLASSFILE_API,
> 
> Since `Classfile` gets renamed to `ClassFile`, do we rename the title to `Class-File API` and constant to `CLASS_FILE_API`?

Rename of classes and interfaces from `Classfile` to `ClassFile` is significant for the API.
`ClassFile` and `Class-File` are considered equal in text.
Internal name of the preview feature is temporary and  invisible in the API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1337223631

From rgiulietti at openjdk.org  Tue Sep 26 14:16:26 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 26 Sep 2023 14:16:26 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview)
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <kICRYF16seAQVM7kC1iCUvrROcaLfleYYKrsyTT5C-I=.f7f9adf7-5983-4722-980f-f04c61ddf555@github.com>

On Fri, 8 Sep 2023 14:17:29 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 45:

> 43:      *
> 44:      * */
> 45:     public static boolean byte_char(byte n)    {return n == (char) n;}

This method doesn't buy you anything more than `int_char(int)`, so I wonder if it is useful.
(The bytecode instructions are exactly the same.)

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 53:

> 51:      *
> 52:      * */
> 53:     public static boolean short_byte(short n)  {return n == (short)(byte)(n);}

Here, too, I wonder if this method is useful, given that `int_byte(int)` gives the same outcomes and its bytecode is one instruction shorter.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 61:

> 59:      *
> 60:      * */
> 61:     public static boolean short_char(short n)  {return n == (char)(n);}

Similarly, usages can be replaced by `int_char(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 69:

> 67:      *
> 68:      * */
> 69:     public static boolean char_byte(char n)    {return n == (byte)(n);}

Usages can be replaced by `int_byte(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 77:

> 75:      *
> 76:      * */
> 77:     public static boolean char_short(char n)   {return n == (short)(n);}

Can be replaced by `int_short(int)`.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 85:

> 83:      *
> 84:      * */
> 85:     public static boolean int_byte(int n)      {return n == (int)(byte)(n);}

Suggestion:

    public static boolean int_byte(int n)      {return n == (int)(byte)n;}

Just for consistency with other methods.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 93:

> 91:      *
> 92:      * */
> 93:     public static boolean int_short(int n)     {return n == (int)(short)(n);}

Suggestion:

    public static boolean int_short(int n)     {return n == (int)(short)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 101:

> 99:      *
> 100:      * */
> 101:     public static boolean int_char(int n)      {return n == (char)(n);}

Suggestion:

    public static boolean int_char(int n)      {return n == (int)(char)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 117:

> 115:      *
> 116:      * */
> 117:     public static boolean long_byte(long n)    {return n == (long)(byte)(n);}

Suggestion:

    public static boolean long_byte(long n)    {return n == (long)(byte)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 125:

> 123:      *
> 124:      * */
> 125:     public static boolean long_short(long n)   {return n == (long)(short)(n);}

Suggestion:

    public static boolean long_short(long n)   {return n == (long)(short)n;}

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 133:

> 131:      *
> 132:      * */
> 133:     public static boolean long_char(long n)    {return n == (char)(n);}

Suggestion:

    public static boolean long_char(long n)    {return n == (long)(char)n;}

for consistency.

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 141:

> 139:      *
> 140:      * */
> 141:     public static boolean long_int(long n)     {return n == (long)(int)(n);}

Suggestion:

    public static boolean long_int(long n)     {return n == (long)(int)n;}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337239197
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337251147
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337257370
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337259180
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221803
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337221156
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337220474
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337219930
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217930
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337217515
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337216448
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1337268643

From abimpoudis at openjdk.org  Tue Sep 26 14:41:00 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 26 Sep 2023 14:41:00 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v2]
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <H9GXyREaq2hsPiI7pMA41tdla5i22SZDwQANe2B7fog=.5ac77a07-c068-4264-b737-17ee9898ae80@github.com>

> This PR finalizes the feature of unnamed variables and patterns.
> 
> ---------
> ### Progress
> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
> `$ git checkout pull/15649`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/15649` \
> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 15649`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 15649`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.org/jdk/pull/15649.diff">https://git.openjdk.org/jdk/pull/15649.diff</a>
> 
> </details>
> 
> 
> ### Webrev
> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review by @lahodaj

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/d334ff29..3becc945

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=00-01

  Stats: 51 lines in 8 files changed: 7 ins; 2 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From abimpoudis at openjdk.org  Tue Sep 26 14:41:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 26 Sep 2023 14:41:04 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v2]
In-Reply-To: <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
Message-ID: <S89aqGthf8GXcUsU2rtHhA7s40kEWgZaQSby3j3yfSc=.bb1d1081-7466-490d-a124-1d091d995235@github.com>

On Mon, 25 Sep 2023 17:05:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review by @lahodaj
>
> test/langtools/tools/javac/diags/examples/UnderscoreInLambdaExpression.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: // options: -Xlint:preview
> 
> `-Xlint:preview` is probably unnecessary here.

If I remove everything, the example does not work. I will leave a `-source 21`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1337320481

From robo at khelekore.org  Tue Sep 26 19:32:48 2023
From: robo at khelekore.org (Robert Olofsson)
Date: Tue, 26 Sep 2023 21:32:48 +0200
Subject: Question about null handling in SwitchLabel
Message-ID: <20230926213248.165cdd51@skully>

Hi!

I hope this is the right place to ask about switch and null handling.

A bit of background:
So I am trying to build my own parser (parjac2) for the java language
and was trying to implement handling for the updated "switch"
according to the updated grammar. This caused me some problem. So I
tried to test a few things with javac and to me it seems like javac
and the grammar are not fully in synch.

Some parts of the grammar to make it easier to understand:

SwitchRule:
  SwitchLabel -> Expression;

SwitchLabel:
  case CaseConstant {, CaseConstant}
  case null [, default]

CaseConstant:
  ConditionalExpression

We can follow ConditionalExpression to Primary and
Primary can be Literal so it allows "null".

So to me this looks like SwitchLabel say that "null" is allowed
anywhere in a sequence of CaseConstants, but when I try this with
javac I of course get "error: invalid case label combination"

Example program:
------------------------------------------------------
class Foo {
    void foo () {
        String foo = "hello";
        switch (foo) {
        case "A", "B", null -> System.out.println ("Yup");
        default -> System.out.println ("Nope!");
        }
    }
}
------------------------------------------------------

Looking closer at the JLS we do find a bullet point:
* For each case constant associated with the switch block that is a
constant expression, the constant is assignment compatible with T, and
T is one of char, byte, short, int, Character, Byte, Short, Integer,
or String.

So I guess this is the reason null is not allowed as CaseConstant?

Actual question:
Now that we do have the option to have null by itself or with
default as a SwitchLAbel is there really a strong case now for not
allowing us to do 'case "A", "B", null -> ...'?

For me right now I guess I will have to find a creative way to
rewrite the grammar I use for my parser to avoid the problem, not yet
sure how I will do that though. Basically I get a conflict that "case
null" can be two versions of SwitchLabel and the earley parsing
algorithm I use do not like that, this is of course for me to figure
out.

Thank you
/robo

From gavin.bierman at oracle.com  Tue Sep 26 21:23:46 2023
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Tue, 26 Sep 2023 21:23:46 +0000
Subject: Question about null handling in SwitchLabel
In-Reply-To: <20230926213248.165cdd51@skully>
References: <20230926213248.165cdd51@skully>
Message-ID: <48FDB6CF-D01D-4C87-9FD7-642106B74008@oracle.com>

If you look in 14.11.1 of JLS just under the grammar you quoted:

> Every case constant must be either a constant expression (?15.29), or the name of an enum constant (?8.9.1), otherwise a compile-time error occurs.

That?s why null is not allowed; it?s not a constant expression, or the name of an enum constant. 

Hope this helps,
Gavin

> On 26 Sep 2023, at 20:32, Robert Olofsson <robo at khelekore.org> wrote:
> 
> Hi!
> 
> I hope this is the right place to ask about switch and null handling.
> 
> A bit of background:
> So I am trying to build my own parser (parjac2) for the java language
> and was trying to implement handling for the updated "switch"
> according to the updated grammar. This caused me some problem. So I
> tried to test a few things with javac and to me it seems like javac
> and the grammar are not fully in synch.
> 
> Some parts of the grammar to make it easier to understand:
> 
> SwitchRule:
>  SwitchLabel -> Expression;
> 
> SwitchLabel:
>  case CaseConstant {, CaseConstant}
>  case null [, default]
> 
> CaseConstant:
>  ConditionalExpression
> 
> We can follow ConditionalExpression to Primary and
> Primary can be Literal so it allows "null".
> 
> So to me this looks like SwitchLabel say that "null" is allowed
> anywhere in a sequence of CaseConstants, but when I try this with
> javac I of course get "error: invalid case label combination"
> 
> Example program:
> ------------------------------------------------------
> class Foo {
>    void foo () {
>        String foo = "hello";
>        switch (foo) {
>        case "A", "B", null -> System.out.println ("Yup");
>        default -> System.out.println ("Nope!");
>        }
>    }
> }
> ------------------------------------------------------
> 
> Looking closer at the JLS we do find a bullet point:
> * For each case constant associated with the switch block that is a
> constant expression, the constant is assignment compatible with T, and
> T is one of char, byte, short, int, Character, Byte, Short, Integer,
> or String.
> 
> So I guess this is the reason null is not allowed as CaseConstant?
> 
> Actual question:
> Now that we do have the option to have null by itself or with
> default as a SwitchLAbel is there really a strong case now for not
> allowing us to do 'case "A", "B", null -> ...'?
> 
> For me right now I guess I will have to find a creative way to
> rewrite the grammar I use for my parser to avoid the problem, not yet
> sure how I will do that though. Basically I get a conflict that "case
> null" can be two versions of SwitchLabel and the earley parsing
> algorithm I use do not like that, this is of course for me to figure
> out.
> 
> Thank you
> /robo


From acobbs at openjdk.org  Tue Sep 26 21:41:54 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 26 Sep 2023 21:41:54 GMT
Subject: RFR: 8268622: Performance issues in javac `Name` class [v2]
In-Reply-To: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>
References: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>
Message-ID: <-pQwJ-St95eN3C7LZsytq6alyi354wm0CLfomGAG-U8=.3e230a05-d6e6-4783-9492-357cebd150b0@github.com>

> Quoting [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622):
>> The javadoc team has identified performance issues in the javac `Name` class, particularly when it is used via its `CharSequence` interface ([JDK-8263321](https://bugs.openjdk.org/browse/JDK-8263321)). The main issue there is that the `CharSequence` is specifically character-oriented, whereas the native form inside javac is a byte[] in modified-UTF8 form. Operations like `.length()` and `.charAt(int)` have "simple" but very inefficient implementations.
> 
> Thanks to [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) we now have the option to swap in a `String`-based `Name` table implementation in place of the current UTF-8-based one. This does in fact improve performance of the compiler.
> 
> This patch does two things:
> * Make the `String`-based `Name` table implementation the default. The two other UTF-8-based implementations are still available via the flags `-XDuseUnsharedTable=true` and `-XDuseSharedTable=true` (the latter was the previous default). This results in a 19% speedup in my simple benchmark (see below).
> * Adds a new flag `-XDinternStringTable=true`, which turns on `intern()`ing of the `String`s in the `String` table. This however is **not** the default because it results in lower performance (see below). But it's possible this could help in other scenarios so it's left in there for future testing purposes.
> 
> Here are results from the [JavacNameTable.java](https://github.com/openjdk/jdk/files/12466359/JavacNameTable.java.txt) benchmark.
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> JavacNameTable.testSharedTable        avgt   25  54.145 ? 1.738  ms/op
> JavacNameTable.testStringTable        avgt   25  45.305 ? 0.415  ms/op
> JavacNameTable.testStringTableIntern  avgt   25  50.736 ? 0.245  ms/op
> JavacNameTable.testUnsharedTable      avgt   25  59.877 ? 2.503  ms/op
> 
> To reiterate: `testSharedTable` reflects the previous default; `testStringTable` reflects the new default. The other two options are available via the flags `-XDinternStringTable=true` and `-XDuseUnsharedTable=true`.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8268622
 - Change the default Name table implementation to StringNameTable.
   
   This removes the "useStringTable" flag (since it's now the default),
   adds a "useSharedTable" flag (since it's no longer the default), and
   adds an "internStringTable" flag enabling intern()'ing Name strings.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15470/files
  - new: https://git.openjdk.org/jdk/pull/15470/files/5f623886..1dcafc70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15470&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15470&range=00-01

  Stats: 17779 lines in 415 files changed: 12781 ins; 2668 del; 2330 mod
  Patch: https://git.openjdk.org/jdk/pull/15470.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15470/head:pull/15470

PR: https://git.openjdk.org/jdk/pull/15470

From vromero at openjdk.org  Wed Sep 27 14:54:15 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 27 Sep 2023 14:54:15 GMT
Subject: RFR: 8268622: Performance issues in javac `Name` class [v2]
In-Reply-To: <-pQwJ-St95eN3C7LZsytq6alyi354wm0CLfomGAG-U8=.3e230a05-d6e6-4783-9492-357cebd150b0@github.com>
References: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>
 <-pQwJ-St95eN3C7LZsytq6alyi354wm0CLfomGAG-U8=.3e230a05-d6e6-4783-9492-357cebd150b0@github.com>
Message-ID: <8iyxFt-Qd5pWZsD0rAxQiGn8p9kmWW75x700xTB6EGs=.fb76340d-e33d-48bc-b38c-5bf5e43bee94@github.com>

On Tue, 26 Sep 2023 21:41:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Quoting [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622):
>>> The javadoc team has identified performance issues in the javac `Name` class, particularly when it is used via its `CharSequence` interface ([JDK-8263321](https://bugs.openjdk.org/browse/JDK-8263321)). The main issue there is that the `CharSequence` is specifically character-oriented, whereas the native form inside javac is a byte[] in modified-UTF8 form. Operations like `.length()` and `.charAt(int)` have "simple" but very inefficient implementations.
>> 
>> Thanks to [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) we now have the option to swap in a `String`-based `Name` table implementation in place of the current UTF-8-based one. This does in fact improve performance of the compiler.
>> 
>> This patch does two things:
>> * Make the `String`-based `Name` table implementation the default. The two other UTF-8-based implementations are still available via the flags `-XDuseUnsharedTable=true` and `-XDuseSharedTable=true` (the latter was the previous default). This results in a 19% speedup in my simple benchmark (see below).
>> * Adds a new flag `-XDinternStringTable=true`, which turns on `intern()`ing of the `String`s in the `String` table. This however is **not** the default because it results in lower performance (see below). But it's possible this could help in other scenarios so it's left in there for future testing purposes.
>> 
>> Here are results from the [JavacNameTable.java](https://github.com/openjdk/jdk/files/12466359/JavacNameTable.java.txt) benchmark.
>> 
>> Benchmark                             Mode  Cnt   Score   Error  Units
>> JavacNameTable.testSharedTable        avgt   25  54.145 ? 1.738  ms/op
>> JavacNameTable.testStringTable        avgt   25  45.305 ? 0.415  ms/op
>> JavacNameTable.testStringTableIntern  avgt   25  50.736 ? 0.245  ms/op
>> JavacNameTable.testUnsharedTable      avgt   25  59.877 ? 2.503  ms/op
>> 
>> To reiterate: `testSharedTable` reflects the previous default; `testStringTable` reflects the new default. The other two options are available via the flags `-XDinternStringTable=true` and `-XDuseUnsharedTable=true`.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8268622
>  - Change the default Name table implementation to StringNameTable.
>    
>    This removes the "useStringTable" flag (since it's now the default),
>    adds a "useSharedTable" flag (since it's no longer the default), and
>    adds an "internStringTable" flag enabling intern()'ing Name strings.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15470#pullrequestreview-1646854592

From abimpoudis at openjdk.org  Thu Sep 28 08:40:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 08:40:40 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: <lrWtk-gpVoX4slOkUaZQRKrRu89tKOryyTMEKjEwHAo=.d161d0ed-b7c9-42b6-9ffd-7712990e75ba@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
 <lrWtk-gpVoX4slOkUaZQRKrRu89tKOryyTMEKjEwHAo=.d161d0ed-b7c9-42b6-9ffd-7712990e75ba@github.com>
Message-ID: <MTaHzg9LWCYFYKzZkTe8RSFZo61JRXNF3z_mTrL-6Ns=.8a09b2fa-c033-4bf5-aee4-08838b8678fd@github.com>

On Tue, 26 Sep 2023 10:21:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/lambda/IdentifierTest9.out line 33:
>> 
>>> 31: IdentifierTest.java:152:17: compiler.err.use.of.underscore.not.allowed
>>> 32: IdentifierTest.java:158:16: compiler.err.use.of.underscore.not.allowed.with.brackets
>>> 33: IdentifierTest.java:160:25: compiler.err.use.of.underscore.not.allowed
>> 
>> Note the errors are like:
>> 
>> /home/jlahoda/src/jdk/jdk2/test/langtools/tools/javac/lambda/IdentifierTest.java:160: error: as of release 21, the underscore keyword '_' is only allowed to declare
>>         for(String _s : _ ) {
>>                         ^
>>   unnamed patterns, local variables, exception parameters or lambda parameters
>> 
>> 
>> At least the release version should be updated, but to not let the message to be broken into two lines like this. Maybe produce a top-level diagnostic along the line of "underscore not allowed here" with sub-diagnostic with the details (which then can (maybe?) span multiple lines).
>> 
>> Also, the wording sounds to me like if there was a restriction in JDK 22, while underscore is actually permitted on more places than before.
>> 
>> So, maybe something like:
>> 
>> 
>> underscore not allowed here
>> as of release 9, ''_'' is a keyword, and may not be used as an identifier
>> as of release 21, ''_'' can be used as a name in the declaration of unnamed patterns, local variables, exception parameters or lambda parameters
>> 
>> ?
>> Just an idea.
>
> I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.

@mcimadamore @lahodaj I attempted to do this split for non variables that do not allow underscore. I print the simple version of the error message. Is that what you meant Maurizio?

I also fixed the `UnderscoreAsIdent` adding the missing `--release 9`. It was the same omission as with other tests that @lahodaj pointed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1339746518

From mcimadamore at openjdk.org  Thu Sep 28 09:49:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 09:49:25 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: <D7FrP7XOO92eNEYsGkEyK_RK-4TuWufqWH6LmvNm8KA=.8ad0dad2-6f1a-4c0b-8c43-7ec95db4b7e2@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <D7FrP7XOO92eNEYsGkEyK_RK-4TuWufqWH6LmvNm8KA=.8ad0dad2-6f1a-4c0b-8c43-7ec95db4b7e2@github.com>
Message-ID: <1oDhU7VVjIshfuZZkqHH8O8w-R5J-nrKVQQrA7PiFCk=.a1f40dcb-b0dc-4814-a4fa-463334b520c8@github.com>

On Thu, 28 Sep 2023 08:40:20 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>> 
>> ---------
>> ### Progress
>> - [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> - [ ] Change requires CSR request [JDK-8315851](https://bugs.openjdk.org/browse/JDK-8315851) to be approved
>> 
>> 
>> 
>> ### Reviewing
>> <details><summary>Using <code>git</code></summary>
>> 
>> Checkout this PR locally: \
>> `$ git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649` \
>> `$ git checkout pull/15649`
>> 
>> Update a local copy of the PR: \
>> `$ git checkout pull/15649` \
>> `$ git pull https://git.openjdk.org/jdk.git pull/15649/head`
>> 
>> </details>
>> <details><summary>Using Skara CLI tools</summary>
>> 
>> Checkout this PR locally: \
>> `$ git pr checkout 15649`
>> 
>> View PR using the GUI difftool: \
>> `$ git pr show -t 15649`
>> 
>> </details>
>> <details><summary>Using diff file</summary>
>> 
>> Download this PR as a diff file: \
>> <a href="https://git.openjdk.org/jdk/pull/15649.diff">https://git.openjdk.org/jdk/pull/15649.diff</a>
>> 
>> </details>
>> 
>> 
>> ### Webrev
>> [Link to Webrev Comment](https://git.openjdk.org/jdk/pull/15649#issuecomment-1733906010)
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review by @mcimadamore

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1648347760

From mcimadamore at openjdk.org  Thu Sep 28 09:49:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 09:49:28 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v3]
In-Reply-To: <MTaHzg9LWCYFYKzZkTe8RSFZo61JRXNF3z_mTrL-6Ns=.8a09b2fa-c033-4bf5-aee4-08838b8678fd@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <FGkp91Yd-HIjJhlWnN491pD5trOpMS4V5D14JVg7L-Y=.7b8b321c-7866-4020-b1d3-9fb8f0a40055@github.com>
 <lrWtk-gpVoX4slOkUaZQRKrRu89tKOryyTMEKjEwHAo=.d161d0ed-b7c9-42b6-9ffd-7712990e75ba@github.com>
 <MTaHzg9LWCYFYKzZkTe8RSFZo61JRXNF3z_mTrL-6Ns=.8a09b2fa-c033-4bf5-aee4-08838b8678fd@github.com>
Message-ID: <3uZtVJWgJ6rB14Obf-vPR78BGM3ksFUfV1h8srBNSZs=.69390415-3b3b-4032-8d21-907555cff993@github.com>

On Thu, 28 Sep 2023 08:38:27 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> I agree. Also, this is not helped by the fact that in this particular message, the `_` does not appear in a variable declaration. Maybe we should use two distinct messages for when `_` is found as an "expression" (e.g. an identifier) and when it is used as a declaration _name_.
>
> @mcimadamore @lahodaj I attempted to do this split for non variables that do not allow underscore. I print the simple version of the error message. Is that what you meant Maurizio?
> 
> I also fixed the `UnderscoreAsIdent` adding the missing `--release 9`. It was the same omission as with other tests that @lahodaj pointed.

This looks much better!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15649#discussion_r1339840526

From gbierman at openjdk.org  Thu Sep 28 10:16:31 2023
From: gbierman at openjdk.org (Gavin Bierman)
Date: Thu, 28 Sep 2023 10:16:31 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <pV-13lX3dvoRIx7cBWpACVba9m34bVpPCuyGtj-Z5Fg=.adcea474-2908-4ade-9c49-3c907da915d4@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
 <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>
 <pV-13lX3dvoRIx7cBWpACVba9m34bVpPCuyGtj-Z5Fg=.adcea474-2908-4ade-9c49-3c907da915d4@github.com>
Message-ID: <AytBOuT8Lem7EWctkTkXN1y7QYDV6QGtgHWuvIRHECA=.60103beb-4083-488e-9605-c99eec18892f@github.com>

On Mon, 25 Sep 2023 17:52:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> @GavinBierman do you think the compiler message should mention the official JLS terminology?
>
> For instance:
> 
> 
> explicit constructor invocation may only appear within constructors
> 
> 
> 
> redundant explicit constructor invocation
> 
> 
> 
> explicit constructor invocation not allowed here
> 
> 
> 
> 'return'' not allowed before explicit constructor invocation

@mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good.

(The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1339876223

From mcimadamore at openjdk.org  Thu Sep 28 13:21:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:21:47 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls
Message-ID: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>

This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.

The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.

While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.

The output from javac looks as follows:


Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
      Arena.ofAuto().allocate(10).reinterpret(100);
                                 ^
  (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

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

Commit messages:
 - Add tests
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/15964/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316971
  Stats: 95 lines in 14 files changed: 92 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15964/head:pull/15964

PR: https://git.openjdk.org/jdk/pull/15964

From mcimadamore at openjdk.org  Thu Sep 28 13:21:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:21:51 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <r3KCwD0iyxvd-1vJwp3WCNJ8uSWWj970EkgIzLbYtBk=.5591bf70-2690-4af2-9350-2e95835cb746@github.com>

On Thu, 28 Sep 2023 13:13:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

make/modules/java.base/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += this-escape restricted

I've disabled restricted warnings in java.base as there's a lot of restricted calls in the Linker API implementation :-)

make/test/BuildMicrobenchmark.gmk line 94:

> 92:     SMALL_JAVA := false, \
> 93:     CLASSPATH := $(MICROBENCHMARK_CLASSPATH), \
> 94:     DISABLED_WARNINGS := restricted this-escape processing rawtypes cast serial preview, \

This is needed so that we can compile FFM API benchmarks.

test/langtools/tools/javac/diags/examples.not-yet.txt line 219:

> 217: compiler.err.annotation.unrecognized.attribute.name
> 218: 
> 219: # this one is transitional (waiting for FFM API to exit preview)

Note: in principle I could have added an example for this diagnostic. In practice, the fact that FFM is still a preview API makes this a bit difficult - because we need the sample to also have enable preview flags, and also to catch a bunch of preview diagnostics (some of which I can't add directly as they are also excluded on this file). Since this PR already adds a test, I opted to exclude the diagnostic sample for now, and I will come back later (after FFM is no longer preview) to add one (so as to minimize disruption).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340137452
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340137937
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340142294

From mcimadamore at openjdk.org  Thu Sep 28 13:36:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 13:36:27 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <rCbHJ_IiVzxR3baLyresoFeaNfeG_pNm7ovOiva1rDg=.33bba5f4-6f1c-46e5-a340-d9089e9d7c5d@github.com>

On Thu, 28 Sep 2023 13:13:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

test/langtools/tools/javac/RestrictedMethods.java line 5:

> 3:  * @bug 8316971
> 4:  * @summary Smoke test for restricted method call warnings
> 5:  * @compile/fail/ref=RestrictedMethods.out -Xlint:restricted -Werror -XDrawDiagnostics --enable-preview --source ${jdk.version} RestrictedMethods.java

The `--enable-preview` related options will need to be removed when FFM is finalized

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340165979

From ihse at openjdk.org  Thu Sep 28 15:24:25 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 28 Sep 2023 15:24:25 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <mipUwxwb7VTUz9Tq0ttptjhMKQGq3U4N2NaPjucYaCg=.9f5774bb-4967-4f30-85c2-940d8841fb04@github.com>

On Thu, 28 Sep 2023 13:13:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

Build changes look trivially fine.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15964#pullrequestreview-1649137432

From mcimadamore at openjdk.org  Thu Sep 28 15:36:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 28 Sep 2023 15:36:30 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update warning message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/8370e79d..21b7d860

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15964/head:pull/15964

PR: https://git.openjdk.org/jdk/pull/15964

From vromero at openjdk.org  Thu Sep 28 15:59:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Sep 2023 15:59:27 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
Message-ID: <ZW-Ghv-bZR9SO35dGtk40uqItRy2ju6O84IILY-yMt4=.bf98a101-8466-4a35-80b7-29e85e330ae8@github.com>

On Thu, 28 Sep 2023 15:36:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
>> 
>> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
>> 
>> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
>> 
>> The output from javac looks as follows:
>> 
>> 
>> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>>       Arena.ofAuto().allocate(10).reinterpret(100);
>>                                  ^
>>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update warning message

question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 393:

> 391: 
> 392:     /**
> 393:      * Flag to indicate sealed class/interface declaration.

this javadoc needs to be adjusted to restricted methods

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

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1739605513
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340351919

From jjg at openjdk.org  Thu Sep 28 16:05:38 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 28 Sep 2023 16:05:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
Message-ID: <anOia88no6DhvyKlmRs5yWBXJ3mCXAWsBltJ_RuZa7Y=.887fc894-7191-475d-9e7d-a5c2f5559eb8@github.com>

On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeature annotated with JEP 457

I don't see anything specific to `javadoc`

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

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1649221047

From acobbs at openjdk.org  Thu Sep 28 16:19:08 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 28 Sep 2023 16:19:08 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v18]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <PjBEolf6jOMdaUvXYVEPZWSB2UGTZzvrhgjFa24J-zQ=.7058e9d2-36d6-4274-ab1a-79d6d334d54b@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Reword new errors to use the JLS term for "explicit constructor invocation".

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/2356ac6f..738c10a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=16-17

  Stats: 22 lines in 3 files changed: 0 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From acobbs at openjdk.org  Thu Sep 28 16:19:10 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 28 Sep 2023 16:19:10 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <AytBOuT8Lem7EWctkTkXN1y7QYDV6QGtgHWuvIRHECA=.60103beb-4083-488e-9605-c99eec18892f@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
 <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>
 <pV-13lX3dvoRIx7cBWpACVba9m34bVpPCuyGtj-Z5Fg=.adcea474-2908-4ade-9c49-3c907da915d4@github.com>
 <AytBOuT8Lem7EWctkTkXN1y7QYDV6QGtgHWuvIRHECA=.60103beb-4083-488e-9605-c99eec18892f@github.com>
Message-ID: <f4lr1U9BaMyYzlKwpwe5En2qA9yeGO66Pm2Mym1pVKI=.a1d53b77-54c0-4456-9d7f-3768a5f06b56@github.com>

On Thu, 28 Sep 2023 10:13:19 GMT, Gavin Bierman <gbierman at openjdk.org> wrote:

>> For instance:
>> 
>> 
>> explicit constructor invocation may only appear within constructors
>> 
>> 
>> 
>> redundant explicit constructor invocation
>> 
>> 
>> 
>> explicit constructor invocation not allowed here
>> 
>> 
>> 
>> 'return'' not allowed before explicit constructor invocation
>
> @mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good.
> 
> (The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.)

Updated error messages in 738c10a57de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1340385904

From abimpoudis at openjdk.org  Thu Sep 28 16:46:11 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 16:46:11 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d354f7eb..1ae06ac8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From rgiulietti at openjdk.org  Thu Sep 28 17:22:25 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 28 Sep 2023 17:22:25 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
Message-ID: <g9DQi4t-JZY-ZZ-VbL_FGJQGZRcKQK2e9uQKxCJkDzc=.41146d2a-2dad-4c88-827d-4e96f3957f53@github.com>

On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

There might be good reasons to have:

- `byte_char()` and `short_char()` in addition to `int_char()`
- `short_byte()` and `char_byte()` in addition to `int_byte()`
- `char_short()` in addition to `int_short()`

but I cannot see the rationale.

Maybe due to the language rules?
Or are they needed for the implementation of patterns, instanceof and switch?

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739727897

From vromero at openjdk.org  Thu Sep 28 17:31:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Sep 2023 17:31:29 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
Message-ID: <4W6VSE5vQJGMJ-prAy0LIGNsLs7AjHvh5a8sfhJRyuA=.a858bf1e-561c-4d6b-a4c4-182a8e5c83fb@github.com>

On Thu, 28 Sep 2023 15:36:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
>> 
>> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
>> 
>> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
>> 
>> The output from javac looks as follows:
>> 
>> 
>> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>>       Arena.ofAuto().allocate(10).reinterpret(100);
>>                                  ^
>>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update warning message

test/langtools/tools/javac/RestrictedMethods.java line 34:

> 32:         }
> 33:     }
> 34: }

shouldn't this test include a case using method references? For example:

    void m(MemorySegment m) {
        foo(m::reinterpret);
    }

    <R> void foo(LongFunction<R> f) {}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1340470730

From abimpoudis at openjdk.org  Thu Sep 28 17:50:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 28 Sep 2023 17:50:29 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
Message-ID: <lf4mAA5bYg-RBT4Jtpmf9k_9ppFEprK8itaSegewzBg=.1798bc11-1079-4d2a-986a-0103677fd86d@github.com>

On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

At the moment the translation is uniform, (simply) computing the method name from the static types of the arguments and generating calls to those methods. This happens from two places, one from the `instanceof`:

> https://github.com/openjdk/jdk/pull/15638/files#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR2999

and one from the `SwitchBootstraps` for `switch` (open the SwitchBootstraps file to see the diff, Github doesn't open it automatically):

> https://github.com/openjdk/jdk/pull/15638/files#diff-d71d82d68cc87a9c7179421f4a57eacdba822eb3e6a2b413ddb35f0b891a3764R246

I will try to find a good way to share code between the two places, by avoiding the further duplication of the code (@mcimadamore, @vicente-romero-oracle, @lahodaj any ideas?). 

In any case (with code duplication or not) maybe I can introduce a small table to "string intern" those names and avoid this computation altogether (including the map that you wrote above).

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1739759884

From vromero at openjdk.org  Thu Sep 28 21:31:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 28 Sep 2023 21:31:20 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body
Message-ID: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>

Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:


enum T {
  ONE("");

  T(String one);  // missing constructor body

  final String one;
}

the fix is a one liner
TIA

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

Commit messages:
 - 8305971: NPE in JavacProcessingEnvironment for missing enum constructor body

Changes: https://git.openjdk.org/jdk/pull/15974/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305971
  Stats: 59 lines in 4 files changed: 58 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15974/head:pull/15974

PR: https://git.openjdk.org/jdk/pull/15974

From darcy at openjdk.org  Thu Sep 28 23:02:28 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 28 Sep 2023 23:02:28 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <_kIfX1FQXUC6OSN51J3GbpQAAYRiByvMQeIUQY9lpzk=.1f971ed3-3cd1-482d-ba93-e4dd0bd3e3c4@github.com>

On Thu, 28 Sep 2023 21:23:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

Is this issue or an analagous issue triggered for default constructors or the special constructors of records?

Is so, it would be good to have explicit test coverage of those cases too.

test/langtools/tools/javac/annotations/crash_empty_enum_const/SimpleProcessor.java line 31:

> 29: import javax.lang.model.element.TypeElement;
> 30: 
> 31: @SupportedAnnotationTypes("*")

The style of annotation processor tests does vary a bit by area of javac. It should be technically possible to put the code being tested and the annotation processor into a single file, as is commonly done in the direct annotation processing tests.

I can send some pointers if that kind of refactoring would be of interest.

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

PR Comment: https://git.openjdk.org/jdk/pull/15974#issuecomment-1740100749
PR Review Comment: https://git.openjdk.org/jdk/pull/15974#discussion_r1340733722

From mcimadamore at openjdk.org  Fri Sep 29 08:17:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:17:06 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <ZW-Ghv-bZR9SO35dGtk40uqItRy2ju6O84IILY-yMt4=.bf98a101-8466-4a35-80b7-29e85e330ae8@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
 <ZW-Ghv-bZR9SO35dGtk40uqItRy2ju6O84IILY-yMt4=.bf98a101-8466-4a35-80b7-29e85e330ae8@github.com>
Message-ID: <P7P9ykX3Fxe_u9xRvgQSazy_AVsK94oNNrAnf2CkkxU=.7260bc03-430a-4ee9-becb-c4af04c4a277@github.com>

On Thu, 28 Sep 2023 15:56:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature

The Restricted annotation is an internal annotation only. So there is no value in annotating it with `@PreviewFeature`. Also, note that there is a PR already filed which, when integrated, will move the FFM API out of preview [1].

[1] - https://git.openjdk.org/jdk/pull/15103

> test/langtools/tools/javac/RestrictedMethods.java line 34:
> 
>> 32:         }
>> 33:     }
>> 34: }
> 
> shouldn't this test include a case using method references? For example:
> 
>     void m(MemorySegment m) {
>         foo(m::reinterpret);
>     }
> 
>     <R> void foo(LongFunction<R> f) {}
> 
> 
> we could also clarify in the CSR that the warning will also be issued for method references where the identifier after `::` is a restricted method

Good point. Will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1740490726
PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1341052841

From mcimadamore at openjdk.org  Fri Sep 29 08:30:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:30:07 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <iQFCLIrUlVVQ6GmbDJtycaD0MCrOrGLUJDbjmvHSq24=.10c4d60d-e947-403e-b50a-bea10ae74fef@github.com>

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/21b7d860..1951b742

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=01-02

  Stats: 34 lines in 6 files changed: 23 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15964/head:pull/15964

PR: https://git.openjdk.org/jdk/pull/15964

From mcimadamore at openjdk.org  Fri Sep 29 08:30:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:30:09 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
In-Reply-To: <iQFCLIrUlVVQ6GmbDJtycaD0MCrOrGLUJDbjmvHSq24=.10c4d60d-e947-403e-b50a-bea10ae74fef@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <iQFCLIrUlVVQ6GmbDJtycaD0MCrOrGLUJDbjmvHSq24=.10c4d60d-e947-403e-b50a-bea10ae74fef@github.com>
Message-ID: <-TtpM5jzRwQ8lw9joSyhFa1v3w5TWIbL3KyUkT-QSlo=.859e060a-5543-4b7b-add7-b1d525118e93@github.com>

On Fri, 29 Sep 2023 08:22:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
>> 
>> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
>> 
>> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
>> 
>> The output from javac looks as follows:
>> 
>> 
>> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>>       Arena.ofAuto().allocate(10).reinterpret(100);
>>                                  ^
>>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1921:

> 1919: 
> 1920: # 0: symbol, 1: symbol
> 1921: compiler.warn.restricted.method=\

I've updated the name of this key (from `compiler.warn.restricted.method.call` to make it more general, and also applicable in the case of method reference. Note that the warning text itself has not changed, as that was already correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15964#discussion_r1341062635

From mcimadamore at openjdk.org  Fri Sep 29 08:34:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 29 Sep 2023 08:34:09 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v16]
In-Reply-To: <f4lr1U9BaMyYzlKwpwe5En2qA9yeGO66Pm2Mym1pVKI=.a1d53b77-54c0-4456-9d7f-3768a5f06b56@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <LFLjCaXmI3OhPT0nKwLkm5IJu0YX-U2RRsthG-sXDDM=.bdb551cf-a885-43f1-b4f6-4c8260840bed@github.com>
 <-QMBZbnVeBt1nMt6dudQdnqfF7iV-Nroesf6-oLsubk=.25127cb5-9c11-4095-a18b-75802d2b82cb@github.com>
 <9vVj80zYSJT8t7_vAbc5b8GFbrs4-GbprfW7lZMw0YY=.fcc22368-83c9-444a-b260-e53df9cb2ac2@github.com>
 <pV-13lX3dvoRIx7cBWpACVba9m34bVpPCuyGtj-Z5Fg=.adcea474-2908-4ade-9c49-3c907da915d4@github.com>
 <AytBOuT8Lem7EWctkTkXN1y7QYDV6QGtgHWuvIRHECA=.60103beb-4083-488e-9605-c99eec18892f@github.com>
 <f4lr1U9BaMyYzlKwpwe5En2qA9yeGO66Pm2Mym1pVKI=.a1d53b77-54c0-4456-9d7f-3768a5f06b56@github.com>
Message-ID: <9QeWO6fjt111oX4GBEyDJ8qed34OmxB92KisUP8wQBw=.ceeb1d53-1c45-424a-9786-b27015daae6d@github.com>

On Thu, 28 Sep 2023 16:11:39 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> @mcimadamore Yes, I like the first. Something like "explicit constructor invocation may only appear within a constructor body" is good.
>> 
>> (The JLS actually says that an (explicit) constructor invocation, i.e. this(...) or super(...), is not a statement, but just a thing that can appear in a constructor body.)
>
> Updated error messages in 738c10a57de.

Good job! I like the new messages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1341070884

From abimpoudis at openjdk.org  Fri Sep 29 10:28:14 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Sep 2023 10:28:14 GMT
Subject: RFR: 8317048: VerifyError with unnamed pattern variable and more than
 one components
Message-ID: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>

There were situations when javac optimizes switch structures (by merging the head of cases recursively) when two neighboring cases have a mix of named and unnamed patterns. This resulted translation is like the following:

>From this:


  static <T1 extends Comparable, T2 extends Comparable> int compareTo(Tuple<R<T1>, R<T2>> o) {
        return switch (o) {
            case Tuple<R<T1>, R<T2>>(R1<T1> _, R1<T2> _) -> -1;
            case Tuple<R<T1>, R<T2>>(R1<T1> _, R2<T2> _) -> -1;
            case Tuple<R<T1>, R<T2>>(R2<T1> _, R1<T2> _) -> -1;
            case Tuple<R<T1>, R<T2>>(R2<T1> fst, R2<T2> snd) -> fst.value().compareTo(snd.value());
        };
    }


to code like this from the deeper nested switch (sample taken from `translateTopLevelClass`):


...
case 1:
   if (!(let snd = (T8317048.R2)selector10$temp; in true)) {
       index$11 = 2;
       continue;
   }
   yield .value().compareTo(snd.value()); // boom, fst is missing
   break;
...


The reason is that in the `resolveAccumulator` we peek the first of the two to replace both, in this case the `R2<T1> _`. 


JCPatternCaseLabel leadingTest = 
        (JCPatternCaseLabel) accummulator.first().labels.head;


On way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed).

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

Commit messages:
 - 8317048: VerifyError with unnamed pattern variable and more than one components
 - Add testfile

Changes: https://git.openjdk.org/jdk/pull/15983/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317048
  Stats: 89 lines in 2 files changed: 89 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15983/head:pull/15983

PR: https://git.openjdk.org/jdk/pull/15983

From abimpoudis at openjdk.org  Fri Sep 29 14:57:51 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 29 Sep 2023 14:57:51 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
Message-ID: <uXUSXmJfmt7DaoORRTWM6JIK67c1bNX2CxjEoTx3SXQ=.1b299e25-2077-4cba-a0bf-d118380be730@github.com>

On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

So, the following shows the changes in `Lower.java`. It removes the methods you propose at the cost of a little bit more indirection which is ok. However, there is a non-trivial amount of re-engineering needed to be done on the `SwitchBootstrap` to support this change. It is not a mere porting of the logic from `Lower` to `SwitchBootstrap`. This is easy (despite the duplication of the code which I am inviting recommendations on how to avoid ? ). What is more, is that the `selectorType` changes within `createRepeatIndexSwitch` and needs to change in various sites as well e.g., `createMethodHandleSwitch`. @lahodaj am I correct?

(this is a footprint vs code uniformity question. If the bytecode instructions are exactly the same and in one occasion (`short_byte` -> `int_byte`) one bytecode instruction shorter, maybe code uniformity should win here?)


Subject: [PATCH] [WIP] Implement type pairs to exactnessMethod name
---
Index: src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java
--- a/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java	(revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23)
+++ b/src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java	(date 1695993935975)
@@ -36,46 +36,6 @@
 
     private ExactnessMethods() { }
 
-    /** Exactness method from byte to char
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean byte_char(byte n)    {return n == (char) n;}
-
-    /** Exactness method from short to byte
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean short_byte(short n)  {return n == (short)(byte)(n);}
-
-    /** Exactness method from short to char
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean short_char(short n)  {return n == (char)(n);}
-
-    /** Exactness method from char to byte
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean char_byte(char n)    {return n == (byte)(n);}
-
-    /** Exactness method from char to short
-     *
-     * @param n value
-     * @return  true if the passed value can be converted exactly to the target type
-     *
-     * */
-    public static boolean char_short(char n)   {return n == (short)(n);}
-
      /** Exactness method from int to byte
      *
      * @param n value
Index: src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java	(revision 1ae06ac8f8cc0c0ce70920c2a62a7c13fdfc6f23)
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java	(date 1695992937983)
@@ -103,6 +103,7 @@
     private final PkgInfo pkginfoOpt;
     private final boolean optimizeOuterThis;
     private final boolean useMatchException;
+    private final HashMap<TypePairs, String> typePairToName;
 
     @SuppressWarnings("this-escape")
     protected Lower(Context context) {
@@ -134,6 +135,7 @@
         Preview preview = Preview.instance(context);
         useMatchException = Feature.PATTERN_SWITCH.allowedInSource(source) &&
                             (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH));
+        typePairToName = TypePairs.initialize(syms);
     }
 
     /** The currently enclosing class.
@@ -2996,15 +2998,81 @@
         }
     }
 
+    static class TypePairs {
+        public Type from, to;
+
+        public static TypePairs of(Symtab syms, Type from, Type to) {
+            if (from == syms.byteType || from == syms.shortType || from == syms.charType) {
+                from = syms.intType;
+            }
+            return new TypePairs(from, to);
+        }
+
+        private TypePairs(Type from, Type to) {
+            this.from = from;
+            this.to = to;
+        }
+
+        public static HashMap<TypePairs, String> initialize(Symtab syms) {
+            HashMap<TypePairs, String> typePairToName = new HashMap<>();
+            typePairToName.put(new TypePairs(syms.byteType,   syms.charType),   "int_char");      // redirected
+            typePairToName.put(new TypePairs(syms.shortType,  syms.byteType),   "int_byte");      // redirected
+            typePairToName.put(new TypePairs(syms.shortType,  syms.charType),   "int_char");      // redirected
+            typePairToName.put(new TypePairs(syms.charType,   syms.byteType),   "int_byte");      // redirected
+            typePairToName.put(new TypePairs(syms.charType,   syms.shortType),  "int_short");     // redirected
+            typePairToName.put(new TypePairs(syms.intType,    syms.byteType),   "int_byte");
+            typePairToName.put(new TypePairs(syms.intType,    syms.shortType),  "int_short");
+            typePairToName.put(new TypePairs(syms.intType,    syms.charType),   "int_char");
+            typePairToName.put(new TypePairs(syms.intType,    syms.floatType),  "int_float");
+            typePairToName.put(new TypePairs(syms.longType,   syms.byteType),   "long_byte");
+            typePairToName.put(new TypePairs(syms.longType,   syms.shortType),  "long_short");
+            typePairToName.put(new TypePairs(syms.longType,   syms.charType),   "long_char");
+            typePairToName.put(new TypePairs(syms.longType,   syms.intType),    "long_int");
+            typePairToName.put(new TypePairs(syms.longType,   syms.floatType),  "long_float");
+            typePairToName.put(new TypePairs(syms.longType,   syms.doubleType), "long_double");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.byteType),   "float_byte");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.shortType),  "float_short");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.charType),   "float_char");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.intType),    "float_int");
+            typePairToName.put(new TypePairs(syms.floatType,  syms.longType),   "float_long");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.byteType),   "double_byte");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.shortType),  "double_short");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.charType),   "double_char");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.intType),    "double_int");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.longType),   "double_long");
+            typePairToName.put(new TypePairs(syms.doubleType, syms.floatType),  "double_float");
+            return typePairToName;
+        }
+
+        @Override
+        public int hashCode() {
+            int code = 0;
+            code += from.tsym.hashCode();
+            code += to.tsym.hashCode();
+            return code;
+        }
+
+        @Override
+        public boolean equals(Object testName) {
+            if ((!(testName instanceof TypePairs testNameAsName))) return false;
+            else {
+                return this.from.tsym.equals(testNameAsName.from.tsym) &&
+                        this.to.tsym.equals(testNameAsName.to.tsym);
+            }
+        }
+    }
+
     private JCExpression getExactnessCheck(JCInstanceOf tree, JCExpression argument) {
-        Name exactnessFunction = names.fromString(types.unboxedTypeOrType(tree.expr.type).tsym.name.toString() + "_"+ tree.pattern.type.toString());
+        TypePairs pair = TypePairs.of(syms, types.unboxedTypeOrType(tree.expr.type), tree.pattern.type);
+
+        Name exactnessFunction = names.fromString(typePairToName.get(pair));
 
         // Resolve the exactness method
         Symbol ecsym = rs.resolveQualifiedMethod(null,
                 attrEnv,
                 syms.exactnessMethodsType,
                 exactnessFunction,
-                List.of(tree.expr.type),
+                List.of(pair.from),
                 List.nil());
 
         // Generate the method call ExactnessChecks.<exactness method>(<argument>);

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741006395

From vromero at openjdk.org  Fri Sep 29 16:13:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 16:13:06 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v3]
In-Reply-To: <iQFCLIrUlVVQ6GmbDJtycaD0MCrOrGLUJDbjmvHSq24=.10c4d60d-e947-403e-b50a-bea10ae74fef@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <iQFCLIrUlVVQ6GmbDJtycaD0MCrOrGLUJDbjmvHSq24=.10c4d60d-e947-403e-b50a-bea10ae74fef@github.com>
Message-ID: <1F1qZ0zrP8REUWPhym75-TjmbDaz0gU-dubBBD8jQEA=.0101f7ee-9955-429a-97ab-34ead661ac6d@github.com>

On Fri, 29 Sep 2023 08:30:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
>> 
>> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
>> 
>> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
>> 
>> The output from javac looks as follows:
>> 
>> 
>> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>>       Arena.ofAuto().allocate(10).reinterpret(100);
>>                                  ^
>>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

looks good, thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15964#pullrequestreview-1651019837

From vromero at openjdk.org  Fri Sep 29 16:13:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 16:13:10 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v2]
In-Reply-To: <P7P9ykX3Fxe_u9xRvgQSazy_AVsK94oNNrAnf2CkkxU=.7260bc03-430a-4ee9-becb-c4af04c4a277@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
 <3MIhZYc0D6jAcR8dG7fbma_Jixd66raLq3C3FMzbtmI=.6c487872-a916-4117-bc2e-c1ba814e6ada@github.com>
 <ZW-Ghv-bZR9SO35dGtk40uqItRy2ju6O84IILY-yMt4=.bf98a101-8466-4a35-80b7-29e85e330ae8@github.com>
 <P7P9ykX3Fxe_u9xRvgQSazy_AVsK94oNNrAnf2CkkxU=.7260bc03-430a-4ee9-becb-c4af04c4a277@github.com>
Message-ID: <BbEFZCA4kH2bK1VlWKQpApQjmfRYDx1kNwmy89nQF-g=.159d2d18-ddf4-4739-9eaa-c3c18daa1792@github.com>

On Fri, 29 Sep 2023 08:14:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > question shouldn't the new Restricted annotation be annotated with the @PreviewFeature annotation? it depends on a preview feature
> 
> The Restricted annotation is an internal annotation only. So there is no value in annotating it with `@PreviewFeature`. Also, note that there is a PR already filed which, when integrated, will move the FFM API out of preview [1].
> 
> [1] - https://git.openjdk.org/jdk/pull/15103

I see, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/15964#issuecomment-1741057810

From rgiulietti at openjdk.org  Fri Sep 29 16:38:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 29 Sep 2023 16:38:17 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
Message-ID: <EoilLyqaD9Fbx8k1mK-dB7nG_Star3e25rH1YaUfmkA=.88e63d0e-454b-4a7e-93f5-707f0ef034b5@github.com>

On Thu, 28 Sep 2023 16:46:11 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

I just had a reading at the `ExactnessMethods` class. From that limited perspective, the methods mentioned above seem redundant.
But if their removal would make other parts more complex, that's a good reason to keep them.

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1741159978

From robo at khelekore.org  Fri Sep 29 18:37:11 2023
From: robo at khelekore.org (Robert Olofsson)
Date: Fri, 29 Sep 2023 20:37:11 +0200
Subject: Question about null handling in SwitchLabel
In-Reply-To: <48FDB6CF-D01D-4C87-9FD7-642106B74008@oracle.com>
References: <20230926213248.165cdd51@skully>
 <48FDB6CF-D01D-4C87-9FD7-642106B74008@oracle.com>
Message-ID: <20230929203711.1b9656ea@skully>

Hi!

Thank you Gavin, I do appreciate that you are trying to help.

On Tue, 26 Sep 2023 21:23:46 +0000
Gavin Bierman <gavin.bierman at oracle.com> wrote:

> If you look in 14.11.1 of JLS just under the grammar you quoted:
> 
> > Every case constant must be either a constant expression (?15.29),
> > or the name of an enum constant (?8.9.1), otherwise a compile-time
> > error occurs.  
> 
> That?s why null is not allowed; it?s not a constant expression, or
> the name of an enum constant. 

Yes, this much is clear. It is also in line with the comment I found.
It is however not what the actual grammar say.

I find it a bit funny and/or annoying that the grammar is not good
enough to really be used. I think it would be really nice to have an
accurate grammar, but it may be that java is too complex to really
allow this.

But I will try to be clearer.

Why is null only allowed on its own or with default.
Why is the grammar not looking like:
---------------------------------------------------------
SwitchLabel:
  case Switchable {, Switchable}

Switchable:
  CaseConstant
  null
  default
---------------------------------------------------------
CaseConstant would of course still be required to be a constant and
null and default could only be used once, but having something like
the above would allow for the example that I gave:
case "A", "B", null -> ....

I do not really have any real use case for this, but to me the current
grammar seems to have a bit complexity that may not be needed and I am
curious if there is a reason for it.

Now, talking about constant expressions is also a bit interesting,
when I look at the grammar
(https://docs.oracle.com/javase/specs/jls/se21/html/jls-19.html)
I find 
ConstantExpression:
  Expression

at the bottom, but searching for ConstantExpressioon gives only this
result, so ConstantExpression is not used in the grammar. Is it needed
by anything or is it something that ought to be removed?

Thanks!
/robo

From vromero at openjdk.org  Fri Sep 29 18:53:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 18:53:54 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v2]
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <uBeD2wWRoLUMmEyTRv1NKDO0tefsgic9bOJo0NdKZbE=.347af0cf-1538-4ea8-af3b-298ffa816731@github.com>

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15974/files
  - new: https://git.openjdk.org/jdk/pull/15974/files/4647c9c7..2902b04d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=00-01

  Stats: 163 lines in 3 files changed: 111 ins; 45 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15974/head:pull/15974

PR: https://git.openjdk.org/jdk/pull/15974

From vromero at openjdk.org  Fri Sep 29 18:53:54 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 18:53:54 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body
In-Reply-To: <_kIfX1FQXUC6OSN51J3GbpQAAYRiByvMQeIUQY9lpzk=.1f971ed3-3cd1-482d-ba93-e4dd0bd3e3c4@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
 <_kIfX1FQXUC6OSN51J3GbpQAAYRiByvMQeIUQY9lpzk=.1f971ed3-3cd1-482d-ba93-e4dd0bd3e3c4@github.com>
Message-ID: <HLajB0Tc82bqHojI-AMWsebpQOIOVIfwxhjdM9j0DTs=.6dd4f66b-d5ca-4d7f-92af-124693d4cf85@github.com>

On Thu, 28 Sep 2023 22:55:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Is this issue or an analagous issue triggered for default constructors or the special constructors of records?
> 
> Is so, it would be good to have explicit test coverage of those cases too.

I didn't see this issue being triggered for default constructors or record's special constructors.

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

PR Comment: https://git.openjdk.org/jdk/pull/15974#issuecomment-1741295715

From vromero at openjdk.org  Fri Sep 29 18:53:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 18:53:55 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v2]
In-Reply-To: <_kIfX1FQXUC6OSN51J3GbpQAAYRiByvMQeIUQY9lpzk=.1f971ed3-3cd1-482d-ba93-e4dd0bd3e3c4@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
 <_kIfX1FQXUC6OSN51J3GbpQAAYRiByvMQeIUQY9lpzk=.1f971ed3-3cd1-482d-ba93-e4dd0bd3e3c4@github.com>
Message-ID: <6IlNDnSc0B4KqIjBu3iWwqXI3qO5WGyfNjTz_AGJJds=.c34dae4e-9892-4150-a063-73bb64a707f4@github.com>

On Thu, 28 Sep 2023 22:58:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The style of annotation processor tests does vary a bit by area of javac. It should be technically possible to put the code being tested and the annotation processor into a single file, as is commonly done in the direct annotation processing tests.
> 
> I can send some pointers if that kind of refactoring would be of interest.

I have uploaded another iteration that refactors the test as suggested

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15974#discussion_r1341666356

From vromero at openjdk.org  Fri Sep 29 23:36:48 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Sep 2023 23:36:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
Message-ID: <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>

On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeature annotated with JEP 457

make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java line 476:

> 474:                         throw parser.newError("is malformed");
> 475:                     }
> 476:                 } else if (token.equals("import")) {

why is this change necessary?

src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34:

> 32: import jdk.internal.javac.PreviewFeature;
> 33: 
> 34: /**

shouldn't we have the preview header applied to all these compilation units?:


{@preview Associated with pattern matching for instanceof, a preview feature of the Java language.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341847954
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341855569

From davidalayachew at gmail.com  Sat Sep 30 03:22:09 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 29 Sep 2023 23:22:09 -0400
Subject: I don't understand the "this-escape" warning under this context
Message-ID: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>

Hello Compiler Dev Team,

I have the following code example.

```java

package Paint;

import javax.swing.*;

public class GUI
{

   private final JFrame frame;

   public GUI()
   {

      this.frame = new JFrame();

      this.frame.add(this.createBottomPanel());

   }

   private final JPanel createBottomPanel()
   {

      final JButton save = new JButton();

      save
         .addActionListener
         (
            actionEvent ->
            {

               this.toString();

            }

         )
         ;

      return null;

   }

}
```

This is the compile command that I used.

```
javac -Xlint:all GUI.java
```

When I compile, I get the following warning.

```
GUI.java:16: warning: [this-escape] possible 'this' escape before subclass
is fully initialized
      this.frame.add(this.createBottomPanel());
                                           ^
GUI.java:28: warning: [this-escape] previous possible 'this' escape happens
here via invocation
            actionEvent ->
            ^
2 warnings
```

Can someone help me understand the what, why, and how of this warning? I
don't understand it at all.

I am pretty sure I understand the basic premise of "this-escape" -- a
not-fully-initialized object (this) can "escape" from its constructor
before completing initialization, usually causing bugs and security
vulnerabilities.

A good example of this is a constructor calling an overridable method. If a
subclass overrides that method, it may expose the state or perform
behaviour that it is not prepared to perform at that time, amongst other
things.

But I struggle to follow that logic for my example. Could someone walk me
through this?

Thank you for your time and help!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230929/f0385aa4/attachment-0001.htm>

From vromero at openjdk.org  Sat Sep 30 04:36:55 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 30 Sep 2023 04:36:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
Message-ID: <FimCVW1larkP9y4yw-3D5wqJ7VgMBgnNPHE599HB2ZE=.8d1168c0-c7bc-4b5e-bcc1-f080bbe3d412@github.com>

On Tue, 26 Sep 2023 12:32:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PreviewFeature annotated with JEP 457

src/java.base/share/classes/java/lang/classfile/Attributes.java line 174:

> 172:     public static final String NAME_RUNTIME_INVISIBLE_ANNOTATIONS = "RuntimeInvisibleAnnotations";
> 173: 
> 174:     /** RuntimeInvisibleTypeAnnotations */

this comment should probably be: RuntimeInvisibleParameterAnnotations

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1341908521

From forax at univ-mlv.fr  Sat Sep 30 05:45:17 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 30 Sep 2023 07:45:17 +0200 (CEST)
Subject: I don't understand the "this-escape" warning under this context
In-Reply-To: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>
References: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>
Message-ID: <455721543.9073242.1696052717946.JavaMail.zimbra@univ-eiffel.fr>

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Saturday, September 30, 2023 5:22:09 AM
> Subject: I don't understand the "this-escape" warning under this context

> Hello Compiler Dev Team,

> I have the following code example.

> ```java

> package Paint;

> import javax.swing.*;

> public class GUI
> {

> private final JFrame frame;

> public GUI()
> {

> this.frame = new JFrame();

> this.frame.add(this.createBottomPanel());

> }

> private final JPanel createBottomPanel()
> {

> final JButton save = new JButton();

> save
> .addActionListener
> (
> actionEvent ->
> {

> this.toString();

> }

> )
> ;

> return null;

> }

> }
> ```

> This is the compile command that I used.

> ```
> javac -Xlint:all GUI.java
> ```

> When I compile, I get the following warning.

> ```
> GUI.java:16: warning: [this-escape] possible 'this' escape before subclass is
> fully initialized
> this.frame.add(this.createBottomPanel());
> ^
> GUI.java:28: warning: [this-escape] previous possible 'this' escape happens here
> via invocation
> actionEvent ->
> ^
> 2 warnings
> ```

> Can someone help me understand the what, why, and how of this warning? I don't
> understand it at all.

> I am pretty sure I understand the basic premise of "this-escape" -- a
> not-fully-initialized object (this) can "escape" from its constructor before
> completing initialization, usually causing bugs and security vulnerabilities.

> A good example of this is a constructor calling an overridable method. If a
> subclass overrides that method, it may expose the state or perform behaviour
> that it is not prepared to perform at that time, amongst other things.

> But I struggle to follow that logic for my example. Could someone walk me
> through this ?

The first error seems to be a false positive because as you said the method createBottomPanel() is private (BTW, all private methods can not be overriden so declaring a private method final is not really useful). 
The second error is due to the fact that the lambda can be called before the end of the constructor, the compiler is not smart enough to know if this is the case or not. 

The usual workaround is to create the GUI inside static methods, the constructor being a static factory named by example createGUI() and createBottomPanel() being declared static. 
If you need objects, pass them as parameter of the static methods, so they are known to be fully initialized. 

Apart for the bugs with subclassing, the problem of publication in a concurrency context, having a constructor that escapes "this" also prevents a class to be a value class. 

> Thank you for your time and help!
> David Alayachew

regards, 
R?mi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230930/438c625b/attachment.htm>

From abimpoudis at openjdk.org  Sat Sep 30 08:09:31 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 30 Sep 2023 08:09:31 GMT
Subject: RFR: 8317300: javac erroneously allows "final" in front of a record
 pattern
Message-ID: <O2KHdJQLfVfTbOpkht3lOCmhE8QLuBCHTocmBZ4tVV4=.9bb2fd68-3700-4234-be04-3cb7f9a6dcf3@github.com>

Introduces the relevant check for `final` in record patterns.

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

Commit messages:
 - 8317300: javac erroneously allows "final" in front of a record pattern

Changes: https://git.openjdk.org/jdk/pull/15997/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317300
  Stats: 30 lines in 3 files changed: 30 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15997/head:pull/15997

PR: https://git.openjdk.org/jdk/pull/15997

From archie.cobbs at gmail.com  Sat Sep 30 14:04:55 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sat, 30 Sep 2023 09:04:55 -0500
Subject: I don't understand the "this-escape" warning under this context
In-Reply-To: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>
References: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>
Message-ID: <CANSoFxuW+VicWN_7tBo3aaWUhUdE+_DrLFcQhLh-J_1_Gp2=xg@mail.gmail.com>

On Sat, Sep 30, 2023 at 12:55?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> package Paint;
>
> import javax.swing.*;
>
> public class GUI
> {
>
>    private final JFrame frame;
>
>    public GUI()
>    {
>
>       this.frame = new JFrame();
>
>       this.frame.add(this.createBottomPanel());
>
>    }
>
>    private final JPanel createBottomPanel()
>    {
>
>       final JButton save = new JButton();
>
>       save
>          .addActionListener
>          (
>             actionEvent ->
>             {
>
>                this.toString();
>
>             }
>
>          )
>          ;
>
>       return null;
>
>    }
>
> }
> ```
> Can someone help me understand the what, why, and how of this warning? I
> don't understand it at all.
>

First note there is really only one warning, even though the compiler says
"2 warnings". It's just trying to show you the full "stack trace" where the
leak occurs.

Here's the sequence of events that the compiler is fretting about:

   1. GUI constructor invokes this.createBottomPanel()
   2. createBottomPanel() creates a lambda that, if/when it ever gets
   invoked, could invoke this.toString()
   3. createBottomPanel() passes this lambda to save.addActionListener()
   4. save.addActionListener() (which the compiler does NOT inspect) might
   possibly invoke the lambda
   5. the lambda invokes GUI.toString()

Since your class GUI is public and non-final, it could be subclassed, and
since GUI.toString() is not final, that subclass could override toString().

So in summary the compiler is deducing that it's *possible* (in theory)
that a subclass could unwittingly operate on an incompletely initialized
object - i.e., a 'this' escape.

Note that the compiler only looks at the one file you are compiling. It
does not try to inspect JButton to see what addActionListener() actually
does. So for step 4 it just assumes the worst case, which is that
addActionListener() immediately invokes the lamba. Of course you and I know
this is not actually how it behaves.

So is this a "false positive"?

Yes in the sense that we "know" JButton.addActionListener() doesn't
immediately invoke the lambda. But in general the compiler can't make
assumptions about the behavior of other classes, even those that are part
of the current compilation, because you could swap out class files at
runtime and change that behavior.

So all inferences are made based only on what can be deduced from the one
file you are currently compiling. In that sense, this warning is not a
false positive.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230930/f24b0599/attachment.htm>

From davidalayachew at gmail.com  Sat Sep 30 18:27:55 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 30 Sep 2023 14:27:55 -0400
Subject: I don't understand the "this-escape" warning under this context
In-Reply-To: <CANSoFxuW+VicWN_7tBo3aaWUhUdE+_DrLFcQhLh-J_1_Gp2=xg@mail.gmail.com>
References: <CAA9v-_MwAbfXSZJpshzYwqmbcFaW07PRnBY-Y8Z+gU2vUQM7zQ@mail.gmail.com>
 <CANSoFxuW+VicWN_7tBo3aaWUhUdE+_DrLFcQhLh-J_1_Gp2=xg@mail.gmail.com>
Message-ID: <CAA9v-_NLH7Q_OQS1_i2677GBuBkebs82z4TcezdWC+oPUFJ0EA@mail.gmail.com>

Hello R?mi and Archie,

Thank you both for your response!

> R?mi:
> The first error seems to be a false positive because as
> you said the method createBottomPanel() is private

Thank you for acknowledging this -- this is the part that threw me off and
prompted me to make this post. It appeared to me to be a false positive as
well, but I figured that I was missing info.

> R?mi:
> (BTW, all private methods can not be overriden so
> declaring a private method final is not really useful).

Fair. I did that out of desperation, since I truly did not understand what
was happening.

> R?mi:
> The second error is due to the fact that the lambda can
> be called before the end of the constructor, the compiler
> is not smart enough to know if this is the case or not.
>
> Archie:
> Note that the compiler only looks at the one file you are
> compiling. It does not try to inspect JButton to see what
> addActionListener() actually does. So for step 4 it just
> assumes the worst case, which is that addActionListener()
> immediately invokes the lamba. Of course you and I know
> this is not actually how it behaves.

I see what you both are saying. At first glance, this feels like it
cheapens the warning, but after thinking about it more, I think that
assumption is only really applicable to the small scale. Once you start
designing massive applications, this "false positive" becomes a lot more
plausible.

> R?mi:
> The usual workaround is to create the GUI inside static
> methods, the constructor being a static factory named by
> example createGUI() and createBottomPanel() being
> declared static.
>
> If you need objects, pass them as parameter of the static
> methods, so they are known to be fully initialized.
>
> Apart for the bugs with subclassing, the problem of
> publication in a concurrency context, having a
> constructor that escapes "this" also prevents a class to
> be a value class.

Thanks for the solutions and context.

Knowing that this is critical for value objects solidifies the warnings
usefulness to me. I have several projects that are throwing this warning,
but knowing what I get in return for fixing this warning makes fixing all
of those projects completely worth it.

And the solutions presented are all easy refactors, so thank you for
pointing me to them.

I do have a request -- documentation on this particular warning, as well as
the info you both brought up here, is difficult to find. Could we get some
documentation or an article by Oracle going in-depth about this warning and
how to avoid it?

My anecdotal justification for why this warning deserves this more than any
other warning that doesn't already have one is that over 40% of my projects
are now throwing this warning. This is the first time that upgrading to a
new JDK has caused this many warnings to show up in such a large percentage
of my projects. Furthermore, remedying this isn't immediately obvious, not
just because of lambdas, but because you must consider the "overridability"
of all methods that receive a reference to this -- including library
methods! That can be a difficult concept to wrap your head around with the
minimal documentation I found [1][2], so some more documentation/guidance
would be appreciated. Finally, if this is going to be useful to us in
utilizing value classes, then that is a solid reason why this should
further be documented.

I now have enough information to solve my current problem, but I'm sure
others would appreciate easy access to this information too.

Thank you for both for your time and help!
David Alayachew

[1]=javac --help-lint
[2]=
https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html#examples-of-using--xlint-keys

On Sat, Sep 30, 2023 at 10:05?AM Archie Cobbs <archie.cobbs at gmail.com>
wrote:

> On Sat, Sep 30, 2023 at 12:55?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> package Paint;
>>
>> import javax.swing.*;
>>
>> public class GUI
>> {
>>
>>    private final JFrame frame;
>>
>>    public GUI()
>>    {
>>
>>       this.frame = new JFrame();
>>
>>       this.frame.add(this.createBottomPanel());
>>
>>    }
>>
>>    private final JPanel createBottomPanel()
>>    {
>>
>>       final JButton save = new JButton();
>>
>>       save
>>          .addActionListener
>>          (
>>             actionEvent ->
>>             {
>>
>>                this.toString();
>>
>>             }
>>
>>          )
>>          ;
>>
>>       return null;
>>
>>    }
>>
>> }
>> ```
>> Can someone help me understand the what, why, and how of this warning? I
>> don't understand it at all.
>>
>
> First note there is really only one warning, even though the compiler says
> "2 warnings". It's just trying to show you the full "stack trace" where the
> leak occurs.
>
> Here's the sequence of events that the compiler is fretting about:
>
>    1. GUI constructor invokes this.createBottomPanel()
>    2. createBottomPanel() creates a lambda that, if/when it ever gets
>    invoked, could invoke this.toString()
>    3. createBottomPanel() passes this lambda to save.addActionListener()
>    4. save.addActionListener() (which the compiler does NOT inspect)
>    might possibly invoke the lambda
>    5. the lambda invokes GUI.toString()
>
> Since your class GUI is public and non-final, it could be subclassed, and
> since GUI.toString() is not final, that subclass could override toString().
>
> So in summary the compiler is deducing that it's *possible* (in theory)
> that a subclass could unwittingly operate on an incompletely initialized
> object - i.e., a 'this' escape.
>
> Note that the compiler only looks at the one file you are compiling. It
> does not try to inspect JButton to see what addActionListener() actually
> does. So for step 4 it just assumes the worst case, which is that
> addActionListener() immediately invokes the lamba. Of course you and I know
> this is not actually how it behaves.
>
> So is this a "false positive"?
>
> Yes in the sense that we "know" JButton.addActionListener() doesn't
> immediately invoke the lambda. But in general the compiler can't make
> assumptions about the behavior of other classes, even those that are part
> of the current compilation, because you could swap out class files at
> runtime and change that behavior.
>
> So all inferences are made based only on what can be deduced from the one
> file you are currently compiling. In that sense, this warning is not a
> false positive.
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230930/05211047/attachment-0001.htm>