From ihse at openjdk.org  Thu Feb  1 12:02:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 1 Feb 2024 12:02:12 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
Message-ID: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>

This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.

Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.

I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

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

Commit messages:
 - 8325109: Sort method modifiers in canonical order

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

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

From dfuchs at openjdk.org  Thu Feb  1 13:43:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Feb 2024 13:43:00 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <8VqjbOBjkNCr7PmXABZ1xmQqvF0jidmGyIMNUdKQDww=.8ffdc2ac-023f-4b79-ac5a-9ef541af68a7@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to IPAdressUtil look fine. I eyeballed the rest and didn't spot any issue.

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

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856519410

From duke at openjdk.org  Thu Feb  1 13:53:34 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 1 Feb 2024 13:53:34 GMT
Subject: RFR: 8303374: Implement JEP 455: Primitive Types in Patterns,
 instanceof, and switch (Preview) [v57]
In-Reply-To: <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <M06P1ym-MnvjB2Z-v9hfGFjXV2RbBeIqg0EMzWr9LNU=.b363d892-f5da-42dc-b53d-7a9a0ed1689e@github.com>
Message-ID: <CLbfoAR5kAC4Pb1kwSn_aHkdrPSdvk9EjO96nov1sTY=.b15cd4ce-03e4-46d5-b85f-d17f0bb9f174@github.com>

On Wed, 31 Jan 2024 10:03:23 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Update summary in ExactnessConversionsSupportTest
>  - Address review by Jan
>  - Remove redundant null check  and introduce a const boolean for unconditionally exact pairs
>  - Small fix in Javadoc
>  - Tidy up Javadoc of Lower.visitTypeTest
>  - Tidy up Javadoc of IllegalArgumentException in typeSwitch
>  - Improve readability in SwitchBootstraps
>  - Update year
>  - Cleanup redundant clone
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ec56c72b...f68748b1

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 721:

> 719:             typePairToName.put(new TypePairs(double.class, long.class),   "isDoubleToLongExact");
> 720:             typePairToName.put(new TypePairs(double.class, float.class),  "isDoubleToFloatExact");
> 721:             return typePairToName;

This?should?return an?immutable?map, so that `TypePairs`?lookups can?be?treated as?constant:
Suggestion:

            return Map.copyOf(typePairToName);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1474502668

From aivanov at openjdk.org  Thu Feb  1 14:44:02 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 1 Feb 2024 14:44:02 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uj6X0EkJ7Id9yviBJdcfrEINU46lON8sZkDN2xF5OB4=.bd123c3f-d79e-46e8-8a5f-241b4a50390e@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks good to me.

I looked through all the changes.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1856683827

From rriggs at openjdk.org  Thu Feb  1 17:02:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Feb 2024 17:02:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <E28xCC3i0n7CBNbkZDdvbd8kDHlZdAfF0o_OrhT88ng=.79424bfe-ea1d-4015-a15b-de98635b7d05@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

lgtm; all look good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857031136

From darcy at openjdk.org  Thu Feb  1 17:24:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Feb 2024 17:24:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Looks fine; I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857088376

From prappo at openjdk.org  Thu Feb  1 23:07:08 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 1 Feb 2024 23:07:08 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <zBTvQPjpQKoxxj5CsUlaOfJkO0EyJy-lUfF8Zg6FQRQ=.132947bd-1b7a-4809-af69-e3d9ba962099@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Changes to jdk.javadoc look fine.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17670#pullrequestreview-1857871131

From ihse at openjdk.org  Fri Feb  2 06:40:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Feb 2024 06:40:01 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
 <uY6CoY9NwuiOEmWivsV3k5OEdoBB4ETOCiK2fo0mDLU=.7ec4beb3-66b9-4076-8aa6-2caa221023bf@github.com>
Message-ID: <c1A2_JMyhmgyx8N0-IvYuVxJ-uK43gJZ-qQRWUYtBbk=.aee9ccc3-254c-41e8-b839-e61c21ca7fae@github.com>

On Thu, 1 Feb 2024 17:21:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>  I just suggest double-checking on the current maintenance procedures for the java.util.concurrent code.

@jddarcy Any idea how to do that? I tried searching for JSR-166 and java.util.concurrent, but all I could find was talk about a now-deleted mailing list concurrency-interest, and a link to a [CVS repo for JDK8](http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/jsr166/src/jdk8/java/util/).

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1923018074

From abimpoudis at openjdk.org  Tue Feb  6 10:54:16 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 6 Feb 2024 10:54:16 GMT
Subject: RFR: 8325257: jshell reports NoSuchFieldError with instanceof
 primitive type
Message-ID: <g7K6PelTU6m2rNVHVe_ep0jUmSpkH3j32bcFjZyXrUE=.11f5cc29-b924-4ebc-93dd-e937e556e55e@github.com>

Fixed compiler bug during lowering of the type test, where the let expression was using the `expr` of the old `tree` and not of the translated one. The latter manifested as a JShell error. Added compiler test as well. e.g., 


class $JShell$2 {
    
