From jlahoda at openjdk.org  Mon Oct  3 07:27:21 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 3 Oct 2022 07:27:21 GMT
Subject: Integrated: 8294431: jshell reports error on initialisation of static
 final field of anonymous class
In-Reply-To: <cdy-3x_NYaQY2qGSY7nH3seslfIEiSIaYW13y0qZiBU=.3f0b1f1a-243a-425f-b202-68855ef32b3e@github.com>
References: <cdy-3x_NYaQY2qGSY7nH3seslfIEiSIaYW13y0qZiBU=.3f0b1f1a-243a-425f-b202-68855ef32b3e@github.com>
Message-ID: <Qq-H-__mV6csOudnjMlVMO-pEcduAlZOCzwsJqs2u4o=.7830a0e7-6d67-4ae4-be44-3a65ec0ef491@github.com>

On Thu, 29 Sep 2022 13:51:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When variable with an inferred type (i.e. `var`) is initialized with an anonymous class, the inferred type of the variable is the actual anonymous type. To implement this in JShell, JShell will unroll the anonymous class into a normal class, and to do this, it needs to initialize fields inside a constructor.
> 
> But, as we can have static fields in the anonymous class now, it is necessary to not try to initialize static fields in the constructor, as we would initialize them too often.

This pull request has now been integrated.

Changeset: 8e9cfeb1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e9cfeb17ccb6c37243d43f76d5eecb3f521141f
Stats:     9 lines in 2 files changed: 5 ins; 0 del; 4 mod

8294431: jshell reports error on initialisation of static final field of anonymous class

Reviewed-by: sundar

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

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

From prappo at openjdk.org  Thu Oct  6 14:35:20 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 6 Oct 2022 14:35:20 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
 <PlQjfMvDRNRyYFL9xVnKoirPgtOk_QhEMl_QbNRnzrU=.0b472944-6d3a-48f2-bc79-ec592df83c79@github.com>
Message-ID: <IDbm-8O6WIU3UVM8RfCgwumVv07BW1zqbpVkwYNhjps=.31e7c071-18d8-4278-a0cd-21a00d26e9ac@github.com>

On Fri, 30 Sep 2022 19:15:17 GMT, Phil Race <prr at openjdk.org> wrote:

> If the docs end up the same as you say that is fine by me since for the two ImageIO classes that seems to be what we'd want.

Since this change does not affect HTML pages for java.desktop, I take it as "approved".

> But inheritDoc behaviour is still "surprising". I've never been sure I understood it and now I'm just sure I don't.
> 
> 1. The two ImageIO methods don't have @OverRide or _anything_ and yet javadoc infers
>    they'd want to inherit the docs from the interface .. clever javadoc .. I guess I can see
>    that some doc is better than none so this is OK
> 2. When it does inherit I'd expected that it copies the EXACT and ENTIRE javadoc
>    from the super-interface, which for your change to work can't be all its doing.
>    You've added JUST
>    /**
> 
> * @throws SomeExceptionSubType blah-blah
>   */
> 
> and yet javadoc somehow figures out this is to be ADDED to the super-type doc for the method and not replace it .. ???
> 
> 3. What the old code was doing seems to me to be "natural" to the extent any of
>    this does and the fix you are preparing would add to the surprising behaviours ..

Let me try to clarify exception documentation inheritance for you.

A method **never** inherits exception documentation unless that method explicitly requests to do so. A method that wants to inherit documentation for a particular exception has two options: use a doc comment or use a method declaration.

Let's see how those options work. Suppose, a method wants to inherit documentation for an exception `X`. To inherit documentation through a doc comment, the method adds the following exception tag (`@throws` or `@exception`) to that method's doc comment:


?    @throws X {@inheritDoc}


To inherit documentation through a method declaration, the method lists `X` in that method's `throws` clause:


?    throws ..., X, ...


If a method chooses neither of those options, then that method won't inherit exception documentation for `X` (assuming that exception documentation for `X` exists in the supermethod).

Here's an informal, simplified, but conceptually correct version of the algorithm that javadoc uses to document exceptions thrown by a method:

  Step 1. For each exception tag, do the following. If an exception tag does not have `{@inheritDoc}` in its description, add an entry for the exception that this tag describes to the "Throws:" section. Otherwise, look for corresponding documentation in the supermethod, to which apply this step (Step 1) recursively.

  Step 2. For each exception from the `throws` clause, do the following. If an exception has not been documented on the previous step, document it using corresponding documentation in the supermethod, to which apply this algorithm (both steps in order) recursively.

A few notes on the algorithm: 

* Exception tags are examined prior to the `throws` clause. This allows a method to **override** documentation that could be otherwise inherited from the supermethod: if the method provides exception tags for a particular exception, then documentation for that exception will be found on Step 1 and, hence, won't be looked for in the supermethod on Step 2.


  ?    @throws X <overriding-description>


* If a method wants to **add** documentation for a particular exception, rather than **override** it, the method should both add documentation and inherit it using tags:


  ?    @throws X <additional-description>
  ?    @throws X {@inheritDoc}


The above model might explain a common **misconception** according to which methods inherit documentation for checked exceptions and do not inherit it for unchecked exceptions. In reality, javadoc treats all exceptions equally. It's just that if a method throws a checked exception, that exception (or its superclass) must be listed in that method's `throws` clause. Now, if such an exception is not documented by that method but documented by the supermethod, that exception documentation is inherited. That gives a false impression that the documentation is inherited because the exception is checked. In fact, the documentation would still be inherited if that exception, listed in the `throws` clause, were unchecked.

The above is how it has been working (barring bugs) since documentation comment inheritance appeared in its current form. Implicit inheritance (filling in missing text) appeared in JDK 1.3, explicit inheritance (`{@inheritDoc}`) appeared in JDK 1.4, auto-inheriting documentation for subclasses of exceptions whose documentation is inherited (JDK-4947455) appeared in JDK 5.

Back to this PR change in `java.desktop`. `ImageInputStreamImpl.readBoolean` inherits `EOFException` documentation not because that method doesn't have a doc comment of its own and, thus, inherits "the exact and entire" doc comment from its supermethod (`ImageInputStream.readBoolean`). It's because that when the algorithm reaches Step 2 and tries to find documentation for `IOException` (because it is listed in the `throws` clause), JDK-4947455 kicks in. And JDK-4947455 says that if a method inherits documentation for a particular exception, it should also inherit documentation for that exception's subclasses. So, javadoc goes ahead and inherits documentation for `IOException`, because it's a direct match, and for `EOFException`, because it's a subclass of `IOException`. 

To inherit `EOFException` documentation after JDK-4947455 has been reverted and, thus, the subclassing :magic_wand: has gone, `ImageInputStreamImpl.readBoolean` has two options: 

* list `EOFException` in the `throws` clause
* `@throws EOFException {@inheritDoc}`

Thanks to the current implementation of documentation inheritance, any of the above can be done **before** JDK-4947455 is reverted. For now doing so just adds a redundant but harmless inheritance route, which will become the only route in time. For this PR to be less disruptive and qualify as "noreg-doc" I chose to add an exception tag rather than amend the `throws` clause.

I hope that my reply clarifies the matter. Documentation inheritance can be surprising. We're trying hard to capture its model and simplify it where possible. We are constantly improving the Documentation Comment Specification for the Standard Doclet[^1] (spec), but since documentation inheritance is a popular topic which is often misunderstood, along with improving the spec in this area, we might also provide a less formal document dedicated to documentation inheritance.

[^1]: https://docs.oracle.com/en/java/javase/19/docs/specs/javadoc/doc-comment-spec.html

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

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

From jjg at openjdk.org  Thu Oct  6 15:05:56 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 6 Oct 2022 15:05:56 GMT
Subject: RFR: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited [v2]
In-Reply-To: <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
 <rZOv9leE3Krs9IA7nAMMZPVelsIgC5am13o1oU8BF8Y=.fe7d7524-1a12-4a38-aedb-f9dd60cdded8@github.com>
Message-ID: <lySOn6EkcX5ybd_-t8TFRBQfB51zAnoq5Bz79HZQmws=.f4be94e4-88d9-43c2-b052-0034e957738e@github.com>

