From hannesw at openjdk.org  Thu Aug  1 12:01:40 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 1 Aug 2024 12:01:40 GMT
Subject: RFR: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc [v7]
In-Reply-To: <43YQdIChggAClgqX0386nbz1tnJYekHNVl34a5TPV7I=.6ba0c8dc-bbc1-4f45-89aa-c17a2d73ca5a@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
 <43YQdIChggAClgqX0386nbz1tnJYekHNVl34a5TPV7I=.6ba0c8dc-bbc1-4f45-89aa-c17a2d73ca5a@github.com>
Message-ID: <gmcfoVyfpLl9NHWQd-mV94AqUAqOogILZK8cwMtptuI=.5135f7b4-9c9e-4f06-8a1a-f571ec035350@github.com>

On Wed, 31 Jul 2024 18:00:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module.
>> 
>> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet.
>> 
>> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name.
>> 
>> A few minor bugs were found and fixed.   Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package.  The naming follows `HtmlId` and `HtmlIds`.
>> 
>> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge with upstream master;
>    add reference in HtmlTag to a related RFE
>  - Update/improve merge of HtmlTag and TagName
>  - Fix missing legal headers
>  - Cleanup use of HtmlStyle and HtmlStyles
>  - Fix merge issues
>  - Merge with upstream master
>  - fix whitespace
>  - reorder imports
>  - Cleanup pass
>  - Merge doclint into html: part 2: TagName/HtmlTag
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e4c7850c...2b6363ee

Looks good! It would be nice to have class-level doc comments in the new shared HTML classes.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlAttr.java line 32:

> 30: import java.util.Locale;
> 31: 
> 32: public enum HtmlAttr {

Not essential, but it would be nice to have a simple class doc comment such as "Enum representing HTML tag attributes."

src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlStyle.java line 28:

> 26: package jdk.javadoc.internal.html;
> 27: 
> 28: public interface HtmlStyle {

Again, a simple doc comment would be nice.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19916#pullrequestreview-2212514448
PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1700013819
PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1700014922

From mcimadamore at openjdk.org  Thu Aug  1 13:02:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Aug 2024 13:02:02 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
Message-ID: <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>

> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
> 
> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
> 
> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
> 
> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
> 
> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
> 
> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
> 
> #### Compatibility
> 
> This PR chan...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20349/files
  - new: https://git.openjdk.org/jdk/pull/20349/files/df490071..04633eea

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

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

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

From vromero at openjdk.org  Thu Aug  1 13:26:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 Aug 2024 13:26:32 GMT
Subject: [jdk23] RFR: 8337054: JDK 23 RDP2 L10n resource files update [v3]
In-Reply-To: <wM_z_8I329MPq1EwzFPOpsKQIiaPZMIim1r_pOKmYJo=.c5c629c8-cebf-4ee7-8bc7-cdc7419297b0@github.com>
References: <S7nAzOLzpi02t5-jk_28JZXK_p5E9DBjfMasxr7CtJs=.c4d61155-3341-444a-9cc4-d6f323c5f035@github.com>
 <wM_z_8I329MPq1EwzFPOpsKQIiaPZMIim1r_pOKmYJo=.c5c629c8-cebf-4ee7-8bc7-cdc7419297b0@github.com>
Message-ID: <dXhJdWCJWBN53WirPBjjBhHiXSjMdGNUUlsL6ZsMoUY=.1f596f56-4b2f-4c93-89ca-ec8d0ac0b301@github.com>

On Wed, 31 Jul 2024 11:02:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Localization update for JDK23 RDP2
>> 
>> Please view for enhanced diffs on affected files:
>> https://cr.openjdk.org/~dnguyen/output/
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update another translation

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20394#pullrequestreview-2212723397

From vromero at openjdk.org  Thu Aug  1 13:56:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 1 Aug 2024 13:56:35 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
Message-ID: <G5nq3ZgfumbYpjHngB4s5D1e_oq_GYc2CCYC8JIZP7Q=.d023b402-c63b-4968-a5a2-b99eeeb535a4@github.com>

On Thu, 1 Aug 2024 13:02:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
>> 
>> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
>> 
>> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
>> 
>> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
>> 
>> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
>> 
>> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
>> 
>> #### C...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

latest changes look good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2212903477

From wdietl at gmail.com  Thu Aug  1 16:31:10 2024
From: wdietl at gmail.com (Werner Dietl)
Date: Thu, 1 Aug 2024 12:31:10 -0400
Subject: Redo of backport of JDK-8225377 (type annotations are not visible
 to javac plugins across compilation boundaries)
In-Reply-To: <CAEvq2np4V51Hc2M0Jp_uRNm9onMwx5dXOApAyayLa-LjhTcXFQ@mail.gmail.com>
References: <CAL4QsgtWqufynkRg_Yes2=UocHqjUSkBRiGzgBn-zkCFi1RYeA@mail.gmail.com>
 <CAFXXopOtXc_vpBx0h4L_0U78dONQ=iKh4sKoUAUTxO6OD8AvGg@mail.gmail.com>
 <CAJ_t5UacWsFb6iiWzcKKKsT2O153W5E4kqRStFOKxdJ2oqWCSA@mail.gmail.com>
 <CAEvq2np4V51Hc2M0Jp_uRNm9onMwx5dXOApAyayLa-LjhTcXFQ@mail.gmail.com>
Message-ID: <CAJYRO=7=nTLNm=fn6h-5unb==Fc1eNU7Ey2RwO9_GMds+7BSzQ@mail.gmail.com>

I would also be very happy if this were backported to earlier JDKs.
The pluggable type system frameworks I work on mostly have work-arounds for
this issue, but it would be much nicer to have correct type-use annotation
information from javac directly.
I also agree with Chris's comment on having a positive feedback loop. Any
positive change has some danger of breaking existing code. This shouldn't
stop us from fixing bugs, improving the type-use annotation infrastructure,
and enabling more adoption.

Best,
cu, WMD.

On Mon, Jul 29, 2024 at 11:22?AM Chris Povirk <cpovirk at google.com> wrote:

> Manu spoke about the ability to annotate different positions (e.g.,
> type-parameter bounds) for improved nullness checking. I'd also call out
> that this affects even users who use nullness annotations on "basic"
> locations like fields, parameters, and return types: Unless tools use
> internal javac APIs, type-use annotations in even these basic locations in
> class files are invisible until JDK 22. (And as Josiah points out, this
> affects more tools than just "nullness checkers." We've also seen it with
> AutoValue
> <https://github.com/google/auto/blob/main/value/userguide/index.md>.)
> This means that type-use annotations are worse than declaration annotations
> in some ways, even as they're better in others. As a result, users can't
> confidently pick even a set of nullness annotations without evaluating the
> tradeoffs. It would be great to be able to tell users "Use type-use
> annotations" without waiting for them all to update to JDK 22.
>
> Plus: Even if the fix is backported today, experience shows that users
> will also have to wait for some annotation processors to be enhanced to
> start looking for type-use annotations _at all_. I'd be happy to see us
> continue to drive that positive feedback loop: As type-use annotations
> become more visible to annotation processors, tools increasingly get
> modified to recognize them, leading to more adoption of type-use
> annotations and more opportunity to identify and iron out remaining
> wrinkles.
>
> Thanks,
> Chris
>


-- 
https://ece.uwaterloo.ca/~wdietl/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240801/bb2929e3/attachment-0001.htm>

From cushon at openjdk.org  Thu Aug  1 17:24:34 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 1 Aug 2024 17:24:34 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
Message-ID: <2oxmZsb1vuzBcmGBepsJm-XXNDmStwgaoGUHqXsDHtM=.046fe24b-89df-4940-9fed-04b4ee193002@github.com>

On Thu, 1 Aug 2024 13:02:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
>> 
>> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
>> 
>> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
>> 
>> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
>> 
>> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
>> 
>> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
>> 
>> #### C...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

I did another round of testing with the latest version of the PR, everything still looks good to me.

* I am no longer seeing any serialization compatibility impact.
* I'm still seeing some impact from changes to lambda names. The impact is minor, and all of the occurrences I saw were in tests. I don't have any concerns about proceeding with that part.

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

PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2263577709

From liach at openjdk.org  Thu Aug  1 20:02:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 20:02:54 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v7]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - More refinements from alex
 - Artifact -> construct
 - More about Annotation, add equals note
 - Further refine wording
 - Refine the spec of TypeAnnotation per Alex feedback
 - SealedGraph now redundant
 - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/cf16e7ee..d45c35fc

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

  Stats: 13943 lines in 436 files changed: 7864 ins; 4437 del; 1642 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Thu Aug  1 20:02:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 20:02:54 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v6]
In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com>
Message-ID: <mD-oVdBhV_ww8O9s1HijouilpGyCPPP0YiQkX8pvKd0=.c9ca2b13-1b04-455c-800f-4a570229281f@github.com>

On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note

I have added a few more paragraphs in response to the request for comments on default values and repeatable annotations. Below are the excerpts, for `Annotation` and `AnnotationElement::name`.


 * In an annotation in Java source code, elements in the annotation interface
 * with default values may not be compiled into element-value pairs unless an
 * explicit value is provided. ({@jls 9.6.2}) The default value is derived from
 * the {@link AnnotationDefaultAttribute AnnotationDefault} attribute on the
 * method representing the annotation interface element in the class file
 * representing the annotation interface.
 * <p id="repeatable">
 * Multiple annotations of the same interface <i>A</i> in Java source code
 * ({@jls 9.7.5}) are represented by the {@linkplain AnnotationValue.OfAnnotation
 * annotation-valued} array elements of the {@linkplain AnnotationValue.OfArray
 * array-valued} element named {@code value} of a container annotation of the
 * containing annotation interface of <i>A</i>. ({@jls 9.6.3})


     * <p>
     * A single-element annotation ({@jls 9.7.3}) in Java source code is
     * compiled to an {@link Annotation} with exactly one {@linkplain
     * Annotation#elements key-value pair} where the element has the name
     * {@code value}.
     * <p>
     * Multiple annotations of the same interface <i>A</i> in Java source code
     * is compiled to an implicitly declared container annotation ({@jls 9.7.5})
     * with exactly one {@linkplain Annotation#elements key-value pair} where
     * the element has the name {@code value} and the type of the element is the
     * {@linkplain AnnotationValue.OfArray array} whose component type is the
     * {@linkplain AnnotationValue.OfAnnotation annotation interface <i>A</i>}.

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2263874434

From jjg at openjdk.org  Thu Aug  1 20:05:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Aug 2024 20:05:34 GMT
Subject: RFR: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc [v7]
In-Reply-To: <gmcfoVyfpLl9NHWQd-mV94AqUAqOogILZK8cwMtptuI=.5135f7b4-9c9e-4f06-8a1a-f571ec035350@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
 <43YQdIChggAClgqX0386nbz1tnJYekHNVl34a5TPV7I=.6ba0c8dc-bbc1-4f45-89aa-c17a2d73ca5a@github.com>
 <gmcfoVyfpLl9NHWQd-mV94AqUAqOogILZK8cwMtptuI=.5135f7b4-9c9e-4f06-8a1a-f571ec035350@github.com>
Message-ID: <XhGdLkYGRxhI3KJuckJEf1Iu4j9_Tcy_2Fr-yLram6w=.0fcc23ba-2b55-41c7-9a20-e0ffce59c48c@github.com>

On Thu, 1 Aug 2024 11:53:29 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge with upstream master;
>>    add reference in HtmlTag to a related RFE
>>  - Update/improve merge of HtmlTag and TagName
>>  - Fix missing legal headers
>>  - Cleanup use of HtmlStyle and HtmlStyles
>>  - Fix merge issues
>>  - Merge with upstream master
>>  - fix whitespace
>>  - reorder imports
>>  - Cleanup pass
>>  - Merge doclint into html: part 2: TagName/HtmlTag
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/e4c7850c...2b6363ee
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlAttr.java line 32:
> 
>> 30: import java.util.Locale;
>> 31: 
>> 32: public enum HtmlAttr {
> 
> Not essential, but it would be nice to have a simple class doc comment such as "Enum representing HTML tag attributes."

Of course; will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19916#discussion_r1700776116

From jjg at openjdk.org  Thu Aug  1 20:41:48 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 1 Aug 2024 20:41:48 GMT
Subject: RFR: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc [v8]
In-Reply-To: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
Message-ID: <Ze_YKYzVDCnuGilfznoeb4G76ToD-bVDProhTQtByl0=.22b2451d-4eb9-41e0-b403-0a2250c06503@github.com>

> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module.
> 
> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet.
> 
> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name.
> 
> A few minor bugs were found and fixed.   Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package.  The naming follows `HtmlId` and `HtmlIds`.
> 
> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedback: add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19916/files
  - new: https://git.openjdk.org/jdk/pull/19916/files/2b6363ee..ff489059

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

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

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

From alex.buckley at oracle.com  Thu Aug  1 20:59:09 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 1 Aug 2024 13:59:09 -0700
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v6]
In-Reply-To: <mD-oVdBhV_ww8O9s1HijouilpGyCPPP0YiQkX8pvKd0=.c9ca2b13-1b04-455c-800f-4a570229281f@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com>
 <mD-oVdBhV_ww8O9s1HijouilpGyCPPP0YiQkX8pvKd0=.c9ca2b13-1b04-455c-800f-4a570229281f@github.com>
Message-ID: <33af1a6f-fe95-48e9-80b0-dc5397fc1db4@oracle.com>

On 8/1/2024 1:02 PM, Chen Liang wrote:
>   * In an annotation in Java source code, elements in the annotation interface
>   * with default values may not be compiled into element-value pairs unless an
>   * explicit value is provided. ({@jls 9.6.2}) The default value is derived from
>   * the {@link AnnotationDefaultAttribute AnnotationDefault} attribute on the
>   * method representing the annotation interface element in the class file
>   * representing the annotation interface.
>   * <p id="repeatable">
>   * Multiple annotations of the same interface <i>A</i> in Java source code
>   * ({@jls 9.7.5}) are represented by the {@linkplain AnnotationValue.OfAnnotation
>   * annotation-valued} array elements of the {@linkplain AnnotationValue.OfArray
>   * array-valued} element named {@code value} of a container annotation of the
>   * containing annotation interface of <i>A</i>. ({@jls 9.6.3})

Very good and precise usage of "annotation" versus "annotation 
interface". The last sentence is rather long; you could break it as "... 
of a container annotation. The interface of the container annotation is 
the containing annotation interface of A."

>       * <p>
>       * A single-element annotation ({@jls 9.7.3}) in Java source code is
>       * compiled to an {@link Annotation} with exactly one {@linkplain
>       * Annotation#elements key-value pair} where the element has the name
>       * {@code value}.

I take issue with "compiled to ...". The annotation is *compiled* to a 
Runtime...Annotations attribute, but it's *represented* by an Annotation 
with exactly one ...  (Just as multiple annotations of the same 
interface are *represented* by the annotation-valued ...)

>       * <p>
>       * Multiple annotations of the same interface <i>A</i> in Java source code
>       * is compiled to an implicitly declared container annotation ({@jls 9.7.5})
>       * with exactly one {@linkplain Annotation#elements key-value pair} where
>       * the element has the name {@code value} and the type of the element is the
>       * {@linkplain AnnotationValue.OfArray array} whose component type is the
>       * {@linkplain AnnotationValue.OfAnnotation annotation interface <i>A</i>}.

Multiple annotations ... *are represented* [not "is compiled"] by a 
container annotation [drop "implicitly declared", that's a compile time 
story but you're discussing run time] with exactly one *element-value* 
pair [never seen "key-value pair" used for annotations]. The name of the 
element is ... and the type of the element is ...

Alex

From mcimadamore at openjdk.org  Thu Aug  1 21:14:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Aug 2024 21:14:35 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <2oxmZsb1vuzBcmGBepsJm-XXNDmStwgaoGUHqXsDHtM=.046fe24b-89df-4940-9fed-04b4ee193002@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
 <2oxmZsb1vuzBcmGBepsJm-XXNDmStwgaoGUHqXsDHtM=.046fe24b-89df-4940-9fed-04b4ee193002@github.com>
Message-ID: <eOrRxGyA_YOvYLLGii7rlQxseabVLRICi8qsYDNE0Sw=.119cf07b-f8ca-4eae-a70f-c8d1f36d0958@github.com>

On Thu, 1 Aug 2024 17:21:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> I did another round of testing with the latest version of the PR, everything still looks good to me.
> 
>     * I am no longer seeing any serialization compatibility impact.
> 
>     * I'm still seeing some impact from changes to lambda names. The impact is minor, and all of the occurrences I saw were in tests. I don't have any concerns about proceeding with that part.

Thanks for confirming. I think this is in good shape, and we can now proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2264001099

From dnguyen at openjdk.org  Thu Aug  1 22:59:36 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 1 Aug 2024 22:59:36 GMT
Subject: [jdk23] Integrated: 8337054: JDK 23 RDP2 L10n resource files update
In-Reply-To: <S7nAzOLzpi02t5-jk_28JZXK_p5E9DBjfMasxr7CtJs=.c4d61155-3341-444a-9cc4-d6f323c5f035@github.com>
References: <S7nAzOLzpi02t5-jk_28JZXK_p5E9DBjfMasxr7CtJs=.c4d61155-3341-444a-9cc4-d6f323c5f035@github.com>
Message-ID: <lowPmvEqQB9wQisihGQ5ThF80NBcX7gmNNzP-KLR7Jw=.6785309d-8dda-4670-a067-eb409e8fe6ab@github.com>

On Tue, 30 Jul 2024 20:17:28 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Localization update for JDK23 RDP2
> 
> Please view for enhanced diffs on affected files:
> https://cr.openjdk.org/~dnguyen/output/

This pull request has now been integrated.

Changeset: 2eb7709e
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2eb7709ec3dbe724d9e5d7ecb34d6c9adc48ab4e
Stats:     28 lines in 7 files changed: 6 ins; 3 del; 19 mod

8337054: JDK 23 RDP2 L10n resource files update

Reviewed-by: jlu, prappo, naoto, vromero

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

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

From liach at openjdk.org  Thu Aug  1 23:07:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 23:07:35 GMT
Subject: Withdrawn: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <OX701aCsYNKyNvohWUHxo61QJCiZU_pljtJ8QDeB-Zo=.2a3ede65-c55e-4670-8bcb-520b22d82562@github.com>
References: <OX701aCsYNKyNvohWUHxo61QJCiZU_pljtJ8QDeB-Zo=.2a3ede65-c55e-4670-8bcb-520b22d82562@github.com>
Message-ID: <NJaUJobrbZcDLdF8wkdzdZ4qebngNLhhTHBJmpNNxTU=.7bb11eda-e99b-4a2e-bddd-38e7d9106d58@github.com>

On Sun, 14 Jul 2024 22:30:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove `AnnotationConstantValueEntry` and `AnnotationValue.OfConstant`.
> 
> This is a relic of the old model from https://github.com/openjdk/jdk-sandbox/commit/bb7e29474ecfcfbd1eb01d237593eb80d062944f. In addition, this is bug-prone: the byte, short, char, and boolean constants use the int entry, and getting the `ConstantDesc` for them will return an `Integer`, which cannot be inversed back into the respective annotation values via `AnnotationValue.of(Object)` factory.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Fri Aug  2 00:04:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:04:48 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - More refinements from alex
 - Artifact -> construct
 - More about Annotation, add equals note
 - Further refine wording
 - Refine the spec of TypeAnnotation per Alex feedback
 - ... and 2 more: https://git.openjdk.org/jdk/compare/cfd1bb21...3a91a3a5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/d45c35fc..3a91a3a5

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

  Stats: 531 lines in 22 files changed: 322 ins; 11 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Fri Aug  2 00:04:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:04:50 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v7]
In-Reply-To: <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>
Message-ID: <EEisGWjdGGwDy7dO2kTBZf0dSPHsKS4HwaXde0T6gTQ=.0cdacc6e-0f53-43c0-9332-dd084d283f19@github.com>

On Thu, 1 Aug 2024 20:02:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - SealedGraph now redundant
>  - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

I have implemented the suggestions (compiled to -> represented by, key-value -> element value) and tried to simplify the wording. Please review the current version:

 * <p>
 * In an annotation in Java source code, elements in the annotation interface
 * with default values may not be represented unless an explicit value is provided.
 * ({@jls 9.6.2}) The default value is derived from the {@link AnnotationDefaultAttribute
 * AnnotationDefault} attribute on the method representing the annotation
 * interface element, in the class file representing the annotation interface.
 * <p id="repeatable">
 * Multiple annotations of the same interface <i>A</i> in Java source code
 * ({@jls 9.7.5}) are represented by the {@linkplain AnnotationValue.OfAnnotation
 * annotation-valued} array elements of the {@linkplain AnnotationValue.OfArray
 * array-valued} element named {@code value} of a container annotation, whose
 * interface is the containing annotation interface of <i>A</i>. ({@jls 9.6.3})

// location in class files to source code construct/type section
 * If this annotation is of a {@linkplain ##repeatable repeatable} annotation
 * interface <i>A</i>, is an array element of an array-valued element named
 * {@code value} in a container annotation, and the interface of the container
 * annotation is the containing annotation interface <i>AC</i> of <i>A</i>,
 * this annotation represents a base annotation of type <i>A</i>, which applies
 * to the same source code construct or type as the container annotation of
 * type <i>AC</i>.

// On AnnotationElement::name
     * @apiNote
     * In Java source code, by convention, the name of the sole element in a
     * single-element annotation interface is {@code value}. ({@jls 9.6.1})
     * A single-element annotation ({@jls 9.7.3}) declares the element value
     * for the {@code value} element. The single element of a containing
     * annotation interface that holds {@linkplain Annotation##repeatable
     * multiple} base annotations is also named {@code value}. ({@jls 9.6.3})

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2264242499

From liach at openjdk.org  Fri Aug  2 00:43:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:43:46 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
Message-ID: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>

1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
2. Improved value specification to specify their tags.
3. Improved value factories to return their specific types instead of `OfConstant`
4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

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

Commit messages:
 - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

Changes: https://git.openjdk.org/jdk/pull/20436/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335927
  Stats: 273 lines in 11 files changed: 106 ins; 34 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/20436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20436/head:pull/20436

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

From asotona at openjdk.org  Fri Aug  2 08:00:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Aug 2024 08:00:32 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>

On Fri, 2 Aug 2024 00:39:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 90:

> 88:      */
> 89:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
> 90:     sealed interface OfConstant<C extends AnnotationConstantValueEntry, R extends Comparable<R> & Constable>

I suggest to minimize use of generics in combination with sealed interface trees and pattern matching. It does not give many benefits, it takes out a part of the code readability and adds many unnecessary brackets and questionmarks: 

case AnnotationValue.OfConstant<?, ?> oc ->


`<R extends Comparable<R> & Constable>` at least brings a benefit of types combination. However I still think it does not outweigh the generics use cost. None of the generics parameter is near to orthogonal to the `OfConstant` nor critical for the API to operate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20436#discussion_r1701457480

From liach at openjdk.org  Fri Aug  2 13:19:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 13:19:49 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v2]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <O18-Y5wey2Q0aKBCl28jJAGbZiQJr9DuBpvue9hAJzc=.6bbfb913-6bf2-4d66-b59e-402705804fac@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

Chen Liang 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:

 - Remove generics, further improve docs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/annotation-constant
 - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/611a9505..b212a3ec

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

  Stats: 234 lines in 19 files changed: 111 ins; 17 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/20436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20436/head:pull/20436

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

From liach at openjdk.org  Fri Aug  2 13:29:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 13:29:32 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v2]
In-Reply-To: <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>
Message-ID: <1TgWNYoZlzbpf02df8XWVcHsNvEsfo-mc6YNl3xAuiY=.05a3081f-c15b-4614-ad79-0eaf0da04b5d@github.com>

On Fri, 2 Aug 2024 07:57:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang 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:
>> 
>>  - Remove generics, further improve docs
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/annotation-constant
>>  - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 90:
> 
>> 88:      */
>> 89:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
>> 90:     sealed interface OfConstant<C extends AnnotationConstantValueEntry, R extends Comparable<R> & Constable>
> 
> I suggest to minimize use of generics in combination with sealed interface trees and pattern matching. It does not give many benefits, it takes out a part of the code readability and adds many unnecessary brackets and questionmarks: 
> 
> case AnnotationValue.OfConstant<?, ?> oc ->
> 
> 
> `<R extends Comparable<R> & Constable>` at least brings a benefit of types combination. However I still think it does not outweigh the generics use cost. None of the generics parameter is near to orthogonal to the `OfConstant` nor critical for the API to operate.

Removed the type parameters. Please review again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20436#discussion_r1701848599

From asotona at openjdk.org  Fri Aug  2 13:55:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Aug 2024 13:55:37 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
Message-ID: <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>

On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863

From liach at openjdk.org  Fri Aug  2 14:19:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 14:19:52 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v3]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <WF3-IPcr-orjpBkSOZ_trEgRfYhP9Vkd8Th7q_y_hXY=.21f866e6-a0d0-41fd-ab20-10481d1da40b@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - poolEntry back to constant
 - OfInteger/Character -> OfInt/Char

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/b212a3ec..d2f56527

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

  Stats: 67 lines in 10 files changed: 1 ins; 0 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/20436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20436/head:pull/20436

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

From liach at openjdk.org  Fri Aug  2 14:45:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 14:45:09 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v4]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <cSDJw2WS-i7AMhLDki4HQWZdYLPYTI9khVsTraa9ytc=.28fc4e10-e7fd-4d82-96fb-ae6943a3cd1c@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Compile error in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/d2f56527..d3390fd6

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

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

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

From chen.l.liang at oracle.com  Fri Aug  2 15:45:22 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 2 Aug 2024 15:45:22 +0000
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
Message-ID: <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>

One specification question for Alex: we call an annotation interface's element "element". What about the element-value pair that binds a value to an interface element in an annotation? Can we call this element-value pair an "element", or is there any other more proper name that is still concise? For context:
> [This annotation] is an array element of an array-valued element named {@code value} in a container annotation

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam Sotona <asotona at openjdk.org>
Sent: Friday, August 2, 2024 8:55 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v8]

On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240802/7dc6a2d5/attachment-0001.htm>

From alex.buckley at oracle.com  Fri Aug  2 15:53:49 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 2 Aug 2024 08:53:49 -0700
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
 <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>

In the annotation `@Foo(a=1)`, the left hand side `a` is an _element_ 
(as declared in the annotation interface Foo) and the right hand side 
`1` is an _element value_ (per the first line of JLS 9.7.1).

Syntactically the `a` is an identifier but that's almost never relevant 
what discussing element-value pairs. In the text you quoted, "an array 
element of an array-valued element `value`" is the right way to say it.

Alex

On 8/2/2024 8:45 AM, Chen Liang wrote:
> One specification question for Alex: we call an annotation interface's 
> element "element". What about the element-value pair that binds a value 
> to an interface element in an annotation? Can we call this element-value 
> pair an "element", or is there any other more proper name that is still 
> concise? For context:
>  >?[This annotation] is an array element of an array-valued element 
> named {@code value} in a container annotation
> 
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam 
> Sotona <asotona at openjdk.org>
> *Sent:* Friday, August 2, 2024 8:55 AM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>; 
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
> javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of 
> "be" an Annotation [v8]
> On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:
> 
>>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>> 
>>> Depends on #20205.
>>
>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>? - remove compile, use element-value, break long sentences
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - Improve docs for repeating, default, and value name
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - More refinements from alex
>>? - Artifact -> construct
>>? - More about Annotation, add equals note
>>? - Further refine wording
>>? - Refine the spec of TypeAnnotation per Alex feedback
>>? - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5 
> <https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5>
> 
> Marked as reviewed by asotona (Reviewer).
> 
> -------------
> 
> PR Review: 
> https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863 
> <https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863>

From chen.l.liang at oracle.com  Fri Aug  2 15:59:11 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 2 Aug 2024 15:59:11 +0000
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
 <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
 <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>
Message-ID: <CH3PR10MB767755B5D08A7508FE2B3A6AA2B32@CH3PR10MB7677.namprd10.prod.outlook.com>

Thanks for the confirmation. I will submit this finalized specification for CSR review.
________________________________
From: javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of Alex Buckley <alex.buckley at oracle.com>
Sent: Friday, August 2, 2024 10:53 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v8]