    $JShell$2() {
        super();
    }
    public static boolean $1;
    
    public static Object do_it$() throws Throwable {
        return Boolean.valueOf($1 = (let /*synthetic*/ final Object tmp184$ = $JShell$1.o 
                                     in tmp184$ != null && o instanceof Long));                          
                                                        // ^
    }
}

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

Commit messages:
 - 8325257: jshell reports NoSuchFieldError with instanceof primitive type

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

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

From ihse at openjdk.org  Tue Feb  6 11:39:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 11:39:57 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <hMv74_Mz6j4w5HMKHfGqeYuSNKUfu3ywR8Zdxv3nUBQ=.8965f0fa-9ea6-467b-b8a3-4a1dc59c2d76@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

@DougLea Doug, do you have anything to say about the changes in `java.util.concurrent`?

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1929336942

From mcimadamore at openjdk.org  Tue Feb  6 13:56:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Feb 2024 13:56:54 GMT
Subject: RFR: 8325257: jshell reports NoSuchFieldError with instanceof
 primitive type
In-Reply-To: <g7K6PelTU6m2rNVHVe_ep0jUmSpkH3j32bcFjZyXrUE=.11f5cc29-b924-4ebc-93dd-e937e556e55e@github.com>
References: <g7K6PelTU6m2rNVHVe_ep0jUmSpkH3j32bcFjZyXrUE=.11f5cc29-b924-4ebc-93dd-e937e556e55e@github.com>
Message-ID: <CkBcpEqMfizHZcVGzpomdivIimOVGeAg7qaN9xi9Qs0=.2e570ced-0c38-499f-9ac1-36e5bc7653d8@github.com>

On Tue, 6 Feb 2024 10:50:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Fixed compiler bug during lowering of the type test, where the let expression was using the `expr` of the old `tree` and not of the translated one. The latter manifested as a JShell error. Added compiler test as well. e.g., 
> 
> 
> class $JShell$2 {
>     
>     $JShell$2() {
>         super();
>     }
>     public static boolean $1;
>     
>     public static Object do_it$() throws Throwable {
>         return Boolean.valueOf($1 = (let /*synthetic*/ final Object tmp184$ = $JShell$1.o 
>                                      in tmp184$ != null && o instanceof Long));                          
>                                                         // ^
>     }
> }

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17729#pullrequestreview-1865254355

From ihse at openjdk.org  Tue Feb  6 16:28:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2024 16:28:03 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <NrJTC3stlxFQWztet4N8xhmweI4CStcr10g3fcTpW_4=.d905ff86-5c65-4f88-a39d-6c0a4e6bba7c@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

For the record, when I tried to revive this, it turned out that all changes proposed here were already implemented in master.

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

PR Comment: https://git.openjdk.org/jdk/pull/11487#issuecomment-1930231543

From jlu at openjdk.org  Tue Feb  6 18:43:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 Feb 2024 18:43:01 GMT
Subject: RFR: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <NrJTC3stlxFQWztet4N8xhmweI4CStcr10g3fcTpW_4=.d905ff86-5c65-4f88-a39d-6c0a4e6bba7c@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
 <NrJTC3stlxFQWztet4N8xhmweI4CStcr10g3fcTpW_4=.d905ff86-5c65-4f88-a39d-6c0a4e6bba7c@github.com>
Message-ID: <3VL5M629rog_nnT8coNUIEcHPbhc8KwC8s_1qbFNWAQ=.beb54eca-cbf3-45f8-8208-057acc677951@github.com>

On Tue, 6 Feb 2024 16:24:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
>> 
>> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
>> 
>> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
>> 
>> Doing so has a dual benefit:
>> 
>> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
>> 
>> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
>> 
>> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.
>
> For the record, when I tried to revive this, it turned out that all changes proposed here were already implemented in master.