On Tue, 27 Sep 2022 12:14:23 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
>> 
>> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
>> 
>> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
>> 
>> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
>> 
>>     public class Subtype extends Supertype {
>> 
>>         @Override
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class Supertype {
>> 
>>         /**
>>          * @throws SuperException general problem
>>          * @throws SubExceptionA  specific problem A
>>          * @throws SubExceptionB  specific problem B
>>          */
>>         public void m() throws SuperException {
>>     ...
>> 
>>     public class SuperException extends Exception {
>>     ...
>> 
>>     public class SubExceptionA extends SuperException {
>>     ...
>> 
>>     public class SubExceptionB extends SuperException {
>>     ...
>> 
>> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
>> 
>>     public void m()
>>            throws SuperException
>> 
>>     Overrides:
>>         m in class Supertype
>>     Throws:
>>         SuperException - general problem
>>         SubExceptionA - specific problem A
>>         SubExceptionB - specific problem B 
>> 
>> It works for checked and unchecked exceptions, for methods in classes and interfaces.
>> 
>> 
>> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
>> 
>> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
>> 
>> 
>> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
>> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert an extraneous change to jdk.javadoc

I'm marking the change as approved, in terms of the cumulative efforts of those who have commented.

I've browsed all the changes and read the jshell files in more detail, since no once else has so far.

I understand the reason for the change, and generally approve of undoing the magic of the old feature in JDK-8287796. That being said, the proposed state is "not great", and feels like the interim stage of "one step back, to take two steps forward", even though I do not have a good sense at this time of what that future direction might be.

So, looks OK for now, but I hope we revisit this issue again sometime.  Thanks, in general, for taking on this topic.

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

Marked as reviewed by jjg (Reviewer).

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

From prappo at openjdk.org  Mon Oct 10 16:57:21 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 10 Oct 2022 16:57:21 GMT
Subject: Integrated: 8294377: Prepare to stop auto-inheriting documentation for
 subclasses of exceptions whose documentation is inherited
In-Reply-To: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
References: <vITfPI9S4KD7Gay7azlE9rbQCVb9sSSDE4MAoa49gPE=.4d3d27ba-0123-4c45-b35c-0b321a9c2c88@github.com>
Message-ID: <5x7fG0iSo2qnkGEPeTumleeWMpV15E_qSXdIrdVHoUY=.369c8b00-4a6e-4f50-9ca7-62be5556be8e@github.com>

On Tue, 27 Sep 2022 11:43:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.
> 
> JDK-8287796 seeks to remove an old, undocumented, and esoteric javadoc feature that cannot be suppressed [^2]. The feature is so little known about that IDEs either do not implement it correctly or do not implement it at all, thus rendering documentation differently from how the javadoc tool renders it.
> 
> That feature was introduced in JDK-4947455 and manifests as follows. If a method inherits documentation for an exception, along with that documentation the method automatically inherits documentation for all exceptions that are subclasses of that former exception and are documented in an overridden method.
> 
> To illustrate that behavior, consider the following example. A method `Subtype.m` inherits documentation for `SuperException`, while the overridden method `Supertype.m` documents `SuperException`, `SubExceptionA` and `SubExceptionB`, where the latter two exceptions are subclasses of the former exception:
> 
>     public class Subtype extends Supertype {
> 
>         @Override
>         public void m() throws SuperException {
>     ...
> 
>     public class Supertype {
> 
>         /**
>          * @throws SuperException general problem
>          * @throws SubExceptionA  specific problem A
>          * @throws SubExceptionB  specific problem B
>          */
>         public void m() throws SuperException {
>     ...
> 
>     public class SuperException extends Exception {
>     ...
> 
>     public class SubExceptionA extends SuperException {
>     ...
> 
>     public class SubExceptionB extends SuperException {
>     ...
> 
> For the above example, the API Documentation for `Subtype.m` will contain documentation for all three exceptions; the page fragment for `Subtype.m` in "Method Details" will look like this:
> 
>     public void m()
>            throws SuperException
> 
>     Overrides:
>         m in class Supertype
>     Throws:
>         SuperException - general problem
>         SubExceptionA - specific problem A
>         SubExceptionB - specific problem B 
> 
> It works for checked and unchecked exceptions, for methods in classes and interfaces.
> 
> 
> If it's the first time you hear about that behavior and this change affects your area, it's a good opportunity to reflect on whether the exception documentation this change adds is really needed or you were simply unaware of the fact that it was automatically added before. If exception documentation is not needed, please comment on this PR. Otherwise, consider approving it.
> 
> Keep in mind that if some exception documentation is not needed, **leaving it out** from this PR might require a CSR.
> 
> 
> [^1]: Aside from insignificant changes on class-use and index pages. There's one relatively significant change. This change is in jdk.jshell, where some methods disappeared from "Methods declared in ..." section and other irregularities. We are aware of this and have filed JDK-8291803 to fix the root cause.
> [^2]: In reality, the feature can be suppressed, but it looks like a bug rather than intentional design. If we legitimize the feature and its suppression behavior, the model for exception documentation inheritance might become much more complicated.

This pull request has now been integrated.

Changeset: eb90c4fc
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb90c4fc0479379c8c1452afca8f37746c762e18
Stats:     320 lines in 14 files changed: 310 ins; 0 del; 10 mod

8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited

Reviewed-by: jjg

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

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

From prappo at openjdk.org  Tue Oct 11 14:04:10 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Oct 2022 14:04:10 GMT
Subject: RFR: 8295154: Documentation for RemoteExecutionControl.invoke(Method)
 inherits non-existent documentation
Message-ID: <U1fAeDxOoQi4rhMw8X8rST_TkMU3PsrLOCPmiI3aSps=.9c3b33bc-50b6-4ac9-a478-7c0a62e7cfb2@github.com>

Please review this trivial fix that partially reverts changes from JDK-8294377.

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

Commit messages:
 - Initial commit

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

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

From jjg at openjdk.org  Tue Oct 11 17:54:16 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 11 Oct 2022 17:54:16 GMT
Subject: RFR: 8295154: Documentation for
 RemoteExecutionControl.invoke(Method) inherits non-existent documentation
In-Reply-To: <U1fAeDxOoQi4rhMw8X8rST_TkMU3PsrLOCPmiI3aSps=.9c3b33bc-50b6-4ac9-a478-7c0a62e7cfb2@github.com>
References: <U1fAeDxOoQi4rhMw8X8rST_TkMU3PsrLOCPmiI3aSps=.9c3b33bc-50b6-4ac9-a478-7c0a62e7cfb2@github.com>
Message-ID: <yXm29X2-XoD2Qoj0iACKB8YAXyhsIilSfDUQm8iXGsg=.f526c355-ad4e-4e9f-975a-dc4af9c62052@github.com>

On Tue, 11 Oct 2022 13:56:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix that partially reverts changes from JDK-8294377.

Marked as reviewed by jjg (Reviewer).

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

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

From prappo at openjdk.org  Tue Oct 11 19:37:59 2022
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 11 Oct 2022 19:37:59 GMT
Subject: Integrated: 8295154: Documentation for
 RemoteExecutionControl.invoke(Method) inherits non-existent documentation
In-Reply-To: <U1fAeDxOoQi4rhMw8X8rST_TkMU3PsrLOCPmiI3aSps=.9c3b33bc-50b6-4ac9-a478-7c0a62e7cfb2@github.com>
References: <U1fAeDxOoQi4rhMw8X8rST_TkMU3PsrLOCPmiI3aSps=.9c3b33bc-50b6-4ac9-a478-7c0a62e7cfb2@github.com>
Message-ID: <HXyxOCS2-2EyJ40LKkCRWibLU699s49xrmhtiFdRnvQ=.17e009e9-9002-486e-b74f-86b0bf31072d@github.com>

On Tue, 11 Oct 2022 13:56:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial fix that partially reverts changes from JDK-8294377.

This pull request has now been integrated.

Changeset: 9bb932ce
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bb932ce3007f3f5c67344ebb42dd3c94fa035ab
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8295154: Documentation for RemoteExecutionControl.invoke(Method) inherits non-existent documentation

Reviewed-by: jjg

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

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

From ihse at openjdk.org  Thu Oct 20 12:06:27 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 12:06:27 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
Message-ID: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>

Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.

With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).

The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8295729: Add jcheck whitespace checking for properties files

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

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

From erikj at openjdk.org  Thu Oct 20 18:26:46 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:26:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <NObZDn88VUQ8fHaLhcrqe0wkth0EfVAwjWA7K4eAY2k=.0c70399e-f307-4ca4-a637-e2f1ebedf960@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Nice job!

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

Marked as reviewed by erikj (Reviewer).

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

From naoto at openjdk.org  Thu Oct 20 18:33:47 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 18:33:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <0VhVC2dpGOdpE3OL1278r0iCVXO1Jd_83Q4kszfikjY=.fecfe4ed-9a48-4fe4-827a-7ab1bc2defa2@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

LGTM. Haven't looked at all the l10n files.

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

Marked as reviewed by naoto (Reviewer).

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

From angorya at openjdk.org  Thu Oct 20 18:40:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:40:47 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

I would vote against this change.  Per java properties spec
https://github.com/openjdk/jdk/pull/10792


White space following the property value is not ignored, and is treated as part of the property value.


This change might break localization or messages where trailing whitespace is important (example: "Label: ")

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

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

From ihse at openjdk.org  Thu Oct 20 18:48:17 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 18:48:17 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> I would vote against this change.  Per java properties spec
> https://github.com/openjdk/jdk/pull/10792
> 
> 
> White space following the property value is not ignored, and is treated as part of the property value.
> 
> 
> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
> 
> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
> 
> 
> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;

@andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

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

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

From erikj at openjdk.org  Thu Oct 20 18:53:49 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 20 Oct 2022 18:53:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <qf8daMUSgSlaXN3bROLfbFbpzrDJh5wSJdnTYQdol64=.df762075-9646-4aab-ab95-ead96e45936a@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Given that trailing whitespace may be part of a property value, then I take back my review.

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

Changes requested by erikj (Reviewer).

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

From cjplummer at openjdk.org  Thu Oct 20 18:53:50 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Oct 2022 18:53:50 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
Message-ID: <uNs096Y7_C0U9CTifzO1PL71uAgKv0RwAxTfOuL5LGw=.e8e725f6-3fac-4b54-b406-111628923ae8@github.com>

On Thu, 20 Oct 2022 18:38:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> `White space following the property value is not ignored, and is treated as part of the property value.`

Although I didn't know this was in the spec, I suspected it might be the case. When looking at the jdk.management.agent changes, it looked like the extra space was actually a typo and was copied into all the localized versions (and not actually localized for unicode locales). In this case removing the white space is the right thing to do. It is in fact fixing an actual bug.

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

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

From angorya at openjdk.org  Thu Oct 20 18:53:51 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Oct 2022 18:53:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zdV9qsiWj-FQBgaMMDGnX0S-zzlxqVVQBl8F9vi-EAw=.ee2cedb4-0e1a-4dad-9b37-ee958c865049@github.com>
 <j6FxMycN-ld3OS68tZbfSgemu4x6DcYb7Y8yt5_GWmk=.50161e23-1c85-4f68-930b-214fb4825950@github.com>
Message-ID: <HJm4YG5tr3dJ4SeXPS58BEpkBqzUEk7QwX6Cmf5x8JA=.7076b0a9-6fe2-4e0a-99f9-d3ca8a828a5a@github.com>

On Thu, 20 Oct 2022 18:46:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I would vote against this change.  Per java properties spec
>> https://github.com/openjdk/jdk/pull/10792
>> 
>> 
>> White space following the property value is not ignored, and is treated as part of the property value.
>> 
>> 
>> This change might break localization or messages where trailing whitespace is important (example: "Label: ")
>> 
>> edit: sorry, the link above is not a spec.  looking at the Properties.load(Reader) javadoc:
>> https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader)
>> 
>> 
>> Any white space after the key is skipped; if the first non-white space character after the key is '=' or ':', then it is ignored and any white space characters after it are also skipped. All remaining characters on the line become part of the associated element string;
>
> @andy-goryachev-oracle Oh, I did not know that. Is this really how it is implemented, or is there a discrepancy between the spec and the implementation? The haphazard placement of trailing spaces seems to indicate that they are ignored.

@magicus  : 
no, this is how Properties were working from day one.


package goryachev.research;

import java.io.IOException;
import java.io.StringReader;
import java.util.Properties;

public class TestProperties {
    public static void main(String[] args) throws IOException {
        String text = "key= value ";
        Properties p = new Properties();
        p.load(new StringReader(text));
        System.out.println("value=["  +p.getProperty("key") + "]");
    }
}


outputs:

value=[value ]

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

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

From ihse at openjdk.org  Thu Oct 20 19:07:52 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Oct 2022 19:07:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <vN85_fh3ocln38nEOKYh1GBwW5xzb3nIo_jYOQYqiLY=.6e65e099-3d3c-40fe-8cfa-1acf25fdd0a7@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Okay. That definitely rules out adding .properties to the whitespace jcheck verification.

However, I think that instead opens up a ton of more individual problems, since I think most (if perhaps not all) of these trailing whitespaces are incidental, and thus might be bugs. Perhaps no-one really noticed a double whitespace where it were not supposed to be, etc, especially not if it was just for a translated language.

I'm thinking I should redirect this PR to skip the jcheck requirement, and revert all changes to property values, but keep the part of the patch that removes trailing spaces in `#` comment lines. That seems to account for a majority of the changes.

For the remaining properties files with trailing spaces in the actual values, I'll make a sanity check if it seems correct or not, and if it looks fishy, I'll open bugs on the respective component teams to verify that their property values are indeed correct.

Does that sound reasonable?

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

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

From naoto at openjdk.org  Thu Oct 20 19:29:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:29:51 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <iu-qPLbaWYYTSq2jVgsGXDGt8Weqq2RVuoaHyuI0YRg=.f4131b5a-9685-4246-bbac-85b776fee6e3@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Retracting my approval too. Thanks for the catch, Andy!
That sounds reasonable > Magnus

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

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

From naoto at openjdk.org  Thu Oct 20 19:40:55 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Oct 2022 19:40:55 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <eJ0YaIIkCYOV7stEG2AEVx05evyYix9H9Zp2eAlJsjA=.2e14e322-75f6-4651-bb96-c24cf2f10391@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

(retracting approval)

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

Changes requested by naoto (Reviewer).

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

From ihse at openjdk.org  Fri Oct 21 08:17:46 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:17:46 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove check for .properties from jcheck
 - Restore trailing whitespace for property values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/e33c0765..c91fdaa1

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

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

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

From ihse at openjdk.org  Fri Oct 21 08:31:59 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 21 Oct 2022 08:31:59 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <1mu65mMxl2Nf-mwa4iZczOBqJbPdutKpL6dE_3vMWcg=.c03430ed-70df-40fa-994e-700080b7b8fa@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Ok, I repurposed this PR to deal only with trailing space on non-value lines (comments and empty lines). This should be trivial, and will reduce the trailing spaces to only the value lines.

I believe most, but perhaps not all, trailing spaces in the value lines are actually bugs, but that will need further scrutiny by the owners of the properties files. Expect follow up bugs on this.

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

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

From erikj at openjdk.org  Fri Oct 21 12:59:48 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 21 Oct 2022 12:59:48 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <AoFGXlCHPgwZa3u0Kwp6W-h5k-I_Malb2gWa3tSxSbw=.500a110c-0c73-4205-9a2e-e281bfb3a730@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by erikj (Reviewer).

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

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

From naoto at openjdk.org  Fri Oct 21 16:09:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Oct 2022 16:09:28 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

One possible solution to this is to replace those dangling white spaces with explicit Unicode escapes, i.e. "\u0009" and "\u0020".  This way jcheck can safely be enabled to detect future unwanted trailing spaces, and possibly existing ones can be visually recognizable by the engineers to correct them.

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

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

From angorya at openjdk.org  Fri Oct 21 16:09:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Oct 2022 16:09:29 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <IKSqEfLnlAuM7MsEUUJCb5SGC_SpzMgs3qQ0UVfnBx4=.b25cc081-262b-40e7-bf0b-a2b173f2674a@github.com>
Message-ID: <khuIARsEyKMyIfUxBD69kijyjnwDFCzAra51YwctMyY=.71b00eb7-1312-4db9-a6a5-ff85f7635132@github.com>

On Fri, 21 Oct 2022 16:04:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> replace those dangling white spaces with explicit Unicode escapes

this is a *very good* idea.

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

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

From prr at openjdk.org  Mon Oct 24 03:55:56 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 24 Oct 2022 03:55:56 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <6Nga-zBIoxnexiDJp-uJqSHjkki2U2n6y5WW9chvPz0=.f389c36c-e6bd-4b32-81a2-0304f23ba6a2@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

Marked as reviewed by prr (Reviewer).

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

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

From ihse at openjdk.org  Mon Oct 24 19:21:07 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:21:07 GMT
Subject: RFR: 8295729: Remove trailing whitespace from non-value lines in
 properties files [v3]
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Remove check for .properties from jcheck"
   
   This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
 - Change trailing space and tab in values to unicode encoding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10792/files
  - new: https://git.openjdk.org/jdk/pull/10792/files/c91fdaa1..f4f94341

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

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

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

From angorya at openjdk.org  Mon Oct 24 19:22:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:22:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
Message-ID: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>

On Fri, 21 Oct 2022 08:17:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove check for .properties from jcheck
>  - Restore trailing whitespace for property values

368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

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

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

From ihse at openjdk.org  Mon Oct 24 19:25:38 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:25:38 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <yZpwsDUeKIrGQT3tvyGfGHFjIOuQTOBfRyvV7b-uArA=.077497ab-51b8-4346-b67d-9838e3419964@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I agree, that was an excellent idea Naoto! In my last commit, I have converted all trailing spaces/tabs in value lines into explicit unicode characters. Since that means we have no trailing spaces (from a jcheck perspective), I could also restore the jcheck that was the original driver behind this bug. (And also restore the bug/PR title to show the original intent.)

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

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

From ihse at openjdk.org  Mon Oct 24 19:31:26 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:31:26 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v2]
In-Reply-To: <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <dguku32oUTBGTEokkzDPk1dxSxRBJMtotX7iJvEwQF4=.e077d7e5-6f94-4a5b-b3dd-ab2d5bcb00d5@github.com>
 <2dP1ZXi79c3PWdvTChCcuX8a4PFkig06K606SgaQDoM=.662f6b1b-a325-4270-84c5-446696faa73f@github.com>
Message-ID: <HmB2uBGv-fQnz3Kn7yEA0yIR4akDfM4tmso3sgA4-aQ=.d84de722-5d04-4aad-8ba3-572eea3cacc1@github.com>

On Mon, 24 Oct 2022 19:20:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove check for .properties from jcheck
>>  - Restore trailing whitespace for property values
>
> 368 files to review!  I wish we had separate PRs for fixing properties and checking for trailing whitespace.  i 'd expect it will take some time to review localization, unless we just keep them as is.

@andy-goryachev-oracle They are all automatically processed. There are two kinds of changes: Non-value lines have their trailing whitespace removed. You can verify that part of the PR by looking here: https://github.com/openjdk/jdk/pull/10792/files/c91fdaa19dc06351598bd1c0614e1af3bfa08ae2

This was the state of the PR as of three days ago. The most numerous number of changed files are here, but you can just scroll through the change and verify quickly that it is trivial.

The second change is the one suggested by Naoti; I have replaced all trailing tabs (there were just one) with `\u0009` and all trailing spaces with `\u0020`. That part was just pushed by me now. You can see that part separately here: https://github.com/openjdk/jdk/pull/10792/commits/a509b90f1b7f833924493fbd28b3cbb1a85c1f21

This affects far fewer files. And once again, it was mechanically generated. You can once again just scroll through and verify that all changes are due to the trailing whitespace being converted to unicode sequences.

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Started looking at whether certain trailing spaces can be (and/or should be) removed, but it quickly became apparent that we should just keep these properties as is (with the unicode escapes), rather than risk regression.

src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:

> 185: ### Button Demo ###
> 186: 
> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020

trailing whitespace looks unnecessary (accessible description?)

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Fehler beim Umbenennen von Datei oder Ordner
> 66: FileChooser.renameError.textAndMnemonic={0} kann nicht umbenannt werden
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0} kann nicht umbenannt werden: Es ist bereits eine Datei mit dem angegebenen Namen vorhanden. Geben Sie einen anderen Dateinamen an.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Error al cambiar el nombre del archivo o carpeta
> 66: FileChooser.renameError.textAndMnemonic=No se puede cambiar el nombre de {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=No se puede cambiar el nombre de {0}: ya existe un archivo con el nombre especificado. Especifique otro nombre de archivo.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Erreur lors du changement de nom du fichier ou du dossier
> 66: FileChooser.renameError.textAndMnemonic=Impossible de renommer {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossible de renommer {0} : il existe d\u00E9j\u00E0 un fichier portant le nom indiqu\u00E9. Indiquez-en un autre.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Errore durante la ridenominazione del file o della cartella
> 66: FileChooser.renameError.textAndMnemonic=Impossibile rinominare {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Impossibile rinominare {0}: esiste gi\u00E0 un file con il nome specificato. Specificare un altro nome.\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=\u30D5\u30A1\u30A4\u30EB\u307E\u305F\u306F\u30D5\u30A9\u30EB\u30C0\u306E\u540D\u524D\u5909\u66F4\u30A8\u30E9\u30FC
> 66: FileChooser.renameError.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093
> 67: FileChooser.renameErrorFileExists.textAndMnemonic={0}\u306E\u540D\u524D\u3092\u5909\u66F4\u3067\u304D\u307E\u305B\u3093: \u6307\u5B9A\u3057\u305F\u540D\u524D\u306E\u30D5\u30A1\u30A4\u30EB\u306F\u3059\u3067\u306B\u5B58\u5728\u3057\u307E\u3059\u3002\u5225\u306E\u30D5\u30A1\u30A4\u30EB\u540D\u3092\u6307\u5B9A\u3057\u3066\u304F\u3060\u3055\u3044\u3002\u0020

prob. unnecessary

src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties line 67:

> 65: FileChooser.renameErrorTitle.textAndMnemonic=Ett fel intr\u00E4ffade vid f\u00F6rs\u00F6k att \u00E4ndra namn p\u00E5 fil eller mapp
> 66: FileChooser.renameError.textAndMnemonic=Kan inte namn\u00E4ndra {0}
> 67: FileChooser.renameErrorFileExists.textAndMnemonic=Kan inte namn\u00E4ndra {0}: En fil med angivet namn finns redan. Ange ett annat filnamn.\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat failed on value ( {0} ) in column {1}
> 43: cachedrowsetimpl.doublefail = getDouble failed on value ( {0} ) in column {1}
> 44: cachedrowsetimpl.dtypemismt = Data Type Mismatch\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 73:

> 71: cachedrowsetimpl.numrows = Number of rows is less than zero or less than fetch size
> 72: cachedrowsetimpl.startpos = Start position cannot be negative
> 73: cachedrowsetimpl.nextpage = Populate data before calling\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative : Invalid cursor operation\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 128:

> 126: crswriter.params1 = Value of params1 : {0}\u0020
> 127: crswriter.params2 = Value of params2 : {0}\u0020
> 128: crswriter.conflictsno =  conflicts while synchronizing\u0020

this is tricky.  if this value is a part of a sentence (i.e. something like "5 conflicts..."), the localization is likely to be wrong.  it's hard to tell without looking further into the code.

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 44:

> 42: cachedrowsetimpl.floatfail = getFloat bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 43: cachedrowsetimpl.doublefail = getDouble bei Wert ( {0} ) in Spalte {1} nicht erfolgreich
> 44: cachedrowsetimpl.dtypemismt = Keine Datentyp\u00FCbereinstimmung\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 73:

> 71: cachedrowsetimpl.numrows = Zeilenanzahl ist kleiner als null oder kleiner als Abrufgr\u00F6\u00DFe
> 72: cachedrowsetimpl.startpos = Startposition darf keinen Negativwert aufweisen
> 73: cachedrowsetimpl.nextpage = Daten m\u00FCssen vor dem Aufruf ausgef\u00FCllt werden\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 87:

> 85: 
> 86: #FilteredRowSetImpl exceptions
> 87: filteredrowsetimpl.relative = relative: Ung\u00FCltiger Cursorvorgang\u0020

prob. unnecessary

src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties line 134:

> 132: 
> 133: #SyncResolverImpl exceptions
> 134: syncrsimpl.indexval = Indexwert liegt au\u00DFerhalb des Bereichs\u0020\u0020

prob. unnecessary

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

Marked as reviewed by angorya (no project role).

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

From ihse at openjdk.org  Mon Oct 24 19:45:01 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed. I did not think it was a good idea to hold this PR, waiting for component teams to do the whitespace check first, for two reasons:

1) Now the trailing whitespace will be obvious, and any intended whitespace will not be accidentally stripped by an editor, so it will be easier for engineers to fix any problems.

2) I know from experience that this kind of cleaning-up has a very low priority for many engineers. If this PR were dependent on all JDK groups going through their properties files, it would basically never be closed.

And finally: Here is a complete list of the files which has trailing "unicode whitespace" in values. I will try to figure out to which components these belongs and open corresponding bugs.


src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_CN.properties
src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_zh_TW.properties
src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties
src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties
src/java.desktop/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties
src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties
src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties
src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties
src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties
src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties
src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties
src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties
src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties
src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties
src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties
test/jdk/javax/net/ssl/Stapling/TEST.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/filechooser/resources/FileChooserDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/TableDemo.properties
test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/resources/ToggleButtonDemo.properties
test/jdk/tools/jmod/src/foo/jdk/test/foo/resources/foo.properties

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

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

From jjg at openjdk.org  Mon Oct 24 19:45:01 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:01 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Htn9EBt6AF3tlWd7t1gt23Li4UwB2P5haoCA4hfFD3g=.601d90e0-c4ec-43e1-9828-beaf4943f00c@github.com>
Message-ID: <cuJYgquzi3I4fULUZZz_G_ZjmEd_wDsUPw2mzCceM_w=.ad366bc4-db7f-48ad-9d3f-a8d0ba9e1820@github.com>

On Mon, 24 Oct 2022 19:34:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the files which have trailing "whitespace" (now as unicode sequences), I will file follow-up bugs on the respective components to verify if this is indeed correct, or a bug that should be fixed.

probably not needed - if nobody noticed anything until now we have no problem.  the solution to escape whitespace in values is the right solution, solves both the jcheck and WS visibility issues.

good job!

(and we can ignore my "prob. unnecessary" comments)

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

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

From angorya at openjdk.org  Mon Oct 24 19:45:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 19:45:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <cRpIep8vLpUKvRQH3e_vwTIqVChg5uSLhFH4sSCbmOQ=.9c8e6492-c665-4666-bba9-4947cd6059b1@github.com>

On Mon, 24 Oct 2022 19:23:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties line 187:
> 
>> 185: ### Button Demo ###
>> 186: 
>> 187: ButtonDemo.accessible_description=ButtonDemo\u3067\u306F\u3001JButton\u3001JRadioButton\u3001JToggleButton\u304A\u3088\u3073JCheckBox\u306E\u4F7F\u7528\u4F8B\u3092\u7D39\u4ECB\u3057\u307E\u3059\u0020
> 
> trailing whitespace looks unnecessary (accessible description?)

although this is in demo...

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

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

From naoto at openjdk.org  Mon Oct 24 20:02:54 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:02:54 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

The problem here is that all those (unnecessary) trailing spaces are appended by the external translators, who are not aware those spaces should not be at the end. I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

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

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

From angorya at openjdk.org  Mon Oct 24 20:12:02 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Oct 2022 20:12:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
Message-ID: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>

On Mon, 24 Oct 2022 19:58:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think what we can do is check the original English properties values that the engineers provided, and if there is no trailing spaces there, we can safely remove trailing spaces in localized bundles.

Good idea! I wonder if this should be done as a unit test.  go through all the bundles and check leading/trailing whitespace.

in my experience, the translators also (unintentionally) change the quotes and other symbols, sometimes breaking the code.  I assume the JDK has been exhaustively tested and we have no such problems.

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

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

From naoto at openjdk.org  Mon Oct 24 20:16:56 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Oct 2022 20:16:56 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <hOpyYNSPkQm8SRn5IHc-plflDEnoduQr4HurejO8JRg=.f5380607-e0cf-4fc8-91f8-124a104d86c9@github.com>
 <UGwHhd4Lxgkb_fq1J0eFrNEIfXB8or2LRrWrfOBiuh0=.2266fe08-f382-4bb0-9c2c-fd80a2e2ae26@github.com>
Message-ID: <go6bwGp8ro_LeVwOJyBes4PXwMBEGNyPvq43vxGmmLU=.ed6bfa15-4664-41ab-87a9-51609382b9cf@github.com>

On Mon, 24 Oct 2022 20:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Good idea! I wonder if this should be done as a unit test. go through all the bundles and check leading/trailing whitespace.

Right. Definitely not a job for `jcheck`, but it should be considered somewhere in the l10n process.

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

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

From ihse at openjdk.org  Mon Oct 24 20:39:57 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 24 Oct 2022 20:39:57 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <NfKRwZk2cASJZIeh2KYBJMAy7FTuIm87YyXzt8CT0X4=.767db538-3861-4555-b621-4e65c68e26ef@github.com>
Message-ID: <HMdFi0RZ9_Jhobfq_DLpJY4wycMf6qXcIHo90U8sq80=.4a035bff-b633-400b-bbf4-c3e7111385f3@github.com>

On Mon, 24 Oct 2022 19:39:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I think it would be better to try and remove incidental trailing whitespace first, before encoding any remaining whitespace. Hiding the trailing whitespace as a Unicode escape seems like a bad idea, equivalent to sweeping the issue under the rug. While I agree with the goals of improving the check, I think this is going about it the wrong way, or at least in the wrong order.

I respectfully disagree. I think changing a trailing " " into a "\u0020" is the opposite of hiding it; it is making it plainly visible. In fact, I believe most of these trailing spaces are the result of them not being visible enough (and the tooling not warning).

Secondly, there are a lot of definitely unintentional trailing spaces, in comments and blank lines. I'd say there is factor 10:1 more of these. Getting these out of the way allows developers to focus more clearly on the trailing whitespace that matters: those in the key-value pairs.

And as I said, I intend to file follow-up issues for all files where there is a trailing unicode-sequence whitespace, so it will definitely not be lost on the respective component teams that they have something they need to address.

> Maybe it would be a good idea to first validate the default/English files, checking for incidental whitespace there, then check localized versions of each property against the English version.

That's probably a good idea, but I think we should leave that to each respective team. Just like Andy's and Naoto's suggestion of improving i18n tooling to detect issues like this earlier on. Good idea, but I'd like to see that implemented separated from this PR. This PR is already large. The only reason it makes sense is because all changes (except the one to jcheck) are automatically generated and trivial to verify correctness of. If we were to start adding individual, manual changes into this PR, it would be just a huge mess.

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

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

From cjplummer at openjdk.org  Tue Oct 25 03:16:49 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Oct 2022 03:16:49 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <qb_ryMLGem495x0rBbOxd4vVGYPmnRiOkynx6AmvZVE=.5c5d3ee8-8498-4d6d-bfec-04a075ab085c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Changes requested by cjplummer (Reviewer).

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

I believe this space was just a typo and should be removed. Same for `agent.err.agentclass.failed` below and in all the other management property files.

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

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

From weijun at openjdk.org  Tue Oct 25 13:30:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:30:53 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <c28cQxkcVp8YCkAe0wDP4b7cUvb424JsH9ls5bR3m48=.31cad672-bef6-4d55-983d-2cb32a0cafea@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

test/jdk/javax/net/ssl/Stapling/TEST.properties line 5:

> 3:     java.base/sun.security.util \
> 4:     java.base/sun.security.validator \
> 5:     java.base/sun.security.x509\u0020

I'm quite sure this space can be safely removed.

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

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

From weijun at openjdk.org  Tue Oct 25 13:47:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Oct 2022 13:47:02 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

I noticed another problem. In some English properties files (Ex: `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`), `\u0020` is already used today but it turns into a whitespace in the translated files. It looks like the translation tool (most likely written in Java) decoded it while reading the English file but was not able to encode it back in a translation. I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

I suggest we focus on the English files this time and file a bug to the translation tool.

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

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

From naoto at openjdk.org  Tue Oct 25 17:31:52 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Oct 2022 17:31:52 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <BDbRiYAxlM0zHt3mTYNyT58TmpoUMzvMZRFOiDNYu3w=.4baf9ec2-c392-41f4-8de2-c9021b4c6e2c@github.com>
Message-ID: <CWhtHdVfwiBt9m16ZvVgfFbu-h9bRwVLYmwORiLTSVA=.210b4cf3-7f67-4f32-9983-b9fe54bd1571@github.com>

On Tue, 25 Oct 2022 13:43:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I wonder if this means even if we get everything right now the tool might add trailing spaces again later.

Good catch, Max. Yes, that should be dealt with in the translation process.

> I suggest we focus on the English files this time and file a bug to the translation tool.

Agree.

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

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

From asotona at openjdk.org  Wed Oct 26 09:33:08 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Oct 2022 09:33:08 GMT
Subject: RFR: 8294739: jdk/jshell/ToolShiftTabTest.java timed out
Message-ID: <kMOXPHvT14VvR6nzGa4VHazSYOAkXv1Nvdw0mxM7WtE=.3544c361-e053-40fc-85fd-32ae83a2997a@github.com>

ToolShiftTabTest::testFixImport intermittently timeouts.
Reason is exhaustive busy waiting loop for completion  to be ready.
Proposed patch fixes the test loop.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8294739: jdk/jshell/ToolShiftTabTest.java timed out

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

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

From asotona at openjdk.org  Wed Oct 26 10:47:57 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 26 Oct 2022 10:47:57 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]"
Message-ID: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>

File completion in CommandCompletionTest::testSet intermittently fails.
Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
"lists don't have the same size expected [2] but found [1]".

Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).

Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.

Please review.

Thanks,
Adam

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

Commit messages:
 - CommandCompletionTest removed from ProblemList
 - Merge branch 'master' into JDK-8295814
 - 8295814: jdk/jshell/CommandCompletionTest.java fails with "lists don't have the same size expected [2] but found [1]"

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

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

From dcubed at openjdk.org  Wed Oct 26 16:10:16 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 26 Oct 2022 16:10:16 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]"
In-Reply-To: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
Message-ID: <6lSpdP3-lGE8AJNU7SVwJtXLYsZt_7rVZ5nKx4UL0E4=.4c508117-fb46-46dd-b85f-189bfafdeb3a@github.com>

On Wed, 26 Oct 2022 10:28:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> File completion in CommandCompletionTest::testSet intermittently fails.
> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
> "lists don't have the same size expected [2] but found [1]".
> 
> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
> 
> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
> 
> Please review.
> 
> Thanks,
> Adam

@asotona - please see this comment that I added to the bug:

https://bugs.openjdk.org/browse/JDK-8295814?focusedCommentId=14532614&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14532614

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

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

From dfuchs at openjdk.org  Wed Oct 26 16:11:27 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 16:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
Message-ID: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>

Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.

The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 

This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.

In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.

In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.

Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.

The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

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

Commit messages:
 - Fix whitespace issues
 - 8294241

Changes: https://git.openjdk.org/jdk/pull/10874/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294241
  Stats: 849 lines in 82 files changed: 701 ins; 2 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

From michaelm at openjdk.org  Wed Oct 26 16:45:22 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 26 Oct 2022 16:45:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/JarURLConnection.java line 177:

> 175:         @SuppressWarnings("deprecation")
> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
> 177: 

I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

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

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

From weijun at openjdk.org  Wed Oct 26 16:48:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Oct 2022 16:48:22 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <6CBNoueQtp5P8wa0FuOCHQtmw9610BdOrP7pvhg1g70=.6cc91f26-df33-4722-9c49-f390ed6387aa@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

The change to security-related code looks fine to me.

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

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

From jlahoda at openjdk.org  Wed Oct 26 17:02:26 2022
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 26 Oct 2022 17:02:26 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]"
In-Reply-To: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
Message-ID: <Ml_34J-pUbNbYoDN2eatumQ3_TlcABsJF_NRJm-V26w=.3660d9b1-2e25-4e9a-8fff-353ff47645b2@github.com>

On Wed, 26 Oct 2022 10:28:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> File completion in CommandCompletionTest::testSet intermittently fails.
> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
> "lists don't have the same size expected [2] but found [1]".
> 
> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
> 
> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
> 
> Please review.
> 
> Thanks,
> Adam

+1 on the improvement for the logging (although it is unfortunate the TestNG assert is not logging the difference properly by itself, as old asserts did).

But, I wonder if there are particular data showing the problem is in duplicate entries in `getRootDirectories()`. Offhand, that would seem like a less likely explanation. The expected value is a combination of files and directories in the current working directory, and the root directories. To me, it would seem like a more likely explanation that there is a file or directory that initially exists in the current working directory, but then disappears before the completion is computed.

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

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

From xuelei at openjdk.org  Wed Oct 26 17:11:27 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:11:27 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)

What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

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

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

From dfuchs at openjdk.org  Wed Oct 26 17:29:01 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:29:01 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
Message-ID: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>

On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/URL.java line 852:
> 
>> 850:      * @since 20
>> 851:      */
>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
> 
> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?

`URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

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

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

From xuelei at openjdk.org  Wed Oct 26 17:42:31 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 26 Oct 2022 17:42:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
Message-ID: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>

On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URL.java line 852:
>> 
>>> 850:      * @since 20
>>> 851:      */
>>> 852:     public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>> 
>> What do you think to have this method in URI instead: URI.toURL(URLStreamHandler), as there is an URI.toURL() method already?
>
> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.

I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.

I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.

Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

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

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

From dfuchs at openjdk.org  Wed Oct 26 17:57:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Oct 2022 17:57:40 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
Message-ID: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>

On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> `URLStreamHandler` really belongs to `java.net.URL`, and is an implementation detail of the infrastructure/SPI that makes it possible to eventually call `URL::openConnection`. I do not think it would be appropriate to have such a method in `java.net.URI`. Dealing with `URLStreamHandler` is advanced usage and is not something that a regular developer will need to do, and it is better if it isn't too prominent.
>
> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
> 
> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
> 
> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.

One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

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

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

From duke at openjdk.org  Thu Oct 27 05:16:38 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 05:16:38 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
Message-ID: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>

On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
> 
>> 175:         @SuppressWarnings("deprecation")
>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>> 177: 
> 
> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?

Having?unnamed local?variables[^1] would?probably be?best for?this.

[^1]: https://openjdk.org/jeps/8294349

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

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

From michaelm at openjdk.org  Thu Oct 27 09:21:35 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 27 Oct 2022 09:21:35 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
Message-ID: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>

On Thu, 27 Oct 2022 05:14:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/JarURLConnection.java line 177:
>> 
>>> 175:         @SuppressWarnings("deprecation")
>>> 176:         var tmp = jarFileURL = new URL(spec.substring(0, separator++));
>>> 177: 
>> 
>> I realise that @SuppressWarnings needs a declaration here. I wonder if we could agree a better name for the unused variable name though, like `unusedSW` or something better?
>
> Having?unnamed local?variables[^1] would?probably be?best for?this.
> 
> [^1]: https://openjdk.org/jeps/8294349

How about `_unused` or `_unused1`, `_unused2` then in the meantime?

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

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

From asotona at openjdk.org  Thu Oct 27 10:23:03 2022
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 27 Oct 2022 10:23:03 GMT
Subject: RFR: 8295814: jdk/jshell/CommandCompletionTest.java fails with
 "lists don't have the same size expected [2] but found [1]" [v2]
In-Reply-To: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
References: <Na0DBAYloyp1RwGEhThqH0sPY_SXcugqKczmAoEfMCU=.3000692d-33b6-40be-99bc-52652e76aebb@github.com>
Message-ID: <MtEnaU7t3HRKKvuvqdnNiy7QsAOU8CHPnrFu6rCdcR8=.0261cb6d-7130-446d-90cd-3559a9131397@github.com>

> File completion in CommandCompletionTest::testSet intermittently fails.
> Also message provided by org.testng.Assert::assertEquals is also not very verbose when comparing collections:
> "lists don't have the same size expected [2] but found [1]".
> 
> Cause of the failure is in the expected side of the assertion (CommandCompletionTest::getRootDirectories), which may conatain duplicates. While the actual side of the assertion is distinct (CommandCompletionTest::computeCompletions).
> 
> Proposed patch de-duplicates CommandCompletionTest::getRootDirectories and adds full description of the expected result to the error message for future debugging.
> 
> Please review.
> 
> Thanks,
> Adam

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

  relaxed tests depending on shared folders content

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10870/files
  - new: https://git.openjdk.org/jdk/pull/10870/files/35de303a..c3e8fc0b

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

  Stats: 43 lines in 1 file changed: 10 ins; 26 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10870.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10870/head:pull/10870

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

From dfuchs at openjdk.org  Thu Oct 27 11:28:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 11:28:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
Message-ID: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>

On Thu, 27 Oct 2022 09:17:29 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Having?unnamed local?variables[^1] would?probably be?best for?this.
>> 
>> [^1]: https://openjdk.org/jeps/8294349
>
> How about `_unused` or `_unused1`, `_unused2` then in the meantime?

I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

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

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

From joehw at openjdk.org  Thu Oct 27 17:22:26 2022
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Oct 2022 17:22:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

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

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

From dfuchs at openjdk.org  Thu Oct 27 17:38:24 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 17:38:24 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <tBh10CShbGx1KeYJZdDhGauxqCtbde8z-jJzR3hLQy8=.98f3f0b3-a2e4-4b90-b91a-a2d3e7fb4727@github.com>
Message-ID: <9IeUomzE_jMjeWk2jrzY5-1W8n2JhijVyCPO2mQJrtI=.82a69e23-ccae-43a4-988c-5de54e4aad07@github.com>

On Thu, 27 Oct 2022 17:20:04 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Hi Daniel, if it's not a major improvement, we'd like to keep the java.xml module at the JDK 8 code level. Can we remove the 'var' usage in a few java.xml classes?

No problem - I will make this change when we have settled on a name for the variable `tmp` vs `_unused` (proposed by Michael).

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

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

From aturbanov at openjdk.org  Thu Oct 27 17:54:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 27 Oct 2022 17:54:31 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

test/jdk/java/net/URL/URLFromURITest.java line 268:

> 266:             // - URL authority is null or empty depending on the protocol
> 267:             //   and on whether the URL is hierarchical or not.
> 268:             if (isFileBased  && authority == null) {

Suggestion:

            if (isFileBased && authority == null) {

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

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

From dfuchs at openjdk.org  Thu Oct 27 18:08:34 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Oct 2022 18:08:34 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <o0OnSoBYaxEbOk2xXfpzH5EDpT_EZhI0ghk7XjEpg14=.de307c7f-daaa-49fb-96d2-9b7f36ca30bb@github.com>
Message-ID: <VjAEpSLjpUPyUQcaxoONq7Y6zCqP7glgi8QikqXkakI=.689b7ff2-596a-4a87-ba02-b9c1f1c15c64@github.com>

On Thu, 27 Oct 2022 17:50:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> test/jdk/java/net/URL/URLFromURITest.java line 268:
> 
>> 266:             // - URL authority is null or empty depending on the protocol
>> 267:             //   and on whether the URL is hierarchical or not.
>> 268:             if (isFileBased  && authority == null) {
> 
> Suggestion:
> 
>             if (isFileBased && authority == null) {

Thanks - I will apply this suggestion.

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

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

From duke at openjdk.org  Thu Oct 27 22:19:26 2022
From: duke at openjdk.org (Rob Leland)
Date: Thu, 27 Oct 2022 22:19:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <RaFx3blIdoBXwF7RjK7TFIuqHSxTNk9-C94QaPKmEeg=.118063ff-f956-427a-a2f6-a87fc85dc601@github.com>

On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

Why not go ahead and replace all the usages with fromURI(} to start  with.where possible ?

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

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

From jlaskey at openjdk.org  Thu Oct 27 22:27:47 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Oct 2022 22:27:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview)
Message-ID: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>

Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

Commit messages:
 - Tabs to spaces
 - Force processor before template string expression
 - Correct implNote
 - Add valueGetters method
 - Added RAW template processor
 - Merge branch 'master' into 8285932
 - Rename to ValidatingProcessor
 - Javadoc mistakes
 - Rename TemplateProcessor
 - Clean up tests
 - ... and 4 more: https://git.openjdk.org/jdk/compare/0c13d666...7b2011ac

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285932
  Stats: 7452 lines in 74 files changed: 7263 ins; 45 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From duke at openjdk.org  Thu Oct 27 22:47:26 2022
From: duke at openjdk.org (ExE Boss)
Date: Thu, 27 Oct 2022 22:47:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:

> 113:      * we do not use all those slots, to let the strategies with MethodHandle
> 114:      * combinators to use some arguments.
> 115:      */

Suggestion:

     *
     * @since 20
     */

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:

> 1056:          * @throws Throwable if fails to prepend value (unusual).
> 1057:          */
> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;

This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.

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

The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

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

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

From dfuchs at openjdk.org  Fri Oct 28 14:54:26 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Oct 2022 14:54:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
Message-ID: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>

> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
> 
> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
> 
> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
> 
> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
> 
> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
> 
> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
> 
> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949

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

 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
 - Merge branch 'master' into deprecate-url-ctor-8294241
 - Fix whitespace issues
 - 8294241

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10874/files
  - new: https://git.openjdk.org/jdk/pull/10874/files/25a0188c..fd4ca287

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

  Stats: 25761 lines in 392 files changed: 1581 ins; 23649 del; 531 mod
  Patch: https://git.openjdk.org/jdk/pull/10874.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874

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

From jlaskey at openjdk.org  Fri Oct 28 14:55:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Move StringConcatItem to FormatConcatItem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/7b2011ac..26485968

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

  Stats: 239 lines in 6 files changed: 93 ins; 109 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Fri Oct 28 14:55:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 14:55:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <nbF78tdJdTZRiXjUXn46haW_R5T5nk81XRlVeIgPclk=.bff3dcf8-de07-4ce9-aaca-1b41d7d859e7@github.com>
Message-ID: <8KVfwqrbnCSF-80frLIKExvp7jih3Ltp-UY3eaHuTco=.2f87479c-39d9-4eda-87f4-832b6ac8b9cb@github.com>

On Thu, 27 Oct 2022 21:21:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 115:
> 
>> 113:      * we do not use all those slots, to let the strategies with MethodHandle
>> 114:      * combinators to use some arguments.
>> 115:      */
> 
> Suggestion:
> 
>      *
>      * @since 20
>      */

Updated along with a couple @since 19

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1058:
> 
>> 1056:          * @throws Throwable if fails to prepend value (unusual).
>> 1057:          */
>> 1058:         long prepend(long lengthCoder, byte[] buffer) throws Throwable;
> 
> This?method is?inherently?unsafe, as?`StringConcatFactory` uses?`Unsafe.allocateUninitializedArray(...)` to?construct the?`buffer`, the?intrinsic?implementation of?which ***DOESN?T***?zero?out the?memory?region occupied?by?the?array, which?can?contain potentially?sensitive?data.
> 
> --------------------------------------------------------------------------------
> 
> The?`StringConcatItem`?interface should?be?sealed or?at?least moved?to a?`jdk.internal.*`?package.

Went the sealed class route. Unfortunately, the permitted classes are all package private otherwise I would have moved to an internal package.

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

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

From duke at openjdk.org  Fri Oct 28 16:12:50 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 16:12:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:

> 363:         Objects.requireNonNull(sts, "sts must not be null");
> 364:         if (sts.length == 0) {
> 365:             StringTemplate.of("");

Missing return?

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:

> 365:             StringTemplate.of("");
> 366:         } else if (sts.length == 1) {
> 367:             return sts[0];

Check for null?

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

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

From joehw at openjdk.org  Fri Oct 28 16:43:23 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 28 Oct 2022 16:43:23 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <4ThJRTvihtvhX_xBjaCTHOL4w-VHDJuXTUkvtfRVPvY=.ad69332e-e7a2-43fc-9893-3a27f7ca4d5c@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Thanks Daniel. The java.xml part looks good to me.

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

Marked as reviewed by joehw (Reviewer).

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

From jlaskey at openjdk.org  Fri Oct 28 17:57:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 17:57:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Update TemplateRuntime::combine

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/26485968..20f54dec

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

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

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

From jlaskey at openjdk.org  Fri Oct 28 18:01:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 18:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <CaeRe18nvMBHTuBrsFF0RH1zRSnEOHmdTElcREKQ-VU=.5d4eb970-73f0-4c3b-8037-6a985e082919@github.com>
Message-ID: <HhGc5V1_nIfnkwUhoR0KXdaqK12XDy4UdCwfQpYIHoM=.07435759-8a04-4f58-b244-30d81576cc56@github.com>

On Fri, 28 Oct 2022 16:09:51 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 365:
> 
>> 363:         Objects.requireNonNull(sts, "sts must not be null");
>> 364:         if (sts.length == 0) {
>> 365:             StringTemplate.of("");
> 
> Missing return?

Yep - updated

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 367:
> 
>> 365:             StringTemplate.of("");
>> 366:         } else if (sts.length == 1) {
>> 367:             return sts[0];
> 
> Check for null?

Added null checks

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

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

From mcimadamore at openjdk.org  Fri Oct 28 18:38:20 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <qXjmvDvCAAHmElOuzn4nEUEG3d9bBXRHzmJJZHpGt1o=.9d9eb47e-e661-468b-b1ef-658b3d62cf25@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

Added some comments - will probably have some more at a later point

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

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

From mcimadamore at openjdk.org  Fri Oct 28 18:38:26 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
Message-ID: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>

On Fri, 28 Oct 2022 14:55:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move StringConcatItem to FormatConcatItem

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:

> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");

Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:

> 104:     private final Attr attr;
> 105:     private final Symtab syms;
> 106:     private final Types types;

Why this change?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:

> 4972:         if (processor != null) {
> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);

It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:

> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
> 4138: 
> 4139:             if (typeArguments.size() == 2) {

Is this code correct? TemplateProcessor seems to have just one type argument.

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

> 1: /*

This file shouldn't be here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:

> 346:                 try {
> 347:                     chk.disablePreviewCheck = true;
> 348:                     String autoImports = """

I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.

What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.

As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

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

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

From mcimadamore at openjdk.org  Fri Oct 28 18:38:27 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Oct 2022 18:38:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>

On Fri, 28 Oct 2022 16:09:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
> 
>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>> 4138: 
>> 4139:             if (typeArguments.size() == 2) {
> 
> Is this code correct? TemplateProcessor seems to have just one type argument.

Ah - `templateProcessorType` is not what it seems :-)

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

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

From forax at openjdk.org  Fri Oct 28 18:50:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 18:50:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:

> 30: 
> 31: import java.io.IOException;
> 32: import java.util.*;

Please do not use import *.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:

> 34: import java.lang.invoke.MethodHandles.Lookup;
> 35: import java.lang.template.StringTemplate;
> 36: import java.util.*;

Another import * here

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:

> 116:      * @since 20
> 117:      */
> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;

I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:

> 997:      * Promote integral types to int.
> 998:      */
> 999:     private static Class<?> promoteIntType(Class<?> t) {

promoteToIntType ?

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

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

From forax at openjdk.org  Fri Oct 28 19:02:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:02:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:

> 1040:      * The number of fragments must be one more that the number of ptypes.
> 1041:      * The total number of slots used by the ptypes must be less than or equal
> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.

see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:

> 1058:             throws StringConcatException
> 1059:     {
> 1060:         Objects.requireNonNull(fragments, "fragments is null");

I think you need to do some defensive copy here

  ptypes = List.copyOf(pTypes);

to avoid the types and fragments to be changed at the same time they are checked.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:

> 1175:      */
> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(

I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:

> 49:     /**
> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
> 51:      * bootstrap method information.

This comment is quite obscure if you have no idea how it works.
And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:

> 36: record SimpleStringTemplate(List<String> fragments,
> 37:                              List<Object> values
> 38: ) implements StringTemplate {}

A compact constructor doing defensive copies is missing

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

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

From forax at openjdk.org  Fri Oct 28 19:11:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:11:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:

> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 44: @FunctionalInterface
> 45: public interface StringProcessor extends TemplateProcessor<String> {}

The name should be `StringTemplateProcessor`.
And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:

> 27: 
> 28: import java.lang.invoke.MethodHandle;
> 29: import java.util.*;

Please fix.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:

> 147:      * {@return the interpolation of the StringTemplate}
> 148:      */
> 149:     default String interpolate() {

I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:

> 173:      * method {@code processor.process(this)}.
> 174:      */
> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {

signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:

> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
> 203:      */
> 204:     default public List<MethodHandle> valueGetters() {

I think i prefer the term accessors instead of getters

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

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

From forax at openjdk.org  Fri Oct 28 19:31:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:31:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:

> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
> 306:         }
> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));

I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().

src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:

> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 322:      */
> 323:     public static String interpolate(List<String> fragments, List<Object> values) {

This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:

> 352:      * @implNote The result of interpolation is not interned.
> 353:      */
> 354:     public static final StringProcessor STR = st -> st.interpolate();

Should be `StringTemplate::interpolate`.

src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:

> 36:  * that do not throw checked exceptions. For example:
> 37:  * {@snippet :
> 38:  * TemplateProcessor<String> processor = st -> {

This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:

> 43:  */
> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 45: public final class TemplateRuntime {

Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:

> 63:      * @throws Throwable            if linkage fails
> 64:      */
> 65:     public static CallSite stringTemplateBSM(

I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:

> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();

`ValidatingProcessor<?, ?>` should be enough ? No ?
Not using a "? extends Throwable" here make the type unchecked.

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:

> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
> 87:      */
> 88:     private static class TemplateBootstrap {

This class should be `final`

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:

> 115:          * Static final processor.
> 116:          */
> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;

Use `ValidatingProcessor<?, ?>` here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:

> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
> 144:                                   List<String> fragments,
> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {

Use ValidatingProcessor<?, ?> here

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:

> 209:     @SuppressWarnings("unchecked")
> 210:     public static <E> List<E> toList(E... elements) {
> 211:         return Collections.unmodifiableList(Arrays.asList(elements));

This is List.of(), please use List.of() instead

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

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

From jlaskey at openjdk.org  Fri Oct 28 19:31:37 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
Message-ID: <NMJNYCbIc_ENhRzVNutxnKczkfNmxTs3dR6A1ExqFCA=.28e0b8ce-c7fd-466c-b523-ce79102ed487@github.com>

On Fri, 28 Oct 2022 16:33:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move StringConcatItem to FormatConcatItem
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java line 631:
> 
>> 629:         stringTemplateType = enterClass("java.lang.template.StringTemplate");
>> 630:         templateRuntimeType = enterClass("java.lang.template.TemplateRuntime");
>> 631:         templateProcessorType = enterClass("java.lang.template.ValidatingProcessor");
> 
> Please give it a name that matches the corresponding class - this threw me off when looking at the type-checking code.

Renaming.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 106:
> 
>> 104:     private final Attr attr;
>> 105:     private final Symtab syms;
>> 106:     private final Types types;
> 
> Why this change?

Renaming. Was residual to some context based typing (StringTemplate vs String) Jan and I experimented with.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974:
> 
>> 4972:         if (processor != null) {
>> 4973:             resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType));
>> 4974:             resultType = chk.checkProcessorType(processor, resultType, env);
> 
> It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate.

Not sure where you get `StringTemplate`.  If you specify `TemplateProcessor<String>` the `resultType` will be `String`.  For example:


public class Processor implements TemplateProcessor<String> {
    @Override
    public String process(StringTemplate st) {
        return st.interpolate();
    }
}

and

public class Main {
    public static void main(String... args) throws Throwable {
        Processor processor = new Processor();
        System.out.println(processor."1234");
    }
}

works with "1234" as a result.

If you later change to


public class Processor implements TemplateProcessor<Integer> {
    @Override
    public Integer process(StringTemplate st) {
        return Integer.valueOf(st.interpolate());
    }
}


Then you get a `java.lang.ClassCastException` as you would expect.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java.orig line 1:
> 
>> 1: /*
> 
> This file shouldn't be here

oops - We should change the `.gitignore` to include `.orig` and `.rej`

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 348:
> 
>> 346:                 try {
>> 347:                     chk.disablePreviewCheck = true;
>> 348:                     String autoImports = """
> 
> I see why you went down here. It is pragmatic, given we might add other stuff to the list. But it is mildly odd to see parser being called again from here, although harmless.
> 
> What worries me more is the dance around enabling/disabling preview checks. Again, I see why you went there.
> 
> As a possible alternative to disable preview checks globally, you could instead install a deferred log handler (see Log) class - so that all the diagnostics generated when following imports can be dropped on the floor. (we use this mechanism in DeferredAttr, to disable diagnostics during a deferred attribution step).

This was recommended by Jan and the procedure used in other parts of the code.

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

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

From jlaskey at openjdk.org  Fri Oct 28 19:31:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:31:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v2]
In-Reply-To: <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <xbY7c2MnHGoQFvYIr57yoOhLoqf7Tj7eJlC7FnGLXx8=.e93d32df-0968-4a9e-8295-2f3affc699be@github.com>
 <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com>
 <T2c6VHqkP8KtUD12k4uSB3JJr3yDf3eI9oHO1fEoTOw=.9cbebf8f-3282-480f-96ef-16257b3dec35@github.com>
Message-ID: <Bk1GNLr8K1rN6d6Puz8wVQKeOEUaWvVeK7jiM7wICTY=.fb15a02b-82ec-4c08-9e17-233dfa4fee79@github.com>

On Fri, 28 Oct 2022 16:33:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4139:
>> 
>>> 4137:             List<Type> typeArguments = interfaceType.getTypeArguments();
>>> 4138: 
>>> 4139:             if (typeArguments.size() == 2) {
>> 
>> Is this code correct? TemplateProcessor seems to have just one type argument.
>
> Ah - `templateProcessorType` is not what it seems :-)

Renaming. I held off assuming that bike shedding would change it once again.

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

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

From jlaskey at openjdk.org  Fri Oct 28 19:41:33 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:41:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
Message-ID: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>

On Fri, 28 Oct 2022 18:45:05 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32:
> 
>> 30: 
>> 31: import java.io.IOException;
>> 32: import java.util.*;
> 
> Please do not use import *.

Changing.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36:
> 
>> 34: import java.lang.invoke.MethodHandles.Lookup;
>> 35: import java.lang.template.StringTemplate;
>> 36: import java.util.*;
> 
> Another import * here

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
> 
>> 116:      * @since 20
>> 117:      */
>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
> 
> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.

There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 999:
> 
>> 997:      * Promote integral types to int.
>> 998:      */
>> 999:     private static Class<?> promoteIntType(Class<?> t) {
> 
> promoteToIntType ?

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1060:
> 
>> 1058:             throws StringConcatException
>> 1059:     {
>> 1060:         Objects.requireNonNull(fragments, "fragments is null");
> 
> I think you need to do some defensive copy here
> 
>   ptypes = List.copyOf(pTypes);
> 
> to avoid the types and fragments to be changed at the same time they are checked.

Changing

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

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

From forax at openjdk.org  Fri Oct 28 19:41:34 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:41:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:

> 287:         try {
> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",

This should be a constant (using the class holder idiom or not)

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:

> 300: 
> 301:     /**
> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}

Private "method"

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:

> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
> 324:      */
> 325:     static String interpolate(List<String> fragments, List<Object> values) {

I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:

> 387:             }
> 388:         }
> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));

It seems that IntelliJ was lot when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

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

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

From jlaskey at openjdk.org  Fri Oct 28 19:51:49 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Remove .orig file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/20f54dec..347df715

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

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

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

From forax at openjdk.org  Fri Oct 28 19:51:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:51:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
Message-ID: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>

On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TemplateRuntime::combine

src/java.base/share/classes/java/util/FormatProcessor.java line 198:

> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
> 197:      */
> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);

`Locale.US` or `Locale.ROOT` ??
see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

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

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

From forax at openjdk.org  Fri Oct 28 19:55:07 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 19:55:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
Message-ID: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>

On Fri, 28 Oct 2022 19:34:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 118:
>> 
>>> 116:      * @since 20
>>> 117:      */
>>> 118:     public static final int MAX_INDY_CONCAT_ARG_SLOTS = 200;
>> 
>> I do not think it's a good idea to make that constant available for everybody given that it's an artefact of the implementation.
>
> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.

But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

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

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

From duke at openjdk.org  Fri Oct 28 20:01:29 2022
From: duke at openjdk.org (Franz =?UTF-8?B?V2lsaGVsbXN0w7Z0dGVy?=)
Date: Fri, 28 Oct 2022 20:01:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>

On Fri, 28 Oct 2022 19:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
> 
>> 209:     @SuppressWarnings("unchecked")
>> 210:     public static <E> List<E> toList(E... elements) {
>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
> 
> This is List.of(), please use List.of() instead

`List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:

public static <E> List<E> toList(E... elements) {
	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
}

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

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

From forax at openjdk.org  Fri Oct 28 20:01:30 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
Message-ID: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>

On Fri, 28 Oct 2022 19:51:21 GMT, Franz Wilhelmst?tter <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 211:
>> 
>>> 209:     @SuppressWarnings("unchecked")
>>> 210:     public static <E> List<E> toList(E... elements) {
>>> 211:         return Collections.unmodifiableList(Arrays.asList(elements));
>> 
>> This is List.of(), please use List.of() instead
>
> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
> 
> public static <E> List<E> toList(E... elements) {
> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
> }

Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
Using that implementation will avoid a bunch of indirection

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

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

From forax at openjdk.org  Fri Oct 28 20:25:35 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
Message-ID: <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>

On Fri, 28 Oct 2022 19:52:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> There have been several requests to make it public in the past.  You really can't use the methods in this class unless you know the value. Better to have the value exposed instead of developers transcribing the value into their code.
>
> But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area.

Anyway, i think you are right, this can be public

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

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

From jlaskey at openjdk.org  Fri Oct 28 20:25:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
Message-ID: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>

On Fri, 28 Oct 2022 18:52:28 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
> 
>> 1040:      * The number of fragments must be one more that the number of ptypes.
>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
> 
> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public

Disagree.

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
> 
>> 1175:      */
>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
> 
> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not

Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 51:
> 
>> 49:     /**
>> 50:      * Construct a {@link MethodHandle} that constructs a result based on the
>> 51:      * bootstrap method information.
> 
> This comment is quite obscure if you have no idea how it works.
> And the information that the returned method handle has the type of the MethodType passed as parameter is missing.

Deliberate obscure for preview. Once we sort out the functional space you have been looking for, this will likely go away. ProcessorFactory and ProcessorBuilder are a couple of the possibilities.

> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
> 
>> 36: record SimpleStringTemplate(List<String> fragments,
>> 37:                              List<Object> values
>> 38: ) implements StringTemplate {}
> 
> A compact constructor doing defensive copies is missing

The defensive copies are done by the callers.

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
> 
>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 44: @FunctionalInterface
>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
> 
> The name should be `StringTemplateProcessor`.
> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
> 
> see TemplateProcessor

Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

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

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

From forax at openjdk.org  Fri Oct 28 20:25:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 28 Oct 2022 20:25:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
Message-ID: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>

On Fri, 28 Oct 2022 20:01:41 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1042:
>> 
>>> 1040:      * The number of fragments must be one more that the number of ptypes.
>>> 1041:      * The total number of slots used by the ptypes must be less than or equal
>>> 1042:      * to MAX_INDY_CONCAT_ARG_SLOTS.
>> 
>> see my comment about making MAX_INDY_CONCAT_ARG_SLOTS public
>
> Disagree.

As i said above, i consider this thread as resolved

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1177:
>> 
>>> 1175:      */
>>> 1176:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 1177:     public static List<MethodHandle> makeConcatWithTemplateCluster(
>> 
>> I think instead of having two public methods and the user having to choose between them, it's better to have the implementations private and on public methods that calls the correct implementation if maxSlots > MAX_INDY_CONCAT_ARG_SLOTS or not
>
> Use cases are very different.  The first one produces a `MethodHandle` that has multiple inputs, The second one produces a `MethodHandle` that can only have one input.

yes, sorry for the noise.

>> src/java.base/share/classes/java/lang/template/SimpleStringTemplate.java line 38:
>> 
>>> 36: record SimpleStringTemplate(List<String> fragments,
>>> 37:                              List<Object> values
>>> 38: ) implements StringTemplate {}
>> 
>> A compact constructor doing defensive copies is missing
>
> The defensive copies are done by the callers.

In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

>> src/java.base/share/classes/java/lang/template/StringProcessor.java line 45:
>> 
>>> 43: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 44: @FunctionalInterface
>>> 45: public interface StringProcessor extends TemplateProcessor<String> {}
>> 
>> The name should be `StringTemplateProcessor`.
>> And i'm not sure it's useful to have a specialized version for String, TemplateProcessor<String> is not an issue given that most of the time people will implement it, so writing `implements StringTemplateProcessor` instead of `implements TemplateProcessor<String>` does not seem to offer enough bangs for bucks.
>> 
>> see TemplateProcessor
>
> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`

Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?

People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

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

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

From duke at openjdk.org  Fri Oct 28 23:54:22 2022
From: duke at openjdk.org (j3graham)
Date: Fri, 28 Oct 2022 23:54:22 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
Message-ID: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>

On Fri, 28 Oct 2022 19:51:49 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove .orig file

src/java.base/share/classes/java/util/FormatterBuilder.java line 470:

> 468:      */
> 469:     MethodHandle build() {
> 470:         Formatter.parse(format);

`Formatter.parse` is called here, and then again a few lines down.

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

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

From jjg at openjdk.org  Sat Oct 29 00:05:32 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 29 Oct 2022 00:05:32 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <r_58JHoKmjUmSoO1PboxKdQoV8yJ3nwjDn_KIIr5o7k=.13c13918-f42e-4f5b-9557-6894e2b301fb@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

The changes in `jdk.compiler` and `jdk.javadoc` seem innocuous enough.  Because of the bootstrap issue/latency, we'll have to wait before we can update to non-deprecated code.

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

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

From duke at openjdk.org  Sat Oct 29 01:03:23 2022
From: duke at openjdk.org (ExE Boss)
Date: Sat, 29 Oct 2022 01:03:23 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>

On Fri, 28 Oct 2022 19:13:54 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
> 
>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 322:      */
>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
> 
> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.

Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.

The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

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

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

From aturbanov at openjdk.org  Sat Oct 29 10:00:24 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 29 Oct 2022 10:00:24 GMT
Subject: RFR: 8277348: Use String.stripTrailing() in jdk.jshell where
 applicable [v2]
In-Reply-To: <9ZTNjFmoBgjdsjNcBVE9J0uAJK2ZeiPKu3fs3joLHbk=.76707c97-8bf0-4868-8cec-bf6b766df0fb@github.com>
References: <9ZTNjFmoBgjdsjNcBVE9J0uAJK2ZeiPKu3fs3joLHbk=.76707c97-8bf0-4868-8cec-bf6b766df0fb@github.com>
Message-ID: <OdrYQYp1TXdQsIfZ1LAu_AB614nTkOOauXj-84__o0Q=.a5fcbd1f-3fec-47f0-aee0-e5a9fb68e597@github.com>

> There are 2 methods in jdk.jshell module which trim trailing whitespace characters from String.
> 1. jdk.internal.jshell.tool.JShellTool#trimEnd
> 2. jdk.jshell.Util#trimEnd
> 
> Since Java 11 we have a method String.stripTrailing which could be used instead.

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - 8277348: Use String.stripTrailing() in jdk.jshell where applicable
   
   update copyright year
 - Merge remote-tracking branch 'origin/master' into use_String.stripTrailing_in_jdk.jshell
   
   # Conflicts:
   #	src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
 - [PATCH] Use String.stripTrailing() in jdk.jshell where applicable

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

Changes: https://git.openjdk.org/jdk/pull/6365/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=6365&range=01
  Stats: 43 lines in 4 files changed: 0 ins; 33 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/6365.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/6365/head:pull/6365

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

From jpai at openjdk.org  Sat Oct 29 11:58:26 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 11:58:26 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <nFQpK3FHftsI2QvZzRA9ugonzsgB7g9tc6DneWBib_g=.4a284c8d-e3c0-4a33-97d1-d02144637493@github.com>
 <06JPOqCxfz_76ezNcUJXk0No3C803feUe4rqa5VVPZk=.5e212b37-e268-41f5-ac01-c76bab054f9a@github.com>
 <SmOJrlZsr4NBZ1LY8VV500b9v9ssh78FUHF7y235AgU=.75960e91-7103-4f60-a114-fddebb73e176@github.com>
 <JMZ_-77lTdemvfC3K54z8FRMXEuYGV44PHhjhPBnZFk=.e732f51f-7d8c-4ad0-980f-6e93946d43b8@github.com>
Message-ID: <FfQ1_F-GP2tNy3JiwtPN-BLBK6E8b636tX8T1Vfl_5U=.a3f9410a-72fd-4dc2-87d8-35bf91897af9@github.com>

On Thu, 27 Oct 2022 11:24:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How about `_unused` or `_unused1`, `_unused2` then in the meantime?
>
> I'd be happy to make the change. Let's wait to see if anybody has a better naming suggestion.

Hello Daniel, I think calling it `unused` is fine. I did a quick search in the JDK code and we already have places where we use such a variable name for similar usecase. I don't see the need for using an underscore as a prefix, but it is OK with me if you and others prefer to use it.

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

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

From jpai at openjdk.org  Sat Oct 29 12:05:07 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Oct 2022 12:05:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <-1KLQD601j2R4Nmsx9FTo0it7p19hqJoHefzwSCf8XY=.7c94a888-654b-446d-bba3-780b7527d684@github.com>
 <S65yO829xpFquf_0qZL40W28TAUcMLNWsGFk9ivhX3U=.0bd08598-a85d-4205-8744-d1369d38109e@github.com>
 <H7V9nDZ0f8En5Tae61vHsrrDSFNJTBTL2b0bzy9bP48=.a320aae1-520d-47fb-8b60-5035178a611b@github.com>
 <PBw5ZRbl4k_dpeOwMDShAL3ZVEvtMoA05wxR-moxRuU=.448e97e5-2725-4851-a2cd-f4107954a6ce@github.com>
Message-ID: <zzbb3oae_BJ3Xn5x5xJB3tfugG41Om9Mv6LhbXOKH1c=.9ac9052a-8d9f-4450-95df-599ebabc6476@github.com>

On Wed, 26 Oct 2022 17:51:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see your point.  It may be more appropriate if URI.toURL was designed as URL.fromURL.
>> 
>> I was wondering to have application developers a consistent way to get an URL instance.  Now there are two methods in different classes URI.toURL and URL.fromURI.  It might be easier to use the old URI.toURL form.
>> 
>> Never mind, it is just my personal preference.  It is fine to me to have a new URL.fromURI method.
>
> One thing we might do is change the name of the method into `URL.of(URI, StreamHandler)`. It's named `fromURI` merely because there was a pre-existing package protected `fromURI` method. However since we're making it public now, it could be fair game to change its name. Possibly adding an overload `URL::of(URI)` method could be considered, but then there really would be two paths to do the same thing - so I'd rather not add such an overload - unless I get some more feedback on that from the CSR/PR review.

I think `URL.of(URI, URLStreamHandler)` is fine.

As for `URL.of(URI)`, whose implementation I suspect will just do `uri.toURL()` on the passed `URI`, I don't think we need it. It might add to unnecesary confusion on whether/when to use `URL.of(URI)` and when to use `URI.toURL()`

In the case of `URL.of(URI, URLStreamHandler)` it's pretty clear that you use it (only) when you have a specific `URLStreamHandler` to use for the constructed `URL`.

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

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

From aivanov at openjdk.org  Sat Oct 29 12:14:25 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 12:14:25 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <tY6WEcLB-4FPLTsYbhyUOEoZQvt7VTahPfopID5mzjY=.53ecf0f0-2d6f-4eb2-933e-dcff87b505b0@github.com>
Message-ID: <rzIw7fkMmSiQ4HJygtWh3SxVIIZg4QY0nvByxOYUyGs=.b878366e-a60f-410f-94ae-47b486f4e7b5@github.com>

On Mon, 24 Oct 2022 19:29:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Remove check for .properties from jcheck"
>>    
>>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>>  - Change trailing space and tab in values to unicode encoding
>
> src/java.sql.rowset/share/classes/com/sun/rowset/RowSetResourceBundle.properties line 134:
> 
>> 132: 
>> 133: #SyncResolverImpl exceptions
>> 134: syncrsimpl.indexval = Index value out of range\u0020\u0020
> 
> prob. unnecessary

This case is similar the one you mentioned below. If this value is used in a string template or concatenation, the trailing white-space could be necessary; however, one space is probably enough.

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

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

From aivanov at openjdk.org  Sat Oct 29 13:22:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 29 Oct 2022 13:22:09 GMT
Subject: RFR: 8295729: Add jcheck whitespace checking for properties files
 [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <4Npxj4pEaiqkJ2UBTsYb3xTHYseNBoj_3yshwocOIxw=.c701af52-62db-40c2-b3a3-90e47c44ed76@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

Trailing spaces in `LocaleNames_*` are only in two files:

- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties`
- `src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_sv.properties`

It is very unlikely these spaces are part of a country or language name. The former file contains a few trailing spaces, the latter ? only one.

src/jdk.localedata/share/classes/sun/util/resources/ext/LocaleNames_de.properties line 238:

> 236: cpp=Kreolisch-Portugiesische Sprache
> 237: crh=Krimtatarisch
> 238: crp=Kreolische Sprache\u0020

I'm pretty sure locale names shouldn't contain trailing spaces.

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

Marked as reviewed by aivanov (Reviewer).

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

From alanb at openjdk.org  Sat Oct 29 14:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Oct 2022 14:28:07 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <HzzVXi1AJRgDYz_ckHTjIb1L01BjpauxNy7o0RbOC_I=.ef1fbcdd-58e0-42b5-a87d-4cce016f0893@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

src/java.base/share/classes/java/net/URL.java line 133:

> 131:  * specified. The optional fragment is not inherited.
> 132:  *
> 133:  * <h2><a id="constructor-deprecation"></a>Constructing instances of {@code URL}</h2>

Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated?

src/java.base/share/classes/java/net/URL.java line 157:

> 155:  * The URL constructors are specified to throw
> 156:  * {@link MalformedURLException} but the actual parsing/validation
> 157:  * that are performed is implementation dependent. Some parsing/validation

"the ... are performed" -> "the ... is performed".

src/java.base/share/classes/java/net/URL.java line 166:

> 164:  * The {@code java.net.URL} constructors are deprecated.
> 165:  * Developers are encouraged to use {@link URI java.net.URI} to parse
> 166:  * or construct any {@code URL}. In cases where an instance of {@code

"any URL" -> "a URL" or "all URLs".

src/java.base/share/classes/java/net/URL.java line 168:

> 166:  * or construct any {@code URL}. In cases where an instance of {@code
> 167:  * java.net.URL} is needed to open a connection, {@link URI} can be used
> 168:  * to construct or parse the URL string, possibly calling {@link

I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString.

src/java.base/share/classes/java/net/URL.java line 852:

> 850:      * @since 20
> 851:      */
> 852:     public static URL of(URI uri, URLStreamHandler streamHandler)

The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion.

src/java.base/share/classes/java/net/URL.java line 885:

> 883: 
> 884:             @SuppressWarnings("deprecation")
> 885:             var result = new URL("jrt", host, port, file, null);

The URL scheme for jrt does have a port so we should look at that some time.

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

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

From forax at openjdk.org  Mon Oct 31 07:17:49 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 07:17:49 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
Message-ID: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>

On Sat, 29 Oct 2022 00:56:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 323:
>> 
>>> 321:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>>> 322:      */
>>> 323:     public static String interpolate(List<String> fragments, List<Object> values) {
>> 
>> This method also exists has a static method, having both is a bad idea because it makes StringTemplate::interpolate a compile error, the compiler has no way to know that it's the same implementation.
>
> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
> 
> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.

Ok, get it.
I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.

The less methods in the API, the better.

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

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

From jlaskey at openjdk.org  Mon Oct 31 12:39:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:39:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <EQVJmKVbtnwEXTfgghVb4mU5BE4xtbqoLDTOgwCmqDU=.73928cc8-ed53-4da1-81dd-a5b847aa9595@github.com>

On Fri, 28 Oct 2022 20:23:26 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Wrong use case. Think `StringProcessor upper = st -> st.interpolate().toUpperCase();`
>
> Is it that different from`TemplateProcessor<String> upper = st -> st.interpolate().toUpperCase();` ?
> 
> People are really used to use <> with the functional interfaces of java.util.function, and you avoid the "two ways" to express the same thing.

Noted

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

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

From jlaskey at openjdk.org  Mon Oct 31 12:53:29 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:29 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <OIUDXCNftOdGHiKS44vTdCuDosKklkect9B3NrfkNNk=.2a399201-95dd-4f7c-a768-14da71da6c41@github.com>

On Fri, 28 Oct 2022 20:07:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The defensive copies are done by the callers.
>
> In that case, i wonder if not not better to move that record inside another class, closer to where the callers are

Moving to TemplateRuntime

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

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

From jlaskey at openjdk.org  Mon Oct 31 12:53:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:53:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <hEQTvtQgMLQMCZHJWaVzJzCGo_H7PAYWpR_X8Vs3Hcw=.c9102791-3f62-4222-afea-3aba32323325@github.com>

On Fri, 28 Oct 2022 19:05:10 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 29:
> 
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
>> 29: import java.util.*;
> 
> Please fix.

Changing

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

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

From jlaskey at openjdk.org  Mon Oct 31 12:59:36 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 12:59:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <ZE2vcmQWISh2duTMkVFwVLUj4JfRFSR5ZQ9gz8AWhgk=.e9946cbe-e5a4-4a9c-a2c6-f309bd536142@github.com>

On Fri, 28 Oct 2022 19:06:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 175:
> 
>> 173:      * method {@code processor.process(this)}.
>> 174:      */
>> 175:     default <R, E extends Throwable> R process(ValidatingProcessor<R, E> processor) throws E {
> 
> signature should be `ValidatingProcessor<? extends R, ? extends E> processor`

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 204:
> 
>> 202:      * embedded expressions fields, otherwise this method returns getters for the values list.
>> 203:      */
>> 204:     default public List<MethodHandle> valueGetters() {
> 
> I think i prefer the term accessors instead of getters

Changing

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:04:32 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:04:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
Message-ID: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>

On Fri, 28 Oct 2022 19:08:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
> 
>> 147:      * {@return the interpolation of the StringTemplate}
>> 148:      */
>> 149:     default String interpolate() {
> 
> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy

Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <n5D2AKUK150bLdl1X1PAp8RZQ9Oo4EOJh863F8tMSMQ=.078b48c3-59bb-40c1-a3df-660242f8ae74@github.com>

On Fri, 28 Oct 2022 19:12:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/StringTemplate.java line 307:
> 
>> 305:             Objects.requireNonNull(fragment, "fragments elements must be non-null");
>> 306:         }
>> 307:         fragments = Collections.unmodifiableList(new ArrayList<>(fragments));
> 
> I think using `List.copyOf()` is more efficient that `Collections.unmodifiableList(new ArrayList<>(...))` because there is no copy if the list is already created with List.of().
> 
> Edit:
> fragments should use List.copyOf() but i suppose that a value inside values can be null, so you can not use List.copyOf() for the values.
> 
> There a little secret, the ImmutableList  has a special flag to represent an unmodifiable list that can access null, this implementation is used by `stream.toList()`, i think you should use a shared secret access to have have access to this implementation instead of relying on `Collections.unmodifiableList(new ArrayList<>(...))`.
> 
> @stuart-marks, do you think it's a good idea to use the null allowed ImmutableList here ?

Changing as recommended

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 354:
> 
>> 352:      * @implNote The result of interpolation is not interned.
>> 353:      */
>> 354:     public static final StringProcessor STR = st -> st.interpolate();
> 
> Should be `StringTemplate::interpolate`.

Yep

> src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 38:
> 
>> 36:  * that do not throw checked exceptions. For example:
>> 37:  * {@snippet :
>> 38:  * TemplateProcessor<String> processor = st -> {
> 
> This is a good example of why having both way to describe a template processor of string, TemplateProcessor<String and `StringPorcessor` is a bad idea.

Noted

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:40:38 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:40:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <1z__57riFNdKeH9suhrdghSWvqOephCqEHsEZNIYyxI=.8baaf50c-f9fc-4cf9-be80-9cf7e93dbca8@github.com>
 <tKFfjNxQlnujdkks6xs_bz7zj25Xu78HCxTP-6vBFqA=.eaa0f100-d584-436c-9997-0dc3b898dc23@github.com>
Message-ID: <IQ1cw48hyO6eHZumI9fehaIEPEFhx4GHZaRtexHoW7k=.b9cb907b-f4f7-4bbb-ace7-32c86b86fdfe@github.com>

On Mon, 31 Oct 2022 07:14:45 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Actually, `StringTemplate::interpolate` is?fine, as?this?method takes?two?parameters, whereas the?instance?method only?takes an?implicit `this`?parameter.
>> 
>> The?instance?method is?only?assignable to?`Function<StringTemplate, String>` or?`Supplier<String>`, and?the?static?method is?only?assignable to?`BiFunction<List<String>, List<Object>, String>`.
>
> Ok, get it.
> I still see not reason to have this method being public given that this is equivalent to `Template.of(fragments, values).interpolate()`.
> 
> The less methods in the API, the better.

Noted

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:49:18 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com>

On Fri, 28 Oct 2022 19:20:40 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45:
> 
>> 43:  */
>> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 45: public final class TemplateRuntime {
> 
> Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc)

Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 65:
> 
>> 63:      * @throws Throwable            if linkage fails
>> 64:      */
>> 65:     public static CallSite stringTemplateBSM(
> 
> I wonder if this method should be moved to a class named `TemplateProcesorFactory` inside `java.lang.runtime`? Like the all the bootstrap methods recently added.

Will work on it.

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:49:20 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:49:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
 <MgrbKiLk6zgXStZPO4BTKlb_LQywda818nHGjuK81x4=.0d08c25a-4240-4efe-ac77-ba7fec7def1e@github.com>
 <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com>
Message-ID: <bGVojc8FhYiLJbpzQl5TyXcYKzEurvx_Sf9Mc0R5IkA=.c35beb5c-11d4-4413-a766-82e7fd200bdf@github.com>

On Fri, 28 Oct 2022 19:57:41 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> `List.of()` can't be used here, since the elements are nullable, according to the documentation. But the the returned list can still be modified, by changing the given `elements` array. The input array must be explicitly copied:
>> 
>> public static <E> List<E> toList(E... elements) {
>> 	return Collections.unmodifiableList(new ArrayList<>(Arrays.asList(elements)));
>> }
>
> Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used).
> Using that implementation will avoid a bunch of indirection

Changing to use `JUCA`.

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

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

From jlaskey at openjdk.org  Mon Oct 31 13:54:44 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 13:54:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <FX944qXhJQEfYq57azNhngLKYfgX85DkqRZo6CZW3kQ=.899d3824-ce51-4746-8c96-d3436615c725@github.com>
Message-ID: <Z7QI2E1zswpmzuoUkBJzlEYAh1l9iOcTYwe82y4X2Uw=.0056169c-283a-4012-a943-c7223b67485e@github.com>

On Fri, 28 Oct 2022 19:26:20 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 79:
> 
>> 77:         MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class);
>> 78:         ValidatingProcessor<?, ? extends Throwable> processor =
>> 79:                 (ValidatingProcessor<?, ? extends Throwable>)processorGetter.asType(processorGetterType).invokeExact();
> 
> `ValidatingProcessor<?, ?>` should be enough ? No ?
> Using a "? extends Throwable" here make the type unchecked.

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 88:
> 
>> 86:      * Manages the boostrapping of {@link ProcessorLinkage} callsites.
>> 87:      */
>> 88:     private static class TemplateBootstrap {
> 
> This class should be `final`

Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 117:
> 
>> 115:          * Static final processor.
>> 116:          */
>> 117:         private final ValidatingProcessor<?, ? extends Throwable> processor;
> 
> Use `ValidatingProcessor<?, ?>` here

That works. Changing.

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 145:
> 
>> 143:         private TemplateBootstrap(MethodHandles.Lookup lookup, String name, MethodType type,
>> 144:                                   List<String> fragments,
>> 145:                                   ValidatingProcessor<?, ? extends Throwable> processor) {
> 
> Use ValidatingProcessor&lt;?, ?&gt; here

That works. Changing.

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

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

From jlaskey at openjdk.org  Mon Oct 31 14:30:28 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:30:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <K46-FD72Mtz3zFIhWwj9_0QI100Sy4_XE2q34hxNyMU=.9e66b1d0-5031-4564-8404-e1b545f2fafa@github.com>

On Fri, 28 Oct 2022 19:33:38 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 289:
> 
>> 287:         try {
>> 288:             MethodHandles.Lookup lookup = MethodHandles.lookup();
>> 289:             MethodHandle getter = lookup.findStatic(TemplateRuntime.class, "getValue",
> 
> This should be a constant (using the class holder idiom or not)

Changing

> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 302:
> 
>> 300: 
>> 301:     /**
>> 302:      * Private ethod used by {@link TemplateRuntime#valueGetters(StringTemplate)}
> 
> Private "method"

Changing

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

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

From jlaskey at openjdk.org  Mon Oct 31 14:39:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:39:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <EprEHey_-RlxTSqSiEgb7upgHtblKqAQO6mM_Exgqjs=.eaf0be7b-85d2-4179-847c-da5d07c80eb7@github.com>

On Fri, 28 Oct 2022 19:39:01 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 389:
> 
>> 387:             }
>> 388:         }
>> 389:         return new SimpleStringTemplate(java.lang.template.TemplateRuntime.toList(fragments), java.lang.template.TemplateRuntime.toList(values));
> 
> It seems that IntelliJ was lost when auto-completing or doing a refactoring given that you are alreay in the class TemplateRuntime.

Changing

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

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

From jlaskey at openjdk.org  Mon Oct 31 14:49:30 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 14:49:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <dYbncntg4ut06nU1VZnH-LNHESE3JEK2zEabeI29avs=.8a81dfcb-86ef-4418-b8db-c8c80085486d@github.com>
Message-ID: <hJKj6jjb0I6mnmYZW8CO7T_AfPDBzbz1B4xuG8mZ9Gc=.b156b047-8839-4447-b21f-fbe7b3b4eb8f@github.com>

On Fri, 28 Oct 2022 19:36:07 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 325:
> 
>> 323:      * @throws NullPointerException fragments or values is null or if any of the fragments is null
>> 324:      */
>> 325:     static String interpolate(List<String> fragments, List<Object> values) {
> 
> I think it should be better to ensure that the caller always call with a List.of() or a List.copyOf() so null is not a possible element

Changing

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

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

From jlaskey at openjdk.org  Mon Oct 31 15:01:31 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <ZXOR2DFGeBi_5SAcLFwI8AFN6twTWHwmH3EXtQ-PbPM=.451cefa6-0079-44d1-9d10-12aaa1c9a2fe@github.com>
Message-ID: <YUiKJ6MKELuPwEDxpmhH3AEsMk8mG7vLANniLjwaGuM=.d88e51b7-a807-4892-8dd0-977ab9fa8037@github.com>

On Fri, 28 Oct 2022 19:45:55 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update TemplateRuntime::combine
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 198:
> 
>> 196:      * {@link FMT} uses the Locale.US {@link Locale}.
>> 197:      */
>> 198:     public static final FormatProcessor FMT = new FormatProcessor(Locale.US);
> 
> `Locale.US` or `Locale.ROOT` ??
> see https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Locale.html#ROOT

There was a bug in DecimalFormatSymbols when I started this work and Locale.ROOT was problematic. I didn't circle around to check later. Changing.

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

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

From jlaskey at openjdk.org  Mon Oct 31 15:01:35 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:01:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v4]
In-Reply-To: <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Vm-ESzckLkw2CBnaGn9P34yT9X57cU6topVrmIRPwPU=.25208860-5b2d-44c5-847a-beaae99b64ac@github.com>
 <bIcwEOMV4yvuGyqyMUSc5QrN7OY7YCYPO1uHeRhx_oI=.b9ea045c-9c7c-4859-8a56-1d16cc9ee448@github.com>
Message-ID: <HhniXeb1FMUt_2zLv1ioKD232wB4uGp6wNf06Lym3KI=.977dc53f-abe0-47dc-b06b-9475f919308c@github.com>

On Fri, 28 Oct 2022 23:50:11 GMT, j3graham <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove .orig file
>
> src/java.base/share/classes/java/util/FormatterBuilder.java line 470:
> 
>> 468:      */
>> 469:     MethodHandle build() {
>> 470:         Formatter.parse(format);
> 
> `Formatter.parse` is called here, and then again a few lines down.

Residue cruft. Thanks. Changing.

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

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

From jlaskey at openjdk.org  Mon Oct 31 15:38:42 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 15:38:42 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v5]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <UEq7NU7NgwbZA9fmIW88hdE8TtJfMV1xgTUoyT9UUGQ=.9fa69424-0a2f-4909-8f77-8b1109f407d0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Requested changes #2
 - Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/347df715..d30e6eff

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

  Stats: 168 lines in 15 files changed: 60 ins; 60 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From forax at openjdk.org  Mon Oct 31 15:55:28 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 15:55:28 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v3]
In-Reply-To: <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <l_ff7IsHVffAdt_Pjlpq9jDZ-zJ6-BHZWqoFpuBxrXQ=.33205308-fafc-41f4-bd51-de1dab633b64@github.com>
 <AuXu5Tt-BH4uF77lfyoruGNOx5ZzaWaXf-mrYBwkCn0=.5b58dd3c-7105-45c8-9298-e9a285ea98f0@github.com>
Message-ID: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com>

On Mon, 31 Oct 2022 13:02:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/template/StringTemplate.java line 149:
>> 
>>> 147:      * {@return the interpolation of the StringTemplate}
>>> 148:      */
>>> 149:     default String interpolate() {
>> 
>> I wonder if all the default methods should not be better as static methods given that they are not the important part of the API but more side information that may be handy
>
> Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage  of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor<JSONObject> JSON = st -> new JSONObject(st.interpolate());`

Interesting !
I believe the javadoc should mention that.

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

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

From jlaskey at openjdk.org  Mon Oct 31 17:39:58 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 17:39:58 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v6]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <DJB8X-GwBxtqwAX0Rv_zRn_GhLXHyCF2-1RszcbcVtc=.532ca016-1d04-40f1-8523-399e24d59d75@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Move template bootstrap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d30e6eff..75fcc49a

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

  Stats: 364 lines in 4 files changed: 210 ins; 147 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Mon Oct 31 20:11:34 2022
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 31 Oct 2022 20:11:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Add @SafeVarargs declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/75fcc49a..6d1d902e

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

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

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

From forax at openjdk.org  Mon Oct 31 20:49:36 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:49:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <ZMO73T5DijZRuY1syZG_RLF5MAYKZP6ExGtpTxCeToo=.a9194cfa-96f0-4a5d-af04-040b692f4842@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132:

> 130:             return result;
> 131:         }
> 132:         for (Object value : st.values()) {

I think that valueTypes() should return the types of the values not the dynamic classes of the values.
Here there is no type information so it should be Object for all values.

It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent.

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

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

From forax at openjdk.org  Mon Oct 31 20:54:33 2022
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 31 Oct 2022 20:54:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <hfpGudVxbuScm9qfmg7NrTNXwG3iowWfXvP7FF6jdT8=.91f0e3f9-ed56-4f80-bb8a-835a3706df03@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119:

> 117:         Class<?> tsClass = st.getClass();
> 118:         if (tsClass.isSynthetic()) {
> 119:             try {

I do not know if this code is worth of optimizing but the way to avoid to recompute the List<Class<?>> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class<?>[] -> List<Class<?>>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here

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

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

From smarks at openjdk.org  Mon Oct 31 21:25:41 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 31 Oct 2022 21:25:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates
 (Preview) [v7]
In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com>
Message-ID: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com>

On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SafeVarargs declarations

src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99:

> 97:     private static <E> List<E> toList(E... elements) {
> 98:         return JUCA.listFromTrustedArrayNullsAllowed(elements);
> 99:     }

I'm ok with using JUCA to create an unmodifiable list that can contain nulls.

However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable.

In particular, the call site in StringTemplate.of()

https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309

passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path.

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

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

From prr at openjdk.org  Mon Oct 31 22:02:15 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 31 Oct 2022 22:02:15 GMT
Subject: RFR: 8294241: Deprecate URL public constructors [v2]
In-Reply-To: <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
References: <EIGXBfWfGgY-Uu-igdMELFeq032c1B6m0aLYSjPgU_c=.38875a6c-a0c1-4aa0-9c8d-67a177ed6b57@github.com>
 <hfaizoBQtD0okGjw2PMSRxVfxvcad_bwZTeNC4rvB-g=.531151b3-ef86-4b61-9110-cd70372637a1@github.com>
Message-ID: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com>

On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL.
>> 
>> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. 
>> 
>> This has lead to many issues in the past.  Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account.
>> 
>> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred.
>> 
>> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as  part of this change.
>> 
>> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`.  Some related issues will be logged to revisit the calling code.
>> 
>> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml
>  - Merge branch 'master' into deprecate-url-ctor-8294241
>  - Fix whitespace issues
>  - 8294241

Deprecate URL constructors.
Developers are encouraged to use java.net.URI to parse or construct any URL.
...
To construct a URL, using URI::toURL should be preferred.

You have jumped through some refactoring hoops to be able to apply the deprecation suppression
to as little code as possible .. having made such changes, then why didn't you just make the
recommended change instead ?

Should I presume that the recommended route will have some nasty little incompatibilities
we will need to be careful of first ?

And what about Peter Firmstone's comment
"We stopped using java.net.URI some years ago as it's obsolete.?"

I can't reconcile that with the recommendation to use it ..

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

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