In the annotation `@Foo(a=1)`, the left hand side `a` is an _element_
(as declared in the annotation interface Foo) and the right hand side
`1` is an _element value_ (per the first line of JLS 9.7.1).

Syntactically the `a` is an identifier but that's almost never relevant
what discussing element-value pairs. In the text you quoted, "an array
element of an array-valued element `value`" is the right way to say it.

Alex

On 8/2/2024 8:45 AM, Chen Liang wrote:
> One specification question for Alex: we call an annotation interface's
> element "element". What about the element-value pair that binds a value
> to an interface element in an annotation? Can we call this element-value
> pair an "element", or is there any other more proper name that is still
> concise? For context:
>  > [This annotation] is an array element of an array-valued element
> named {@code value} in a container annotation
>
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam
> Sotona <asotona at openjdk.org>
> *Sent:* Friday, August 2, 2024 8:55 AM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>;
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of
> "be" an Annotation [v8]
> On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>>
>>> Depends on #20205.
>>
>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>>
>>  - remove compile, use element-value, break long sentences
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - Improve docs for repeating, default, and value name
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - More refinements from alex
>>  - Artifact -> construct
>>  - More about Annotation, add equals note
>>  - Further refine wording
>>  - Refine the spec of TypeAnnotation per Alex feedback
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5
> <https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5>
>
> Marked as reviewed by asotona (Reviewer).
>
> -------------
>
> PR Review:
> https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863
> <https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240802/328908ae/attachment-0001.htm>

From liach at openjdk.org  Fri Aug  2 16:31:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 16:31:48 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix another failing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/d3390fd6..fb6b2f99

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

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

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

From jjg at openjdk.org  Fri Aug  2 17:26:48 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Aug 2024 17:26:48 GMT
Subject: RFR: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc [v9]
In-Reply-To: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
Message-ID: <F2bAa_0Ap0nmcsY8j0uBIUiZ0ymueHnhEbTF1dJLnDA=.06c78446-908d-4ad1-b003-6b46ab9f6d96@github.com>

> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module.
> 
> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet.
> 
> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name.
> 
> A few minor bugs were found and fixed.   Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package.  The naming follows `HtmlId` and `HtmlIds`.
> 
> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Fix trailing whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19916/files
  - new: https://git.openjdk.org/jdk/pull/19916/files/ff489059..69023df2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19916&range=07-08

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

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

From hannesw at openjdk.org  Fri Aug  2 17:43:35 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 2 Aug 2024 17:43:35 GMT
Subject: RFR: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc [v9]
In-Reply-To: <F2bAa_0Ap0nmcsY8j0uBIUiZ0ymueHnhEbTF1dJLnDA=.06c78446-908d-4ad1-b003-6b46ab9f6d96@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
 <F2bAa_0Ap0nmcsY8j0uBIUiZ0ymueHnhEbTF1dJLnDA=.06c78446-908d-4ad1-b003-6b46ab9f6d96@github.com>
Message-ID: <CCapmxIiYrAiAJd0ovBDvPRjpAXYAlsRVg-enVKGkgA=.5cd00ced-400b-4cf2-998a-75c84bb04ca5@github.com>

On Fri, 2 Aug 2024 17:26:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module.
>> 
>> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet.
>> 
>> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name.
>> 
>> A few minor bugs were found and fixed.   Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package.  The naming follows `HtmlId` and `HtmlIds`.
>> 
>> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix trailing whitespace

Thanks for adding the comments, looks good to me.

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

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19916#pullrequestreview-2216095763

From jjg at openjdk.org  Fri Aug  2 17:56:38 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 2 Aug 2024 17:56:38 GMT
Subject: Integrated: 8335122: Reorganize internal low-level support for HTML in
 jdk.javadoc
In-Reply-To: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
References: <Z_KYuJn5mA8poWSEJFK88fXu4o_N-YWIfEDx3x0I_nE=.4e08104a-6ef0-4ac8-92ed-d148f49a801e@github.com>
Message-ID: <o-gy0msoayf9PkbgbjKEUvRMQVadpI1ZrOZFlHY8xcw=.d09ba6dc-3f43-436c-9e8d-f6fd3540eabc@github.com>

On Wed, 26 Jun 2024 23:00:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to reorganize the internal low-level support for HTML in the jdk.javadoc module.
> 
> Hitherto, there are two separate sets of classes for low-level support for HTML in the `jdk.javadoc` module: one, in doclint, focused on reading and checking classes, the other, in the standard doclet, focused on generating HTML. This PR merges those two sets, into a new package `jdk.javadoc.internal.html` that is now used by both `doclint` and the standard doclet.
> 
> There was a naming "anti-clash" -- `HtmlTag` in `doclint` vs `TagName` in the standard doclet. The resolution is to use `HtmlTag`, since the merged class is more than just the tag name.
> 
> A few minor bugs were found and fixed.   Other minor cleanup was done, but otherwise, there should be no big surprises here. But, one small item of note: `enum HtmlStyle` was split into `interface HtmlStyle` and `enum HtmlStyles implements HtmlStyle` to avoid having a doclet-specific enum class in the new `internal.html` package.  The naming follows `HtmlId` and `HtmlIds`.
> 
> There is no attempt at this time to simplify `HtmlTag` and `HtmlAttr` to remove support for older versions of HTML.

This pull request has now been integrated.

Changeset: 7deee745
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7deee745254e5f32b75a09d84ac5078a122c8b8d
Stats:     3063 lines in 108 files changed: 1203 ins; 1221 del; 639 mod

8335122: Reorganize internal low-level support for HTML in jdk.javadoc

Reviewed-by: hannesw

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

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

From dnguyen at openjdk.org  Fri Aug  2 18:26:59 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 2 Aug 2024 18:26:59 GMT
Subject: RFR: 8337054: JDK 23 RDP2 L10n resource files update
Message-ID: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>

Clean forward-port from JDK23 of RDP2 L10N.

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

Commit messages:
 - Clean forwardport

Changes: https://git.openjdk.org/jdk/pull/20444/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20444&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337054
  Stats: 28 lines in 7 files changed: 6 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20444.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20444/head:pull/20444

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

From naoto at openjdk.org  Fri Aug  2 21:28:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Aug 2024 21:28:31 GMT
Subject: RFR: 8337054: JDK 23 RDP2 L10n resource files update
In-Reply-To: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
References: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
Message-ID: <vuAoG77wstYVbeDYoKK-8_olMxGdGJfEGULQjeL17dw=.c5eed8eb-c78a-4042-a2d2-dc06096f1905@github.com>

On Fri, 2 Aug 2024 18:20:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Forwardport for JDK-8337054 from JDK23 of RDP2 L10N, fix applied cleanly.
> 
> Forward-porting to add translated files from JDK23 RDP2 into mainline and prevent re-translating these files in the next L10N drop.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20444#pullrequestreview-2216420194

From jlu at openjdk.org  Fri Aug  2 21:34:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 Aug 2024 21:34:46 GMT
Subject: RFR: 8337054: JDK 23 RDP2 L10n resource files update
In-Reply-To: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
References: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
Message-ID: <eM0CWPS_1pGNJv75lub9pcJehGoVkx0pvCA2Y5oCaUw=.7cf571d1-3a91-48e4-8e2c-fc260941198e@github.com>

On Fri, 2 Aug 2024 18:20:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Forwardport for JDK-8337054 from JDK23 of RDP2 L10N, fix applied cleanly.
> 
> Forward-porting to add translated files from JDK23 RDP2 into mainline and prevent re-translating these files in the next L10N drop.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/20444#pullrequestreview-2216427975

From cushon at openjdk.org  Sun Aug  4 20:16:40 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sun, 4 Aug 2024 20:16:40 GMT
Subject: RFR: 8337795: Type annotation attached to incorrect type during class
 reading
Message-ID: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>

This change fixes a bug in the logic for adding type annotations to types during class reading.

The implementation searched for contained types that type annotations applied to, and then separately rewrote the type to add the annotations using `StructuralTypeMapping`, relying on the object identity of `Type` instances to keep track of them between the two passes. This produced incorrect results if the same type (with the same identity) appeared multiple times as a contained type.

This fix merges the two passes into a single visitor that both locates annotated contained types, and rewrites them to add the annotations. This requires duplicating similar logic to `StructuralTypeMapping`, which seems unavoidable.

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

Commit messages:
 - 8337795: Type annotation attached to incorrect type during class reading

Changes: https://git.openjdk.org/jdk/pull/20460/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337795
  Stats: 109 lines in 2 files changed: 25 ins; 44 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/20460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20460/head:pull/20460

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

From dnguyen at openjdk.org  Mon Aug  5 16:50:39 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 5 Aug 2024 16:50:39 GMT
Subject: Integrated: 8337054: JDK 23 RDP2 L10n resource files update
In-Reply-To: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
References: <xMK6qBynbEyEH4UPutds-B4E0cUkAAD-gVDBXe2prws=.fa043a67-959a-46ce-80d3-c916cfd5d2d9@github.com>
Message-ID: <qjy3WVU3MBo0c0gJ6BLIJAxQZcUeQXTmLI5K7cqLMwY=.d40c8f08-3ae9-444f-9153-4d6bd4c6badc@github.com>

On Fri, 2 Aug 2024 18:20:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Forwardport for JDK-8337054 from JDK23 of RDP2 L10N, fix applied cleanly.
> 
> Forward-porting to add translated files from JDK23 RDP2 into mainline and prevent re-translating these files in the next L10N drop.

This pull request has now been integrated.

Changeset: e68df528
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e68df528f80cff3a5564a12b7ec71a920800ce28
Stats:     28 lines in 7 files changed: 6 ins; 3 del; 19 mod

8337054: JDK 23 RDP2 L10n resource files update

Reviewed-by: naoto, jlu

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

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

From duke at openjdk.org  Tue Aug  6 05:55:57 2024
From: duke at openjdk.org (toshiogata)
Date: Tue, 6 Aug 2024 05:55:57 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg
Message-ID: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>

Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
Testing: modified tests

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

Commit messages:
 - Merge branch 'master' into 8337851
 - 8337851: Some tests have name which confuse jtreg

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

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

From duke at openjdk.org  Tue Aug  6 09:15:34 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 6 Aug 2024 09:15:34 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.a3eb0b03-e287-4434-bc61-f2f7c06bc99c@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.df639556-1e88-41f4-9f87-12ca432f6617@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.a3eb0b03-e287-4434-bc61-f2f7c06bc99c@github.com>
Message-ID: <ThW0-XhNZcWXBxBeaTUu_zonbyNvLG8JkByOVVZsxbA=.d6d5a990-73a2-4ab6-9299-1457bd90551e@github.com>