Hi @magicus, the trailing white space in all .properties files between the localized and un-localized versions was standardized in [8300719](https://bugs.openjdk.org/browse/JDK-8300719) as part of the L10n translations. The changes there likely included the proposed changes here as well.

For context, there was no removal of questionable trailing white space, only the standardization that the localized versions matched the original version. And similar to this patch, `/u0020` was used in replacement of ` `. We usually see that the external translation tool causes inconsistency in trailing white space, so we re-run our white space tool during each L10n translation drop.

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

PR Comment: https://git.openjdk.org/jdk/pull/11487#issuecomment-1930543225

From abimpoudis at openjdk.org  Wed Feb  7 07:03:00 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 7 Feb 2024 07:03:00 GMT
Subject: Integrated: 8325257: jshell reports NoSuchFieldError with instanceof
 primitive type
In-Reply-To: <g7K6PelTU6m2rNVHVe_ep0jUmSpkH3j32bcFjZyXrUE=.11f5cc29-b924-4ebc-93dd-e937e556e55e@github.com>
References: <g7K6PelTU6m2rNVHVe_ep0jUmSpkH3j32bcFjZyXrUE=.11f5cc29-b924-4ebc-93dd-e937e556e55e@github.com>
Message-ID: <r__J87qeLczUrsYTbe3mb5903HPCiuwjQJ-rHpHhSoA=.d4b5b53c-da93-406a-b689-4c446fdfb731@github.com>

On Tue, 6 Feb 2024 10:50:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Fixed compiler bug during lowering of the type test, where the let expression was using the `expr` of the old `tree` and not of the translated one. The latter manifested as a JShell error. Added compiler test as well. e.g., 
> 
> 
> class $JShell$2 {
>     
>     $JShell$2() {
>         super();
>     }
>     public static boolean $1;
>     
>     public static Object do_it$() throws Throwable {
>         return Boolean.valueOf($1 = (let /*synthetic*/ final Object tmp184$ = $JShell$1.o 
>                                      in tmp184$ != null && o instanceof Long));                          
>                                                         // ^
>     }
> }

This pull request has now been integrated.

Changeset: e0d98dd3
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0d98dd3019b2fd6b95dd341296899dc0b470cb1
Stats:     22 lines in 3 files changed: 17 ins; 0 del; 5 mod

8325257: jshell reports NoSuchFieldError with instanceof primitive type

Reviewed-by: mcimadamore

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

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

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: RFR: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <AbyHgk1wHchuCkp0snusjEkqPmCzyc_IRaEbP8f9tNE=.eb528716-b511-4d83-a3a9-480f8487ff6d@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

Just to confirm publicly, there is no need for any special handling of `java.util.concurrent` any longer; the JDK repo is the single source of truth nowadays.

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

PR Comment: https://git.openjdk.org/jdk/pull/17670#issuecomment-1932335281

From ihse at openjdk.org  Wed Feb  7 15:53:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Feb 2024 15:53:59 GMT
Subject: Integrated: 8325109: Sort method modifiers in canonical order
In-Reply-To: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
References: <BbICMGps3zSn7DLxe-b-MC7Uu4QDLRAlnz6BudkoyZA=.be51525d-91fb-4973-87fd-cbc2d6099754@github.com>
Message-ID: <xk3ADOyZQDY-sxr5Ph7VYQTzRabzGFg0kBCsVxThQro=.b8764313-7ea0-4939-93a5-8e9501b63756@github.com>

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a follow-up on [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the bin/blessed-modifier-order.sh on the entire code base, and manually checked the result. I have reverted all but these trivial and uncontroversial changes.
> 
> Almost all of these are about moving `static` to its proper position; a few do not involve `static` but instead puts `final` or `abstract` in the correct place.
> 
> I have deliberately stayed away from `default` in this PR, since they should probably get a more thorough treatment, see https://github.com/openjdk/jdk/pull/17468#pullrequestreview-1829238473.

This pull request has now been integrated.

Changeset: 18e24d06
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18e24d0619ffef7c6dbfc419105faba9f7ba1874
Stats:     61 lines in 39 files changed: 0 ins; 0 del; 61 mod

8325109: Sort method modifiers in canonical order

Reviewed-by: aivanov, rriggs, darcy, prappo

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

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

From hgreule at openjdk.org  Thu Feb 15 17:05:21 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 15 Feb 2024 17:05:21 GMT
Subject: RFR: 8325936: jshell - crash on 'new Object().""'
Message-ID: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>

This fixes a crash in jshell when the target of a StringTemplate is not a processor. We only look up the `process` method if the type is actually a processor. The added test case fails without that fix.

Please let me know what you think of this fix, and if there are things that should be changed.

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

Commit messages:
 - cleanup
 - add test case
 - Simplify, add test
 - Don't expect confusing errors
 - Fix fatal error when string template target is not a processor

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

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

From hgreule at openjdk.org  Thu Feb 15 17:05:21 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 15 Feb 2024 17:05:21 GMT
Subject: RFR: 8325936: jshell - crash on 'new Object().""'
In-Reply-To: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
References: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
Message-ID: <OVj2iS6RddjUVehML2ySYTIvnp_7cRx3F_3SXgIKd2A=.c7b11e1d-2720-49d3-81b8-a06f78545735@github.com>

On Thu, 15 Feb 2024 16:55:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> This fixes a crash in jshell when the target of a StringTemplate is not a processor. We only look up the `process` method if the type is actually a processor. The added test case fails without that fix.
> 
> Please let me know what you think of this fix, and if there are things that should be changed.

test/langtools/tools/javac/diags/examples/StringTemplateNotProcessor.java line 26:

> 24:  // key: compiler.note.preview.filename
> 25:  // key: compiler.err.cant.resolve.location.args
> 26:  // key: compiler.misc.location

I think this error was rather confusing, e.g.

Simple2.java:3: error: cannot find symbol
        System.out.println(e."{e}");
                             ^
  symbol:   method process(StringTemplate)
  location: class String

It mentions the `process` method while it's not visible in the code. It also always came directly after e.g.

Simple2.java:3: error: not a processor type: String
        System.out.println(e."{e}");

so it basically just caused 2 errors when there actually only is 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17876#discussion_r1491337338