On Fri, 14 Jun 2024 07:08:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I fixed to get Charset from native.encoding instead of Charset.defaultCharset() when reading a file to which the output of javac run in the test was redirected.
>> The modified code is based on the alternatives given in JEP400.
>> I verified that the test passed on Windows in both Japanese and English locales with this fix.
>
> test/langtools/tools/javac/newlines/NewLineTest.java line 61:
> 
>> 59:                 .run(Task.Expect.FAIL);
>> 60: 
>> 61:         String encoding = System.getProperty("native.encoding");
> 
> Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work.
> 
> I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`.
> Can you give that change a try on your setup and see if it solves the issue for you?

@jaikiran 
I'm looking forward to your comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1705192781

From jpai at openjdk.org  Tue Aug  6 09:15:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Aug 2024 09:15:34 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <ThW0-XhNZcWXBxBeaTUu_zonbyNvLG8JkByOVVZsxbA=.d6d5a990-73a2-4ab6-9299-1457bd90551e@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.df639556-1e88-41f4-9f87-12ca432f6617@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.a3eb0b03-e287-4434-bc61-f2f7c06bc99c@github.com>
 <ThW0-XhNZcWXBxBeaTUu_zonbyNvLG8JkByOVVZsxbA=.d6d5a990-73a2-4ab6-9299-1457bd90551e@github.com>
Message-ID: <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.c2063e9a-1648-4763-8a5f-f3e145b88672@github.com>

On Tue, 6 Aug 2024 09:11:31 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/newlines/NewLineTest.java line 61:
>> 
>>> 59:                 .run(Task.Expect.FAIL);
>>> 60: 
>>> 61:         String encoding = System.getProperty("native.encoding");
>> 
>> Hello @tkiriyama, I don't have experience in javac area or this test, but I had a brief look at this change. What I understand is that `javac` will print to `STDOUT` using a `PrinterWriter` for `System.out`, which as per the documentation https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#out will use `stdout.encoding` value for the character encoding. The default value of `stdout.encoding` standard system property https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/System.html#stdout.encoding is currently not mentioned but I checked with people familiar with this area and it defaults to platform specific values. It is not guaranteed that `stdout.encoding` will be the same value as `native.encoding`. So the proposed change here isn't guaranteed to (always) work.
>> 
>> I think to make this deterministic, you might have to update the `javac` launch command (a few lines above) to pass `-J-Dstdout.encoding=UTF-8` and then when reading from the file to which the content was redirected, use `StandardCharsets.UTF_8`.
>> Can you give that change a try on your setup and see if it solves the issue for you?
>
> @jaikiran 
> I'm looking forward to your comments.

Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1705196105

From ihse at openjdk.org  Tue Aug  6 16:19:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Aug 2024 16:19:31 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg
In-Reply-To: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
Message-ID: <NBBfIKYB61zfSgkXbwVx-oEp_R5Z8gkyBVyuoFJK9yA=.d1a4d625-2985-4c66-8770-4e7d64153bb9@github.com>

On Tue, 6 Aug 2024 05:51:35 GMT, toshiogata <duke at openjdk.org> wrote:

> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
> Testing: modified tests

@jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2271665937

From jjg at openjdk.org  Tue Aug  6 17:27:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 6 Aug 2024 17:27:32 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg
In-Reply-To: <NBBfIKYB61zfSgkXbwVx-oEp_R5Z8gkyBVyuoFJK9yA=.d1a4d625-2985-4c66-8770-4e7d64153bb9@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <NBBfIKYB61zfSgkXbwVx-oEp_R5Z8gkyBVyuoFJK9yA=.d1a4d625-2985-4c66-8770-4e7d64153bb9@github.com>
Message-ID: <3Td2vLLcPueF_vnXvGXF637nREXWsZsvT5gHOFRNNdE=.c703c4ce-0fae-42e3-989a-2821798eefad@github.com>

On Tue, 6 Aug 2024 16:17:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?

Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!".  That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.

In the meantime, renaming the files to avoid the problem is the recommended solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2271784061

From duke at openjdk.org  Wed Aug  7 20:47:35 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 7 Aug 2024 20:47:35 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
Message-ID: <dWo6QgWKFFyc98cCTuf39Pj-8gjIOBACzPX-NwFOlc0=.b7d3afa3-5995-498e-9de9-84d7ee1d2617@github.com>

On Thu, 1 Aug 2024 13:02:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
>> 
>> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
>> 
>> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
>> 
>> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
>> 
>> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
>> 
>> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
>> 
>> #### C...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment

Using?`SequencedSet` would?allow to?skip the?call to?`com.sun.tools.javac.util.List?::reverse()` on?the?result of?`CaptureScanner?::analyzeCaptures()`.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 36:

> 34: import java.util.HashSet;
> 35: import java.util.LinkedHashSet;
> 36: import java.util.Set;

Suggestion:

import java.util.Set;
import java.util.SequencedSet;

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 59:

> 57:      * The set of captured local variables accessed from within the tree under analysis.
> 58:      */
> 59:     private final Set<VarSymbol> fvs = new LinkedHashSet<>();

Suggestion:

    private final SequencedSet<VarSymbol> fvs = new LinkedHashSet<>();

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CaptureScanner.java line 96:

> 94:     List<Symbol.VarSymbol> analyzeCaptures() {
> 95:         scan(tree);
> 96:         return List.from(fvs);

Suggestion:

        return List.from(fvs.reversed());

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 317:

> 315:         }
> 316:         FreeVarCollector collector = new FreeVarCollector(classDef(c));
> 317:         fvs = collector.analyzeCaptures().reverse();

Suggestion:

        fvs = collector.analyzeCaptures();

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

PR Review: https://git.openjdk.org/jdk/pull/20349#pullrequestreview-2226139559
PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1707861562
PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1707854283
PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1707860442
PR Review Comment: https://git.openjdk.org/jdk/pull/20349#discussion_r1707860631

From cushon at openjdk.org  Wed Aug  7 22:18:05 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 Aug 2024 22:18:05 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations
Message-ID: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>

This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.

Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.

This change handles the completion failures, and reports an error diagnostic instead of the current crash.

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

Commit messages:
 - Update not-yet list
 - Remove unused import
 - 8337998: CompletionFailure in getEnclosingType attaching type annotations

Changes: https://git.openjdk.org/jdk/pull/20495/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337998
  Stats: 115 lines in 4 files changed: 112 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20495/head:pull/20495

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

From cushon at openjdk.org  Wed Aug  7 22:30:32 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 Aug 2024 22:30:32 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <Bc2zrDKvSh0rXimWxxp3vP9hYG-9aPhpMcLbY0I8Q-Y=.e11e51f8-8ec0-4b91-af94-85fe3b87e852@github.com>

On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

I still think it'd be slightly worthwhile to fix the built-in sunapi implementation to handle this case, but if the feeling is that it isn't worth spending time on and the possible disruption to `-Werror`, that's also OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2274455669

From jlahoda at openjdk.org  Fri Aug  9 15:03:03 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 9 Aug 2024 15:03:03 GMT
Subject: RFR: 8337976: Insufficient error recovery in parser for switch inside
 class body
Message-ID: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>

Consider this code:

public class T9999999 {
    switch (0) { default: }
}


When trying to compile this, javac crashes:


$ .../jdk-22/bin/javac -XDdev /tmp/T9999999.java
/tmp/T9999999.java:2: error: switch expression does not have any result expressions
    switch (0) { default: } f;
    ^
1 error
An exception has occurred in the compiler (22.0.1-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError: Unexpected tree: switch (0) {
default:

} with kind: SWITCH_EXPRESSION within: switch (0) {
default:

} with kind: SWITCH_EXPRESSION
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
        at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5881)
        at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5727)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1022)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5780)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
        at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5677)
        at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:144)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
        at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1827)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1081)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
printing javac parameters to: /home/jlahoda/src/jdk/jdk/javac.20240809_163551.args


The problem is that while parsing a the class body, javac will try to parse a type (as a type of a field or method), but finds the switch. Which will get parsed as an expression, and used as the type of the field `f`. This then crashes type annotation validation, but generally does not make much sense.

The proposal here is to check if there's a token that inevitably is a start of a statement used inside a class (or interface, enum, annotation type or record), and if yes, parse the input as a statement.

As a result, the parser tolerates statements inside a class body. The statement's tree is wrapped inside an `ErroneousTree`, so that it is obvious it is not a correct AST.

The attribution is also tweaked a bit to handle the augmented AST better.

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

Commit messages:
 - Cleanup.
 - Cleanup/reducing scope
 - Fixing tests.
 - 8337976: Insufficient error recovery in parser for switch inside class body, and missing name in parameterized type

Changes: https://git.openjdk.org/jdk/pull/20526/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337976
  Stats: 128 lines in 9 files changed: 118 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20526/head:pull/20526

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

From vromero at openjdk.org  Fri Aug  9 17:28:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 Aug 2024 17:28:31 GMT
Subject: RFR: 8337976: Insufficient error recovery in parser for switch
 inside class body
In-Reply-To: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
References: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
Message-ID: <XkQUm5F0z1djbDOvnZbhKkqgWjasqaLaVEXZriCvW-A=.ac43be32-62c6-4863-b431-8dbc122e8fe4@github.com>

On Fri, 9 Aug 2024 14:57:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> public class T9999999 {
>     switch (0) { default: }
> }
> 
> 
> When trying to compile this, javac crashes:
> 
> 
> $ .../jdk-22/bin/javac -XDdev /tmp/T9999999.java
> /tmp/T9999999.java:2: error: switch expression does not have any result expressions
>     switch (0) { default: } f;
>     ^
> 1 error
> An exception has occurred in the compiler (22.0.1-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: Unexpected tree: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION within: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5881)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5727)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1022)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5780)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5677)
>         at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1827)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1081)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(...

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4923:

> 4921:     private boolean isDefiniteStatementStartToken() {
> 4922:         return switch (token.kind) {
> 4923:             case IF, WHILE, DO, SWITCH, RETURN, TRY, FOR, ASSERT, BREAK,

should `yield`, `synchronized` be included?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20526#discussion_r1711849240

From vromero at openjdk.org  Fri Aug  9 17:46:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 Aug 2024 17:46:34 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations
In-Reply-To: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
Message-ID: <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>

On Wed, 7 Aug 2024 15:59:58 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
> 
> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
> 
> This change handles the completion failures, and reports an error diagnostic instead of the current crash.

test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java line 78:

> 76: 
> 77:         // now if we remove A.class there will be an error but javac should not crash
> 78:         tb.deleteFiles(out.resolve("A.class"));

here the problem doesn't seem to be with the annotation not being found but with the annotated type not being found right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1711876910

From cushon at openjdk.org  Fri Aug  9 17:51:37 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 9 Aug 2024 17:51:37 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations
In-Reply-To: <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>
Message-ID: <kDm5_7Rdg21zdrb1eYsR8lRUna2wmo0JmXbQ1NQ6kbQ=.2075be11-ef2c-4a06-a965-00b4b6bb350b@github.com>

On Fri, 9 Aug 2024 17:44:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
>> 
>> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
>> 
>> This change handles the completion failures, and reports an error diagnostic instead of the current crash.
>
> test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java line 78:
> 
>> 76: 
>> 77:         // now if we remove A.class there will be an error but javac should not crash
>> 78:         tb.deleteFiles(out.resolve("A.class"));
> 
> here the problem doesn't seem to be with the annotation not being found but with the annotated type not being found right?

Yes if the annotation is missing that should get handled earlier, the issue here is if visiting the annotated type causes completion failures, e.g. when calling `getEnclosingType`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1711884642

From vromero at openjdk.org  Fri Aug  9 18:06:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 Aug 2024 18:06:31 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations
In-Reply-To: <kDm5_7Rdg21zdrb1eYsR8lRUna2wmo0JmXbQ1NQ6kbQ=.2075be11-ef2c-4a06-a965-00b4b6bb350b@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>
 <kDm5_7Rdg21zdrb1eYsR8lRUna2wmo0JmXbQ1NQ6kbQ=.2075be11-ef2c-4a06-a965-00b4b6bb350b@github.com>
Message-ID: <VAPAEP9HiSdpjwFL6cNgwDrEqGW27XYPHbVVBu6gCFk=.39c9a8e4-7023-4cb7-b8a0-1296119a1d43@github.com>

On Fri, 9 Aug 2024 17:49:23 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java line 78:
>> 
>>> 76: 
>>> 77:         // now if we remove A.class there will be an error but javac should not crash
>>> 78:         tb.deleteFiles(out.resolve("A.class"));
>> 
>> here the problem doesn't seem to be with the annotation not being found but with the annotated type not being found right?
>
> Yes if the annotation is missing that should get handled earlier, the issue here is if visiting the annotated type causes completion failures, e.g. when calling `getEnclosingType`.

right I guess I was confused by the key in the error message: `type.annotation.not.found`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1711917467

From cushon at openjdk.org  Fri Aug  9 19:28:42 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 9 Aug 2024 19:28:42 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations
In-Reply-To: <VAPAEP9HiSdpjwFL6cNgwDrEqGW27XYPHbVVBu6gCFk=.39c9a8e4-7023-4cb7-b8a0-1296119a1d43@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>
 <kDm5_7Rdg21zdrb1eYsR8lRUna2wmo0JmXbQ1NQ6kbQ=.2075be11-ef2c-4a06-a965-00b4b6bb350b@github.com>
 <VAPAEP9HiSdpjwFL6cNgwDrEqGW27XYPHbVVBu6gCFk=.39c9a8e4-7023-4cb7-b8a0-1296119a1d43@github.com>
Message-ID: <RG9WHm9a3Wj68I4uFwZJ5FyRBSkpq3yWS4d0c1E7jpw=.40f31f7c-ad12-4d19-ac53-f6d1c1419d2c@github.com>

On Fri, 9 Aug 2024 18:03:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Yes if the annotation is missing that should get handled earlier, the issue here is if visiting the annotated type causes completion failures, e.g. when calling `getEnclosingType`.
>
> right I guess I was confused by the key in the error message: `type.annotation.not.found`

Good point, I will think of a better name for the diagnostic key.

It would also work to use a more generic error message for this, but I think it is helpful to include some context about the annotation that was being attached when the completion failure occurred, as a hint to where the problem is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1712037670

From vromero at openjdk.org  Fri Aug  9 19:40:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 Aug 2024 19:40:31 GMT
Subject: RFR: 8337795: Type annotation attached to incorrect type during
 class reading
In-Reply-To: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
References: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
Message-ID: <YVl7KFuSXn6pkpgObCk8V0dczWZwdnpHMb1Pw9WQfac=.52235797-7085-494e-a4bc-9ceeef2db9c3@github.com>

On Sun, 4 Aug 2024 19:49:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a bug in the logic for adding type annotations to types during class reading.
> 
> The implementation searched for contained types that type annotations applied to, and then separately rewrote the type to add the annotations using `StructuralTypeMapping`, relying on the object identity of `Type` instances to keep track of them between the two passes. This produced incorrect results if the same type (with the same identity) appeared multiple times as a contained type.
> 
> This fix merges the two passes into a single visitor that both locates annotated contained types, and rewrites them to add the annotations. This requires duplicating similar logic to `StructuralTypeMapping`, which seems unavoidable.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20460#pullrequestreview-2230922244

From acobbs at openjdk.org  Fri Aug  9 20:50:53 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 9 Aug 2024 20:50:53 GMT
Subject: RFR: 8337980: Javac allows invocation of an inherited instance method
 from a static method
Message-ID: <x5FiNY9UbloZFoGb-mUSkWMoao0DfaseLzA2Weh2r4E=.9edec92d-89e9-4cd0-b0a4-554022b889c2@github.com>

The method `Resolve.findFun()` performs the lookup for an unqualified method invocation like `foo()`. It does this by invoking `findMethod()` to find the method in each containing class scope, working from the inside out.

In this loop, as soon as it finds a matching method, but before returning, it performs the checks that prevent (a) invoking an instance method from a static context, and (b) invoking an instance method of the same class from an early-initialization context.

However, these checks don't account for the fact that in some cases `findMethod()` can return an `AmbiguityError` even though the code is perfectly valid. This is because `findMethod()` performs the "maximally specific" logic of JLS ?15.12.2.5 ("Choosing the Most Specific Method"), but not the "preferred method" logic. Instead, in the case there are multiple "maximally specific" methods, they are all returned wrapped in an `AmbiguityError`; disambiguation is the caller's job.

When this happens, if the code is actually valid, there's no problem, but if the code has one of the errors (a) or (b), the error does not get detected, with resulting downstream chaos.

Here's an example of when `findMethod()` can return an `AmbiguityError` for perfectly valid code:

public class Bug {

    public interface A {
        int op();
    }

    public abstract static class B {
        public abstract int op();
    }

    public abstract static class C extends B implements A {

        public int test() {
            return op();   // findMethod("op") returns both A.op() and B.op() here
        }
    }
}

The fix in this PR is to add a few lines to `findFun()` to resolve the ambiguity (if possible) before performing checks (a) and (b). It's possible there is an opportunity for a more thorough refactoring here, but short of that, I tried to add a few helpful comments.

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

Commit messages:
 - Avoid crash caused by failure to resolve a valid AmbiguityError.

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

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

From vromero at openjdk.org  Fri Aug  9 21:19:55 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 9 Aug 2024 21:19:55 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v2]
In-Reply-To: <NYjoZqUmCMaTz3NCEXUluuKSfxlVntKO7lJ-tFhKAPc=.e9e8d11d-f7ab-4e4a-9631-73a00cb3f6df@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <NYjoZqUmCMaTz3NCEXUluuKSfxlVntKO7lJ-tFhKAPc=.e9e8d11d-f7ab-4e4a-9631-73a00cb3f6df@github.com>
Message-ID: <QDn6thd2viAOi0jTwyy8SZxnu_MEP0m0EpXJamfIXG0=.ea53d4b6-b190-4b28-93c3-b6eab45f1b74@github.com>

On Mon, 29 Jul 2024 08:12:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
>> 
>> The change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add vm.debug for requires.properties in test/langtools/TEST.ROOT

test/langtools/tools/javac/7142086/T7142086.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 7142086

I would add the current bug number `8337334` after the previous one, so:

- * @bug 7142086
+ * @bug 7142086 8337334

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20370#discussion_r1712214875

From mcimadamore at openjdk.org  Fri Aug  9 23:40:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 Aug 2024 23:40:32 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <dWo6QgWKFFyc98cCTuf39Pj-8gjIOBACzPX-NwFOlc0=.b7d3afa3-5995-498e-9de9-84d7ee1d2617@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
 <dWo6QgWKFFyc98cCTuf39Pj-8gjIOBACzPX-NwFOlc0=.b7d3afa3-5995-498e-9de9-84d7ee1d2617@github.com>
Message-ID: <sS8zEP0MTyqjFlQrFqYMgkUOYxHA2aFse_yfFigBzGE=.5ac75a0f-b82b-4a66-827f-88a7f10d69a5@github.com>

On Wed, 7 Aug 2024 20:45:20 GMT, ExE Boss <duke at openjdk.org> wrote:

> Using `SequencedSet` would allow to skip the call to `com.sun.tools.javac.util.List?::reverse()` on the result of `CaptureScanner?::analyzeCaptures()`.

Not sure about that. Note that `Lower` wants the order of capture to be reversed compared to the "logical" order, but `LambdaToMethod` does not. To me, it is cleaner to put the reverse call close to the code that has "special" requirements, which in this case happens to be `Lower` (which is why the code ended up with that shape).

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

PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2278881133

From syan at openjdk.org  Sat Aug 10 00:50:57 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 10 Aug 2024 00:50:57 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v3]
In-Reply-To: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
Message-ID: <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>

> Hi all,
> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
> 
> The change has been verified, no risk.

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

  add bug id 8337334

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20370/files
  - new: https://git.openjdk.org/jdk/pull/20370/files/98b26e29..205a6b30

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

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

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

From syan at openjdk.org  Sat Aug 10 00:50:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 10 Aug 2024 00:50:58 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v2]
In-Reply-To: <QDn6thd2viAOi0jTwyy8SZxnu_MEP0m0EpXJamfIXG0=.ea53d4b6-b190-4b28-93c3-b6eab45f1b74@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <NYjoZqUmCMaTz3NCEXUluuKSfxlVntKO7lJ-tFhKAPc=.e9e8d11d-f7ab-4e4a-9631-73a00cb3f6df@github.com>
 <QDn6thd2viAOi0jTwyy8SZxnu_MEP0m0EpXJamfIXG0=.ea53d4b6-b190-4b28-93c3-b6eab45f1b74@github.com>
Message-ID: <dWlqRCHmCTqij4X6BoyiDXG8mdgRnZAeXpRdFJVDAZY=.61170eda-bb40-4b4f-9a10-ae74c0322fb7@github.com>

On Fri, 9 Aug 2024 21:16:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add vm.debug for requires.properties in test/langtools/TEST.ROOT
>
> test/langtools/tools/javac/7142086/T7142086.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 7142086
> 
> I would add the current bug number `8337334` after the previous one, so:
> 
> - * @bug 7142086
> + * @bug 7142086 8337334

Thanks for your advice, the bug number `8337334 ` has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20370#discussion_r1712435156

From cushon at openjdk.org  Sat Aug 10 19:17:08 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 10 Aug 2024 19:17:08 GMT
Subject: RFR: 8337795: Type annotation attached to incorrect type during
 class reading [v2]
In-Reply-To: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
References: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
Message-ID: <k6jcLlUHTQZ_YaLmL2KmLP4qr9Crwsd43gV1ci_xwCg=.f43dd432-d758-4f4f-80a0-8b53f1ec2f20@github.com>

> This change fixes a bug in the logic for adding type annotations to types during class reading.
> 
> The implementation searched for contained types that type annotations applied to, and then separately rewrote the type to add the annotations using `StructuralTypeMapping`, relying on the object identity of `Type` instances to keep track of them between the two passes. This produced incorrect results if the same type (with the same identity) appeared multiple times as a contained type.
> 
> This fix merges the two passes into a single visitor that both locates annotated contained types, and rewrites them to add the annotations. This requires duplicating similar logic to `StructuralTypeMapping`, which seems unavoidable.

Liam Miller-Cushon 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-8337795
 - 8337795: Type annotation attached to incorrect type during class reading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20460/files
  - new: https://git.openjdk.org/jdk/pull/20460/files/e801a291..a107e4fc

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

  Stats: 29806 lines in 910 files changed: 14941 ins; 11076 del; 3789 mod
  Patch: https://git.openjdk.org/jdk/pull/20460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20460/head:pull/20460

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

From duke at openjdk.org  Mon Aug 12 05:05:39 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 12 Aug 2024 05:05:39 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v16]
In-Reply-To: <sS8zEP0MTyqjFlQrFqYMgkUOYxHA2aFse_yfFigBzGE=.5ac75a0f-b82b-4a66-827f-88a7f10d69a5@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
 <_87eGey6no1EMH6TmI9o_jxEXT4XD3MGHffdFng81ew=.2c514646-eac4-4674-98d6-90ff30622057@github.com>
 <dWo6QgWKFFyc98cCTuf39Pj-8gjIOBACzPX-NwFOlc0=.b7d3afa3-5995-498e-9de9-84d7ee1d2617@github.com>
 <sS8zEP0MTyqjFlQrFqYMgkUOYxHA2aFse_yfFigBzGE=.5ac75a0f-b82b-4a66-827f-88a7f10d69a5@github.com>
Message-ID: <6r-BKJ2JS96htlywmt0JTYuYigBad_lK4QdRkaxBmDo=.41109909-cd3d-405e-b395-cb329570e7ab@github.com>

On Fri, 9 Aug 2024 23:37:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Using `SequencedSet` would allow to skip the call to `com.sun.tools.javac.util.List?::reverse()` on the result of `CaptureScanner?::analyzeCaptures()`.
> 
> Not sure about that. Note that `Lower` wants the order of capture to be reversed compared to the "logical" order, but `LambdaToMethod` does not. To me, it is cleaner to put the reverse call close to the code that has "special" requirements, which in this case happens to be `Lower` (which is why the code ended up with that shape).

Well, at?least?typing the?field as?a?`SequencedSet` would?signal?that the?iteration?order is?important.

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

PR Comment: https://git.openjdk.org/jdk/pull/20349#issuecomment-2283117689

From jlahoda at openjdk.org  Mon Aug 12 06:26:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Aug 2024 06:26:37 GMT
Subject: RFR: 8334466: Ambiguous method call with generics may cause
 FunctionDescriptorLookupError
In-Reply-To: <kBgo1TBnv4kAF34GrEzF6P2TMBjcHjVKJ1DGeoDX8dI=.f161f640-cc40-49c0-be61-0392edd31866@github.com>
References: <kBgo1TBnv4kAF34GrEzF6P2TMBjcHjVKJ1DGeoDX8dI=.f161f640-cc40-49c0-be61-0392edd31866@github.com>
Message-ID: <Zg_5y69fFQGvDZ-mqUljdNtMUsZ0slCZxoGeBxX2Hug=.5fabcdf2-4c6b-483b-8f4b-173b0cdd0f4f@github.com>

On Tue, 23 Jul 2024 14:13:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is crashing while compiling code like:
> 
> 
> import java.util.List;
> 
> class Test {
>     void m() {
>         List<X> list = List.of(new X());
>         test(list.get(0));
>     }
> 
>     void test(A<?> a) { }
>     void test(B<?> b) { }
> 
>     interface A<T extends A<T>> { T a(); }
>     interface B<T extends B<T>> { T b(); }
>     class X implements A<X>, B<X> {
>         public X a() { return null; }
>         public X b() { return null; }
>     }
> }
> 
> this is because method Types::findDescriptorType, which is invoked in this particular case, throws `FunctionDescriptorLookupError` which is an internal exception that is supposed to be captured by the client. The client then should interpret the exception depending on the context. This was not happening in the code path stressed by this test case. This PR is fixing this issue
> 
> TIA

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20300#pullrequestreview-2232123348

From jlahoda at openjdk.org  Mon Aug 12 12:06:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Aug 2024 12:06:16 GMT
Subject: RFR: 8337976: Insufficient error recovery in parser for switch
 inside class body [v2]
In-Reply-To: <XkQUm5F0z1djbDOvnZbhKkqgWjasqaLaVEXZriCvW-A=.ac43be32-62c6-4863-b431-8dbc122e8fe4@github.com>
References: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
 <XkQUm5F0z1djbDOvnZbhKkqgWjasqaLaVEXZriCvW-A=.ac43be32-62c6-4863-b431-8dbc122e8fe4@github.com>
Message-ID: <FuOAbps0G6ebZgWUqipCmME7vzBO0NAGBGzT-HQaDX0=.091cb21b-3990-4b45-8a14-a2edfed0881a@github.com>

On Fri, 9 Aug 2024 17:25:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding a comment for the isDefiniteStatementStartToken.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 4923:
> 
>> 4921:     private boolean isDefiniteStatementStartToken() {
>> 4922:         return switch (token.kind) {
>> 4923:             case IF, WHILE, DO, SWITCH, RETURN, TRY, FOR, ASSERT, BREAK,
> 
> should `yield`, `synchronized` be included?

`synchronized` may be part of an method declaration (`synchronized void t() {}`). For `yield`, even though `yield` cannot be used as a type name, I thought it would be better to let the rest of error recovery mechanisms to handle it, hopefully producing some sensible error in more cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20526#discussion_r1713629168

From jlahoda at openjdk.org  Mon Aug 12 12:06:15 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 12 Aug 2024 12:06:15 GMT
Subject: RFR: 8337976: Insufficient error recovery in parser for switch
 inside class body [v2]
In-Reply-To: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
References: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
Message-ID: <lP4Qs_MYbCi3Pd2nZCvD2O_C5BEaLLciqF5zSzR3e58=.424e582a-ad64-4141-9c18-870a84a950e4@github.com>

> Consider this code:
> 
> public class T9999999 {
>     switch (0) { default: }
> }
> 
> 
> When trying to compile this, javac crashes:
> 
> 
> $ .../jdk-22/bin/javac -XDdev /tmp/T9999999.java
> /tmp/T9999999.java:2: error: switch expression does not have any result expressions
>     switch (0) { default: } f;
>     ^
> 1 error
> An exception has occurred in the compiler (22.0.1-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: Unexpected tree: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION within: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5881)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5727)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1022)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5780)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5677)
>         at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1827)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1081)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(...

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

  Adding a comment for the isDefiniteStatementStartToken.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20526/files
  - new: https://git.openjdk.org/jdk/pull/20526/files/c4ba6845..88e28ca2

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

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

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

From vromero at openjdk.org  Mon Aug 12 13:55:38 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 13:55:38 GMT
Subject: RFR: 8334466: Ambiguous method call with generics may cause
 FunctionDescriptorLookupError
In-Reply-To: <Zg_5y69fFQGvDZ-mqUljdNtMUsZ0slCZxoGeBxX2Hug=.5fabcdf2-4c6b-483b-8f4b-173b0cdd0f4f@github.com>
References: <kBgo1TBnv4kAF34GrEzF6P2TMBjcHjVKJ1DGeoDX8dI=.f161f640-cc40-49c0-be61-0392edd31866@github.com>
 <Zg_5y69fFQGvDZ-mqUljdNtMUsZ0slCZxoGeBxX2Hug=.5fabcdf2-4c6b-483b-8f4b-173b0cdd0f4f@github.com>
Message-ID: <lIMhmfHOSRWSUHeBO0FTd2EPJ3GanOTq8O_i1a9zWr4=.941470b6-dbf4-4b40-9655-9f8518775af6@github.com>

On Mon, 12 Aug 2024 06:24:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Looks reasonable to me.

thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/20300#issuecomment-2284051881

From vromero at openjdk.org  Mon Aug 12 13:55:39 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 13:55:39 GMT
Subject: Integrated: 8334466: Ambiguous method call with generics may cause
 FunctionDescriptorLookupError
In-Reply-To: <kBgo1TBnv4kAF34GrEzF6P2TMBjcHjVKJ1DGeoDX8dI=.f161f640-cc40-49c0-be61-0392edd31866@github.com>
References: <kBgo1TBnv4kAF34GrEzF6P2TMBjcHjVKJ1DGeoDX8dI=.f161f640-cc40-49c0-be61-0392edd31866@github.com>
Message-ID: <B_MF4-iQiGTVILCQXnvvjorqV8r_A87PhykDAU4Rw3o=.a1aa1ab6-e4ab-468a-ab1a-719921ffa740@github.com>

On Tue, 23 Jul 2024 14:13:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is crashing while compiling code like:
> 
> 
> import java.util.List;
> 
> class Test {
>     void m() {
>         List<X> list = List.of(new X());
>         test(list.get(0));
>     }
> 
>     void test(A<?> a) { }
>     void test(B<?> b) { }
> 
>     interface A<T extends A<T>> { T a(); }
>     interface B<T extends B<T>> { T b(); }
>     class X implements A<X>, B<X> {
>         public X a() { return null; }
>         public X b() { return null; }
>     }
> }
> 
> this is because method Types::findDescriptorType, which is invoked in this particular case, throws `FunctionDescriptorLookupError` which is an internal exception that is supposed to be captured by the client. The client then should interpret the exception depending on the context. This was not happening in the code path stressed by this test case. This PR is fixing this issue
> 
> TIA

This pull request has now been integrated.

Changeset: 61d1dc59
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61d1dc59535a3dc186bc1986a04efdb4e5a8fa18
Stats:     38 lines in 3 files changed: 35 ins; 0 del; 3 mod

8334466: Ambiguous method call with generics may cause FunctionDescriptorLookupError

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Mon Aug 12 14:21:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 14:21:37 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v3]
In-Reply-To: <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
Message-ID: <jhYfzaaWgrX3vMaSTk6vjCiUhqYr6Ex3MlDHnm8gJ1Y=.17618a05-20cb-48dc-8ca0-fb51117edd4d@github.com>

On Sat, 10 Aug 2024 00:50:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
>> 
>> The change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8337334

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20370#pullrequestreview-2233174548

From vromero at openjdk.org  Mon Aug 12 14:45:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 14:45:34 GMT
Subject: RFR: 8337976: Insufficient error recovery in parser for switch
 inside class body [v2]
In-Reply-To: <lP4Qs_MYbCi3Pd2nZCvD2O_C5BEaLLciqF5zSzR3e58=.424e582a-ad64-4141-9c18-870a84a950e4@github.com>
References: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
 <lP4Qs_MYbCi3Pd2nZCvD2O_C5BEaLLciqF5zSzR3e58=.424e582a-ad64-4141-9c18-870a84a950e4@github.com>
Message-ID: <qWLdXZXThybTdiBFVD5zIst0grkI7R_Tzt5HbzogKI0=.31e9dd43-f32b-4997-abe1-3a1a2984aa8a@github.com>

On Mon, 12 Aug 2024 12:06:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider this code:
>> 
>> public class T9999999 {
>>     switch (0) { default: }
>> }
>> 
>> 
>> When trying to compile this, javac crashes:
>> 
>> 
>> $ .../jdk-22/bin/javac -XDdev /tmp/T9999999.java
>> /tmp/T9999999.java:2: error: switch expression does not have any result expressions
>>     switch (0) { default: } f;
>>     ^
>> 1 error
>> An exception has occurred in the compiler (22.0.1-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.AssertionError: Unexpected tree: switch (0) {
>> default:
>> 
>> } with kind: SWITCH_EXPRESSION within: switch (0) {
>> default:
>> 
>> } with kind: SWITCH_EXPRESSION
>>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5881)
>>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5727)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1022)
>>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5780)
>>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
>>         at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5677)
>>         at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:144)
>>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200)
>>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
>>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
>>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1827)
>>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1081)
>>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
>>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
>>         at jdk.compiler/com.sun.tools.javac.main.Main....
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a comment for the isDefiniteStatementStartToken.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20526#pullrequestreview-2233260341

From vromero at openjdk.org  Mon Aug 12 15:07:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 15:07:35 GMT
Subject: RFR: 8337795: Type annotation attached to incorrect type during
 class reading [v2]
In-Reply-To: <k6jcLlUHTQZ_YaLmL2KmLP4qr9Crwsd43gV1ci_xwCg=.f43dd432-d758-4f4f-80a0-8b53f1ec2f20@github.com>
References: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
 <k6jcLlUHTQZ_YaLmL2KmLP4qr9Crwsd43gV1ci_xwCg=.f43dd432-d758-4f4f-80a0-8b53f1ec2f20@github.com>
Message-ID: <BKOY5m9AA619LOcOuLbF0JC0H7WBmt4y5McQQY0QnXU=.2817ee83-e9a2-4c39-9303-778f00591fe4@github.com>

On Sat, 10 Aug 2024 19:17:08 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a bug in the logic for adding type annotations to types during class reading.
>> 
>> The implementation searched for contained types that type annotations applied to, and then separately rewrote the type to add the annotations using `StructuralTypeMapping`, relying on the object identity of `Type` instances to keep track of them between the two passes. This produced incorrect results if the same type (with the same identity) appeared multiple times as a contained type.
>> 
>> This fix merges the two passes into a single visitor that both locates annotated contained types, and rewrites them to add the annotations. This requires duplicating similar logic to `StructuralTypeMapping`, which seems unavoidable.
>
> Liam Miller-Cushon 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-8337795
>  - 8337795: Type annotation attached to incorrect type during class reading

Marked as reviewed by vromero (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20460#pullrequestreview-2233323802

From asotona at openjdk.org  Mon Aug 12 15:12:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Aug 2024 15:12:38 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
Message-ID: <cp1x2IWrHbqUFysMwQs1RrYaDnqI6xyKkRy5jGwYIkY=.56eb6fe8-676b-48b1-9be6-5da60f67e5be@github.com>

On Fri, 2 Aug 2024 16:31:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
>> 2. Improved value specification to specify their tags.
>> 3. Improved value factories to return their specific types instead of `OfConstant`
>> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
>> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another failing test

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20436#pullrequestreview-2233337319

From syan at openjdk.org  Mon Aug 12 15:24:32 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 12 Aug 2024 15:24:32 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v3]
In-Reply-To: <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
Message-ID: <Lz3hROwo73uzKzb3g1nMPfFc4BG0lwE0T5fMUYN3a9U=.3467a103-5b39-44d6-a063-389abe2a2f4f@github.com>

On Sat, 10 Aug 2024 00:50:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
>> 
>> The change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8337334

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20370#issuecomment-2284270116

From duke at openjdk.org  Mon Aug 12 15:24:33 2024
From: duke at openjdk.org (duke)
Date: Mon, 12 Aug 2024 15:24:33 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v3]
In-Reply-To: <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
Message-ID: <YiblobevyTgfskUf-iMqscChfjicEEKXasybQvVTuQo=.e6e1ec5c-9066-45fd-8bff-6978bf5c6568@github.com>

On Sat, 10 Aug 2024 00:50:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
>> 
>> The change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8337334

@sendaoYan 
Your change (at version 205a6b30520e4e4dca849825b80bfe519cd6cc59) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20370#issuecomment-2284271835

From syan at openjdk.org  Mon Aug 12 15:46:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 12 Aug 2024 15:46:37 GMT
Subject: Integrated: 8337334: Test tools/javac/7142086/T7142086.java timeout
 with fastdebug binary
In-Reply-To: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
Message-ID: <POx0yVjcKpQS4v2zd5AhebofQKJbT0XSVpEaJpauTG0=.c45c365b-b239-4473-889e-d12e4250e37d@github.com>

On Mon, 29 Jul 2024 08:02:17 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
> 
> The change has been verified, no risk.

This pull request has now been integrated.

Changeset: 04b146a3
Author:    SendaoYan <syan at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04b146a31f55825e2c8e3c8e42310b3b3337ae95
Stats:     12 lines in 2 files changed: 9 ins; 0 del; 3 mod

8337334: Test tools/javac/7142086/T7142086.java timeout with fastdebug binary

Reviewed-by: vromero

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

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

From syan at openjdk.org  Mon Aug 12 15:50:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 12 Aug 2024 15:50:35 GMT
Subject: RFR: 8337334: Test tools/javac/7142086/T7142086.java timeout with
 fastdebug binary [v3]
In-Reply-To: <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
References: <MqUcQ05V-QEjtYhqI7mqOqQAnFvKbnBlR8fluAdfqDI=.47ad9f06-46ad-430d-ac0b-af24976ec984@github.com>
 <zMMLeb9u5P_6-7g8XjTDcbzbPVqttFCki9S59K9vTeM=.8f82b9b2-26d0-44ee-bfa5-c8537622054d@github.com>
Message-ID: <AQInm9lGQw_xhJ30QjZ_wMtlE6aKdmwQFsjkmpcBjVE=.045f8c6c-68b8-427d-bcc3-bc0c3b28da7f@github.com>

On Sat, 10 Aug 2024 00:50:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `tools/javac/7142086/T7142086.java` run timeouted with fastdebug binary. I think it's necessory set more timeout value  when the tested binary is fastdebug or slowdebug.
>> 
>> The change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id 8337334

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/20370#issuecomment-2284330163

From cushon at openjdk.org  Mon Aug 12 17:18:38 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 12 Aug 2024 17:18:38 GMT
Subject: Integrated: 8337795: Type annotation attached to incorrect type during
 class reading
In-Reply-To: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
References: <K85UiT0dgsCom74c6_MfnW2qx1NZ82qt8_sQvOP5uM0=.6aa3b493-7b8c-421d-b3ec-474381130473@github.com>
Message-ID: <OwlN3HOKilHKWWyUmLwOGYCcxqcX3LXGX0fuMRgYrK0=.c118664c-ed5e-4636-bf0a-5cf730244460@github.com>

On Sun, 4 Aug 2024 19:49:20 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a bug in the logic for adding type annotations to types during class reading.
> 
> The implementation searched for contained types that type annotations applied to, and then separately rewrote the type to add the annotations using `StructuralTypeMapping`, relying on the object identity of `Type` instances to keep track of them between the two passes. This produced incorrect results if the same type (with the same identity) appeared multiple times as a contained type.
> 
> This fix merges the two passes into a single visitor that both locates annotated contained types, and rewrites them to add the annotations. This requires duplicating similar logic to `StructuralTypeMapping`, which seems unavoidable.

This pull request has now been integrated.

Changeset: 8d083147
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d0831478338e9b084b2c47f46eba9faae3a5eb6
Stats:     109 lines in 2 files changed: 25 ins; 44 del; 40 mod

8337795: Type annotation attached to incorrect type during class reading

Reviewed-by: vromero

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

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

From cushon at openjdk.org  Mon Aug 12 18:15:55 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 12 Aug 2024 18:15:55 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v2]
In-Reply-To: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
Message-ID: <Ve5pYuj9tbR506bIZqsR_nn8ZCNO_prNCUkWu9DIjV4=.fbfaffb5-12c0-44a5-bb2a-436fe1e8b37c@github.com>

> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
> 
> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
> 
> This change handles the completion failures, and reports an error diagnostic instead of the current crash.

Liam Miller-Cushon 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 six additional commits since the last revision:

 - Merge branch 'master' into JDK-8337998
 - Update diagnostic key and text to refer to 'attaching', not 'reading' type annotations
 - Update diagnostic key
 - Update not-yet list
 - Remove unused import
 - 8337998: CompletionFailure in getEnclosingType attaching type annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20495/files
  - new: https://git.openjdk.org/jdk/pull/20495/files/3e19fc73..a1e7e33d

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

  Stats: 10127 lines in 304 files changed: 4001 ins; 5108 del; 1018 mod
  Patch: https://git.openjdk.org/jdk/pull/20495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20495/head:pull/20495

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

From cushon at openjdk.org  Mon Aug 12 18:15:55 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 12 Aug 2024 18:15:55 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v2]
In-Reply-To: <RG9WHm9a3Wj68I4uFwZJ5FyRBSkpq3yWS4d0c1E7jpw=.40f31f7c-ad12-4d19-ac53-f6d1c1419d2c@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Uf2Pij5VYfTYpgLoglBOx48JvDTiG5ZeQixASg3F3GU=.ee50d60b-81af-4883-9fda-6097c0912c11@github.com>
 <kDm5_7Rdg21zdrb1eYsR8lRUna2wmo0JmXbQ1NQ6kbQ=.2075be11-ef2c-4a06-a965-00b4b6bb350b@github.com>
 <VAPAEP9HiSdpjwFL6cNgwDrEqGW27XYPHbVVBu6gCFk=.39c9a8e4-7023-4cb7-b8a0-1296119a1d43@github.com>
 <RG9WHm9a3Wj68I4uFwZJ5FyRBSkpq3yWS4d0c1E7jpw=.40f31f7c-ad12-4d19-ac53-f6d1c1419d2c@github.com>
Message-ID: <tnFbYq9OHJGtpBQft3FJNtdLu2zc6wVJdhlod6ZfFB4=.ad41f524-d15b-458e-a0d3-55b282b9a76e@github.com>

On Fri, 9 Aug 2024 19:26:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> right I guess I was confused by the key in the error message: `type.annotation.not.found`
>
> Good point, I will think of a better name for the diagnostic key.
> 
> It would also work to use a more generic error message for this, but I think it is helpful to include some context about the annotation that was being attached when the completion failure occurred, as a hint to where the problem is.

I reworked the diagnostic a bit and updated the key to `compiler.err.cant.attach.type.annotations`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1714194703

From vromero at openjdk.org  Mon Aug 12 21:15:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 12 Aug 2024 21:15:32 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v2]
In-Reply-To: <Ve5pYuj9tbR506bIZqsR_nn8ZCNO_prNCUkWu9DIjV4=.fbfaffb5-12c0-44a5-bb2a-436fe1e8b37c@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Ve5pYuj9tbR506bIZqsR_nn8ZCNO_prNCUkWu9DIjV4=.fbfaffb5-12c0-44a5-bb2a-436fe1e8b37c@github.com>
Message-ID: <2_tLuu7nVEpmrIXZrZWiu057xbS7x9r0_tCxTQiuhtg=.7e4a6ebf-6041-46bf-a067-e6cc6fa78aac@github.com>

On Mon, 12 Aug 2024 18:15:55 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
>> 
>> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
>> 
>> This change handles the completion failures, and reports an error diagnostic instead of the current crash.
>
> Liam Miller-Cushon 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 six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337998
>  - Update diagnostic key and text to refer to 'attaching', not 'reading' type annotations
>  - Update diagnostic key
>  - Update not-yet list
>  - Remove unused import
>  - 8337998: CompletionFailure in getEnclosingType attaching type annotations

Marked as reviewed by vromero (Reviewer).

test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java line 27:

> 25:  * @test
> 26:  * @bug 8332850
> 27:  * @summary XXX

looks good, nit: we will need a meaningful summary here

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

PR Review: https://git.openjdk.org/jdk/pull/20495#pullrequestreview-2234031307
PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1714375498

From cushon at openjdk.org  Tue Aug 13 01:01:09 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 13 Aug 2024 01:01:09 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v2]
In-Reply-To: <2_tLuu7nVEpmrIXZrZWiu057xbS7x9r0_tCxTQiuhtg=.7e4a6ebf-6041-46bf-a067-e6cc6fa78aac@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <Ve5pYuj9tbR506bIZqsR_nn8ZCNO_prNCUkWu9DIjV4=.fbfaffb5-12c0-44a5-bb2a-436fe1e8b37c@github.com>
 <2_tLuu7nVEpmrIXZrZWiu057xbS7x9r0_tCxTQiuhtg=.7e4a6ebf-6041-46bf-a067-e6cc6fa78aac@github.com>
Message-ID: <rBWBnxETXV1W3zcP6y7NmAvphEJd_E-5nhqfxsD9bSk=.b98316a4-2745-42d1-85e2-ee5f552cd288@github.com>

On Mon, 12 Aug 2024 21:13:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8337998
>>  - Update diagnostic key and text to refer to 'attaching', not 'reading' type annotations
>>  - Update diagnostic key
>>  - Update not-yet list
>>  - Remove unused import
>>  - 8337998: CompletionFailure in getEnclosingType attaching type annotations
>
> test/langtools/tools/javac/annotations/typeAnnotations/CompletionErrorOnEnclosingType.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8332850
>> 27:  * @summary XXX
> 
> looks good, nit: we will need a meaningful summary here

Thanks, fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20495#discussion_r1714521909

From cushon at openjdk.org  Tue Aug 13 01:01:07 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 13 Aug 2024 01:01:07 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v3]
In-Reply-To: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
Message-ID: <gEyNQt1lOYX38M-4tXphQQrpUZE0AzgGfqFwE7zbZds=.7c23fe51-cc39-4bcb-b6b3-e675681e0526@github.com>

> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
> 
> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
> 
> This change handles the completion failures, and reports an error diagnostic instead of the current crash.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Update bug number and summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20495/files
  - new: https://git.openjdk.org/jdk/pull/20495/files/a1e7e33d..1ccd79d2

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

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

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

From vromero at openjdk.org  Tue Aug 13 13:20:52 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 13 Aug 2024 13:20:52 GMT
Subject: RFR: 8337998: CompletionFailure in getEnclosingType attaching type
 annotations [v3]
In-Reply-To: <gEyNQt1lOYX38M-4tXphQQrpUZE0AzgGfqFwE7zbZds=.7c23fe51-cc39-4bcb-b6b3-e675681e0526@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
 <gEyNQt1lOYX38M-4tXphQQrpUZE0AzgGfqFwE7zbZds=.7c23fe51-cc39-4bcb-b6b3-e675681e0526@github.com>
Message-ID: <2X4XlWgDVAesUKMrCcfYzbIldqqaLdE9C00hkFGjgDE=.8cd32567-f305-4279-83c4-e76f70a868c6@github.com>

On Tue, 13 Aug 2024 01:01:07 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
>> 
>> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
>> 
>> This change handles the completion failures, and reports an error diagnostic instead of the current crash.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update bug number and summary

lgtm, thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20495#pullrequestreview-2235532067

From cushon at openjdk.org  Tue Aug 13 15:08:56 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 13 Aug 2024 15:08:56 GMT
Subject: Integrated: 8337998: CompletionFailure in getEnclosingType attaching
 type annotations
In-Reply-To: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
References: <uC1ak5uBIQsDhx1jNHb9ZUp94lOw8xOon8k0BzSKO10=.ea51926b-a4f8-4ce1-8175-1ce6a2369550@github.com>
Message-ID: <SQjA5Jyl6E9SHd6FoGiDaTLNbS6ODr5O5Su7xkFiliw=.13111ae7-fce2-4da5-97bf-5eb7cd4d45f2@github.com>

On Wed, 7 Aug 2024 15:59:58 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a `CompletionFailure` crash in javac when a missing class is discovered while attaching type annotations read from a class file.
> 
> Type annotations on classes are located with a type path starting on the 'outermost part of the type for which a type annotation is admissible', so annotating a type requires knowing its outer classes, and the call to `ClassType#getEnclosingType` can cause additional symbols to be completed.
> 
> This change handles the completion failures, and reports an error diagnostic instead of the current crash.

This pull request has now been integrated.

Changeset: 9e282e5c
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e282e5c966a9c065de8b901b7d30bb5c9ccf243
Stats:     116 lines in 4 files changed: 113 ins; 0 del; 3 mod

8337998: CompletionFailure in getEnclosingType attaching type annotations

Reviewed-by: vromero

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

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

From cushon at openjdk.org  Tue Aug 13 15:12:08 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 13 Aug 2024 15:12:08 GMT
Subject: RFR: 8336942: Improve test coverage for class loading elements
 with annotations of different retentions [v2]
In-Reply-To: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
References: <7XFgdT8JCKJ6oszaPembiilLaSX66njbsfWs_ur73JE=.662140f6-0645-4c08-af1d-cd7b62858912@github.com>
Message-ID: <Ggm8_uuAUv8gNof1ZqdemcYVksg8hFxjkVGIeAtSRwQ=.4c0e74de-b369-40d9-b9bc-e24c5df85937@github.com>

> This changes adds some additional test coverage for the handling of type use annotations read from class files added in [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> If both a `RUNTIME` and `CLASS` retention type annotation appear on the same element loaded from a class file, the annotations are attached by separate `TypeAnnotationCompleter's`s, and the logic in `ClassReader` needs to merge the annotations from the second attribute with annotations added by the first one.
> 
> The implementation already handles this correctly, but there isn't explicit test coverage for it. This change adds test coverage for that case.

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

 - Merge branch 'master' into JDK-8336942
 - Sort entries in nameToAnnotation
 - 8336942: Improve test coverage for class loading elements with annotations of different retentions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20287/files
  - new: https://git.openjdk.org/jdk/pull/20287/files/b598c5d8..7e5bbd58

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

  Stats: 31993 lines in 1037 files changed: 16087 ins; 11622 del; 4284 mod
  Patch: https://git.openjdk.org/jdk/pull/20287.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20287/head:pull/20287

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

From liach at openjdk.org  Tue Aug 13 15:17:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 15:17:04 GMT
Subject: Integrated: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <2nhkV2zBPm6lyeRuDboFGmIh9tNVACktx5RPSB1p9Yc=.f6a1790b-9856-4048-b8ac-80ed25526f7b@github.com>

On Fri, 2 Aug 2024 00:39:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

This pull request has now been integrated.

Changeset: 6af1d6ff
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6af1d6ff210b3ddbc7d1585428b49631248a500b
Stats:     397 lines in 12 files changed: 216 ins; 39 del; 142 mod

8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

Reviewed-by: asotona

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

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

From liach at openjdk.org  Tue Aug 13 15:17:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 15:17:04 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
Message-ID: <OuI3zRiE6u0l-c5Ygb3CeVZOngX48frX7QfCl0JucFY=.e0212eab-02c8-41b4-94f2-32f777453cb8@github.com>

On Fri, 2 Aug 2024 16:31:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
>> 2. Improved value specification to specify their tags.
>> 3. Improved value factories to return their specific types instead of `OfConstant`
>> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
>> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another failing test

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/20436#issuecomment-2286501451

From liach at openjdk.org  Tue Aug 13 19:47:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:47:30 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v9]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <nYQhpgoVZ9KHWpCcsce10UwAhRjd0id7hbFRAyC1-sg=.14365076-bb5e-4a91-8f12-e0998da9b828@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

Chen Liang 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:

 - More bad terms and redundancy
 - Fix terminology
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - ... and 8 more: https://git.openjdk.org/jdk/compare/f09e48cb...c66c7d25

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/3a91a3a5..c66c7d25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=07-08

  Stats: 15357 lines in 539 files changed: 6184 ins; 6850 del; 2323 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Tue Aug 13 19:56:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:56:22 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Missed JLS prefix from web review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/c66c7d25..8af07782

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=08-09

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

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

From darcy at openjdk.org  Tue Aug 13 20:02:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Aug 2024 20:02:15 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
Message-ID: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>

The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

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

Commit messages:
 - JDK-8338333: Add jls links to javax.lang.model.element.Modifier

Changes: https://git.openjdk.org/jdk/pull/20572/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338333
  Stats: 92 lines in 1 file changed: 81 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20572/head:pull/20572

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

From liach at openjdk.org  Tue Aug 13 20:06:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 20:06:48 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
In-Reply-To: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
Message-ID: <jDuhVFktFBOGEwHCf6FJETniMYpn1_4VsJP_UjPgaG8=.a33c1485-4abe-462b-b484-549aeb448753@github.com>

On Tue, 13 Aug 2024 19:57:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

The section numbers and titles (code fonts, casing) look all right.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2236475801

From prappo at openjdk.org  Tue Aug 13 21:50:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Aug 2024 21:50:49 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
In-Reply-To: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
Message-ID: <GV9l54rE641HMlmk7kGIunHO4_oSQcWk0pWayG5BqRs=.55743a86-4ff4-4278-96b4-ee5564177ca7@github.com>

On Tue, 13 Aug 2024 19:57:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

src/java.compiler/share/classes/javax/lang/model/element/Modifier.java line 95:

> 93:      * The modifier {@code static}
> 94:      *
> 95:      * @jls 8.1.1.4 {@code static} Classes

Do we need to add this?

    @jls 9.1.1.3 {@code static} Interfaces

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20572#discussion_r1715968256

From darcy at openjdk.org  Tue Aug 13 23:24:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Aug 2024 23:24:05 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v2]
In-Reply-To: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
Message-ID: <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>

> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Correct issue found in code review.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20572/files
  - new: https://git.openjdk.org/jdk/pull/20572/files/f16c4f37..2e45196b

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

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

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

From darcy at openjdk.org  Tue Aug 13 23:24:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Aug 2024 23:24:05 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v2]
In-Reply-To: <GV9l54rE641HMlmk7kGIunHO4_oSQcWk0pWayG5BqRs=.55743a86-4ff4-4278-96b4-ee5564177ca7@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <GV9l54rE641HMlmk7kGIunHO4_oSQcWk0pWayG5BqRs=.55743a86-4ff4-4278-96b4-ee5564177ca7@github.com>
Message-ID: <jdhyKivjrrGJQBNELhnoqz24QeQgGRU1gFtfvj33m5U=.23c45226-78bc-489e-9e7f-e695a85f0c28@github.com>

On Tue, 13 Aug 2024 21:47:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct issue found in code review.
>
> src/java.compiler/share/classes/javax/lang/model/element/Modifier.java line 95:
> 
>> 93:      * The modifier {@code static}
>> 94:      *
>> 95:      * @jls 8.1.1.4 {@code static} Classes
> 
> Do we need to add this?
> 
>     @jls 9.1.1.3 {@code static} Interfaces

Good catch @pavelrappo ; fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20572#discussion_r1716084718

From iris at openjdk.org  Wed Aug 14 00:49:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Aug 2024 00:49:55 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v2]
In-Reply-To: <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
Message-ID: <1PTZ6dpSbyY3K2FZQ8CK9MTDvXiBx1hTjpckkASj60Y=.078083af-85c9-4bf1-9397-cfc014ab9700@github.com>

On Tue, 13 Aug 2024 23:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct issue found in code review.

References appear correct as compared to the annotated version of the JLS version for Java SE 23:

https://cr.openjdk.org/~iris/se/23/latestSpec/java-se-23-jls-fr-diffs.pdf

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2236919865

From asotona at openjdk.org  Wed Aug 14 09:13:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Aug 2024 09:13:59 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
Message-ID: <hdWhMTIYi9hVMdGK92lj--c4-ncreGYKr1Z2Yu7akr4=.1a300276-2fd1-4549-9eb3-42d9c0054c21@github.com>

On Tue, 13 Aug 2024 19:56:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed JLS prefix from web review

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2237594219

From vromero at openjdk.org  Wed Aug 14 10:07:49 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 14 Aug 2024 10:07:49 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v2]
In-Reply-To: <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
Message-ID: <bvuVf830k-TyQxsQCe64OQMP5C3veRv1VSuuG4_104M=.b9834bdf-4193-4461-866d-ed102fe73d01@github.com>

On Tue, 13 Aug 2024 23:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct issue found in code review.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2237719768

From mcimadamore at openjdk.org  Wed Aug 14 10:49:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Aug 2024 10:49:22 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v17]
In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
Message-ID: <g7e-O7cfuFKS7PX7OMj27He8m0BtAxmeA0S_19TJyV8=.cb3abe6f-7ac6-496c-849a-91d56aad508a@github.com>

> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
> 
> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
> 
> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
> 
> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
> 
> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
> 
> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
> 
> #### Compatibility
> 
> This PR chan...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20349/files
  - new: https://git.openjdk.org/jdk/pull/20349/files/04633eea..32b676a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=15-16

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

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

From mcimadamore at openjdk.org  Wed Aug 14 11:16:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Aug 2024 11:16:13 GMT
Subject: RFR: 8336492: Regression in lambda serialization [v18]
In-Reply-To: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
References: <1rfvo7jEXb6LdDMF4_xUn1OZau-41HKhUFKz4BQDxu0=.17564dac-2696-4e78-abfd-9763087c9a59@github.com>
Message-ID: <cuidcUbVnyQuABMA_M8fj4_09RH9UUwEe9dg1k7vAok=.d96cb328-111c-4089-9dd2-12138d741bf8@github.com>

> This PR consolidates the code for dealing with local captures in both `Lower` and `LambdaToMethod`. It does so by adding a new tree scanner, namely `CaptureScanner`, which is then subclassed by `Lower.FreeVarCollector` and also by the new `LambdaToMethod.LambdaCaptureScanner`.
> 
> The main idea behind the new visitor is that we can compute the set of (most) captured locals w/o relying on complex state from `Lower`, and make the logic general enough to work on *any* tree. This can be done by keeping track of all local variable declarations occurring in a given subtree `T`. Then, if `T` contains a reference to a local variable that has not been seen, we can assume that this variable is a captured variable. This simple logic works rather well, and doesn't rely on checking e.g. that the accessed variable has the same owner of the method that owns a local class (which then caused other artifacts such as `Lower::ownerToCopyFreeVarsFrom`, now removed).
> 
> The bigger rewrite is the one in `LambdaToMethod`. That class featured a custom visitor called `LambdaAnalyzerPreprocessor` (now removed) which maintains a stack of frames encountered during a visit, and tries to establish which references to local variables needs to be captured by the lambda, as well as whether `this` needs to be referenced by the lambda. Thanks to the new `CaptureScanner` visitor, all this logic can be achieved in a very small subclass of `CaptureScanner`, namely `LambdaCaptureScanner`.
> 
> This removes the need to keep track of frames, and other ancillary data structures. `LambdaTranslationContext` is now significantly simpler, and its most important field is a `Map<VarSymbol, VarSymbol>` which maps logical lambda symbols to translated ones (in the generated lambda method). We no longer need to maintain different maps for different kinds of captured symbols.
> 
> The code for patching identifiers in a lambda expression also became a lot simpler: we just check if we have pending lambda translation context and, if so, we ask if the identifier symbol is contained in the translation map. Otherwise, we leave the identifier as is.
> 
> Fixing the issue referenced by this PR is now very simple: inside `LambdaCaptureScanner`, we just need to make sure that any identifier referring to a captured local field generated by `Lower` is re-captured, and the rest just works. To make the code more robust I've added a new variable flag to denote synthetic captured fields generated by `Lower`.
> 
> #### Compatibility
> 
> This PR chan...

Maurizio Cimadamore 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 20 additional commits since the last revision:

 - Merge branch 'master' into lambda_capture
 - Address review comment
 - Fix comment
 - Beef up serializable lambda test
 - Remove whitespaces
 - Make sure order of captured vars is the same as before.
   Do not remove `this$0` from serializable local classes.
 - Minory style cleanup to get rid of IDE warnings
 - Drop TranslationContext
 - Fix more cases where EnclosingMethodAttribute is wrong for lambdas declared in instance field inits
 - Drop caching of clinit fake symbols in Attr
 - ... and 10 more: https://git.openjdk.org/jdk/compare/e68a382f...6a730ed0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20349/files
  - new: https://git.openjdk.org/jdk/pull/20349/files/32b676a7..6a730ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20349&range=16-17

  Stats: 23430 lines in 882 files changed: 10104 ins; 9936 del; 3390 mod
  Patch: https://git.openjdk.org/jdk/pull/20349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20349/head:pull/20349

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

From jpai at openjdk.org  Wed Aug 14 11:44:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Aug 2024 11:44:08 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v9]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <8vhOrUuChIsS-WydzDA2wnbnQOzYRg6yabkqf56Ey4c=.e0ca6a02-390e-4084-93e2-28c91a3b3f88@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - cleanup testExtractNoDestDirWithPFlag() test
 - merge latest from master branch
 - merge latest from master branch
 - convert the new test to junit
 - merge latest from master branch
 - Lance's review - include tests for --extract long form option
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3dd07b91...49abed2e

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=08
  Stats: 569 lines in 4 files changed: 558 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/2752/head:pull/2752

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

From jlahoda at openjdk.org  Wed Aug 14 12:22:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Aug 2024 12:22:57 GMT
Subject: Integrated: 8337976: Insufficient error recovery in parser for switch
 inside class body
In-Reply-To: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
References: <u6ryFe6yCiq60PT5WqU55LI3pq7mIOfHWwkosbDDXcY=.4575c227-3595-42f9-9b3f-e19add8b68fd@github.com>
Message-ID: <JZReOEa1jgfZPeY8ZgccLzCOPipINnMUpEzUbWeCOcA=.facdcfaf-880b-492a-85cf-fd46beb00f82@github.com>

On Fri, 9 Aug 2024 14:57:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> public class T9999999 {
>     switch (0) { default: }
> }
> 
> 
> When trying to compile this, javac crashes:
> 
> 
> $ .../jdk-22/bin/javac -XDdev /tmp/T9999999.java
> /tmp/T9999999.java:2: error: switch expression does not have any result expressions
>     switch (0) { default: } f;
>     ^
> 1 error
> An exception has occurred in the compiler (22.0.1-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com/) after checking the Bug Database (https://bugs.java.com/) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.AssertionError: Unexpected tree: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION within: switch (0) {
> default:
> 
> } with kind: SWITCH_EXPRESSION
>         at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5881)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5727)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:1022)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitClassDef(Attr.java:5780)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:814)
>         at jdk.compiler/com.sun.tools.javac.comp.Attr.validateTypeAnnotations(Attr.java:5677)
>         at jdk.compiler/com.sun.tools.javac.code.TypeAnnotations.lambda$validateTypeAnnotationsSignatures$1(TypeAnnotations.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.flush(Annotate.java:200)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.unblockAnnotations(Annotate.java:144)
>         at jdk.compiler/com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:157)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterDone(JavaCompiler.java:1827)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:1081)
>         at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:947)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
>         at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
>         at jdk.compiler/com.sun.tools.javac.Main.compile(...

This pull request has now been integrated.

Changeset: fbe4f056
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe4f05636c8f692bd40bbe11fb5bb8b77b77042
Stats:     132 lines in 9 files changed: 122 ins; 1 del; 9 mod

8337976: Insufficient error recovery in parser for switch inside class body

Reviewed-by: vromero

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

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

From jlahoda at openjdk.org  Wed Aug 14 12:45:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 14 Aug 2024 12:45:49 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v2]
In-Reply-To: <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <r9FV-5IDsTURSR-cAbuauXEn6UyCtMuQ5x-BMMD74tk=.f6750d84-c13e-4f35-8296-c02ad3d1a334@github.com>
Message-ID: <ubQcYn_DOAS1Rxqy8lI-S48Ntn7XACHWxXtXCNZFUU4=.8fedcedb-e5a2-424b-a50f-4ec6f12833ce@github.com>

On Tue, 13 Aug 2024 23:24:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct issue found in code review.

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2238050505

From darcy at openjdk.org  Wed Aug 14 17:15:06 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 14 Aug 2024 17:15:06 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v3]
In-Reply-To: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
Message-ID: <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>

> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20572/files
  - new: https://git.openjdk.org/jdk/pull/20572/files/2e45196b..adc18630

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

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

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

From iris at openjdk.org  Wed Aug 14 17:39:50 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 14 Aug 2024 17:39:50 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v3]
In-Reply-To: <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
Message-ID: <PnGwJncL-bw11Idjtdi7pQGY0ruCXOyWfriiI5ZnUr4=.e92ca398-9986-4a1c-a826-2b47e426ab80@github.com>

On Wed, 14 Aug 2024 17:15:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2238813799

From liach at openjdk.org  Wed Aug 14 17:39:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 17:39:50 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v3]
In-Reply-To: <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
Message-ID: <oP9ofiVrtoGfl4Waa9HMWVGZZgV4jVj0nTAUzRYJz5I=.8b4e91e2-f87f-4767-8691-4f918111412b@github.com>

On Wed, 14 Aug 2024 17:15:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2238816891

From prappo at openjdk.org  Wed Aug 14 18:21:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Aug 2024 18:21:51 GMT
Subject: RFR: 8338333: Add jls links to javax.lang.model.element.Modifier
 [v3]
In-Reply-To: <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
 <cUJwkIGKlYzlSVUi-zVr-Hsaumk2erDHIHbmDz3H_8c=.c1131c50-406b-4293-b3c3-459c85828c72@github.com>
Message-ID: <QdUWbzBV3jPSpBsC1Ee2PKYF8CsOKMNlHEz817L-6is=.9716aa96-bf8f-44aa-b353-dea604fe059f@github.com>

On Wed, 14 Aug 2024 17:15:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Looks good, Joe.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20572#pullrequestreview-2238897644

From darcy at openjdk.org  Wed Aug 14 18:45:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 14 Aug 2024 18:45:52 GMT
Subject: Integrated: 8338333: Add jls links to
 javax.lang.model.element.Modifier
In-Reply-To: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
References: <4T5iU04d6O4lhC0kz5bfSuEd_9yee2OeZjzG0dmDCmM=.940c00a6-cbc8-4797-bdc0-e85a005abe93@github.com>
Message-ID: <Sj-uej3P4E7Vfqea462p8oMES_mmkyOwoHViz2nF7F0=.7096df2e-399f-4605-972b-1892c567c9b1@github.com>

On Tue, 13 Aug 2024 19:57:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The javadoc in javax.lang.model.element.Modifier would be more informative to readers if it linked to the relevant JLS sections discussing that modifier.

This pull request has now been integrated.

Changeset: aff7936f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff7936ff088249d1fc787a9f9ef687f987f556c
Stats:     94 lines in 1 file changed: 82 ins; 0 del; 12 mod

8338333: Add jls links to javax.lang.model.element.Modifier

Reviewed-by: liach, iris, prappo, vromero, jlahoda

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

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

From achung at openjdk.org  Wed Aug 14 23:47:51 2024
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 14 Aug 2024 23:47:51 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg
In-Reply-To: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
Message-ID: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>

On Tue, 6 Aug 2024 05:51:35 GMT, toshiogata <duke at openjdk.org> wrote:

> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
> Testing: modified tests

test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1:

> 1: /*

since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import?

test/langtools/tools/javac/warnings/Serial/Serial.java line 1:

> 1: /*

move jtreg tags below imports and add copyrights

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1717644293
PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1717644469

From jlahoda at openjdk.org  Thu Aug 15 08:46:17 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 15 Aug 2024 08:46:17 GMT
Subject: RFR: 8338301: Error recovery and reporting should be improved for
 erroneous implicitly declared classes
Message-ID: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>

Consider code like:

$ cat /tmp/M.java 
main() {}


which is compiled like:

$ javac --enable-preview --source 24 /tmp/M.java 
/tmp/M.java:1: error: class, interface, enum, or record expected
main() {}
^
1 error


This error is problematic for two reasons:
 - this is clearly a method with missing return type, but the error recovery does not see it as such
 - with implicitly declared classes, not only classes/interfaces/enum/records are expected here, but also methods and fields as permitted

Note that if a method inside a class is missing a return type, the error is much better, so this is a problem specifically for methods on the top-level:

$ cat /tmp/C.java
public class C {
    main() {}
}
$ javac --enable-preview --source 24 /tmp/C.java 
/tmp/C.java:2: error: invalid method declaration; return type required
    main() {}
    ^
1 error


The immediate reason is that the javac's parser will speculatively parse the code to see if the code looks-like a method or a field, but this speculative parse does not special-case methods without return types (unlike class-member parsing, which has this special case, partly because of constructors).

I tried to remove this speculative parsing, reusing the code to parse class members, but I wasn't successful in that, sadly.

So, the proposal here is three-fold:
 - the speculative parse will special-case methods without return type, as member parsing does
 - when the parser cannot figure out the at the top-level code, the error will be "class, interface, annotation type, enum, record, method or field expected", instead of the current "class, interface, enum, or record expected", to cover all possibilities. (This is only when implicitly declared classes are permitted, i.e. when preview is enabled and source level is correct, otherwise the existing error will be emitted. The idea here is not to suggest something that will lead to another compile-time error.)
 - (definite) statements at the top-level are special-cased, similarly to how they are special-cased for members after https://github.com/openjdk/jdk/pull/20526

With this patch, errors like this are produced:

$ cat /tmp/M.java 
main() {}
$ javac --enable-preview -source 24 /tmp/M.java 
/tmp/M.java:1: error: invalid method declaration; return type required
main() {}
^
Note: /tmp/M.java uses preview features of Java SE 24.
Note: Recompile with -Xlint:preview for details.
1 error



$ cat /tmp/S.java 
if (true);
$ javac --enable-preview -source 24 /tmp/S.java 
/tmp/S.java:1: error: statements not expected outside of methods and initializers
if (true);
^
1 error



$ cat /tmp/L.java 
"not-handled"
$ javac --enable-preview -source 24 /tmp/L.java 
/tmp/L.java:1: error: class, interface, annotation type, enum, record, method or field expected
"not-handled"
^
1 error

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

Commit messages:
 - Cleanup.
 - Merge branch 'master' into JDK-8338301
 - Cleanup.
 - Handling semicolons.
 - 8338301: Error recovery and reporting should be improved for erroneous implicitly declared classes
 - Adding a comment for the isDefiniteStatementStartToken.
 - Cleanup.
 - Cleanup/reducing scope
 - Fixing tests.
 - 8337976: Insufficient error recovery in parser for switch inside class body, and missing name in parameterized type

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

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

From cstein at openjdk.org  Thu Aug 15 09:16:48 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 15 Aug 2024 09:16:48 GMT
Subject: RFR: 8338301: Error recovery and reporting should be improved for
 erroneous implicitly declared classes
In-Reply-To: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
References: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
Message-ID: <zqf-s9PQlh2K_xDFBeRslqw6rXAMq7G-i6QZ5JTTyOE=.1cd989bc-484c-427a-bb72-827a6cd8fe80@github.com>

On Thu, 15 Aug 2024 08:41:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat /tmp/M.java 
> main() {}
> 
> 
> which is compiled like:
> 
> $ javac --enable-preview --source 24 /tmp/M.java 
> /tmp/M.java:1: error: class, interface, enum, or record expected
> main() {}
> ^
> 1 error
> 
> 
> This error is problematic for two reasons:
>  - this is clearly a method with missing return type, but the error recovery does not see it as such
>  - with implicitly declared classes, not only classes/interfaces/enum/records are expected here, but also methods and fields as permitted
> 
> Note that if a method inside a class is missing a return type, the error is much better, so this is a problem specifically for methods on the top-level:
> 
> $ cat /tmp/C.java
> public class C {
>     main() {}
> }
> $ javac --enable-preview --source 24 /tmp/C.java 
> /tmp/C.java:2: error: invalid method declaration; return type required
>     main() {}
>     ^
> 1 error
> 
> 
> The immediate reason is that the javac's parser will speculatively parse the code to see if the code looks-like a method or a field, but this speculative parse does not special-case methods without return types (unlike class-member parsing, which has this special case, partly because of constructors).
> 
> I tried to remove this speculative parsing, reusing the code to parse class members, but I wasn't successful in that, sadly.
> 
> So, the proposal here is three-fold:
>  - the speculative parse will special-case methods without return type, as member parsing does
>  - when the parser cannot figure out the at the top-level code, the error will be "class, interface, annotation type, enum, record, method or field expected", instead of the current "class, interface, enum, or record expected", to cover all possibilities. (This is only when implicitly declared classes are permitted, i.e. when preview is enabled and source level is correct, otherwise the existing error will be emitted. The idea here is not to suggest something that will lead to another compile-time error.)
>  - (definite) statements at the top-level are special-cased, similarly to how they are special-cased for members after https://github.com/openjdk/jdk/pull/20526
> 
> With this patch, errors like this are produced:
> 
> $ cat /tmp/M.java 
> main() {}
> $ javac --enable-preview -source 24 /tmp/M.java 
> /tmp/M.java:1: error: invalid method declaration; return type required
> main() {}
> ^
> Note: /tmp/M.java uses preview features of Java SE 24.
> Note: Recompile with -Xlint:preview for details.
> 1 error
> 
> 
> 
> $ cat /tmp/S.java 
> if (true);
> $ javac --enable-preview -source 24 /tmp/S.java 
> /tmp/S.j...

Looks good to me - error messages are much better now.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20591#pullrequestreview-2240025301

From jonathan.gibbons at oracle.com  Thu Aug 15 21:38:08 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 15 Aug 2024 14:38:08 -0700
Subject: CFV: Withdraw sponsorship of Closures and Detroit Projects
Message-ID: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>

I propose that the Compiler Group withdraw Sponsorship of the long inactive
Closures [1] and Detroit [2] Projects

Closures was one of the Innovators' Challenge Projects.? It's been 
inactive for years.

Detroit never got off the ground.

A consequence of withdrawing sponsorship? is that the Project may be
dissolved. [c]

Votes are due by COB 29 Aug 2024.

Only current Compiler Group Members [a] are eligible to vote on this
motion.? Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [b].

-- Jon

[1]: https://openjdk.org/census#closures
[2]: https://openjdk.org/census#detroit
[a]: https://openjdk.org/census#compiler
[b]: https://openjdk.org/bylaws#lazy-consensus
[c]: https://openjdk.org/bylaws#sponsor






From iris.clark at oracle.com  Thu Aug 15 23:50:08 2024
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 15 Aug 2024 23:50:08 +0000
Subject: CFV: Withdraw sponsorship of Closures and Detroit Projects
In-Reply-To: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
References: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
Message-ID: <SJ2PR10MB761751F049DDA324A2DAF457FB802@SJ2PR10MB7617.namprd10.prod.outlook.com>

Vote: yes

Thanks,
Iris

________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Thursday, August 15, 2024 2:38 PM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: CFV: Withdraw sponsorship of Closures and Detroit Projects

I propose that the Compiler Group withdraw Sponsorship of the long inactive
Closures [1] and Detroit [2] Projects

Closures was one of the Innovators' Challenge Projects.  It's been
inactive for years.

Detroit never got off the ground.

A consequence of withdrawing sponsorship  is that the Project may be
dissolved. [c]

Votes are due by COB 29 Aug 2024.

Only current Compiler Group Members [a] are eligible to vote on this
motion.  Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [b].

-- Jon

[1]: https://openjdk.org/census#closures
[2]: https://openjdk.org/census#detroit
[a]: https://openjdk.org/census#compiler
[b]: https://openjdk.org/bylaws#lazy-consensus
[c]: https://openjdk.org/bylaws#sponsor





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240815/76a5567b/attachment.htm>

From duke at openjdk.org  Fri Aug 16 01:05:21 2024
From: duke at openjdk.org (toshiogata)
Date: Fri, 16 Aug 2024 01:05:21 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2]
In-Reply-To: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
Message-ID: <Rn-623kjMe33v6MUddsetZ_eZmVPDPPtN901QKVnG4A=.fe0a79ab-3c8c-4b5b-9a56-5789321fbf62@github.com>

> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
> Testing: modified tests

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

  Move jtreg tags and expand wildcard imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20475/files
  - new: https://git.openjdk.org/jdk/pull/20475/files/4f973c70..9b30df12

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

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

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

From duke at openjdk.org  Fri Aug 16 01:05:22 2024
From: duke at openjdk.org (toshiogata)
Date: Fri, 16 Aug 2024 01:05:22 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2]
In-Reply-To: <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
Message-ID: <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>

On Wed, 14 Aug 2024 23:43:14 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move jtreg tags and expand wildcard imports
>
> test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1:
> 
>> 1: /*
> 
> since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import?

As you mentioned, it's a good time to make a minor improvement, so I modified the test.

> test/langtools/tools/javac/warnings/Serial/Serial.java line 1:
> 
>> 1: /*
> 
> move jtreg tags below imports and add copyrights

The copyright has been intentionally omitted as explained in https://bugs.openjdk.org/browse/JDK-8258525
I moved the jtreg tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719166472
PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719166674

From aivanov at openjdk.org  Fri Aug 16 11:42:48 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Aug 2024 11:42:48 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2]
In-Reply-To: <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
Message-ID: <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>

On Fri, 16 Aug 2024 01:01:52 GMT, toshiogata <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/generics/parametricException/ParametricException.java line 1:
>> 
>>> 1: /*
>> 
>> since you're renaming this file for jtreg testing anyway could you move the jtreg tags down below the imports and expand the wildcard import?
>
> As you mentioned, it's a good time to make a minor improvement, so I modified the test.

I propose not to edit the renamed files.

First of all, the purpose of this PR is to *rename tests* to workaround a _misfeature_ of jtreg.

Git does not support renames natively, therefore by editing the renamed files you could break Git ability to detect renaming.

Additionally, these tests are not part of client and I am not aware of the practices in Java Compiler team. Expanding wildcard imports should be fine, yet I would rather avoid editing the renamed files as I mentioned above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1719731264

From aivanov at openjdk.org  Fri Aug 16 11:45:48 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 16 Aug 2024 11:45:48 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2]
In-Reply-To: <Rn-623kjMe33v6MUddsetZ_eZmVPDPPtN901QKVnG4A=.fe0a79ab-3c8c-4b5b-9a56-5789321fbf62@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <Rn-623kjMe33v6MUddsetZ_eZmVPDPPtN901QKVnG4A=.fe0a79ab-3c8c-4b5b-9a56-5789321fbf62@github.com>
Message-ID: <wWyKHnukDETD6PbCKKz_vv98CMTbXPz3myRf_7wKmeI=.f1f48b95-c2bd-48f8-82bc-fbebee2bba69@github.com>

On Fri, 16 Aug 2024 01:05:21 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move jtreg tags and expand wildcard imports

I suggest not to edit the files and only *rename them* as it was in the first iteration of the review.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2242537764

From liach at openjdk.org  Fri Aug 16 15:28:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:28:03 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Missed JLS prefix from web review
 - More bad terms and redundancy
 - Fix terminology
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

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

Changes: https://git.openjdk.org/jdk/pull/20247/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=10
  Stats: 374 lines in 20 files changed: 131 ins; 114 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Fri Aug 16 15:28:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:28:03 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
Message-ID: <DxjT4RbKeot_mRG0QaXsaV8vAMEs5DrKdn-nn2ZkX3k=.35205e14-18b7-47ae-b5cf-9d062f40b69b@github.com>

On Tue, 13 Aug 2024 19:56:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed JLS prefix from web review

Swallowed the 2 conflicts from #20513: The tags are already correct in this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2293712126

From asotona at openjdk.org  Fri Aug 16 15:44:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 16 Aug 2024 15:44:51 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
Message-ID: <p-MYukNHMpJWWbfq-l9kgtBADyMGmP2WVoY9iAH45jU=.e0367801-f143-4a0d-b8c7-9005cd988bd0@github.com>

On Fri, 16 Aug 2024 15:28:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Missed JLS prefix from web review
>  - More bad terms and redundancy
>  - Fix terminology
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2243000645

From liach at openjdk.org  Fri Aug 16 15:52:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:52:09 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
Message-ID: <yHfD4ZEt1V_KlwziM_MKMB6FwUMDCpa4q4M8GUl4IKc=.3a143031-ccb4-4146-ba0b-d97c64107b76@github.com>

On Fri, 16 Aug 2024 15:28:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Missed JLS prefix from web review
>  - More bad terms and redundancy
>  - Fix terminology
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2293747699

From liach at openjdk.org  Fri Aug 16 15:52:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:52:09 GMT
Subject: Integrated: 8336754: Remodel TypeAnnotation to "has" instead of "be"
 an Annotation
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <RDK7N3d2Q1upLL1wGWV4Vk3qTY-9WcEoBXT0DK_MWpE=.e8a265c8-2fe2-4112-a00d-427bd2944396@github.com>

On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

This pull request has now been integrated.

Changeset: 961e944f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/961e944fa731dc84be2764c01e4b326187474605
Stats:     374 lines in 20 files changed: 131 ins; 114 del; 129 mod

8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

Co-authored-by: Alex Buckley <abuckley at openjdk.org>
Reviewed-by: asotona

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

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

From jonathan.gibbons at oracle.com  Fri Aug 16 20:39:52 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 16 Aug 2024 13:39:52 -0700
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
Message-ID: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>

I propose that the Compiler Group withdraw Sponsorship of the
Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.

All three projects have been completed successfully and the results
integrated into the mainline JDK repositories.

A consequence of withdrawing sponsorship is that the Project may be
dissolved. [c]

Votes are due by COB 30 Aug 2024.

Only current Compiler Group Members [a] are eligible to vote on this
motion.? Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [b].

-- Jon

[1]: https://openjdk.org/census#lambda
[2]: https://openjdk.org/census#tiered-attrib
[3]: https://openjdk.org/census#type-annotations
[a]: https://openjdk.org/census#compiler
[b]: https://openjdk.org/bylaws#lazy-consensus
[c]: https://openjdk.org/bylaws#sponsor



From joe.darcy at oracle.com  Fri Aug 16 20:47:30 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 16 Aug 2024 13:47:30 -0700
Subject: CFV: Withdraw sponsorship of Closures and Detroit Projects
In-Reply-To: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
References: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
Message-ID: <c4fcbbdc-1ced-4a69-afa4-998ac5c613ea@oracle.com>

Vote yes to the withdrawal of Sponsorship.

-Joe

On 8/15/2024 2:38 PM, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the long 
> inactive
> Closures [1] and Detroit [2] Projects
>
> Closures was one of the Innovators' Challenge Projects.? It's been 
> inactive for years.
>
> Detroit never got off the ground.
>
> A consequence of withdrawing sponsorship? is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 29 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#closures
> [2]: https://openjdk.org/census#detroit
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>
>
>
>

From joe.darcy at oracle.com  Fri Aug 16 20:48:19 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 16 Aug 2024 13:48:19 -0700
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
Message-ID: <8fb9a20b-0509-42be-917e-383e8b1e382b@oracle.com>

Vote yes to the withdrawal of Sponsorship.

-Joe

On 8/16/2024 1:39 PM, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the
> Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.
>
> All three projects have been completed successfully and the results
> integrated into the mainline JDK repositories.
>
> A consequence of withdrawing sponsorship is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 30 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#lambda
> [2]: https://openjdk.org/census#tiered-attrib
> [3]: https://openjdk.org/census#type-annotations
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>

From maurizio.cimadamore at oracle.com  Fri Aug 16 21:07:34 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 16 Aug 2024 22:07:34 +0100
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
Message-ID: <11366291-5f46-4f7c-b13f-1dd1086822f8@oracle.com>

Vote: yes

Maurizio

On 16/08/2024 21:39, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the
> Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.
>
> All three projects have been completed successfully and the results
> integrated into the mainline JDK repositories.
>
> A consequence of withdrawing sponsorship is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 30 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#lambda
> [2]: https://openjdk.org/census#tiered-attrib
> [3]: https://openjdk.org/census#type-annotations
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>

From maurizio.cimadamore at oracle.com  Fri Aug 16 21:07:52 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 16 Aug 2024 22:07:52 +0100
Subject: CFV: Withdraw sponsorship of Closures and Detroit Projects
In-Reply-To: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
References: <85a72a81-9f9e-41a5-b07f-bc68057b7daa@oracle.com>
Message-ID: <086c2d2a-494c-40d6-96ca-7b0790a9dcb0@oracle.com>

Vote: yes

Maurizio

On 15/08/2024 22:38, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the long 
> inactive
> Closures [1] and Detroit [2] Projects
>
> Closures was one of the Innovators' Challenge Projects.? It's been 
> inactive for years.
>
> Detroit never got off the ground.
>
> A consequence of withdrawing sponsorship? is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 29 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#closures
> [2]: https://openjdk.org/census#detroit
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>
>
>
>

From iris.clark at oracle.com  Fri Aug 16 22:43:30 2024
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 16 Aug 2024 22:43:30 +0000
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
Message-ID: <SJ2PR10MB7617C92A8D56460DB05184F6FB812@SJ2PR10MB7617.namprd10.prod.outlook.com>

Vote: yes

Iris

________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Friday, August 16, 2024 1:39 PM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type Annotations Projects

I propose that the Compiler Group withdraw Sponsorship of the
Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.

All three projects have been completed successfully and the results
integrated into the mainline JDK repositories.

A consequence of withdrawing sponsorship is that the Project may be
dissolved. [c]

Votes are due by COB 30 Aug 2024.

Only current Compiler Group Members [a] are eligible to vote on this
motion.  Votes must be cast in the open by replying to this mailing
list.

For Lazy Consensus voting instructions, see [b].

-- Jon

[1]: https://openjdk.org/census#lambda
[2]: https://openjdk.org/census#tiered-attrib
[3]: https://openjdk.org/census#type-annotations
[a]: https://openjdk.org/census#compiler
[b]: https://openjdk.org/bylaws#lazy-consensus
[c]: https://openjdk.org/bylaws#sponsor


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240816/1f36bf02/attachment.htm>

From duke at openjdk.org  Mon Aug 19 01:28:20 2024
From: duke at openjdk.org (toshiogata)
Date: Mon, 19 Aug 2024 01:28:20 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
Message-ID: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>

> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
> Testing: modified tests

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

  Revert "Move jtreg tags and expand wildcard imports"
  
  This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20475/files
  - new: https://git.openjdk.org/jdk/pull/20475/files/9b30df12..b1b2b5fe

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

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

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

From duke at openjdk.org  Mon Aug 19 01:39:54 2024
From: duke at openjdk.org (toshiogata)
Date: Mon, 19 Aug 2024 01:39:54 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
 <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
Message-ID: <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>

On Fri, 16 Aug 2024 11:40:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> As you mentioned, it's a good time to make a minor improvement, so I modified the test.
>
> I propose not to edit the renamed files.
> 
> First of all, the purpose of this PR is to *rename tests* to workaround a _misfeature_ of jtreg.
> 
> Git does not support renames natively, therefore by editing the renamed files you could break Git ability to detect renaming.
> 
> Additionally, these tests are not part of client and I am not aware of the practices in Java Compiler team. Expanding wildcard imports should be fine, yet I would rather avoid editing the renamed files as I mentioned above.

Thank you for pointing it out. I was not aware of the git rename issue.
I changed the fix to only rename files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721122162

From duke at openjdk.org  Mon Aug 19 01:39:55 2024
From: duke at openjdk.org (toshiogata)
Date: Mon, 19 Aug 2024 01:39:55 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
Message-ID: <cRWv3PksCSqmjSb_HFzz5N59vfN-6HNnifandp7yTHU=.1b04e987-1331-422b-88c3-b3e65617d806@github.com>

On Fri, 16 Aug 2024 01:02:17 GMT, toshiogata <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/warnings/Serial/Serial.java line 1:
>> 
>>> 1: /*
>> 
>> move jtreg tags below imports and add copyrights
>
> The copyright has been intentionally omitted as explained in https://bugs.openjdk.org/browse/JDK-8258525
> I moved the jtreg tag.

For the reason aivanov-jdk commented, I would like to only rename files in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721122202

From duke at openjdk.org  Mon Aug 19 01:52:54 2024
From: duke at openjdk.org (toshiogata)
Date: Mon, 19 Aug 2024 01:52:54 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v2]
In-Reply-To: <wWyKHnukDETD6PbCKKz_vv98CMTbXPz3myRf_7wKmeI=.f1f48b95-c2bd-48f8-82bc-fbebee2bba69@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <Rn-623kjMe33v6MUddsetZ_eZmVPDPPtN901QKVnG4A=.fe0a79ab-3c8c-4b5b-9a56-5789321fbf62@github.com>
 <wWyKHnukDETD6PbCKKz_vv98CMTbXPz3myRf_7wKmeI=.f1f48b95-c2bd-48f8-82bc-fbebee2bba69@github.com>
Message-ID: <ue0ymW76IyVo0GbIWlJ5gUYNWinTzGLBQ4gdFryHoII=.99f5f4b6-6dc1-4413-8725-347e9a6e43a1@github.com>

On Fri, 16 Aug 2024 11:43:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move jtreg tags and expand wildcard imports
>
> I suggest not to edit the files and only *rename them* as it was in the first iteration of the review.

@aivanov-jdk 
I agree with you. I changed the fix to only rename files.

@alisenchung 
As aivanov-jdk commented, I would like to hold off on implementing your suggestion for refactoring in this PR. Please check the disucssion.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2295519130

From jlahoda at openjdk.org  Mon Aug 19 07:35:50 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 19 Aug 2024 07:35:50 GMT
Subject: RFR: 8324859: Improve error recovery
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <RS6h0TQV1lgtH9NNLXvI4ZuI--DV3u30vt0TXdTtcLg=.9ab1aa43-faf0-4ebd-8ab5-554d09202aad@github.com>

On Mon, 8 Jul 2024 10:03:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

FWIW, this is a comparison of errors produced by javac from JDK 17 (`javac-17`) and javac with this patch (`javac-patched`), for a set of inputs:

$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
        return true;
    }
    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
TestB.java:6: error: class, interface, enum, or record expected
    public static boolean test2() {
                  ^
TestB.java:8: error: class, interface, enum, or record expected
    }
    ^
3 errors
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace

    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
1 error
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
1 error
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
TestB.java:5: error: class, interface, enum, or record expected
}
^
2 errors
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test(String,
}
class T {}
$ javac-17 TestB.java
TestB.java:3: error: <identifier> expected
    public static boolean test(String,
                                     ^
TestB.java:4: error: illegal start of type
}
^
2 errors
$ javac-patched TestB.java
TestB.java:3: error: <identifier> expected
    public static boolean test(String,
                                     ^
TestB.java:4: error: illegal start of type
}
^
2 errors



$ cat TestB.java
package tests;
public class TestB {
    private Object testMethod(final String arg1 final String arg2) {
        return null;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ',', ')', or '[' expected
    private Object testMethod(final String arg1 final String arg2) {
                                               ^
TestB.java:3: error: ';' expected
    private Object testMethod(final String arg1 final String arg2) {
                                                                 ^
2 errors
$ javac-patched TestB.java
TestB.java:3: error: ',', ')', or '[' expected
    private Object testMethod(final String arg1 final String arg2) {
                                               ^
TestB.java:3: error: ';' expected
    private Object testMethod(final String arg1 final String arg2) {
                                                                 ^
2 errors



$ cat TestB.java
package tests;
public @interface A {
    public String value() default ""
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public String value() default ""
                                    ^
1 error
$ javac-patched TestB.java
TestB.java:3: error: ';' expected
    public String value() default ""
                                    ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
        String s = "";
        return s.isEmpty();
    }
    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
TestB.java:5: error: illegal start of type
        return s.isEmpty();
        ^
TestB.java:5: error: <identifier> expected
        return s.isEmpty();
                        ^
TestB.java:7: error: class, interface, enum, or record expected
    public static boolean test2() {
                  ^
TestB.java:9: error: class, interface, enum, or record expected
    }
    ^
5 errors
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
    String s = ""; //field declaration
    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
1 error
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
        final String s = "";
        return s.isEmpty();
    }
    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
TestB.java:5: error: illegal start of type
        return s.isEmpty();
        ^
TestB.java:5: error: <identifier> expected
        return s.isEmpty();
                        ^
TestB.java:7: error: class, interface, enum, or record expected
    public static boolean test2() {
                  ^
TestB.java:9: error: class, interface, enum, or record expected
    }
    ^
5 errors
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error



$ cat TestB.java
package tests;
public class TestB {
    public static boolean test() // missing open brace
    final String s = ""; //field declaration?
    public static boolean test2() {
        return true;
    }
}
$ javac-17 TestB.java
TestB.java:3: error: ';' expected
    public static boolean test() // missing open brace
                                ^
1 error
$ javac-patched TestB.java
TestB.java:3: error: '{' or ';' expected
    public static boolean test() // missing open brace
                                ^
1 error

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

PR Comment: https://git.openjdk.org/jdk/pull/20070#issuecomment-2295861894

From mcimadamore at openjdk.org  Mon Aug 19 09:43:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 19 Aug 2024 09:43:51 GMT
Subject: RFR: 8324859: Improve error recovery
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <hk0H9Uj1GSQsEuI-lQafeloPzlZ84wcwYJtOO4gZqb4=.40207f3a-2bd0-45f8-8969-11c4db040d00@github.com>

On Mon, 8 Jul 2024 10:03:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 5046:

> 5044:                                 //the opening and closing braces:
> 5045:                                 int braceBalance = 1;
> 5046:                                 VirtualScanner virtualScanner = new VirtualScanner(S);

This seems a new pattern - in other case we use the lookahead method. I don't object to this, as much as note that we now seem to use different styles to lookahead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20070#discussion_r1721501185

From mcimadamore at openjdk.org  Mon Aug 19 09:46:50 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 19 Aug 2024 09:46:50 GMT
Subject: RFR: 8324859: Improve error recovery
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <ZB8OW_ITBXDLTk_8qmDicz3mI8CVj0D0btIesms031s=.b1fe1e18-34a7-4e38-8e29-89497bad8ae9@github.com>

On Mon, 8 Jul 2024 10:03:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 5037:

> 5035:                         parseAsBlock = false;
> 5036:                     } else {
> 5037:                         parseAsBlock = switch (token.kind) {

can we move this "complex" recovery code in a separate method and put a comment in there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20070#discussion_r1721504899

From aivanov at openjdk.org  Mon Aug 19 12:37:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Aug 2024 12:37:12 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
 <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
 <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>
Message-ID: <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com>

On Mon, 19 Aug 2024 01:37:36 GMT, toshiogata <duke at openjdk.org> wrote:

> Thank you for pointing it out. I was not aware of the git rename issue.

Even if it were not for this Git ?limitation?, I still think additional changes should be requested by Java Compiler team. I am not aware of their practices.

@alisenchung knows I'm advocating for expanding imports (whenever a test or source file is modified) and for moving jtreg tags below imports closer to the class declaration. At the same time, we haven't reached an agreement about it, although some people seem to support it too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1721718761

From aivanov at openjdk.org  Mon Aug 19 12:40:51 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 Aug 2024 12:40:51 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <v1LCcXB5kNPx6jyXclvi6s9axjM6cquDQogOtbr8Igc=.1d9edbdb-8895-4a14-a191-1370dd2679a9@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

Looks good to me.

Someone from the compiler team has to approve it too.

All the changes look good, however, only one test, `URLDragTest.java`, is from the *client* area.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2245438992

From mistria at redhat.com  Mon Aug 19 16:02:36 2024
From: mistria at redhat.com (Mickael Istria)
Date: Mon, 19 Aug 2024 18:02:36 +0200
Subject: Javac not trying to recover unresolved parameterized types
Message-ID: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>

Hi all,

As part of our work to allow Eclipse JDT to use Javac as backend, we
noticed that in case of unresolved parameterized types, the compiler
doesn't generate a nice recovered TypeSymbol with interesting data (such as
the name) that can be used later.
For example, my latest issue is that code like
```
class K {
  Regular reg;
  Parameterized<Object> par;
}
```
where neither Regular nor Parameterized exist, make Javac produce a
"recovered" symbol for `Regular` (at least the ErrorTypr stores the
"Regular" name) when asking for the tsym of `reg` VarSymbol, while it
doesn't produce anything useful for `Parameterized` when asking for the
tsym of `par` VarSymbol. In this later case, the symbol points to `noType`
which isn't usable by the IDE to generate a minimal DOM object.

In comparison, ECJ generates a recovered type binding for `Parameterized`,
which can be later used by some refactorings as if the type were existing.
Such refactorings that work with ECJ backend cannot work with the Javac
backend because of the symbol being unusable.

We're currently adding a bunch of workarounds in many places to handle this
case, but we'd obviously rather prefer if Javac can come with such
smartness out of the box.

So this behavior in Javac seems to me like a small issue or limitation in
Javac. What do you think? Is this "problem" already known? Should this be
reported as a bug? Does it make sense to expect Javac to provide such
recovery for parameterized types to? Should we try to fix it?...

Thanks in advance for you guidance
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240819/fee08e43/attachment.htm>

From prappo at openjdk.org  Tue Aug 20 09:10:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 20 Aug 2024 09:10:56 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: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@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

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:

> 93: 
> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.

I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

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

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

From jlahoda at openjdk.org  Tue Aug 20 10:54:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Aug 2024 10:54:28 GMT
Subject: RFR: 8324859: Improve error recovery [v2]
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <uRtFWN86wi_1xFchuxZFLGob8QomkOOAi9E_g81ZXWo=.0b912aaf-4835-4038-8b41-16c03204854f@github.com>

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

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

  Reflecting feedback - separating the estimation logic into a separate method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20070/files
  - new: https://git.openjdk.org/jdk/pull/20070/files/e30722f0..158e6803

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

  Stats: 130 lines in 1 file changed: 78 ins; 51 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20070/head:pull/20070

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

From mcimadamore at openjdk.org  Tue Aug 20 11:03:49 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Aug 2024 11:03:49 GMT
Subject: RFR: 8324859: Improve error recovery [v2]
In-Reply-To: <uRtFWN86wi_1xFchuxZFLGob8QomkOOAi9E_g81ZXWo=.0b912aaf-4835-4038-8b41-16c03204854f@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
 <uRtFWN86wi_1xFchuxZFLGob8QomkOOAi9E_g81ZXWo=.0b912aaf-4835-4038-8b41-16c03204854f@github.com>
Message-ID: <fWnHsfStfvWS5aKtZOtAIKf1XTVo_Vz9KItFehKm1-g=.a79d6411-3a0e-4c0d-98e5-4f1848cf837a@github.com>

On Tue, 20 Aug 2024 10:54:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package tests;
>> public class TestB {
>>     public static boolean test() // <--- missing open brace
>>         return true;
>>     }
>>     public static boolean test2() {
>>         return true;
>>     }
>> }
>> 
>> 
>> In JDK 17, it used to produce 3 compile-time errors:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>>     public static boolean test2() {
>>                   ^
>> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>>     }
>>     ^
>> 3 errors
>> 
>> 
>> Currently, it produces 4:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>>     public static boolean test2() {
>>                   ^
>>   (use --enable-preview to enable implicitly declared classes)
>> /tmp/TestB.java:9: error: class, interface, enum, or record expected
>> }
>> ^
>> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
>> package tests;
>> ^
>> 4 errors
>> 
>> 
>> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
>> 
>> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
>> 
>> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
>> 
>> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
>> - if it is an opening brace, parse the follow up as a block
>> - if it is a statement keyword (like `if`), parse the follow up as a block,
>> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting feedback - separating the estimation logic into a separate method.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 5056:

> 5054:      *
> 5055:      * The estimate is as follows:
> 5056:      * - tokens are skipped until member, statement of identifier is found,

Suggestion:

     * - tokens are skipped until member, statement or identifier is found,

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

PR Review: https://git.openjdk.org/jdk/pull/20070#pullrequestreview-2247681148
PR Review Comment: https://git.openjdk.org/jdk/pull/20070#discussion_r1723120811

From jlahoda at openjdk.org  Tue Aug 20 13:55:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 20 Aug 2024 13:55:18 GMT
Subject: RFR: 8324859: Improve error recovery [v3]
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <j7O48pZlsKMQVq3bTbv2gednQKNYj_vvRZMHxifmcbA=.742eb977-ecf0-4309-b654-92f9a8791a04@github.com>

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Merge branch 'master' into JDK-8324859
 - Reflecting feedback - separating the estimation logic into a separate method.
 - More cases.
 - Improving error message for attributes with default value.
 - Handling another testcase.
 - Merge branch 'master' into JDK-8324859
 - Tweaking the error recovery.
 - 8324859: Improve error recovery

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

Changes: https://git.openjdk.org/jdk/pull/20070/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20070&range=02
  Stats: 623 lines in 2 files changed: 619 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20070/head:pull/20070

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

From vicente.romero at oracle.com  Tue Aug 20 14:03:51 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 20 Aug 2024 10:03:51 -0400
Subject: Javac not trying to recover unresolved parameterized types
In-Reply-To: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
References: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
Message-ID: <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>

Hi,

I think this is probably more a feature request than a bug but in any 
case please file an issue and assign it to myself,

Thanks,
Vicente

On 8/19/24 12:02, Mickael Istria wrote:
> Hi all,
>
> As part of our work to allow Eclipse JDT to use Javac as backend, we 
> noticed that in case of unresolved parameterized types, the compiler 
> doesn't generate a nice recovered TypeSymbol with interesting data 
> (such as the name) that can be used later.
> For example, my latest issue is that code like
> ```
> class K {
> ? Regular reg;
> ? Parameterized<Object> par;
> }
> ```
> where neither Regular nor Parameterized exist, make Javac produce a 
> "recovered" symbol for `Regular` (at least the ErrorTypr stores the 
> "Regular" name) when asking for the tsym of `reg` VarSymbol, while it 
> doesn't produce anything useful for `Parameterized` when asking for 
> the tsym of `par` VarSymbol. In this later case, the symbol points to 
> `noType` which isn't usable by the IDE to generate a minimal DOM object.
>
> In comparison, ECJ generates a recovered type binding for 
> `Parameterized`, which can be later used by some refactorings as if 
> the type were existing. Such refactorings that work with ECJ backend 
> cannot work with the Javac backend because of the symbol being unusable.
>
> We're currently adding a bunch of workarounds in many places to handle 
> this case, but we'd obviously rather prefer if Javac can come with 
> such smartness out of the box.
>
> So this behavior in Javac seems to me like a small issue or limitation 
> in Javac. What do you think? Is this "problem" already known? Should 
> this be reported as a bug? Does it make sense to expect Javac to 
> provide such recovery for parameterized types to? Should we try to fix 
> it?...
>
> Thanks in advance for you guidance
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240820/caa67a8c/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue Aug 20 14:29:58 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Aug 2024 14:29:58 GMT
Subject: RFR: 8324859: Improve error recovery [v3]
In-Reply-To: <j7O48pZlsKMQVq3bTbv2gednQKNYj_vvRZMHxifmcbA=.742eb977-ecf0-4309-b654-92f9a8791a04@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
 <j7O48pZlsKMQVq3bTbv2gednQKNYj_vvRZMHxifmcbA=.742eb977-ecf0-4309-b654-92f9a8791a04@github.com>
Message-ID: <6q0bhAJ04io2vtBhW00mKkkamLVdOfPaIDzL_F49qoQ=.ca3f08b8-dde4-422c-b197-b53a7ebf9da6@github.com>

On Tue, 20 Aug 2024 13:55:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package tests;
>> public class TestB {
>>     public static boolean test() // <--- missing open brace
>>         return true;
>>     }
>>     public static boolean test2() {
>>         return true;
>>     }
>> }
>> 
>> 
>> In JDK 17, it used to produce 3 compile-time errors:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>>     public static boolean test2() {
>>                   ^
>> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>>     }
>>     ^
>> 3 errors
>> 
>> 
>> Currently, it produces 4:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>>     public static boolean test2() {
>>                   ^
>>   (use --enable-preview to enable implicitly declared classes)
>> /tmp/TestB.java:9: error: class, interface, enum, or record expected
>> }
>> ^
>> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
>> package tests;
>> ^
>> 4 errors
>> 
>> 
>> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
>> 
>> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
>> 
>> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
>> 
>> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
>> - if it is an opening brace, parse the follow up as a block
>> - if it is a statement keyword (like `if`), parse the follow up as a block,
>> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the...
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8324859
>  - Reflecting feedback - separating the estimation logic into a separate method.
>  - More cases.
>  - Improving error message for attributes with default value.
>  - Handling another testcase.
>  - Merge branch 'master' into JDK-8324859
>  - Tweaking the error recovery.
>  - 8324859: Improve error recovery

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20070#pullrequestreview-2248180312

From mistria at redhat.com  Tue Aug 20 14:40:12 2024
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 20 Aug 2024 16:40:12 +0200
Subject: Javac not trying to recover unresolved parameterized types
In-Reply-To: <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>
References: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
 <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>
Message-ID: <CAFr6BZShM39W0dfvORehoDPPcuWwww8dugddnB_qZx6+4cfCjA@mail.gmail.com>

OK, thank you.
Should I open such issue through https://bugreport.java.com/bugreport/ ? I
tried to submit an issue there about a month ago and didn't receive any
feedback at all (no confirmation, no followup...). Is this service still
the recommended one for such report or is there something else you
recommend?
Thanks in advance
Mickael

On Tue, Aug 20, 2024 at 4:04?PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> Hi,
>
> I think this is probably more a feature request than a bug but in any case
> please file an issue and assign it to myself,
>
> Thanks,
> Vicente
>
> On 8/19/24 12:02, Mickael Istria wrote:
>
> Hi all,
>
> As part of our work to allow Eclipse JDT to use Javac as backend, we
> noticed that in case of unresolved parameterized types, the compiler
> doesn't generate a nice recovered TypeSymbol with interesting data (such as
> the name) that can be used later.
> For example, my latest issue is that code like
> ```
> class K {
>   Regular reg;
>   Parameterized<Object> par;
> }
> ```
> where neither Regular nor Parameterized exist, make Javac produce a
> "recovered" symbol for `Regular` (at least the ErrorTypr stores the
> "Regular" name) when asking for the tsym of `reg` VarSymbol, while it
> doesn't produce anything useful for `Parameterized` when asking for the
> tsym of `par` VarSymbol. In this later case, the symbol points to `noType`
> which isn't usable by the IDE to generate a minimal DOM object.
>
> In comparison, ECJ generates a recovered type binding for `Parameterized`,
> which can be later used by some refactorings as if the type were existing.
> Such refactorings that work with ECJ backend cannot work with the Javac
> backend because of the symbol being unusable.
>
> We're currently adding a bunch of workarounds in many places to handle
> this case, but we'd obviously rather prefer if Javac can come with such
> smartness out of the box.
>
> So this behavior in Javac seems to me like a small issue or limitation in
> Javac. What do you think? Is this "problem" already known? Should this be
> reported as a bug? Does it make sense to expect Javac to provide such
> recovery for parameterized types to? Should we try to fix it?...
>
> Thanks in advance for you guidance
> --
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
> <https://developers.redhat.com/>
>
>
>

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
<https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240820/1e7ef5ba/attachment.htm>

From jan.lahoda at oracle.com  Tue Aug 20 15:17:28 2024
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 20 Aug 2024 17:17:28 +0200
Subject: Javac not trying to recover unresolved parameterized types
In-Reply-To: <CAFr6BZShM39W0dfvORehoDPPcuWwww8dugddnB_qZx6+4cfCjA@mail.gmail.com>
References: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
 <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>
 <CAFr6BZShM39W0dfvORehoDPPcuWwww8dugddnB_qZx6+4cfCjA@mail.gmail.com>
Message-ID: <e01c998c-86f6-41b5-b45d-aaae24e6b600@oracle.com>

Hello,


I''ve filled:
https://bugs.openjdk.org/browse/JDK-8338678


Thanks,

 ??? Jan


On 20. 08. 24 16:40, Mickael Istria wrote:
> OK, thank you.
> Should I open such issue through https://bugreport.java.com/bugreport/ 
> ? I tried to submit an issue there about a month ago and didn't 
> receive any feedback at all (no confirmation, no followup...). Is this 
> service still the recommended one for such report or is there 
> something else you recommend?
> Thanks in advance
> Mickael
>
> On Tue, Aug 20, 2024 at 4:04?PM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     Hi,
>
>     I think this is probably more a feature request than a bug but in
>     any case please file an issue and assign it to myself,
>
>     Thanks,
>     Vicente
>
>     On 8/19/24 12:02, Mickael Istria wrote:
>>     Hi all,
>>
>>     As part of our work to allow Eclipse JDT to use Javac as backend,
>>     we noticed that in case of unresolved parameterized types, the
>>     compiler doesn't generate a nice recovered TypeSymbol with
>>     interesting data (such as the name) that can be used later.
>>     For example, my latest issue is that code like
>>     ```
>>     class K {
>>     ? Regular reg;
>>     ? Parameterized<Object> par;
>>     }
>>     ```
>>     where neither Regular nor Parameterized exist, make Javac produce
>>     a "recovered" symbol for `Regular` (at least the ErrorTypr stores
>>     the "Regular" name) when asking for the tsym of `reg` VarSymbol,
>>     while it doesn't produce anything useful for `Parameterized` when
>>     asking for the tsym of `par` VarSymbol. In this later case, the
>>     symbol points to `noType` which isn't usable by the IDE to
>>     generate a minimal DOM object.
>>
>>     In comparison, ECJ generates a recovered type binding for
>>     `Parameterized`, which can be later used by some refactorings as
>>     if the type were existing. Such refactorings that work with ECJ
>>     backend cannot work with the Javac backend because of the symbol
>>     being unusable.
>>
>>     We're currently adding a bunch of workarounds in many places to
>>     handle this case, but we'd obviously rather prefer if Javac can
>>     come with such smartness out of the box.
>>
>>     So this behavior in Javac seems to me like a small issue or
>>     limitation in Javac. What do you think? Is this "problem" already
>>     known? Should this be reported as a bug? Does it make sense to
>>     expect Javac to provide such recovery for parameterized types to?
>>     Should we try to fix it?...
>>
>>     Thanks in advance for you guidance
>>     -- 
>>     Mickael Istria
>>     Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for
>>     Red Hat <https://developers.redhat.com/>
>
>
>
> -- 
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
> Hat <https://developers.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240820/68ce8366/attachment-0001.htm>

From naoto at openjdk.org  Tue Aug 20 15:30:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Aug 2024 15:30:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
Message-ID: <9wZvcGjRkpfRm02paHISi86ynU0aYrW9WoinmyIb-RM=.9795a780-b857-4de3-bca6-075305fbd9f7@github.com>

On Tue, 20 Aug 2024 09:07:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:
> 
>> 93: 
>> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
>> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.
> 
> I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

Good catch, Pavel. It is indeed a bug. This type of overtranslation l10n bug happens all the time, and hard to catch.

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

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

From mistria at redhat.com  Tue Aug 20 16:29:08 2024
From: mistria at redhat.com (Mickael Istria)
Date: Tue, 20 Aug 2024 18:29:08 +0200
Subject: Javac not trying to recover unresolved parameterized types
In-Reply-To: <e01c998c-86f6-41b5-b45d-aaae24e6b600@oracle.com>
References: <CAFr6BZRu5aKr0CghbW7feB6tgSy8p_2Gzee0m8YGYGMYjT9erg@mail.gmail.com>
 <224c3b42-ed82-4be1-82cb-d146a382eaa1@oracle.com>
 <CAFr6BZShM39W0dfvORehoDPPcuWwww8dugddnB_qZx6+4cfCjA@mail.gmail.com>
 <e01c998c-86f6-41b5-b45d-aaae24e6b600@oracle.com>
Message-ID: <CAFr6BZRBni2skeM0UcvvjYb6bAKQSqFSAEWT5cN4O_aSMNZc0g@mail.gmail.com>

On Tue, Aug 20, 2024 at 5:17?PM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> I''ve filled:
> https://bugs.openjdk.org/browse/JDK-8338678
>

Thank you very much!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240820/434d0f11/attachment.htm>

From vicente.romero at oracle.com  Wed Aug 21 13:12:10 2024
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 21 Aug 2024 09:12:10 -0400
Subject: CFV: Withdraw sponsorship of Lambda, Tiered Attribution, and Type
 Annotations Projects
In-Reply-To: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
References: <068290f4-8564-48b9-be38-886cecbfd753@oracle.com>
Message-ID: <b1f385ae-1aea-41dd-bd73-6e8142e7470b@oracle.com>

vote: yes

Vicente

On 8/16/24 16:39, Jonathan Gibbons wrote:
> I propose that the Compiler Group withdraw Sponsorship of the
> Lambda [1], Tiered Attribution [2], and Type Annotation [3] Projects.
>
> All three projects have been completed successfully and the results
> integrated into the mainline JDK repositories.
>
> A consequence of withdrawing sponsorship is that the Project may be
> dissolved. [c]
>
> Votes are due by COB 30 Aug 2024.
>
> Only current Compiler Group Members [a] are eligible to vote on this
> motion.? Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [b].
>
> -- Jon
>
> [1]: https://openjdk.org/census#lambda
> [2]: https://openjdk.org/census#tiered-attrib
> [3]: https://openjdk.org/census#type-annotations
> [a]: https://openjdk.org/census#compiler
> [b]: https://openjdk.org/bylaws#lazy-consensus
> [c]: https://openjdk.org/bylaws#sponsor
>
>


From eirbjo at gmail.com  Wed Aug 21 13:35:55 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Wed, 21 Aug 2024 15:35:55 +0200
Subject: Compilation fails on Windows when a sibling file name contains
 illegal char":"
Message-ID: <CA+pBWhuni4gKEx_eKDbMF9fcgqT2wTw7oFQRutb8wwn0PZszkw@mail.gmail.com>

Consider the following scenario where a valid Java source file is compiled
in a directory containing a sibling file with a colon in its file name:

Z:\>dir /B
file:txt
HelloWorld.java

Compilation fails as follows:

Z:\>javac HelloWorld.java
HelloWorld.java:1: error: cannot access unnamed package
public class HelloWorld {
^
  error accessing directory
Z:\invalid-pathjava.nio.file.InvalidPathException: Illegal char <:> at
index 4: file:txt
1 error
printing javac parameters to: Z:\invalid-path\javac.20240821_151610.args

The "error accessing directory" message seems to have been introduced in
JDK-8177332.

The root exception seems to be thrown in WindowsPathParser.normalize.

Questions:

o Is this kind of failure expected according to the JLS and/or common sense?
o If yes, would it be worthwhile to improve the error reporting?  "Cannot
access unnamed package" is not super helpful, "error accessing directory"
is also somewhat vague.
o At the very least, should we add a space in the IOException message
thrown by DirectoryContainer.list, to separate the file path from
the InvalidPathException toString?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240821/523d75e7/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Wed Aug 21 22:57:45 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 21 Aug 2024 15:57:45 -0700
Subject: Compilation fails on Windows when a sibling file name contains
 illegal char":"
In-Reply-To: <CA+pBWhuni4gKEx_eKDbMF9fcgqT2wTw7oFQRutb8wwn0PZszkw@mail.gmail.com>
References: <CA+pBWhuni4gKEx_eKDbMF9fcgqT2wTw7oFQRutb8wwn0PZszkw@mail.gmail.com>
Message-ID: <1883c719-f460-47c2-9f5d-60a2f582a1e2@oracle.com>


On 8/21/24 6:35 AM, Eirik Bj?rsn?s wrote:
>
> Consider the following scenario where a valid Java source file is 
> compiled in a directory containing a sibling file with a colon in its 
> file name:
>
> Z:\>dir /B
> file:txt
> HelloWorld.java
>
> Compilation fails as follows:
>
> Z:\>javac HelloWorld.java
> HelloWorld.java:1: error: cannot access unnamed package
> public class HelloWorld {
> ^
> ? error accessing directory 
> Z:\invalid-pathjava.nio.file.InvalidPathException: Illegal char <:> at 
> index 4: file:txt
> 1 error
> printing javac parameters to: Z:\invalid-path\javac.20240821_151610.args
>
> The "error accessing directory" message seems to have been introduced 
> in JDK-8177332.
>
> The root exception seems to be thrown in WindowsPathParser.normalize.
>
> Questions:
>
> o Is this kind of failure expected according to the JLS and/or common 
> sense?

The JLS says very little about the host system that may be used to 
compile a program.
As for common sense, maybe, but maybe not. It is effectively impossible 
to anticipate all the quirks of all the file systems that may be 
encountered while compiling a program. That being said, it is arguable 
that `javac` should ignore any files that are not the well-formed 
filename of a valid Java class.


> o If yes, would it be worthwhile to improve the error reporting?? 
> "Cannot access unnamed package" is not super helpful, "error accessing 
> directory" is also somewhat?vague.
Well, you did get a very helpful and very specific error message .... 
`Illegal char <:> at index 4: file:txt`


> o At the very least, should we add a space in the IOException message 
> thrown by?DirectoryContainer.list, to separate the file path from 
> the?InvalidPathException toString?

Yes.


>
> Cheers,
> Eirik.

From eirbjo at gmail.com  Thu Aug 22 08:30:13 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Thu, 22 Aug 2024 10:30:13 +0200
Subject: Compilation fails on Windows when a sibling file name contains
 illegal char":"
In-Reply-To: <1883c719-f460-47c2-9f5d-60a2f582a1e2@oracle.com>
References: <CA+pBWhuni4gKEx_eKDbMF9fcgqT2wTw7oFQRutb8wwn0PZszkw@mail.gmail.com>
 <1883c719-f460-47c2-9f5d-60a2f582a1e2@oracle.com>
Message-ID: <CA+pBWhu001byrQ=5qdczZASe44K1C0oEHyBJU9ycQd1E1y=arw@mail.gmail.com>

On Thu, Aug 22, 2024 at 12:58?AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

As for common sense, maybe, but maybe not. It is effectively impossible
> to anticipate all the quirks of all the file systems that may be
> encountered while compiling a program. That being said, it is arguable
> that `javac` should ignore any files that are not the well-formed
> filename of a valid Java class.
>

Thanks Jonathan. I did wonder a bit why the file scanning was including all
file types in this context. (fileKinds includes
JavaFileObject.Kind.OTHER).


> > o If yes, would it be worthwhile to improve the error reporting?
> > "Cannot access unnamed package" is not super helpful, "error accessing
> > directory" is also somewhat vague.
> Well, you did get a very helpful and very specific error message ....
> `Illegal char <:> at index 4: file:txt`
>

Yes, that last part was indeed helpful in diagnosing the problem at the
implementation level.

While this is probably unlikely to happen in any properly organized,
version controlled code base, experimental code using JEP-330 might be more
likely to stumble upon it. This was what happened to me when I discovered
this while using "java HelloWorld.java" in some scratch directory
containing some oddly named, partially downloaded files.


> > o At the very least, should we add a space in the IOException message
> > thrown by DirectoryContainer.list, to separate the file path from
> > the InvalidPathException toString?
>

I filed JDK-8338815 to track this trivial enhancement, and will follow up
with a PR shortly.

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240822/cfadae55/attachment.htm>

From eirbjo at openjdk.org  Thu Aug 22 08:36:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 22 Aug 2024 08:36:13 GMT
Subject: RFR: 8338815: Add separation to exception message in
 JavacFileManager.DirectoryContainer
Message-ID: <pJ1L0oIu6pvlMgtcBGXtSuWF7QlAIYJ3jy_DOHHAR7s=.daa5c44e-a877-4ea7-a886-3683e849a41b@github.com>

Please review this trivial PR which injects a `": "` separator between the directory name and the exeption toString when constructing the IOException message in `JavacFileManager.DirectoryContainer.list`.

This changes the javac error message from:

`error accessing directory Z:\invalid-pathjava.nio.file.InvalidPathException: Illegal char <:> at index 4: file:txt`

into:

`error accessing directory Z:\invalid-path: java.nio.file.InvalidPathException: Illegal char <:> at index 4: file:txt`

We could alternatively use some other separator, such as a `", "`.

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

Commit messages:
 - Add separation between directory name and InvalidPathException toString in DirectoryContainer.list

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

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

From prappo at openjdk.org  Thu Aug 22 16:17:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Aug 2024 16:17:14 GMT
Subject: RFR: 8338834: Remove unused import declarations in java.compiler
Message-ID: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>

Please review this simple cleanup. I tested it first by usual means, and then additionally compared documentation before and after the change.

How did I end up with this cleanup? I finally got tired of an eyesore which greyed-out unused imports in my IDE are. So I removed them as per IDE suggestion and then had some fun chasing bugs. Who would've thought that removing imports can be so painful?

During my bug chase, I created the following issues, from which you could guess the kind of bugs I ran into:

  * https://youtrack.jetbrains.com/issue/IDEA-358082/Import-of-a-symbol-referred-to-by-snippet-target-is-considered-unused
  * https://youtrack.jetbrains.com/issue/IDEA-358073/Support-changes-in-documentation-inheritance
  * https://bugs.openjdk.org/browse/JDK-8338833

And a bonus one:

  * https://bugs.openjdk.org/browse/JDK-8338838

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20679/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338834
  Stats: 56 lines in 29 files changed: 0 ins; 46 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20679/head:pull/20679

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

From darcy at openjdk.org  Thu Aug 22 16:34:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Aug 2024 16:34:03 GMT
Subject: RFR: 8338834: Remove unused import declarations in java.compiler
In-Reply-To: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
References: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
Message-ID: <6TBw5NYWSbEA4Z09_YqhV4JxMofRPOu_NxhWWbCBwew=.c6d4b16f-a799-4adf-aeb8-fddac2b9a583@github.com>

On Thu, 22 Aug 2024 16:12:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple cleanup. I tested it first by usual means, and then additionally compared documentation before and after the change.
> 
> How did I end up with this cleanup? I finally got tired of an eyesore which greyed-out unused imports in my IDE are. So I removed them as per IDE suggestion and then had some fun chasing bugs. Who would've thought that removing imports can be so painful?
> 
> During my bug chase, I created the following issues, from which you could guess the kind of bugs I ran into:
> 
>   * https://youtrack.jetbrains.com/issue/IDEA-358082/Import-of-a-symbol-referred-to-by-snippet-target-is-considered-unused
>   * https://youtrack.jetbrains.com/issue/IDEA-358073/Support-changes-in-documentation-inheritance
>   * https://bugs.openjdk.org/browse/JDK-8338833
> 
> And a bonus one:
> 
>   * https://bugs.openjdk.org/browse/JDK-8338838

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20679#pullrequestreview-2255130651

From prappo at openjdk.org  Thu Aug 22 17:35:45 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Aug 2024 17:35:45 GMT
Subject: RFR: 8338834: Remove unused import declarations in java.compiler
 [v2]
In-Reply-To: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
References: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
Message-ID: <uR-Ml2o5jVuxwkapKwVZKX2rkGP9ChLC105YcXd4OVg=.af6fcdaa-d59b-4b2a-b7f5-d9d37f15df8d@github.com>

> Please review this simple cleanup. I tested it first by usual means, and then additionally compared documentation before and after the change.
> 
> How did I end up with this cleanup? I finally got tired of an eyesore which greyed-out unused imports in my IDE are. So I removed them as per IDE suggestion and then had some fun chasing bugs. Who would've thought that removing imports can be so painful?
> 
> During my bug chase, I created the following issues, from which you could guess the kind of bugs I ran into:
> 
>   * https://youtrack.jetbrains.com/issue/IDEA-358082/Import-of-a-symbol-referred-to-by-snippet-target-is-considered-unused
>   * https://youtrack.jetbrains.com/issue/IDEA-358073/Support-changes-in-documentation-inheritance
>   * https://bugs.openjdk.org/browse/JDK-8338833
> 
> And a bonus one:
> 
>   * https://bugs.openjdk.org/browse/JDK-8338838

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 two additional commits since the last revision:

 - Merge branch 'master' into 8338834
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20679/files
  - new: https://git.openjdk.org/jdk/pull/20679/files/fb3397fe..05f3e0cf

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

  Stats: 4348 lines in 110 files changed: 3005 ins; 651 del; 692 mod
  Patch: https://git.openjdk.org/jdk/pull/20679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20679/head:pull/20679

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

From darcy at openjdk.org  Thu Aug 22 20:20:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Aug 2024 20:20:30 GMT
Subject: RFR: 8337715: Update --release 23 symbol information for JDK 23 build
 37
Message-ID: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>

JDK-8337824 fixed in b36 made a change visible in the symbol files; no further changes in b37.

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

Commit messages:
 - JDK-8337715: Update --release 23 symbol information for JDK 23 build 37

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

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

From iris at openjdk.org  Thu Aug 22 20:42:02 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 22 Aug 2024 20:42:02 GMT
Subject: RFR: 8337715: Update --release 23 symbol information for JDK 23
 build 37
In-Reply-To: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
References: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
Message-ID: <WLe3Q7n94fjjM3Yybre5-iIGKOkQovddUE9IKj5zX8Q=.b1e7cc7c-2c0f-400d-90ca-2a6c64787775@github.com>

On Thu, 22 Aug 2024 20:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8337824 fixed in b36 made a change visible in the symbol files; no further changes in b37.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20685#pullrequestreview-2255612017

From duke at openjdk.org  Thu Aug 22 21:45:11 2024
From: duke at openjdk.org (duke)
Date: Thu, 22 Aug 2024 21:45:11 GMT
Subject: Withdrawn: 8334870: javac does not accept classfiles with certain
 permitted RuntimeVisibleParameterAnnotations and
 RuntimeInvisibleParameterAnnotations attributes.
In-Reply-To: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
References: <hwBrS7kvOhOUHtQgmzdNtNdDqUX0Vue66R1A9PMEG74=.634ae479-90f1-46d9-a3bb-fac055cb85c0@github.com>
Message-ID: <nYtNa1PKBwTUGizvsJ8eZpoHhO3NlfSY_tWAFdOfwtE=.f82e3ff0-56d9-4582-8490-eb278649c88a@github.com>

On Mon, 24 Jun 2024 15:06:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> JVMS 4.7.18 and 4.7.19 say this about the entries in the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes:
> 
>> The i'th entry in the parameter_annotations table may, but is not required to, correspond to the i'th parameter descriptor in the method descriptor (?4.3.3).
> 
> When reading classfiles, javac does not follow this specification (which puts no requirements on the number of entries in the attributes), but rather expects as many entries as the `MethodSymbol.type` has (which is either based in the `Signature` attribute, if present, or the method descritor, if `Signature` is not present).
> 
> This patch proposes to adjust javac to accept the attributes with any number of entries, implementing a number of heuristics to map the content of the entries in the attributes to the parameters. There are comments in the code explaining the heuristics.
> 
> javac will ignore the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes it cannot handle with a warning.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Fri Aug 23 02:28:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Aug 2024 02:28:12 GMT
Subject: RFR: 8337715: Update --release 23 symbol information for JDK 23
 build 37
In-Reply-To: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
References: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
Message-ID: <qCv81UndlnYgFDTZFsqSpM0bSLzz_-8dxlWXX23YlMQ=.8ffc881c-205f-40c8-b568-0dc4ff6236a9@github.com>

On Thu, 22 Aug 2024 20:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8337824 fixed in b36 made a change visible in the symbol files; no further changes in b37.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20685#pullrequestreview-2256118917

From prappo at openjdk.org  Fri Aug 23 08:08:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Aug 2024 08:08:06 GMT
Subject: Integrated: 8338834: Remove unused import declarations in
 java.compiler
In-Reply-To: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
References: <45oTPSh8Vk69dIz4oCxVVhwzVsnKlhpsjsDVQkcDm6o=.3bced3e6-9fb5-4c41-a592-f1dc8f2b05b2@github.com>
Message-ID: <6Y0XpSM78rnmW9TO3nnhbheLQtu_EoQDhqyDvJsWwRw=.b02e9314-43fd-4a1a-a58b-c9f764b3ba61@github.com>

On Thu, 22 Aug 2024 16:12:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple cleanup. I tested it first by usual means, and then additionally compared documentation before and after the change.
> 
> How did I end up with this cleanup? I finally got tired of an eyesore which greyed-out unused imports in my IDE are. So I removed them as per IDE suggestion and then had some fun chasing bugs. Who would've thought that removing imports can be so painful?
> 
> During my bug chase, I created the following issues, from which you could guess the kind of bugs I ran into:
> 
>   * https://youtrack.jetbrains.com/issue/IDEA-358082/Import-of-a-symbol-referred-to-by-snippet-target-is-considered-unused
>   * https://youtrack.jetbrains.com/issue/IDEA-358073/Support-changes-in-documentation-inheritance
>   * https://bugs.openjdk.org/browse/JDK-8338833
> 
> And a bonus one:
> 
>   * https://bugs.openjdk.org/browse/JDK-8338838

This pull request has now been integrated.

Changeset: a5e28005
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5e28005fa95426f811e1ed98a7d726cbdbe196d
Stats:     56 lines in 29 files changed: 0 ins; 46 del; 10 mod

8338834: Remove unused import declarations in java.compiler

Reviewed-by: darcy

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

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

From prr at openjdk.org  Fri Aug 23 18:28:07 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 23 Aug 2024 18:28:07 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <Ra6jYmLwnPhWMJeTtiZurfuIWFjWq65jcmMB-2gZMgA=.42447e8c-10a8-42f4-9933-e015a3c353ee@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

Some one else should decide bout the langtools changes but for the AWT one I agree the minimal rename is all we need here to solve the specific problem which has nothing to do with the test itself.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20475#pullrequestreview-2257847981

From darcy at openjdk.org  Fri Aug 23 20:04:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Aug 2024 20:04:09 GMT
Subject: Integrated: 8337715: Update --release 23 symbol information for JDK 23
 build 37
In-Reply-To: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
References: <fFS-_uj5GE_HIGlPLy6S216lNt_vet55ODHBoNrx5pA=.4d8023d8-08e1-4347-9b33-87b7960c81e4@github.com>
Message-ID: <GAJUUXOF2CIBx085oIee2-W9SiLdTaC9G8w6gk5ICcA=.e450c7ca-fe42-420b-beb9-09edaa785436@github.com>

On Thu, 22 Aug 2024 20:15:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> JDK-8337824 fixed in b36 made a change visible in the symbol files; no further changes in b37.

This pull request has now been integrated.

Changeset: 5d12ac3f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d12ac3fcb076bf701d7a572942f57f4de7a9ca0
Stats:     12 lines in 1 file changed: 0 ins; 12 del; 0 mod

8337715: Update --release 23 symbol information for JDK 23 build 37

Reviewed-by: iris, liach

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

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

From jjg at openjdk.org  Fri Aug 23 22:17:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Aug 2024 22:17:04 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
 <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
 <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>
 <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com>
Message-ID: <Hc2wcnI9clPcuTWcr3KkxEFq1EFIPnkdaUO0dazvNKQ=.744e78cd-230e-4725-955c-c2569aa89981@github.com>

On Mon, 19 Aug 2024 12:34:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Thank you for pointing it out. I was not aware of the git rename issue.
>> I changed the fix to only rename files.
>
>> Thank you for pointing it out. I was not aware of the git rename issue.
> 
> Even if it were not for this Git ?limitation?, I still think additional changes should be requested by Java Compiler team. I am not aware of their practices.
> 
> @alisenchung knows I'm advocating for expanding imports (whenever a test or source file is modified) and for moving jtreg tags below imports closer to the class declaration. At the same time, we haven't reached an agreement about it, although some people seem to support it too.

With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any of the source code that comprises the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1729563721

From jjg at openjdk.org  Fri Aug 23 22:34:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Aug 2024 22:34:04 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
Message-ID: <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>

On Mon, 19 Aug 2024 01:28:20 GMT, toshiogata <duke at openjdk.org> wrote:

>> Rename the tests to prevent unexpected deletion of result files when `-retain` jtreg option is specified.
>> Testing: modified tests
>
> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Move jtreg tags and expand wildcard imports"
>   
>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.

Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package.

Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier.

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2307886982

From jjg at openjdk.org  Fri Aug 23 22:39:03 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 23 Aug 2024 22:39:03 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
Message-ID: <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>

On Fri, 23 Aug 2024 22:31:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> toshiogata has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Move jtreg tags and expand wildcard imports"
>>   
>>   This reverts commit 9b30df1230b7e31b42e63ae01ef1549565bcc078.
>
> Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package.
> 
> Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier.

> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?
> 
> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.
> 
> In the meantime, renaming the files to avoid the problem is the recommended solution.

Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2307890897

From duke at openjdk.org  Fri Aug 23 23:53:13 2024
From: duke at openjdk.org (duke)
Date: Fri, 23 Aug 2024 23:53:13 GMT
Subject: Withdrawn: 8334248: Invalid error for early construction local class
 constructor method reference
In-Reply-To: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
Message-ID: <OY7EHDNA7GICP7J0supTxA55QRfFbJzkcy3JFMxWMeY=.4c149c5f-ec84-4a5f-afe2-6693bcef8c49@github.com>

On Wed, 26 Jun 2024 11:17:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via `new`, or, indirectly, via `super`. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what *should* happen, in the various cases.
> 
> #### Member inner classes
> 
> Whenever we see `new M()` where `M` is a member inner class, we need to infer an expression for `M`?s enclosing instance, given none is provided. This inference problem is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking new `M()`.
> 
> This inference process should look at *all* the enclosing instances available to us, and pick the innermost enclosing instance of type `C` such that:
> * `C.this` is accessible (e.g. not in `C`?s early construction context) and;
> * `C` is a subclass of `M`?s enclosing class.
> 
> The crucial observation here is that there can be **multiple** valid enclosing instances, and the innermost one might not be available due to early construction context, so we need to be able to skip that, and jump to the next. See the test `EarlyIndirectOuterCapture`, which fails to compile today, but is accepted with the fixes in this PR.
> 
> This check is defined in `Reslve::findSelfContaining`.
> 
> #### Local and anonymous inner classes
> 
> When creating local and anonymous inner classes, we should **not** check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this. What matters, for local and anon classes, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.
> 
> This check is defined in `Reslve::findLocalClassOwner`.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sat Aug 24 03:08:13 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 03:08:13 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>

On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I've been trying to work with classfile api, and:
- `AttributesProcessingOption` is unused, does nothing?
- Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as `JAVA_1_VERSION` exist in `java.lang.classfile.ClassFile`.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308012254

From liach at openjdk.org  Sat Aug 24 03:49:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 03:49:07 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
Message-ID: <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>

On Sat, 24 Aug 2024 03:05:14 GMT, xxDark <duke at openjdk.org> wrote:

> Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as `JAVA_1_VERSION` exist in `java.lang.classfile.ClassFile`.

Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, for release N, we will not support correct parsing or writing of preview class files from N-1, N-2, etc.

While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):
https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/hotspot/share/classfile/classFileParser.cpp#L2332-L2334
Nor by the JVMS: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.7.3

And as such, it falls out of the [goals](https://openjdk.org/jeps/466#Goals) of the API, and is likely not going to be added. You most likely will resort to a third party library to handle such frozen format, as the main issue ClassFile API is solving is that a library built against JDK 21 may not run on JDK 23 unless it bumps its ASM dependency to support reading JDK 23 Class File format, which doesn't exist for the said oak format.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308036118

From duke at openjdk.org  Sat Aug 24 04:07:02 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 04:07:02 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
 <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>
Message-ID: <8mR8hNkY-JGoTiHFXQ3o9JO53s4lPc9_c0vEW_5IXgo=.bac37181-9774-4a50-b3ab-1f1e4f7e8d13@github.com>

On Sat, 24 Aug 2024 03:45:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):
> 
> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/hotspot/share/classfile/classFileParser.cpp#L2332-L2334

Interesting. I guess handling of oak classfiles was removed a long time ago by [this](https://github.com/openjdk/jdk17u-dev/commit/eedc99c9ab2647f0233e4899a2976eb6f3095319) commit.
But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

java -cp . Test
Hello, World

jdk-1.8.0_402\bin\java -cp . Test
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.ClassFormatError: Invalid code attribute name index 10 in class file Test
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308042111

From liach at openjdk.org  Sat Aug 24 04:59:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 04:59:07 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>

On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I think so. See https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039795.html for some context. There are also historical evaluations available at https://bugs.openjdk.org/browse/JDK-8232890 and https://bugs.openjdk.org/browse/JDK-8232967, notably the judgement in Compatibility Risk Description:

> Class files with versions < 45.3 predate Java.

> But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

It appears so. See note in `ClassFileFormatVersion`: https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java#L413-L414
It seems that now major version 45, regardless of the minor version, is simply seen as the Class File format for Java 1.1.

> Also now, [this](https://github.com/Col-E/CAFED00D) library which took special care to parse oak files reports wrong instructions does not parse classfile at all.

Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.

> `jdk-1.8.0_402\bin\java -cp . Test`
> `Hello World`

For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308099862

From duke at openjdk.org  Sat Aug 24 05:07:03 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 05:07:03 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
Message-ID: <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>

On Sat, 24 Aug 2024 04:56:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> 
> Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.
> 
I don't think at this point in time there would be any change in the format of any existing attributes, as that would be a binary incompatible change.
But yes, having a way to override parsing of builtin attributes would be nice.

> For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

I don't think that many projects use pre-Java 1 format at this point. While I saw some libraries that kept their version set to versions like Java 4 for no apparent reason... Hey, at least it's not Java 1 version.
If Hotspot now parses these files incorrectly, it might be worth to just throw `UnsupportedClassVersionError` for oak class files?

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308102351

From duke at openjdk.org  Sat Aug 24 06:46:08 2024
From: duke at openjdk.org (Matt)
Date: Sat, 24 Aug 2024 06:46:08 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <R4codYRoyxsreqAWoonXwPQWZMCg-PSngjNrH3gdW9g=.185e4e51-fc1c-45b5-8ac0-7a30d6a410f8@github.com>

On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

> Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, **for release N, we will not support correct _parsing_ or writing of preview class files from N-1, N-2, etc.**

I understand that there is no explicit goal for this API to be used for general purposes, but it seems really odd that I cannot safely assume that classes that are successfully loaded in the current runtime will be parsable. Oak classes are a notable exception, and nobody should realistically expect to see an oak class ever. However, if we only can guarantee that the current class file version will be supported and not even N-1 then no application/library expecting reliability _(without constant recompilation to ensure the class versions are current)_ should use the API.

Again, its not a goal per-say but it seems really disappointing and odd.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308154137

From liach at openjdk.org  Sat Aug 24 13:56:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 13:56:04 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
 <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
Message-ID: <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>

On Sat, 24 Aug 2024 05:03:33 GMT, xxDark <duke at openjdk.org> wrote:

> If Hotspot now parses these files incorrectly, it might be worth to just throw `UnsupportedClassVersionError` for oak class files?

This would be an important decision; I would wait till Monday when more engineers are back to discuss about the histroy of dropping support for such files, why this format never made its way to the JVMS, and the correct way to handle so as to avoid inconsistency between different versions.

> Edit: I missed the word `preview` in the quote. Does this only apply to *preview* class file features?

Yes, Class-File API is supposed to handle whatever the VM handles. It's actually considered a "JVM API" in Oracle's documentations: https://docs.oracle.com/en/java/javase/22/vm/class-file-api.html

OpenJDK's preview version policy allows shipping the preview features for testing to a wider audience without any implied burden of long-term maintenance. So for example, if the Nullable Types JEP preview adds `~` as a null marker in `Signature` attribute but changes it to `?` in a subsequent preview, the JVM and core libraries will act as if a previous iteration with `~` marker never existed; the policy is similar to that for preview libraries.

Unfortunately, there seems to be some misunderstanding around the role of preview, so some are asking if preview features that is largely unchanged and finalized in a future release can become finalized in an LTS as well. Short answer, no: it's an experiment format enabled by the new 6-month release schedule.

And note that javap uses ClassFile API, and as a result, javap for release N cannot correctly decompile Class Files with version N-1.65535, etc. We are planning to decompile on a best-effort basis, that we try to interpret such as class as if it's N.65535 (maybe emit a warning), trying to salvage the most out of the Class File and printing errors (but continue to output) if we encounter anything we don't expect.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308402818

From duke at openjdk.org  Mon Aug 26 01:11:16 2024
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Mon, 26 Aug 2024 01:11:16 GMT
Subject: RFR: 8333427: langtools/tools/javac/newlines/NewLineTest.java is
 failing on Japanese Windows
In-Reply-To: <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.c2063e9a-1648-4763-8a5f-f3e145b88672@github.com>
References: <LJWe8A-pcFYqtdqVupsKrjNJM9jL2uKUOJ8rI-Eaeog=.df639556-1e88-41f4-9f87-12ca432f6617@github.com>
 <dZNiJNVW2-JR7nOWHitCCaAmF2KJEQCBkwv5D3_2JQw=.a3eb0b03-e287-4434-bc61-f2f7c06bc99c@github.com>
 <ThW0-XhNZcWXBxBeaTUu_zonbyNvLG8JkByOVVZsxbA=.d6d5a990-73a2-4ab6-9299-1457bd90551e@github.com>
 <k0tWoEFM1nkI7QLZdJ1dGTD6uJycdgcn9iJySa9bT0w=.c2063e9a-1648-4763-8a5f-f3e145b88672@github.com>
Message-ID: <hmHnm50cvSN1m8mwLwv7acgPT0B1FCuTQ0bqEg0fBaM=.3572beb3-06f9-4236-b976-1a7c9039c03a@github.com>

On Tue, 6 Aug 2024 09:12:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @jaikiran 
>> I'm looking forward to your comments.
>
> Hello @tkiriyama, sorry I hadn't paid attention to this PR. I will take a look soon.

Hello @jaikiran,
This is just a friendly reminder. How is the task going?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19519#discussion_r1730493382

From duke at openjdk.org  Mon Aug 26 07:38:04 2024
From: duke at openjdk.org (toshiogata)
Date: Mon, 26 Aug 2024 07:38:04 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <hw2ar_bTsYWoUYRwApfmTSdoaWSRZz25mbs6-uU4iP8=.c2c3aa48-96ac-4d41-a413-9dc83556e6f2@github.com>
 <pCVdEUx0veIrZOzWK6Q-v9mfX98I_mirvqrOPybayyE=.53bdd20c-7723-4243-94e8-d52dcb3892ab@github.com>
 <UQeiy7wEZjrXxCuhOcOEssL1XKlTFAAwS2qUdzuvLBs=.13b82d2a-e074-46a3-8730-6ea18e8a43bf@github.com>
Message-ID: <Ls9zQKB2mvi8V-fdE8w1cJoaqajnu1CxKS4DlWzfNlI=.2babb995-750e-4382-bcf5-732e12f7c20f@github.com>

On Fri, 23 Aug 2024 22:36:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Moving files from one directory to another can sometimes be a bit risky, especially for `javac` tests, because that implies moving the classes from one unnamed package to a different unnamed package.
>> 
>> Please confirm that all tests under `test/langtools/tools/javac` continue to pass after the files have been moved. You can either run just those tests, or run all langtools `tier1` tests if that is easier.
>
>> > @jonathan-gibbons Is this a bug in jtreg, or where these files actually improperly named?
>> 
>> Not a bug as such, but maybe a little-known misfeature. `jtreg` has always had problems with filenames that could cause confusion, and the general sense has generally been, "if it hurts, don't do it!". That being said, our overall library API and infrastructure is way better these days than in times past, and it might be reasonable to file an Enhancement for `jtreg` to have a utility/check/test to detect these anomalous situations.
>> 
>> In the meantime, renaming the files to avoid the problem is the recommended solution.
> 
> Filed https://bugs.openjdk.org/browse/CODETOOLS-7903803

@jonathan-gibbons 
Thank you for your comment and filing jtreg enhancement.
I confirmed that all tests under langtools/tools/javac passed after renaming.


$ jtreg_7_4_1/jtreg/bin/jtreg -dir:jdk/test/langtools -retain:all -verbose:summary -ignore:quiet -exclude:jdk/test/langtools/ProblemList.txt -jdk:jdk-24+12 tools/javac
Directory "JTwork" not found: creating
Directory "JTreport" not found: creating
Passed: tools/javac/4241573/T4241573.java
Passed: tools/javac/4846262/CheckEBCDICLocaleTest.java

...

Passed: tools/javac/generics/odersky/Test3.java
Passed: tools/javac/generics/odersky/Test4.java
Passed: tools/javac/generics/parametricException/J.java
Passed: tools/javac/generics/parametricException/ParametricException.java
Passed: tools/javac/generics/rare/6665356/T6665356.java
Passed: tools/javac/generics/rare/Rare1.java

...

Passed: tools/javac/warnings/Serial/RecordExtern.java
Passed: tools/javac/warnings/Serial/RecordSerial.java
Passed: tools/javac/warnings/Serial/Serial.java
Passed: tools/javac/warnings/Serial/SerialMethodArity.java
Passed: tools/javac/warnings/Serial/SerialMethodMods.java

...

Passed: tools/javac/VersionOpt.java
Passed: tools/javac/VoidArray.java
Test results: passed: 3,869

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

PR Comment: https://git.openjdk.org/jdk/pull/20475#issuecomment-2309542735

From nbenalla at openjdk.org  Mon Aug 26 09:09:58 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 Aug 2024 09:09:58 GMT
Subject: RFR: 8337111: Add system wide checks to the generated documentation
Message-ID: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>

Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
More details are in the JBS issue

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

Commit messages:
 - Convert parts of doccheck into tests

Changes: https://git.openjdk.org/jdk/pull/20711/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20711&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337111
  Stats: 1944 lines in 13 files changed: 1943 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20711.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20711/head:pull/20711

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

From nbenalla at openjdk.org  Mon Aug 26 09:18:06 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 Aug 2024 09:18:06 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation
In-Reply-To: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
Message-ID: <DafyxI1a98qVL1cGezzsaNwxuoC0mLXe1uLZn7oZPL0=.c9653d1e-a657-4b7f-b50c-15f46dc0dc5c@github.com>

On Mon, 26 Aug 2024 09:00:28 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
> More details are in the JBS issues

Sorry for the title change.

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

PR Comment: https://git.openjdk.org/jdk/pull/20711#issuecomment-2309740959

From nbenalla at openjdk.org  Mon Aug 26 09:22:59 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 26 Aug 2024 09:22:59 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v2]
In-Reply-To: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
Message-ID: <BZa-fX2i-oB0WqJ26nS8IC8ya--gCGOtIoTmVe4z_LY=.81dd3f68-fdcd-4c56-b726-580b95bdd62e@github.com>

> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
> More details are in the JBS issues

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Fix path passed to the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20711/files
  - new: https://git.openjdk.org/jdk/pull/20711/files/1b49ed06..031c49bd

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

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

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

From jlahoda at openjdk.org  Mon Aug 26 14:28:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 Aug 2024 14:28:35 GMT
Subject: RFR: 8338678: Erroneous parameterized type represented as <any>
Message-ID: <em6AGvqN2EsB_L_j8Fpw64d1TNn8eaNy-JrXN5NhPXM=.4f73a574-854a-4eb8-b4af-c669b4d86cec@github.com>

Consider code like:

class C {
    Undefined u1;
    Undefined<UndefinedParam> u2;
}


The types of both `u1` and `u2` are erroneous, but the internal properties of the types are different. For `u1`, the erroneous type keeps the name (`Undefined`), while for `u2`, the type is simply `<any>`.

The proposal here is to improve the error recovery, and create a parameterized error type for the second case.

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

Commit messages:
 - 8338678: Erroneous parameterized type represented as <any>

Changes: https://git.openjdk.org/jdk/pull/20716/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20716&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338678
  Stats: 104 lines in 3 files changed: 98 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20716.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20716/head:pull/20716

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

From vromero at openjdk.org  Mon Aug 26 14:28:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 26 Aug 2024 14:28:35 GMT
Subject: RFR: 8338678: Erroneous parameterized type represented as <any>
In-Reply-To: <em6AGvqN2EsB_L_j8Fpw64d1TNn8eaNy-JrXN5NhPXM=.4f73a574-854a-4eb8-b4af-c669b4d86cec@github.com>
References: <em6AGvqN2EsB_L_j8Fpw64d1TNn8eaNy-JrXN5NhPXM=.4f73a574-854a-4eb8-b4af-c669b4d86cec@github.com>
Message-ID: <SJDPcPAiUoa4zOIbLmBseab6Z4Ef2Ae_D3-Vg_IGQXI=.ead24693-6489-4b2d-98fe-92cff316b4eb@github.com>

On Mon, 26 Aug 2024 14:20:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> class C {
>     Undefined u1;
>     Undefined<UndefinedParam> u2;
> }
> 
> 
> The types of both `u1` and `u2` are erroneous, but the internal properties of the types are different. For `u1`, the erroneous type keeps the name (`Undefined`), while for `u2`, the type is simply `<any>`.
> 
> The proposal here is to improve the error recovery, and create a parameterized error type for the second case.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20716#pullrequestreview-2260831475

From acobbs at openjdk.org  Mon Aug 26 15:04:10 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 26 Aug 2024 15:04:10 GMT
Subject: RFR: 8334248: Invalid error for early construction local class
 constructor method reference [v2]
In-Reply-To: <Q4-7pMlc7A0MvAB3UUUD3Sv6VCFrh5fBFSTH2yjKahI=.fbba12e1-ccb3-476d-a083-72adc3c4feff@github.com>
References: <udIpnsixbBqltZo7Cv0onXm-cjZRFBFojYBL7Zqg7uA=.27d62054-8ecd-4994-b1f7-6570a4a31ec4@github.com>
 <3bjw2SgNVcaTpxrnGXF2A4rwYukX1xxU0fNtAkGNDxA=.a22e05c5-0827-465a-bd26-9361273de134@github.com>
 <Q4-7pMlc7A0MvAB3UUUD3Sv6VCFrh5fBFSTH2yjKahI=.fbba12e1-ccb3-476d-a083-72adc3c4feff@github.com>
Message-ID: <9pcEL3rH_5fSEQZwk3B2-eTBeT9-uuBFozMWOPbe4q4=.4800233f-2898-43ec-a022-c7c2e9776da6@github.com>

On Wed, 26 Jun 2024 15:51:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test summary
>
> As the changes here change the space of compilable programs, it would be better to document these changes in a CSR.

@mcimadamore, this PR is still needed (i.e., the compiler is not following the current spec), right? Would it help for me to take a stab at drafting the CSR for you?

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

PR Comment: https://git.openjdk.org/jdk/pull/19904#issuecomment-2310430456

From liach at openjdk.org  Mon Aug 26 19:05:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 19:05:10 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
 <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
 <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>
Message-ID: <9nKJtghqH1bWDla1-rp0Jm02gsruqWloECon0HFUp1I=.06f67fe2-7459-49f3-baaf-41de31488eb6@github.com>

On Sat, 24 Aug 2024 13:53:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> If Hotspot now parses these files incorrectly, it might be worth to just throw UnsupportedClassVersionError for oak class files?

I was informed in offline discussion that this is unlikely to be changed and this change is unlikely to be backported unless for security purposes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2310872682

From jjg at openjdk.org  Mon Aug 26 20:34:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Aug 2024 20:34:04 GMT
Subject: RFR: 8337111: Bad HTML checker for generated documentation [v2]
In-Reply-To: <BZa-fX2i-oB0WqJ26nS8IC8ya--gCGOtIoTmVe4z_LY=.81dd3f68-fdcd-4c56-b726-580b95bdd62e@github.com>
References: <NaBCNIdwt7TrWl5yODTrQel0UVPo2YAXusz2m4DTbJA=.62704afd-a6c6-4ad0-b07c-f40444554de1@github.com>
 <BZa-fX2i-oB0WqJ26nS8IC8ya--gCGOtIoTmVe4z_LY=.81dd3f68-fdcd-4c56-b726-580b95bdd62e@github.com>
Message-ID: <u6LvIjKFLoss45jlEtBThWltxzCWizNd95V6rA4R9iU=.824a9996-c546-4c03-bbb8-0e149bb0834b@github.com>

On Mon, 26 Aug 2024 09:22:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I please get a review for this PR that adds 4 new html "Checkers" for the generated documentation.
>> More details are in the JBS issues
>> 
>> These tests were mostly inspired /converted from the existing [Doccheck](https://github.com/openjdk/doccheck).
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix path passed to the test

Good start!  Some suggestions inline

test/langtools/jdk/javadoc/doccheck/DocCheck.java line 43:

> 41: import java.util.concurrent.ExecutorService;
> 42: import java.util.concurrent.Executors;
> 43: import java.util.concurrent.Future;

It is often common practice to put Java SE and JDK imports first.

test/langtools/jdk/javadoc/doccheck/DocCheck.java line 56:

> 54:     @Before
> 55:     public void setUp() {
> 56:         Path root = Path.of(ROOT_PATH.getParent() + File.separator + "docs" + File.separator + System.getProperty("doccheck.dir"));

somewhat preferable to use `Path.resolve` instead of adding strings like this

test/langtools/jdk/javadoc/doccheck/DocCheck.java line 71:

> 69:                 BadCharacterChecker badChars = new BadCharacterChecker();
> 70:                 HtmlFileChecker docChecker = new HtmlFileChecker(new DocTypeChecker());
> 71:                 HtmlFileChecker htmlChecker = new HtmlFileChecker(new LinkChecker());

I suggest extracting these declarations into a method called something like `getCheckers()`
and then having two alternative methods to call them, called homelike like `runSerially(List<Checker> checkers)` and `runWithExecutor(List<Checker> checkers)`

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

PR Review: https://git.openjdk.org/jdk/pull/20711#pullrequestreview-2261580004
PR Review Comment: https://git.openjdk.org/jdk/pull/20711#discussion_r1731783076
PR Review Comment: https://git.openjdk.org/jdk/pull/20711#discussion_r1731784158
PR Review Comment: https://git.openjdk.org/jdk/pull/20711#discussion_r1731787106

From duke at openjdk.org  Mon Aug 26 21:50:33 2024
From: duke at openjdk.org (Evemose)
Date: Mon, 26 Aug 2024 21:50:33 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside the
 permits clause of the enclosing top-level class
Message-ID: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>

Fix is quite hacky, but this is best solution that i came up with without making invasive changes in other parts of jdk. Basically, I check if current symbol is symbol for tree inside of permits clause i na following way:

1. env.tree is JCTree.JCClassDecl;
2. Trees in extends and implements clauses are already not null
3. There is at least one tree with null sym in permits clause (main indicator that permits clause resolution is in process)

Not sure if this is a correct way to do it, hope more expirienced people out here could look into it more carefully.

DEV NOTE: Will add test a bit later

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

Commit messages:
 - fix permit clause

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

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

From duke at openjdk.org  Mon Aug 26 22:07:33 2024
From: duke at openjdk.org (Evemose)
Date: Mon, 26 Aug 2024 22:07:33 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
Message-ID: <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>

> Fix is quite hacky, but this is best solution that i came up with without making invasive changes in other parts of jdk. Basically, I check if current symbol is symbol for tree inside of permits clause i na following way:
> 
> 1. env.tree is JCTree.JCClassDecl;
> 2. Trees in extends and implements clauses are already not null
> 3. There is at least one tree with null sym in permits clause (main indicator that permits clause resolution is in process)
> 
> If all three of above are true, the requirment for symbol to be visible is to have sym.owner.outermostClass() == env.tree.sym.outermostClass()
> 
> Not sure if this is a correct way to do it, hope more expirienced people out here could look into it more carefully.
> 
> DEV NOTE: Will add test a bit later
> 
> DEV NOTE 2: I`m not sure if non immidiate private memebrs should also be available in permit clause (like private static class A in private static class B that is in sealed class C should be available in permits clause of C as well). If not, condition on owner of symbol should be tightened a bit

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

  allowed non-direct members to be permitted

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20718/files
  - new: https://git.openjdk.org/jdk/pull/20718/files/6df5e3f5..fd6e673d

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

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

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

From jlahoda at openjdk.org  Tue Aug 27 09:19:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 27 Aug 2024 09:19:02 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
Message-ID: <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>

On Mon, 26 Aug 2024 22:07:33 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix is quite hacky, but this is best solution that i came up with without making invasive changes in other parts of jdk. Basically, I check if current symbol is symbol for tree inside of permits clause i na following way:
>> 
>> 1. env.tree is JCTree.JCClassDecl;
>> 2. Trees in extends and implements clauses are already not null
>> 3. There is at least one tree with null sym in permits clause (main indicator that permits clause resolution is in process)
>> 
>> If all three of above are true, the requirment for symbol to be visible is to have sym.owner.outermostClass() == env.tree.sym.outermostClass()
>> 
>> Not sure if this is a correct way to do it, hope more expirienced people out here could look into it more carefully.
>> 
>> DEV NOTE: Will add test a bit later
>> 
>> DEV NOTE 2: I`m not sure if non immidiate private memebrs should also be available in permit clause (like private static class A in private static class B that is in sealed class C should be available in permits clause of C as well). If not, condition on owner of symbol should be tightened a bit
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allowed non-direct members to be permitted

Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).

I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2311992230

From duke at openjdk.org  Tue Aug 27 10:13:03 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 27 Aug 2024 10:13:03 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
 <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
Message-ID: <Af_eeV6_0vXR5CBcbW_1R3bcncJFPvbenxFxjW_YcTE=.dae8c224-b78b-4b8b-aba1-7643fa93e235@github.com>

On Tue, 27 Aug 2024 09:16:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).
> 
> I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.

Honestly, I agree with you, I just didnt know how much invasive changes to existing code could be. I will look into AttrContext later today

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2312111017

From aivanov at openjdk.org  Tue Aug 27 12:58:09 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 Aug 2024 12:58:09 GMT
Subject: RFR: 8337851: Some tests have name which confuse jtreg [v3]
In-Reply-To: <Hc2wcnI9clPcuTWcr3KkxEFq1EFIPnkdaUO0dazvNKQ=.744e78cd-230e-4725-955c-c2569aa89981@github.com>
References: <NglaDEADAHmN4v7TUvv7YxzZeFFawp9l96gFu2EWR3A=.f01b2a1b-ec59-4170-99bf-8d407bfdd03f@github.com>
 <9Ohvnc6MgnokscABDpbRhBYuXtjguHrcJd7eVRWSXYs=.cd938d32-de8b-4eb1-a601-421762f991f3@github.com>
 <QJxYoziy1I-reLexFIVm3QmAuuNS2nbORAqHL66p2Kc=.e604616f-31c2-4b16-bf3f-5ad45a40e686@github.com>
 <G6Ionzwifny03fp6nYvqmwTEnxs1e71AZ1-wVmz2WrU=.80f1eeb9-0850-4ae8-a54d-094668df9252@github.com>
 <p22z4EdyOjFd4N0BKDYEcv806a_wXV4VjxL8xBbc2mU=.7b61c522-ca36-49ea-a9ea-54f12875de9f@github.com>
 <-ua0I6lCxPPp57ELQTFMnMOS8pJP03pGxmGMaVMrJYI=.e87e09a5-6475-44b5-855c-b005fff2ad1c@github.com>
 <Hc2wcnI9clPcuTWcr3KkxEFq1EFIPnkdaUO0dazvNKQ=.744e78cd-230e-4725-955c-c2569aa89981@github.com>
Message-ID: <5m5fXgRoiwNZBV49deCIdmBxsGff6gOJ_Z99zr_Pyfc=.96edb6e6-231f-4771-8362-28131c46c613@github.com>

On Fri, 23 Aug 2024 22:14:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> With my official `jtreg` hat on, I recommend always placing the `jtreg` tags immediately after any legal header comments and _before_ any and all of the source code that comprises the test.

@jonathan-gibbons Are there any disadvantages to placing jtreg tags right before the test class declaration, after all the import statements? It is more convenient when viewing test code in IDE: the jtreg tags are clearly visible. If the tags are after the legal header, they're collapsed together with the legal header (and imports).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20475#discussion_r1732798992

From asotona at openjdk.org  Tue Aug 27 15:21:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Aug 2024 15:21:51 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v3]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <e_4h8d6qNH5LUzVDM60f8nUZBuE8hxQB6xmG4Y8OcEM=.a3ab6c1c-de25-4911-ae58-9761d0ae567b@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.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 four commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

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

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=02
  Stats: 713 lines in 165 files changed: 0 ins; 476 del; 237 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

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

From duke at openjdk.org  Wed Aug 28 09:36:22 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 28 Aug 2024 09:36:22 GMT
Subject: RFR: 8338981: Access to private classes should be permitted inside
 the permits clause of the enclosing top-level class [v2]
In-Reply-To: <Af_eeV6_0vXR5CBcbW_1R3bcncJFPvbenxFxjW_YcTE=.dae8c224-b78b-4b8b-aba1-7643fa93e235@github.com>
References: <6nPsNaZZqOAvLaSw0b2TZVGC2cXAZCtcAS1PByOz8kc=.c98d9dfa-2de3-4fad-af31-8b4043293cc7@github.com>
 <jyajDq5jER23e9_g54iUrzFKeZrRBItKzdBtcFClHdY=.98d31792-5d7e-42d6-ba0b-595176287f1c@github.com>
 <X8AWF1FKsHNNdPI0G1cJRcS67erfOcuYobP6Lji4lPs=.e55ed447-9452-415e-a5fc-df2cb051c90d@github.com>
 <Af_eeV6_0vXR5CBcbW_1R3bcncJFPvbenxFxjW_YcTE=.dae8c224-b78b-4b8b-aba1-7643fa93e235@github.com>
Message-ID: <3p-GZ30CERYgO0m0s2CxbQ67xbnspSybNpPSUdpcGmM=.fbbc3ddd-7f4a-4acf-9811-2455719f5369@github.com>

On Tue, 27 Aug 2024 10:10:31 GMT, Evemose <duke at openjdk.org> wrote:

> Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).
> 
> I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.

I have decided to write tests before reworking fix. Could you please suggest where could i put it? I have found tools/javac/diags/examples folder, but it seems to only contain negative tests, while I need positive ones. Is there any suitable place for this kind of thing?

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2314818883

From jlahoda at openjdk.org  Thu Aug 29 06:28:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 Aug 2024 06:28:25 GMT
Subject: Integrated: 8324859: Improve error recovery
In-Reply-To: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
References: <LwJ1Ka6btYugBNkbPv4mDVzPXcSqep1Pv6lokHvr-oc=.35c0de0d-e204-4970-bf87-22fdc6dec28d@github.com>
Message-ID: <e59nDeGdzNZkOU8RKOhOwYjpmLc8cUuMf37eQWN9n-0=.0de485db-9afe-4762-8fa1-3ea8219be1c4@github.com>

On Mon, 8 Jul 2024 10:03:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> package tests;
> public class TestB {
>     public static boolean test() // <--- missing open brace
>         return true;
>     }
>     public static boolean test2() {
>         return true;
>     }
> }
> 
> 
> In JDK 17, it used to produce 3 compile-time errors:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>     public static boolean test2() {
>                   ^
> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>     }
>     ^
> 3 errors
> 
> 
> Currently, it produces 4:
> 
> $ javac  /tmp/TestB.java 
> /tmp/TestB.java:3: error: ';' expected
>     public static boolean test() // <--- missing open brace
>                                 ^
> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>     public static boolean test2() {
>                   ^
>   (use --enable-preview to enable implicitly declared classes)
> /tmp/TestB.java:9: error: class, interface, enum, or record expected
> }
> ^
> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
> package tests;
> ^
> 4 errors
> 
> 
> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
> 
> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
> 
> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
> 
> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
> - if it is an opening brace, parse the follow up as a block
> - if it is a statement keyword (like `if`), parse the follow up as a block,
> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the file - if yes, parse the follow up as a block,
> - otherwise, try to speculatively parse the follow up - if it look...

This pull request has now been integrated.

Changeset: 0b4a7d53
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b4a7d534204b7b3b041f5117282dd13b1c7c62f
Stats:     623 lines in 2 files changed: 619 ins; 1 del; 3 mod

8324859: Improve error recovery

Reviewed-by: mcimadamore

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

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

From jlahoda at openjdk.org  Thu Aug 29 06:30:25 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 29 Aug 2024 06:30:25 GMT
Subject: Integrated: 8338678: Erroneous parameterized type represented as <any>
In-Reply-To: <em6AGvqN2EsB_L_j8Fpw64d1TNn8eaNy-JrXN5NhPXM=.4f73a574-854a-4eb8-b4af-c669b4d86cec@github.com>
References: <em6AGvqN2EsB_L_j8Fpw64d1TNn8eaNy-JrXN5NhPXM=.4f73a574-854a-4eb8-b4af-c669b4d86cec@github.com>
Message-ID: <98iS5VzynF_l5CjKtcQAQC0hHkMSRu8YdwooKIS0EMA=.0fd742fd-60d4-4320-8968-7e8a22d8c6f1@github.com>

On Mon, 26 Aug 2024 14:20:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> class C {
>     Undefined u1;
>     Undefined<UndefinedParam> u2;
> }
> 
> 
> The types of both `u1` and `u2` are erroneous, but the internal properties of the types are different. For `u1`, the erroneous type keeps the name (`Undefined`), while for `u2`, the type is simply `<any>`.
> 
> The proposal here is to improve the error recovery, and create a parameterized error type for the second case.

This pull request has now been integrated.

Changeset: ff59532d
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff59532ddd3002df61e46d58b3f29d26c78295da
Stats:     104 lines in 3 files changed: 98 ins; 4 del; 2 mod

8338678: Erroneous parameterized type represented as <any>

Reviewed-by: vromero

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

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

From vromero at openjdk.org  Thu Aug 29 12:51:21 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 29 Aug 2024 12:51:21 GMT
Subject: RFR: 8338301: Error recovery and reporting should be improved for
 erroneous implicitly declared classes
In-Reply-To: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
References: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
Message-ID: <Nz6-SXtX7CjK_VsFJQghoU0u8_c5MkuPT4Lh-wh6034=.c4c1ffa3-fabb-459a-8839-86a40c092313@github.com>

On Thu, 15 Aug 2024 08:41:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat /tmp/M.java 
> main() {}
> 
> 
> which is compiled like:
> 
> $ javac --enable-preview --source 24 /tmp/M.java 
> /tmp/M.java:1: error: class, interface, enum, or record expected
> main() {}
> ^
> 1 error
> 
> 
> This error is problematic for two reasons:
>  - this is clearly a method with missing return type, but the error recovery does not see it as such
>  - with implicitly declared classes, not only classes/interfaces/enum/records are expected here, but also methods and fields as permitted
> 
> Note that if a method inside a class is missing a return type, the error is much better, so this is a problem specifically for methods on the top-level:
> 
> $ cat /tmp/C.java
> public class C {
>     main() {}
> }
> $ javac --enable-preview --source 24 /tmp/C.java 
> /tmp/C.java:2: error: invalid method declaration; return type required
>     main() {}
>     ^
> 1 error
> 
> 
> The immediate reason is that the javac's parser will speculatively parse the code to see if the code looks-like a method or a field, but this speculative parse does not special-case methods without return types (unlike class-member parsing, which has this special case, partly because of constructors).
> 
> I tried to remove this speculative parsing, reusing the code to parse class members, but I wasn't successful in that, sadly.
> 
> So, the proposal here is three-fold:
>  - the speculative parse will special-case methods without return type, as member parsing does
>  - when the parser cannot figure out the at the top-level code, the error will be "class, interface, annotation type, enum, record, method or field expected", instead of the current "class, interface, enum, or record expected", to cover all possibilities. (This is only when implicitly declared classes are permitted, i.e. when preview is enabled and source level is correct, otherwise the existing error will be emitted. The idea here is not to suggest something that will lead to another compile-time error.)
>  - (definite) statements at the top-level are special-cased, similarly to how they are special-cased for members after https://github.com/openjdk/jdk/pull/20526
> 
> With this patch, errors like this are produced:
> 
> $ cat /tmp/M.java 
> main() {}
> $ javac --enable-preview -source 24 /tmp/M.java 
> /tmp/M.java:1: error: invalid method declaration; return type required
> main() {}
> ^
> Note: /tmp/M.java uses preview features of Java SE 24.
> Note: Recompile with -Xlint:preview for details.
> 1 error
> 
> 
> 
> $ cat /tmp/S.java 
> if (true);
> $ javac --enable-preview -source 24 /tmp/S.java 
> /tmp/S.j...

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20591#pullrequestreview-2268636135

From jlahoda at openjdk.org  Fri Aug 30 08:14:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 30 Aug 2024 08:14:26 GMT
Subject: Integrated: 8338301: Error recovery and reporting should be improved
 for erroneous implicitly declared classes
In-Reply-To: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
References: <6W5Rrvt7Jgx06S8t-UtLWy7IqB7gOsyla3LDRTwXFi0=.eff1503f-83fd-4995-a464-5529ce809a40@github.com>
Message-ID: <Y9cf3dsXp_E54ikn_-N36lx4pIeCJWKvWTjLtjDH4tU=.5f9f6f21-4d3f-4c1b-b2c5-7d4ba7c91c84@github.com>

On Thu, 15 Aug 2024 08:41:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> $ cat /tmp/M.java 
> main() {}
> 
> 
> which is compiled like:
> 
> $ javac --enable-preview --source 24 /tmp/M.java 
> /tmp/M.java:1: error: class, interface, enum, or record expected
> main() {}
> ^
> 1 error
> 
> 
> This error is problematic for two reasons:
>  - this is clearly a method with missing return type, but the error recovery does not see it as such
>  - with implicitly declared classes, not only classes/interfaces/enum/records are expected here, but also methods and fields as permitted
> 
> Note that if a method inside a class is missing a return type, the error is much better, so this is a problem specifically for methods on the top-level:
> 
> $ cat /tmp/C.java
> public class C {
>     main() {}
> }
> $ javac --enable-preview --source 24 /tmp/C.java 
> /tmp/C.java:2: error: invalid method declaration; return type required
>     main() {}
>     ^
> 1 error
> 
> 
> The immediate reason is that the javac's parser will speculatively parse the code to see if the code looks-like a method or a field, but this speculative parse does not special-case methods without return types (unlike class-member parsing, which has this special case, partly because of constructors).
> 
> I tried to remove this speculative parsing, reusing the code to parse class members, but I wasn't successful in that, sadly.
> 
> So, the proposal here is three-fold:
>  - the speculative parse will special-case methods without return type, as member parsing does
>  - when the parser cannot figure out the at the top-level code, the error will be "class, interface, annotation type, enum, record, method or field expected", instead of the current "class, interface, enum, or record expected", to cover all possibilities. (This is only when implicitly declared classes are permitted, i.e. when preview is enabled and source level is correct, otherwise the existing error will be emitted. The idea here is not to suggest something that will lead to another compile-time error.)
>  - (definite) statements at the top-level are special-cased, similarly to how they are special-cased for members after https://github.com/openjdk/jdk/pull/20526
> 
> With this patch, errors like this are produced:
> 
> $ cat /tmp/M.java 
> main() {}
> $ javac --enable-preview -source 24 /tmp/M.java 
> /tmp/M.java:1: error: invalid method declaration; return type required
> main() {}
> ^
> Note: /tmp/M.java uses preview features of Java SE 24.
> Note: Recompile with -Xlint:preview for details.
> 1 error
> 
> 
> 
> $ cat /tmp/S.java 
> if (true);
> $ javac --enable-preview -source 24 /tmp/S.java 
> /tmp/S.j...

This pull request has now been integrated.

Changeset: b8727181
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8727181f3ceac6f37272a1152f267ed1b6e2297
Stats:     278 lines in 4 files changed: 276 ins; 0 del; 2 mod

8338301: Error recovery and reporting should be improved for erroneous implicitly declared classes

Reviewed-by: cstein, vromero

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

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