From vromero at openjdk.org  Mon Apr  1 18:33:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 1 Apr 2024 18:33:29 GMT
Subject: RFR: 8328383: Method is not used:
 com.sun.tools.javac.comp.Attr::thisSym
Message-ID: <wazOTNLp-Qxdo-qRhtkx5l6FXn9ondASY7BRSysg2L8=.392c30e6-ed31-436b-a802-81d3e104d514@github.com>

Please review this simple fix that is just removing a method not used by any client. As indicated in the title the method belong to class `com.sun.tools.javac.comp.Attr`

TIA

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

Commit messages:
 - 8328383: Method is not used: com.sun.tools.javac.comp.Attr::thisSym

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

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

From duke at openjdk.org  Tue Apr  2 09:16:01 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 2 Apr 2024 09:16:01 GMT
Subject: RFR: 8325217: MethodSymbol.getModifiers() returns SEALED for
 restricted methods
In-Reply-To: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
References: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
Message-ID: <jsrwiNu3wk3MB2gyml3J2a0clk_09pKwMCwVsiMypcU=.69d70861-49e3-49b1-a718-f49c22276c48@github.com>

On Fri, 29 Mar 2024 01:17:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix, basically javadoc is showing the `sealed` modifier for methods annotated with the `jdk.internal.javac.Restricted` annotation. This is because the `SEALED` and `RESTRICTED` flags share the same bit. The proposed solution is to drop the `RESTRICTED` flag at MethodSymbol::getModifiers before converting the flags to modifiers,
> 
> TIA,
> Vicente

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1999:

> 1997:             // just in case the method is restricted but that is not a modifier
> 1998:             long flags = flags() & ~RESTRICTED;
> 1999:             return Flags.asModifierSet((flags & DEFAULT) != 0 ? flags & ~ABSTRACT : flags);

Maybe?`Flags::asModifierSet` could?be?extended in?another?PR to?take a?parameter for?the?different modifier?kinds, which?would then?be?used to?disambiguate overloaded?`Flags`?bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18543#discussion_r1547464269

From duke at openjdk.org  Tue Apr  2 12:57:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 2 Apr 2024 12:57:08 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

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

> 1413:                                                      canonicalConstructorTypes,
> 1414:                                                      List.nil());
> 1415:         createNew.constructor = init;

Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):

DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]


with?the `derivedConstructor` bootstrap?method:

public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
	requireNonNull(lookup);
	requireNonNull(type);
	// implicit null-check:
	List<String> modifiedComponentNames = List.of(modifiedComponents);

	Class<?> rtype = type.returnType();
	if (
		!rtype.isRecord()
		|| type.parameterCount() != modifiedComponents.length + 1
		|| type.parameterType(0) != rtype
	) {
		throw new IllegalArgumentException("...");
	}

	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
	}

	RecordComponent[] recordComponents = rtype.getRecordComponents();

	var componentTypes = new Class<?>[recordComponents.length];
	var filters = new MethodHandle[recordComponents.length];
	var reorder = new int[recordComponents.length];

	for (int i = 0, j = 1; i < recordComponents.length; i++) {
		var component = recordComponents[i];
		componentTypes[i] = component.getType();

		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
		if (modifiedComponentNames.contains(component.getName())) {
			remainingComponentNames.remove(component.getName());
			filters[i] = null;
			reorder[i] = j++;
		} else {
			filters[i] = getter;
			reorder[i] = 0;
		}
	}

	if (!remainingComponentNames.isEmpty()) {
		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);
	}

	var canonicalConstructor = lookup.findConstructor(rtype, MethodType.methodType(rtype, componentTypes);
	var filteredConstructor = MethodHandles.filterArguments(canonicalConstructor, 0, filters);
	// implicitly verifies that type's parameter types match the actual component types
	var permutedConstructor = MethodHandles.permuteArguments(filterArguments, type, reorder);

	return permutedConstructor;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1547819538

From vromero at openjdk.org  Tue Apr  2 15:04:00 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 2 Apr 2024 15:04:00 GMT
Subject: RFR: 8325217: MethodSymbol.getModifiers() returns SEALED for
 restricted methods
In-Reply-To: <jsrwiNu3wk3MB2gyml3J2a0clk_09pKwMCwVsiMypcU=.69d70861-49e3-49b1-a718-f49c22276c48@github.com>
References: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
 <jsrwiNu3wk3MB2gyml3J2a0clk_09pKwMCwVsiMypcU=.69d70861-49e3-49b1-a718-f49c22276c48@github.com>
Message-ID: <AdrJAhuHAavjv4Y_uGs6kauciaWex3gavJpZEkd2Pm4=.bed695f3-f96e-49c8-b08d-e3cb0bfdda2e@github.com>

On Tue, 2 Apr 2024 09:13:03 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Please review this simple fix, basically javadoc is showing the `sealed` modifier for methods annotated with the `jdk.internal.javac.Restricted` annotation. This is because the `SEALED` and `RESTRICTED` flags share the same bit. The proposed solution is to drop the `RESTRICTED` flag at MethodSymbol::getModifiers before converting the flags to modifiers,
>> 
>> TIA,
>> Vicente
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1999:
> 
>> 1997:             // just in case the method is restricted but that is not a modifier
>> 1998:             long flags = flags() & ~RESTRICTED;
>> 1999:             return Flags.asModifierSet((flags & DEFAULT) != 0 ? flags & ~ABSTRACT : flags);
> 
> Maybe?`Flags::asModifierSet` could?be?extended in?another?PR to?take a?parameter for?the?different modifier?kinds, which?would then?be?used to?disambiguate overloaded?`Flags`?bits.

yep we could have other instances of this same issue in the future

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18543#discussion_r1548068147

From darcy at openjdk.org  Tue Apr  2 18:08:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Apr 2024 18:08:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2032717646

From darcy at openjdk.org  Tue Apr  2 18:12:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 2 Apr 2024 18:12:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
Message-ID: <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>

On Tue, 2 Apr 2024 18:05:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.

I can help develop the visitor changes if you'd like.

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2032724647

From acobbs at openjdk.org  Tue Apr  2 18:18:59 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 2 Apr 2024 18:18:59 GMT
Subject: RFR: 8328649: Disallow enclosing instances for local classes in
 constructor prologues
In-Reply-To: <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com>
References: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
 <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com>
Message-ID: <nZcOfJR1stBsM6VTW2MeZj_24a8Bpqo0t79-qLmklMc=.17e7bb86-b2c7-44a0-ad96-d2059aaff037@github.com>

On Thu, 21 Mar 2024 21:49:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo).
>> 
>> However, the compiler is allowing code like this to successfully compile:
>> 
>> import java.util.concurrent.atomic.*;
>> public class Test extends AtomicReference<Object> {
>>   
>>     public Test() {
>>         super(switch (0) {
>>           default -> {
>>               class Local { { Test.this.hashCode(); } }   // this should fail
>>               yield null;
>>             }
>>         });
>>     }
>> }
>> 
>> This patch fixes the "leak".
>
> looks good to me

@vicente-romero-oracle, would you (or anyone) mind reviewing the [associated CSR](https://bugs.openjdk.org/browse/JDK-8328706) per @jddarcy's request?

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18416#issuecomment-2032737965

From mchung at openjdk.org  Tue Apr  2 18:55:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 2 Apr 2024 18:55:12 GMT
Subject: Integrated: 8326979: (jdeps) improve the error message for
 FindException caused by InvalidModuleDescriptorException
In-Reply-To: <Kk24dug_yvI5s_W8v636SACpzJia3TDHPDbCrOQiKHg=.edcd1d99-564c-4308-b914-53eaf7c7180d@github.com>
References: <Kk24dug_yvI5s_W8v636SACpzJia3TDHPDbCrOQiKHg=.edcd1d99-564c-4308-b914-53eaf7c7180d@github.com>
Message-ID: <PqcIILqvCeo8EV0x28U1IlwOFSwt6Sn9k8CZl0vv7gc=.a012c6c1-481b-4e2b-9ecb-92be4169bf71@github.com>

On Thu, 14 Mar 2024 17:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.  Improve the error message to print the cause of the module resolution failure if present.

This pull request has now been integrated.

Changeset: 044f4ed5
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/044f4ed55dfce7f1aed9e10accf459b4af9b975e
Stats:     89 lines in 2 files changed: 88 ins; 0 del; 1 mod

8326979: (jdeps) improve the error message for FindException caused by InvalidModuleDescriptorException

Reviewed-by: jpai, alanb

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

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

From josiahnoel at gmail.com  Tue Apr  2 18:55:40 2024
From: josiahnoel at gmail.com (Josiah Noel)
Date: Tue, 2 Apr 2024 14:55:40 -0400
Subject: Elements#getDocComment returns null for record components
Message-ID: <CAJ_t5UZNTA_R4BFrtLRD8XPedxh+uzwV=KRbtn+Q-Jz0c9N=-A@mail.gmail.com>

Hello there,

It seems that when I try to read the Javadoc for record components with my
annotation processor, I get null. When I convert the record into a regular
class it works as expected.
-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240402/74c05783/attachment-0001.htm>

From vromero at openjdk.org  Tue Apr  2 19:14:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 2 Apr 2024 19:14:09 GMT
Subject: RFR: 8328649: Disallow enclosing instances for local classes in
 constructor prologues
In-Reply-To: <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com>
References: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
 <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com>
Message-ID: <6W8G5C10uJaLNVUC5O7pTEHO7JKyjprP2FZEBFUZsiU=.289c6db1-abde-441f-bf2a-4969b99d865e@github.com>

On Thu, 21 Mar 2024 21:49:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo).
>> 
>> However, the compiler is allowing code like this to successfully compile:
>> 
>> import java.util.concurrent.atomic.*;
>> public class Test extends AtomicReference<Object> {
>>   
>>     public Test() {
>>         super(switch (0) {
>>           default -> {
>>               class Local { { Test.this.hashCode(); } }   // this should fail
>>               yield null;
>>             }
>>         });
>>     }
>> }
>> 
>> This patch fixes the "leak".
>
> looks good to me

> @vicente-romero-oracle, would you (or anyone) mind reviewing the [associated CSR](https://bugs.openjdk.org/browse/JDK-8328706) per @jddarcy's request?
> 
> Thanks.

looks good

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

PR Comment: https://git.openjdk.org/jdk/pull/18416#issuecomment-2032865591

From darcy at openjdk.org  Wed Apr  3 06:00:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 06:00:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <LNXC3butqNvq566NxesHBtfldFXC4irGFLvII-f3kPo=.644dd63f-0901-4bae-878a-c0d5b7cbe5b1@github.com>
 <xedikVjcXFBPNR3yrDWrR70EQ50R00FE9YCF_fC3jxY=.984cb642-db6d-48c9-b976-3e55f9b5a23f@github.com>
Message-ID: <6fCRor2HD_QqKJVqLkMG7ON3rnHkZ_B9dNLLuOSebcg=.0b0d66c6-1523-4858-857a-f9ebfb02516b@github.com>

On Tue, 2 Apr 2024 18:09:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > For the `javax.lang.model` changes, as a new ElementKind is being introduced, there should be a matching layer of new concrete visitors and selected updates to existing visitor implementations, etc.
> 
> I can help develop the visitor changes if you'd like.

PS On top the state of the code in webrev 04, I took a first pass over what I think the javax.lang.model support should look like:

https://github.com/openjdk/jdk/pull/18590

HTH

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

PR Comment: https://git.openjdk.org/jdk/pull/18509#issuecomment-2033598036

From darcy at openjdk.org  Wed Apr  3 06:02:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 06:02:04 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record Creation
 (Preview)
Message-ID: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>

Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

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

Commit messages:
 - Add more support for component local variables.
 - Add uses of new visitor types.
 - JDK-8329556: javax.lang.model suppor for Derived Record Creation (Preview)
 - Baseline on 04 version of the webrev.

Changes: https://git.openjdk.org/jdk/pull/18590/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329556
  Stats: 1640 lines in 49 files changed: 1550 ins; 20 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/18590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18590/head:pull/18590

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

From jlahoda at openjdk.org  Wed Apr  3 07:16:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 Apr 2024 07:16:09 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
Message-ID: <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>

On Tue, 2 Apr 2024 12:50:19 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1415:
> 
>> 1413:                                                      canonicalConstructorTypes,
>> 1414:                                                      List.nil());
>> 1415:         createNew.constructor = init;
> 
> Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):
> 
> DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]
> 
> 
> with?the `derivedConstructor` bootstrap?method:
> 
> public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
> 	requireNonNull(lookup);
> 	requireNonNull(type);
> 	// implicit null-check:
> 	List<String> modifiedComponentNames = List.of(modifiedComponents);
> 
> 	Class<?> rtype = type.returnType();
> 	if (
> 		!rtype.isRecord()
> 		|| type.parameterCount() != modifiedComponents.length + 1
> 		|| type.parameterType(0) != rtype
> 	) {
> 		throw new IllegalArgumentException("...");
> 	}
> 
> 	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
> 	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
> 		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
> 	}
> 
> 	RecordComponent[] recordComponents = rtype.getRecordComponents();
> 
> 	var componentTypes = new Class<?>[recordComponents.length];
> 	var filters = new MethodHandle[recordComponents.length];
> 	var reorder = new int[recordComponents.length];
> 
> 	for (int i = 0, j = 1; i < recordComponents.length; i++) {
> 		var component = recordComponents[i];
> 		componentTypes[i] = component.getType();
> 
> 		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
> 		if (modifiedComponentNames.contains(component.getName())) {
> 			remainingComponentNames.remove(component.getName());
> 			filters[i] = null;
> 			reorder[i] = j++;
> 		} else {
> 			filters[i] = getter;
> 			reorder[i] = 0;
> 		}
> 	}
> 
> 	if (!remainingComponentNames.isEmpty()) {
> 		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);
> 	}
> 
> 	var canonicalConstructor = lookup.findConstructor(rtype, MethodType.methodType(rtype, componentTypes);
> ...

While this is very smart, I would prefer not to do that. JLS 13.4.27 talks about binary compatibility for record, and warns that adding or removing components may break record usages. So I don't think we need to provide too much support for adding or removing record components.

Overall, I believe the current code adheres to what the JLS draft says. If the author of the record wants to add or remove components, they can make it so that the existing compiled code still works (by adding constructor overloads and keeping the accessors for removed component). It is better, IMO, to keep the behavior predictable, and leave adjustments after record component modifications up to the record author, than to introduce some magic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1549052694

From ihse at openjdk.org  Wed Apr  3 10:04:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 10:04:01 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

The build changes look okay. 

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1976255818

From abimpoudis at openjdk.org  Wed Apr  3 14:50:42 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 Apr 2024 14:50:42 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on switch
 on sealed classes
Message-ID: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>

This PR addresses the issue that the expected signature for `typeSwitch` is different prior JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.

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

Commit messages:
 - 8328747: WrongMethodTypeException with pattern matching on switch on sealed classes

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

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

From abimpoudis at openjdk.org  Wed Apr  3 15:00:25 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 3 Apr 2024 15:00:25 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v2]
In-Reply-To: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
Message-ID: <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>

> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.

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

  Append empty line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18606/files
  - new: https://git.openjdk.org/jdk/pull/18606/files/ba7a0449..95e153b4

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

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

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

From jlahoda at openjdk.org  Wed Apr  3 15:24:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 Apr 2024 15:24:59 GMT
Subject: RFR: 8328383: Method is not used:
 com.sun.tools.javac.comp.Attr::thisSym
In-Reply-To: <wazOTNLp-Qxdo-qRhtkx5l6FXn9ondASY7BRSysg2L8=.392c30e6-ed31-436b-a802-81d3e104d514@github.com>
References: <wazOTNLp-Qxdo-qRhtkx5l6FXn9ondASY7BRSysg2L8=.392c30e6-ed31-436b-a802-81d3e104d514@github.com>
Message-ID: <x-JsfhbEPV5qe40fl_Uh0mvzCfHpJrKJFc1uqnZds2k=.7beaaf5b-6318-490f-916a-25b6a7224bf0@github.com>

On Mon, 1 Apr 2024 18:27:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is just removing a method not used by any client. As indicated in the title the method belong to class `com.sun.tools.javac.comp.Attr`
> 
> TIA

Looks OK.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18566#pullrequestreview-1977175103

From jlahoda at openjdk.org  Wed Apr  3 15:25:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 3 Apr 2024 15:25:09 GMT
Subject: RFR: 8325217: MethodSymbol.getModifiers() returns SEALED for
 restricted methods
In-Reply-To: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
References: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
Message-ID: <iiRXncs4i5n17nAiz-QpkzSuGTxugxio9BEUamyF2F0=.93fde4aa-84bf-49fc-8965-71c74a323829@github.com>

On Fri, 29 Mar 2024 01:17:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix, basically javadoc is showing the `sealed` modifier for methods annotated with the `jdk.internal.javac.Restricted` annotation. This is because the `SEALED` and `RESTRICTED` flags share the same bit. The proposed solution is to drop the `RESTRICTED` flag at MethodSymbol::getModifiers before converting the flags to modifiers,
> 
> TIA,
> Vicente

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18543#pullrequestreview-1977176838

From vromero at openjdk.org  Wed Apr  3 15:58:11 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 15:58:11 GMT
Subject: Integrated: 8328383: Method is not used:
 com.sun.tools.javac.comp.Attr::thisSym
In-Reply-To: <wazOTNLp-Qxdo-qRhtkx5l6FXn9ondASY7BRSysg2L8=.392c30e6-ed31-436b-a802-81d3e104d514@github.com>
References: <wazOTNLp-Qxdo-qRhtkx5l6FXn9ondASY7BRSysg2L8=.392c30e6-ed31-436b-a802-81d3e104d514@github.com>
Message-ID: <eoZXxOYxYN7bDh-o5HrKsiMPcjwUcOLTTMkyoFE9-vw=.8f960735-7978-480d-a062-5e3f8c413a84@github.com>

On Mon, 1 Apr 2024 18:27:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is just removing a method not used by any client. As indicated in the title the method belong to class `com.sun.tools.javac.comp.Attr`
> 
> TIA

This pull request has now been integrated.

Changeset: 1c691938
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c691938e98a2dd825f20b58a0032b6a0c9b03b2
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8328383: Method is not used: com.sun.tools.javac.comp.Attr::thisSym

Reviewed-by: jlahoda

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

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

From vromero at openjdk.org  Wed Apr  3 15:59:04 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 15:59:04 GMT
Subject: Integrated: 8325217: MethodSymbol.getModifiers() returns SEALED for
 restricted methods
In-Reply-To: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
References: <wTLUHdPYB5g7ataiX3pb2T4y9jSut5N-6KfsZz6PcrM=.8e0566cd-d875-454b-93d1-0bb5dd9ae14e@github.com>
Message-ID: <w7VhSdR0s6ua78lr7r68Co5g5CAfh0U05AQ8CR7Y22A=.6f190845-7b0c-4141-a946-71d0440cc69d@github.com>

On Fri, 29 Mar 2024 01:17:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix, basically javadoc is showing the `sealed` modifier for methods annotated with the `jdk.internal.javac.Restricted` annotation. This is because the `SEALED` and `RESTRICTED` flags share the same bit. The proposed solution is to drop the `RESTRICTED` flag at MethodSymbol::getModifiers before converting the flags to modifiers,
> 
> TIA,
> Vicente

This pull request has now been integrated.

Changeset: 8dc43aa0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8dc43aa0fe8cdba2a2953258de02c6afa072987a
Stats:     10 lines in 2 files changed: 1 ins; 2 del; 7 mod

8325217: MethodSymbol.getModifiers() returns SEALED for restricted methods

Reviewed-by: jlahoda

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

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

From cushon at openjdk.org  Wed Apr  3 19:02:08 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 3 Apr 2024 19:02:08 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v2]
In-Reply-To: <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
 <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>
Message-ID: <C6Ya6jKTkkm2WP9tOd9fLe17NJa4UuWJTKMiDk_9gAo=.9ad0d0d4-2615-4f68-a66b-ea6e85d344b5@github.com>

On Wed, 3 Apr 2024 15:00:25 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Append empty line

This looks good to me.

I double-checked that it fixes the original code that I minimized for the bug report. Thanks for the fix!

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java line 232:

> 230:     /** Releases prior to JDK 23 expect a less precise SwitchBootstraps.typeSwitch signature on the selectorType
> 231:      */
> 232:     public boolean releaseAfterJEP455() {

Perhaps consider a more descriptive method name instead of referring to the JEP number, for consistency with the other method names in this class.

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

Marked as reviewed by cushon (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18606#pullrequestreview-1977714422
PR Review Comment: https://git.openjdk.org/jdk/pull/18606#discussion_r1550297407

From darcy at openjdk.org  Wed Apr  3 20:23:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 20:23:53 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
Message-ID: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>

When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.

The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.

To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

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

Commit messages:
 - Remove accidentally added file.
 - JDK-8329624: Add visitors for preview language features

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

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

From darcy at openjdk.org  Wed Apr  3 20:32:08 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 20:32:08 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <wr5jlKvUcAM_oVcnoUABHesCpi7U8WwKHvWImcw9DEk=.cea6f91a-6e00-4a95-a0db-c2060ecf6a10@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as #18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

When one of the preview visitors is subclassed, javac emits a warning like:


javac VisitorTest.java 
VisitorTest.java:2: warning: [preview] ElementKindVisitorPreview is a reflective preview API and may be removed in a future release.
public class VisitorTest extends javax.lang.model.util.ElementKindVisitorPreview {
                                                      ^
1 warning


Once these preview visitors are present, the particular API to support language change P can be added and reviewed without being dwarfed in the overall scaffolding. The anticipated usage would be:

Methods particular to supporting preview feature P can be annotated accordingly to indicate that usage.
When P goes to a final feature, a new set of JDK $N visitors would be inserted between to latest numbered set of visitors and the preview visitors. Methods particular to P would be moved up into the new JDK $N visitors.

For example, if feature P when final in JDK 25, there would be a new set of JDK 25 concrete visitors extended the existing JDK 14 visitors and superclass of the preview visitors would be changed from the JDK 14 visitor to the corresponding JDK 25 visitor. Methods associated with feature P would be moved up from the preview visitors into the JDK 25 visitors.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2035521547

From vromero at openjdk.org  Wed Apr  3 20:37:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 20:37:10 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v2]
In-Reply-To: <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
 <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>
Message-ID: <cxjFus-nYfXr1r_FyXPxwatWlbYBE2uiidbnYtRlND8=.81903ab4-5287-4aae-880c-415da0cc3fa7@github.com>

On Wed, 3 Apr 2024 15:00:25 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Append empty line

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

> 498:             boolean primitiveSelector = seltype.isPrimitive();
> 499:             Name bootstrapName = enumSelector ? names.enumSwitch : names.typeSwitch;
> 500:             MethodSymbol bsm = rs.resolveInternalMethod(tree.pos(), env, syms.switchBootstrapsType,

side: variable `primitiveSelector` is not used and could be removed

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

> 501:                     bootstrapName, staticArgTypes, List.nil());
> 502: 
> 503:             Type resolvedSelectorType = syms.objectType;

isn't this change assigning Object to `resolvedSelectorType` for more cases than before JEP455? not sure if there is a semantic change here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18606#discussion_r1550418688
PR Review Comment: https://git.openjdk.org/jdk/pull/18606#discussion_r1550420697

From vromero at openjdk.org  Wed Apr  3 21:36:00 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 21:36:00 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

looks good

src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:

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

general, please check the copyright years

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18609#pullrequestreview-1978047611
PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550497836

From darcy at openjdk.org  Wed Apr  3 21:41:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 3 Apr 2024 21:41:09 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
Message-ID: <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>

On Wed, 3 Apr 2024 21:05:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
>> 
>> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
>> 
>> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.
>
> src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> general, please check the copyright years

Starting with 2019 was intentional as I copied the corresponding FooVisitor14 file into FooVisitorPreview and then began editing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550538694

From josiahnoel at gmail.com  Wed Apr  3 21:43:01 2024
From: josiahnoel at gmail.com (Josiah Noel)
Date: Wed, 3 Apr 2024 17:43:01 -0400
Subject: Elements#getDocComment returns null for record components
In-Reply-To: <CAJ_t5UZNTA_R4BFrtLRD8XPedxh+uzwV=KRbtn+Q-Jz0c9N=-A@mail.gmail.com>
References: <CAJ_t5UZNTA_R4BFrtLRD8XPedxh+uzwV=KRbtn+Q-Jz0c9N=-A@mail.gmail.com>
Message-ID: <CAJ_t5UbDioA4wTTRTkK=itx_ExBJN13Dn+iwfRHpqAzGmxdsuw@mail.gmail.com>

I have created a simple project that reproduces the issue:
SentryMan/record-javadoc-APT-bug
(github.com) <https://github.com/SentryMan/record-javadoc-APT-bug>

On Tue, Apr 2, 2024 at 2:55?PM Josiah Noel <josiahnoel at gmail.com> wrote:

> Hello there,
>
> It seems that when I try to read the Javadoc for record components with my
> annotation processor, I get null. When I convert the record into a regular
> class it works as expected.
> --
> Cheers, Josiah.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240403/5060472f/attachment.htm>

From vromero at openjdk.org  Wed Apr  3 21:46:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 3 Apr 2024 21:46:10 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <nGUN4Wc51exZPWebfpBm2TmW8xLIJSotYJtcASZ1Yuo=.03bf5332-2eea-437d-9b4f-4c7e441cf5d3@github.com>
 <S7CI2vfGV7MKjgctDNmZ5V02VPiICf0nLsVNmNwVjMA=.489b5516-89a3-4756-ae5a-7b4d4232797f@github.com>
Message-ID: <NfA1ahYApo0VlcqPIRys0Nbx95LwLpU48ak2wtfLzxw=.3a66cd42-da9f-45bc-812e-9d9c6f17c3ec@github.com>

On Wed, 3 Apr 2024 21:38:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> general, please check the copyright years
>
> Starting with 2019 was intentional as I copied the corresponding FooVisitor14 file into FooVisitorPreview and then began editing.

ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18609#discussion_r1550548814

From acobbs at openjdk.org  Thu Apr  4 02:17:30 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 Apr 2024 02:17:30 GMT
Subject: RFR: 8329595: spurious variable "might not have been initialized" on
 static final field
Message-ID: <sH-ZiQYOeLi7YOl8Wd7IIi8arNrLgyPHUUImi3GKbIs=.0978e242-0f44-4abd-b2e4-0dfe7209d508@github.com>

This bug causes the compiler to generate a bogus error `variable NAME might not have been initialized` for the following program:

public class StaticFinalNestedClass {
    public class Inner {
        public static final String NAME;
        static {
            try {
                NAME = "bob";
            } catch (Exception e) {
                throw new Error(e);
            }
        }
    }
}

An interesting fact is that if you make the class `Inner` a `static` inner class, then the bug disappears. The oddness of that fact is indicative of the oddness of the underlying problem, some of which I probably contributed to and which I'll try to summarize...

First some background. The various flow analyzers are written to recurse through the entire AST including nested classes in one go. So for example if there is an inner class, the analysis of the outer class is paused while the inner class is analyzed, and then the former state is restored and the outer class analysis proceeds. This causes a bit of chaos in situations where the analyzer needs to "jump around" for whatever reason. For example, when `super()` is encountered while analyzing a constructor, we need to analyze any field initializers because that's when they execute.

As a result, there are several cases where the same code gets visited more than once, which is not harmful but is obviously inefficient. But it also leads to this bug.

So what is the actual bug? The bug is that (one of the times) the inner class static initializer was being checked for uninitialized variables was when the outer class constructor was being analyzed, and that analysis recursed into the inner class. Because the outer class constructor was being analyzed, and no other method had been entered yet, the `isConstructor` flag was still set to `true`, so the code that marks all fields as initialized when an exception is thrown from a constructor or static initializer (because the instance or class is unusable so don't bother complaining about uninitialized fields) was only marking the instance fields.

In commit 12e983a72e72 I did some refactoring to create a method `forEachInitializer()` for analyzing initializers, but the existing behavior of recursing into nested classes was preserved in order to not break things. With this commit, in order to impose some order, `forEachInitializer()` is being changed to not recurse into nested classes. Instead, the various bits of code that use `forEachInitializer()` and also need to recurse into nested classes now do that explicitly themselves (and the rest do not, eliminating some redundancy). This change also makes it easier to fix the actual bug - the bug fix is to simply remove a workaround for the previous redundant recursion. I've broken the changes into two corresponding commits for clarity.

There was also a separate bug in `forEachInitializer()`. It takes a boolean `isStatic` parameter (for whether you want to visit instance initializers or static initializers). The bug is that it would only recurse into nested classes with the same staticness as `isStatic`. That's explains the odd observation about the static-ness of class `Inner` in the given test case. Of course, now that `forEachInitializer()` no longer recurses into nested classes that problem goes away as well.

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

Commit messages:
 - Don't report unintialized fields when a static initializer throws.
 - Refactor so forEachInitializer() doesn't recurse into nested classes.

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

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

From alanb at openjdk.org  Thu Apr  4 05:51:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 05:51:11 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

The visitor classes are themselves preview APIs. Is this the first time that preview APIs have been proposed without a JEP? Just wondering how much visibility this preview API will get.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2036238254

From darcy at openjdk.org  Thu Apr  4 06:40:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 Apr 2024 06:40:11 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
 <BLnqfgrphEYISv8H_K1eVX78rzAX5HfgdrKSa-vp9l4=.b6ba350a-a99e-466a-a7a8-29accda21350@github.com>
Message-ID: <3sSjWLu9scH-sWzCLWHKnXWOjuvpc5bT_KJ2O3qD8do=.07fd8fa1-94ea-484b-a910-d258d2103e09@github.com>

On Thu, 4 Apr 2024 05:48:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The visitor classes are themselves preview APIs. Is this the first time that preview APIs have been proposed without a JEP? Just wondering how much visibility this preview API will get.

To clarify the intention, the visitor classes are meant to be persistent preview APIs to help host specific preview APIs associated with modeling upcoming new language features. In particular, these visitor classes are expected to get small updates as part of the work being done in

https://github.com/openjdk/jdk/pull/18509

The preview visitor classes as such don't need much visibility as their use will be through various previewing language features.

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

PR Comment: https://git.openjdk.org/jdk/pull/18609#issuecomment-2036304517

From jlahoda at openjdk.org  Thu Apr  4 06:48:10 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 06:48:10 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <AzanYeupkPjTDSJ8a-pMZtvk48VYlqMaCoYetzyNRMM=.2284e4f0-4383-4271-9d7b-2cb84b732f40@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18609#pullrequestreview-1978870962

From jlahoda at openjdk.org  Thu Apr  4 07:35:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 07:35:33 GMT
Subject: RFR: 8328935: Implement Module Imports.
Message-ID: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>

This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
https://bugs.openjdk.org/browse/JDK-8315129

It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
There is a few notable aspects, however:
- the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
- JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

Commit messages:
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - Merge branch 'module-imports' of github.com:lahodaj/jdk into module-imports
 - ... and 5 more: https://git.openjdk.org/jdk/compare/f26e4308...9cab0ae8

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328935
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From abimpoudis at openjdk.org  Thu Apr  4 09:05:26 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 Apr 2024 09:05:26 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v3]
In-Reply-To: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
Message-ID: <kCt4DcgdmPbQ9xaUw5YzsVsmd15f1eQn7QmXl_OPfYQ=.902174a5-20d4-48f8-b32b-3c083d402ee3@github.com>

> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.

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

  Address review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18606/files
  - new: https://git.openjdk.org/jdk/pull/18606/files/95e153b4..85642511

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

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

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

From abimpoudis at openjdk.org  Thu Apr  4 09:26:24 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 Apr 2024 09:26:24 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v2]
In-Reply-To: <cxjFus-nYfXr1r_FyXPxwatWlbYBE2uiidbnYtRlND8=.81903ab4-5287-4aae-880c-415da0cc3fa7@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
 <1pR-PP36peAK8CfAYY4diqNJTTPMU4XU4Luzk1gksBs=.0280f298-ddef-4a11-94f8-c2cb4b87e98d@github.com>
 <cxjFus-nYfXr1r_FyXPxwatWlbYBE2uiidbnYtRlND8=.81903ab4-5287-4aae-880c-415da0cc3fa7@github.com>
Message-ID: <9QSNn7rrzzMz9YJFHofijvnIcaAlCgVz0r6mggSssnE=.b9600cd8-842c-4c43-a391-42af2aa0898e@github.com>

On Wed, 3 Apr 2024 20:33:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Append empty line
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 503:
> 
>> 501:                     bootstrapName, staticArgTypes, List.nil());
>> 502: 
>> 503:             Type resolvedSelectorType = syms.objectType;
> 
> isn't this change assigning Object to `resolvedSelectorType` for more cases than before JEP455? not sure if there is a semantic change here

Correct. I also moved it at the top of this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18606#discussion_r1551311934

From abimpoudis at openjdk.org  Thu Apr  4 09:26:24 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 4 Apr 2024 09:26:24 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v4]
In-Reply-To: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
Message-ID: <j6OW_KiGYyn-ubPu-l6mpGV3y0L-_cXSl3M51yBzED4=.1fb2a6a0-3131-4eac-b00a-f8a575c607f0@github.com>

> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.

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

  Further cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18606/files
  - new: https://git.openjdk.org/jdk/pull/18606/files/85642511..33ea27e9

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

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

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

From duke at openjdk.org  Thu Apr  4 11:46:10 2024
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Thu, 4 Apr 2024 11:46:10 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>

On Thu, 4 Apr 2024 07:30:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036941814

From jlahoda at openjdk.org  Thu Apr  4 11:52:59 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 11:52:59 GMT
Subject: RFR: 8328481: Implement Module Imports
In-Reply-To: <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Ea4tZRFAGsNDyU4MyXBGP56-KQj0Or094CnZbXXzXcI=.9eb561a8-34e8-4086-ae31-ada8ea97d4b1@github.com>
Message-ID: <PkEjwtAGwGv4mLh5mGGtGVBIPSHTF0738uNTmcQryzw=.830b4b46-94ba-40b0-bb89-9a1b50c8833a@github.com>

On Thu, 4 Apr 2024 11:43:07 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> Should the pull request incorporate a modification to the JAVASE script file for JShell, specifically substituting it with `import module java.se`? (right now the imports are computed, not read from a file)

Given we need to keep the existing code (as `import module java.se` would only work when preview is enabled), and given the outcomes for the user should be (I think, at least) the same, it does not seem necessary to me to complicate things by having two ways to achieve the same outcome.

When the feature goes final, then maybe we could consider replacing the hardcoded JAVASE with a script. But, even then, the user might use `-C--release=21`, and `import module java.se` would not work then, so it may be easier to keep the current code even then.

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

PR Comment: https://git.openjdk.org/jdk/pull/18614#issuecomment-2036957025

From vromero at openjdk.org  Thu Apr  4 13:41:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Apr 2024 13:41:09 GMT
Subject: RFR: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes [v4]
In-Reply-To: <j6OW_KiGYyn-ubPu-l6mpGV3y0L-_cXSl3M51yBzED4=.1fb2a6a0-3131-4eac-b00a-f8a575c607f0@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
 <j6OW_KiGYyn-ubPu-l6mpGV3y0L-_cXSl3M51yBzED4=.1fb2a6a0-3131-4eac-b00a-f8a575c607f0@github.com>
Message-ID: <7ZbE_kjuG-Jcq-2iYOgwT-uqit6tXeJMBUjyTW9i8Hg=.3d870930-983a-454c-bafe-9b73f403dc7b@github.com>

On Thu, 4 Apr 2024 09:26:24 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further cleanup

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18606#pullrequestreview-1979937167

From josiahnoel at gmail.com  Thu Apr  4 13:41:37 2024
From: josiahnoel at gmail.com (Josiah Noel)
Date: Thu, 4 Apr 2024 09:41:37 -0400
Subject: Elements#getDocComment returns null for record components
In-Reply-To: <CAOrkh=VUAm4djpGoOpqbqyShv6cwZt_xNYaVEYXK5u3Kw+nmrA@mail.gmail.com>
References: <CAJ_t5UZNTA_R4BFrtLRD8XPedxh+uzwV=KRbtn+Q-Jz0c9N=-A@mail.gmail.com>
 <CAJ_t5UbDioA4wTTRTkK=itx_ExBJN13Dn+iwfRHpqAzGmxdsuw@mail.gmail.com>
 <CAOrkh=VUAm4djpGoOpqbqyShv6cwZt_xNYaVEYXK5u3Kw+nmrA@mail.gmail.com>
Message-ID: <CAJ_t5UatPwA4znx0nyi4h=jTuz48Lh6vSvm5HbhJwRAzQVUrhQ@mail.gmail.com>

I see, so it's a feature rather than a bug. It still seems like a bit of a
hassle that we have to parse the params from the top record Javadoc and
manually associate it by name to a record component element.

On Thu, Apr 4, 2024 at 4:17?AM Petr Portnov <mrjarviscraft at gmail.com> wrote:

> Aren't the comments on records only available via `@param componentName`
> on the type?
>
> ??, 4 ???. 2024 ?., 01:31 Josiah Noel <josiahnoel at gmail.com>:
>
>> I have created a simple project that reproduces the issue: SentryMan/record-javadoc-APT-bug
>> (github.com) <https://github.com/SentryMan/record-javadoc-APT-bug>
>>
>> On Tue, Apr 2, 2024 at 2:55?PM Josiah Noel <josiahnoel at gmail.com> wrote:
>>
>>> Hello there,
>>>
>>> It seems that when I try to read the Javadoc for record components with
>>> my annotation processor, I get null. When I convert the record into a
>>> regular class it works as expected.
>>> --
>>> Cheers, Josiah.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240404/e057a494/attachment.htm>

From jlahoda at openjdk.org  Thu Apr  4 14:13:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 14:13:27 GMT
Subject: RFR: 8328481: Implement Module Imports [v2]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <JO0h7iNpNt6eGqBfRUboq8R6AKfKJ4yvAps-kGdKD8Y=.23754f67-5b3b-4505-8aaa-e19b10751f80@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda 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 16 additional commits since the last revision:

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - More correct handling of requires transitive.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c0c0131b...3f2deab9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/9cab0ae8..3f2deab9

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

  Stats: 318 lines in 18 files changed: 46 ins; 198 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From acobbs at openjdk.org  Thu Apr  4 14:31:28 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 Apr 2024 14:31:28 GMT
Subject: RFR: 8328649: Disallow enclosing instances for local classes in
 constructor prologues [v2]
In-Reply-To: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
References: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
Message-ID: <uzc2gHt6PQMc-Msk2THrGme6auschsnXmgRdeagkcXs=.a40d8cba-993c-4fd9-be08-24d8182a7654@github.com>

> A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo).
> 
> However, the compiler is allowing code like this to successfully compile:
> 
> import java.util.concurrent.atomic.*;
> public class Test extends AtomicReference<Object> {
>   
>     public Test() {
>         super(switch (0) {
>           default -> {
>               class Local { { Test.this.hashCode(); } }   // this should fail
>               yield null;
>             }
>         });
>     }
> }
> 
> This patch fixes the "leak".

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

 - Merge branch 'master' into JDK-8328649
 - Remove obsolete test cases.
 - No enclosing instance for local classes in constructor prologues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18416/files
  - new: https://git.openjdk.org/jdk/pull/18416/files/d98cb3d5..c9d399d7

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

  Stats: 357608 lines in 2856 files changed: 17713 ins; 14957 del; 324938 mod
  Patch: https://git.openjdk.org/jdk/pull/18416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18416/head:pull/18416

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

From darcy at openjdk.org  Thu Apr  4 16:34:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 Apr 2024 16:34:50 GMT
Subject: RFR: JDK-8329624: Add visitors for preview language features [v2]
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <TihoImdTm2OP4-JkhnrBjoEMjEv-ADSkLp1F1B9-KBg=.74865fda-4d9a-43e0-a60c-c8a03b59b78e@github.com>

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

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

  Add informative links.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18609/files
  - new: https://git.openjdk.org/jdk/pull/18609/files/45bbc292..5fc414bc

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

  Stats: 36 lines in 10 files changed: 22 ins; 2 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18609/head:pull/18609

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

From jlahoda at openjdk.org  Thu Apr  4 16:41:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 16:41:33 GMT
Subject: RFR: 8325324: Implement Declared Classes and Instance main Methods
Message-ID: <5ys3-6c31Pr82nxjqd6ARD9YhA7PkBOdvl7lm62snSA=.35e20dba-9758-44fc-8302-6bb7893b3f39@github.com>

This is an implementation of a change for JEP draft: Implicitly Declared Classes and Instance Main Methods (Third Preview)[1]. The primary change here is that implicitly declared classes have two new implicit imports:

import module java.base;
import static java.io.SimpleIO.*;


Both of these depend on other changes, the first one on https://github.com/openjdk/jdk/pull/18614, and the second one on https://bugs.openjdk.org/browse/JDK-8305457. This PR depends on 18614, and the patch here can should be able to work both in the presence and absence of `java.io.SimpleIO`, including testing. Some tweaking may still be necessary when `java.io.SimpleIO` is introduced. But, overall the patch should be fairly straightforward - the imports are injected at the same time the long-existing import for `java.lang` is added.

There is also an obvious relation to String Templates, which may need tweaking/simplification.

Additional tweak will be needed once the JEP is Candidate, to updated the proper JEP number.

[1] https://openjdk.org/jeps/8323335

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

Depends on: https://git.openjdk.org/jdk/pull/18614

Commit messages:
 - Adding test verifying that the new implicit imports are not used for ordinary classes.
 - Merge branch 'module-imports' into JDK-8325324
 - Fixing test.
 - Merge branch 'master' into JDK-8325324
 - Disabling the preview check when working with the STR.
 - Cleanup StringTemplate.STR import.
 - Implicitly importing SimpleIO.
 - 8325324: Implement Declared Classes and Instance main Methods

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

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

From vromero at openjdk.org  Thu Apr  4 17:05:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Apr 2024 17:05:05 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
Message-ID: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>

On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:

> 131:      */
> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
> 133:     COMPONENT_LOCAL_VARIABLE;

I wonder if we can't just use: LOCAL_VARIABLE

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2235:

> 2233:             }
> 2234:             sym.adr = nextadr;
> 2235:             vars[nextadr] = sym;

could we use a record here? these two arrays seem to be in sync

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

> 1362: 
> 1363:     @Override
> 1364:     public void visitDerivedInstance(JCDerivedInstance tree) {

I was expecting this code to belong to Lower, not saying that it is wrong here though but probably more naturally in Lower I think

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1574:

> 1572:             @Override
> 1573:             public void visitDerivedInstance(JCDerivedInstance tree) {
> 1574:                 hasPatterns |= true;

it could be thought as a pattern but it is not a pattern nor it is internally converted to a pattern, unless I'm missing something

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1550678834
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552065329
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552076515
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552088772

From jlahoda at openjdk.org  Thu Apr  4 20:30:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 4 Apr 2024 20:30:00 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>

On Thu, 4 Apr 2024 00:37:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:
> 
>> 131:      */
>> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
>> 133:     COMPONENT_LOCAL_VARIABLE;
> 
> I wonder if we can't just use: LOCAL_VARIABLE

We could, and I was thinking of that. But, then I decided to go with a new kind, as I think it matches better the overall design of the Elements/Kinds. E.g. we have existing `EXCEPTION_PARAMETER` (used in `catch`) or `BINDING_VARIABLE`, rather than using `LOCAL_VARIABLE` for them.

(Also, many of these variable kinds have some small, but significant differences in semantics from `LOCAL_VARIABLE` - e.g. some are never blank/are always definitely assigned.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1552385305

From acobbs at openjdk.org  Thu Apr  4 20:55:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 Apr 2024 20:55:11 GMT
Subject: RFR: 8328649: Disallow enclosing instances for local classes in
 constructor prologues [v2]
In-Reply-To: <6W8G5C10uJaLNVUC5O7pTEHO7JKyjprP2FZEBFUZsiU=.289c6db1-abde-441f-bf2a-4969b99d865e@github.com>
References: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
 <7o_xOUPuX7rOv_8PmACGB1QOZgNf5S7L1pTlIVmgC4Q=.05a44a0f-d9cb-440b-b89e-7a9a3fecf349@github.com>
 <6W8G5C10uJaLNVUC5O7pTEHO7JKyjprP2FZEBFUZsiU=.289c6db1-abde-441f-bf2a-4969b99d865e@github.com>
Message-ID: <0dp7l8A5sH79b23g_TyMS8eSDk5fofBKI6WMYLZKxRQ=.f1eca76f-f6ea-438f-aedc-bb8c8c0279f0@github.com>

On Tue, 2 Apr 2024 19:11:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> looks good to me
>
>> @vicente-romero-oracle, would you (or anyone) mind reviewing the [associated CSR](https://bugs.openjdk.org/browse/JDK-8328706) per @jddarcy's request?
>> 
>> Thanks.
> 
> looks good

Hi @vicente-romero-oracle , thanks for reviewing & sponsoring. Please sponsor one more time as the bot got confused somehow. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18416#issuecomment-2038197984

From acobbs at openjdk.org  Thu Apr  4 21:17:05 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 4 Apr 2024 21:17:05 GMT
Subject: Integrated: 8328649: Disallow enclosing instances for local classes in
 constructor prologues
In-Reply-To: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
References: <MxPTXbEhTlnYa0zWN5Slm55JQXSMljLQ8CxKfKQx_T8=.191777a4-6695-4a39-8c93-1ea75dbdb794@github.com>
Message-ID: <QkEZkXGpLn6TqlRaa_MOiEX4oLJT6tssU0CNpVVzo2o=.c8e8e265-52c7-46a6-b866-867b3da65a4e@github.com>

On Thu, 21 Mar 2024 02:10:09 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> A local class declared in a static context is not supposed to have an immediately enclosing instance (?15.9.2). That includes local classes declared in constructors prior to `super()` (during the "constructor prologue" in the new lingo).
> 
> However, the compiler is allowing code like this to successfully compile:
> 
> import java.util.concurrent.atomic.*;
> public class Test extends AtomicReference<Object> {
>   
>     public Test() {
>         super(switch (0) {
>           default -> {
>               class Local { { Test.this.hashCode(); } }   // this should fail
>               yield null;
>             }
>         });
>     }
> }
> 
> This patch fixes the "leak".

This pull request has now been integrated.

Changeset: d80d4781
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d80d4781828d68c498831cddf9782055dda472d1
Stats:     69 lines in 5 files changed: 36 ins; 29 del; 4 mod

8328649: Disallow enclosing instances for local classes in constructor prologues

Reviewed-by: vromero

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

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

From duke at openjdk.org  Fri Apr  5 00:06:16 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 5 Apr 2024 00:06:16 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet
Message-ID: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>

In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions

- SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)

- isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)

This is similar to #18032

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

Commit messages:
 - add `@since` to `SNIPPET_PATH` and `isBlockTag()`

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

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

From darcy at openjdk.org  Fri Apr  5 05:08:15 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 05:08:15 GMT
Subject: Integrated: JDK-8329624: Add visitors for preview language features
In-Reply-To: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
References: <VUSCpOjBcIrjfSNTP0HfuNnaxAqRFtKYmn96MaCeqsc=.843c48b8-ec72-4c42-997c-50bf927a20fa@github.com>
Message-ID: <QQr-PzBcisQrDf876CQaOZ04DlvtNKbKqZK9Pqo4wJA=.7e93e411-3414-48e8-bcc1-b277575e4461@github.com>

On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> When new language features are added, the javax.lang.model may need to be updated. For certain classes of features, the API update includes introducing a new set of concrete visitors to handle the language feature.
> 
> The API scaffolding to support the new feature tends to be considerably larger than the API specifically for the new feature.
> 
> To aid work in progress (such as https://github.com/openjdk/jdk/pull/18509) and anticipated in the future, I think it would be helpful to introduce a persistent set of preview visitors independent of any particular language change.

This pull request has now been integrated.

Changeset: 5860a48c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5860a48c71e324f77a7ecc613c063cbb81580011
Stats:     745 lines in 12 files changed: 735 ins; 0 del; 10 mod

8329624: Add visitors for preview language features

Reviewed-by: vromero, jlahoda

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

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

From abimpoudis at openjdk.org  Fri Apr  5 08:09:10 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 5 Apr 2024 08:09:10 GMT
Subject: Integrated: 8328747: WrongMethodTypeException with pattern matching on
 switch on sealed classes
In-Reply-To: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
References: <ZarjUg9o8FwmkBp6ONrqsg3hBsIB56rvTHlgZsW0dgQ=.9e1a99c8-b241-431d-b3a8-c93587d8ee75@github.com>
Message-ID: <4AFGhwTTy8FypfTolYcf3VIxkZk1MnwAabGNsy5NbCo=.dbdad2c3-add8-4c98-a5a6-9fb9bca47932@github.com>

On Wed, 3 Apr 2024 14:45:35 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR addresses the issue that the expected signature for `typeSwitch` is different when a release target refers to a version prior to JDK 23. The signature, due to JEP 455, needs to be more precise on the `selectorType` now that primitive type support is previewed.

This pull request has now been integrated.

Changeset: 8efe569b
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8efe569b8dc0ae865aa75757ca0e5c4cda12aa61
Stats:     137 lines in 3 files changed: 132 ins; 3 del; 2 mod

8328747: WrongMethodTypeException with pattern matching on switch on sealed classes

Reviewed-by: cushon, vromero

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

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

From prappo at openjdk.org  Fri Apr  5 09:34:11 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 5 Apr 2024 09:34:11 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet
In-Reply-To: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
Message-ID: <GqgaSUOIJ8LvzAIZhJ3GcsGoh6UqYtdDQWmJqY8fM7c=.424f887e-fc99-446c-bdc0-cb2ae54d97f4@github.com>

On Fri, 5 Apr 2024 00:02:00 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions
> 
> - SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)
> 
> - isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)
> 
> This is similar to #18032

Looks good. Thanks.

src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java line 99:

> 97:      * @implSpec This implementation returns the inverse
> 98:      * result to {@code isInlineTag}.
> 99:      * @since 15

Might as well insert a blank line above.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18640#pullrequestreview-1982467362
PR Review Comment: https://git.openjdk.org/jdk/pull/18640#discussion_r1553259747

From prappo at openjdk.org  Fri Apr  5 12:05:22 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 5 Apr 2024 12:05:22 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
 <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>
Message-ID: <AIeLnH8fFFBMOnJVxipGUsiQBgFB-1DXwJEOoGe8Fd0=.9b08dd17-1cbd-44e3-b625-756d91b2e3f1@github.com>

On Fri, 5 Apr 2024 12:02:41 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions
>> 
>> - SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)
>> 
>> - isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)
>> 
>> This is similar to #18032
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add blank line

Marked as reviewed by prappo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18640#pullrequestreview-1982978404

From duke at openjdk.org  Fri Apr  5 12:05:21 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 5 Apr 2024 12:05:21 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
Message-ID: <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>

> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions
> 
> - SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)
> 
> - isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)
> 
> This is similar to #18032

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

  add blank line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18640/files
  - new: https://git.openjdk.org/jdk/pull/18640/files/0ffee115..0c5a300d

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

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

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

From duke at openjdk.org  Fri Apr  5 12:05:22 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 5 Apr 2024 12:05:22 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <GqgaSUOIJ8LvzAIZhJ3GcsGoh6UqYtdDQWmJqY8fM7c=.424f887e-fc99-446c-bdc0-cb2ae54d97f4@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
 <GqgaSUOIJ8LvzAIZhJ3GcsGoh6UqYtdDQWmJqY8fM7c=.424f887e-fc99-446c-bdc0-cb2ae54d97f4@github.com>
Message-ID: <yuZxtdcUv_w9yN7FTuPViGCFkNy-Qyk27luQtq8dc_g=.331f3f94-353f-42d1-bd43-7ce2befd7340@github.com>

On Fri, 5 Apr 2024 09:30:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add blank line
>
> src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java line 99:
> 
>> 97:      * @implSpec This implementation returns the inverse
>> 98:      * result to {@code isInlineTag}.
>> 99:      * @since 15
> 
> Might as well insert a blank line above.

Done, looking at the existing source code sometimes I find a blank line and sometimes I don't.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18640#discussion_r1553504955

From prappo at openjdk.org  Fri Apr  5 12:12:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 5 Apr 2024 12:12:09 GMT
Subject: RFR: JDK-8329717 Missing `@since` tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <yuZxtdcUv_w9yN7FTuPViGCFkNy-Qyk27luQtq8dc_g=.331f3f94-353f-42d1-bd43-7ce2befd7340@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
 <GqgaSUOIJ8LvzAIZhJ3GcsGoh6UqYtdDQWmJqY8fM7c=.424f887e-fc99-446c-bdc0-cb2ae54d97f4@github.com>
 <yuZxtdcUv_w9yN7FTuPViGCFkNy-Qyk27luQtq8dc_g=.331f3f94-353f-42d1-bd43-7ce2befd7340@github.com>
Message-ID: <wpQMvpQSZ6Ef8gR893WKdq7AJA8lFCreW12aqE3aBQY=.80ee5c90-3953-43c4-a068-3a206e2d632d@github.com>

On Fri, 5 Apr 2024 12:01:52 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/doclet/Taglet.java line 99:
>> 
>>> 97:      * @implSpec This implementation returns the inverse
>>> 98:      * result to {@code isInlineTag}.
>>> 99:      * @since 15
>> 
>> Might as well insert a blank line above.
>
> Done, looking at the existing source code sometimes I find a blank line and sometimes I don't.

Understood; my comment was a mild suggestion, not a requirement. I find it easier to read when `@since` is set off with a blank line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18640#discussion_r1553514019

From jlahoda at openjdk.org  Fri Apr  5 12:35:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:35:26 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v6]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <czrY9ETJy2yEFJewX4s1zn2IJbHb-YpBnmLExRTgLLg=.b5174e96-5461-4216-96d5-512c9666034f@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - Fixing tests.
 - Adding tests.
 - The var declaration can be any JCTree.
 - Renaming visitReconstruction to visitDerivedInstance as suggested.
 - Fixing support for derived record creation expression in JShell.
 - Removing whitespace
 - Cleanup.
 - ... and 19 more: https://git.openjdk.org/jdk/compare/18c925cd...f9b6c403

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

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=05
  Stats: 1772 lines in 50 files changed: 1687 ins; 20 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

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

From jlahoda at openjdk.org  Fri Apr  5 12:35:26 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:35:26 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <-5qPp90Gs9kig6Urog31yB80MJ0K9phxs80m4UIB468=.7a67fd90-04f3-42f3-856a-5b3c7795453f@github.com>

On Thu, 4 Apr 2024 16:47:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2235:
> 
>> 2233:             }
>> 2234:             sym.adr = nextadr;
>> 2235:             vars[nextadr] = sym;
> 
> could we use a record here? these two arrays seem to be in sync

Sure, done. Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1364:
> 
>> 1362: 
>> 1363:     @Override
>> 1364:     public void visitDerivedInstance(JCDerivedInstance tree) {
> 
> I was expecting this code to belong to Lower, not saying that it is wrong here though but probably more naturally in Lower I think

Moved to `Lower`. Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553545686
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553546716

From jlahoda at openjdk.org  Fri Apr  5 12:40:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:40:22 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  JavaCompiler cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/f9b6c403..c91e87fd

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

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

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

From jlahoda at openjdk.org  Fri Apr  5 12:40:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 12:40:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
Message-ID: <VW-FkuTbQzX-wk20ohdHMO1yixVEkUJPYSD2E5K0nUU=.b202e2d0-92c1-46c3-946a-a192b62782b8@github.com>

On Thu, 4 Apr 2024 17:00:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1574:
> 
>> 1572:             @Override
>> 1573:             public void visitDerivedInstance(JCDerivedInstance tree) {
>> 1574:                 hasPatterns |= true;
> 
> it could be thought as a pattern but it is not a pattern nor it is internally converted to a pattern, unless I'm missing something

The main point here is to make not run `TransPatterns` in case the visitor is not performing any work (because loading the class causes some perf tests to regress - we do the same for `LambdaToMethod`). But, as the desugaring was moved to `Lower`, we no longer need to do anything in `JavaCompiler`. Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553555861

From mcimadamore at openjdk.org  Fri Apr  5 12:58:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 12:58:10 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <5Q_7slvUUYbJm_E75Pzc2EEK1topAjjBfZgH0gaUx5M=.3293c88d-b951-4481-acde-e5bd8847973b@github.com>
 <o7ijrPPLmzq7LdxFWnecxPa-uJIB-9K-3FRTM3qGl2Q=.12a9d5ec-64e6-40e3-b518-632c68e84dc8@github.com>
Message-ID: <4sL69UCPpTH3iACJsM6NfwJKGkJ7Elc8vMKeGQkjkcI=.24ea7f83-bb52-415c-be43-8a245af29347@github.com>

On Thu, 4 Apr 2024 20:27:36 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 133:
>> 
>>> 131:      */
>>> 132:     @PreviewFeature(feature=PreviewFeature.Feature.DERIVED_RECORD_CREATION, reflective=true)
>>> 133:     COMPONENT_LOCAL_VARIABLE;
>> 
>> I wonder if we can't just use: LOCAL_VARIABLE
>
> We could, and I was thinking of that. But, then I decided to go with a new kind, as I think it matches better the overall design of the Elements/Kinds. E.g. we have existing `EXCEPTION_PARAMETER` (used in `catch`) or `BINDING_VARIABLE`, rather than using `LOCAL_VARIABLE` for them.
> 
> (Also, many of these variable kinds have some small, but significant differences in semantics from `LOCAL_VARIABLE` - e.g. some are never blank/are always definitely assigned.)

Given the JLS defines "component local variable" I think it makes sense to have a separate kind

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553580520

From mcimadamore at openjdk.org  Fri Apr  5 13:05:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:05:10 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <BSC2pDkRc8mjv_BguuoooIXehNeFdVeTebvAcqVvsmg=.6d25e545-8137-4e86-bde1-56faf4b29a19@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

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

> 4911: 
> 4912:     void checkDerivedInstanceBlockStructure(JCDerivedInstance instance) {
> 4913:         new TreeScanner() {

I note that here we don't care about leaving locals declared inside a block in the `seenVariables` after the block ends (e.g. I see no visitBlock). I think that's probably ok, given that every variable has a fresh symbol, so checking against the `seenVariables` set will fail anyway for two variables that have same name, but different scopes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553596699

From mcimadamore at openjdk.org  Fri Apr  5 13:13:03 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:13:03 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2117:

> 2115:          *  position.
> 2116:          */
> 2117:         protected VarAndDeclarationTree[] vars;

So... normally, a `JCVariableDecl` would have a symbol attached, which is how the old code used to work. Is it correct that this change is needed because the `componentLocalVariables` list is a list of symbols and not of JCVariableDecl? Would it be too complex to create a declaration in Attr and save those in the derived creation tree?

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

> 4441:     }
> 4442: 
> 4443:     @Override

As usual, I suggest to add some brief comment with the shape of the generated code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553607860
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1553608813

From mcimadamore at openjdk.org  Fri Apr  5 13:36:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 Apr 2024 13:36:00 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
Message-ID: <dmK3tjutF5mm6goWcidZTFbSYf3oYrkWF4UO3FcRPsQ=.7253bc31-fef4-4a97-baee-fbfd830be56b@github.com>

On Fri, 5 Apr 2024 12:40:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JavaCompiler cleanup

Good job!

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

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-1983199416

From acobbs at openjdk.org  Fri Apr  5 14:47:25 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 5 Apr 2024 14:47:25 GMT
Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor
 Bodies (Second Preview) [v2]
In-Reply-To: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
References: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
Message-ID: <hvtB7CF4UjcHYx7DLB7u92I60itTwRWpcjnAtaQLXvE=.64172207-1613-46ba-8dd5-a888678f23bd@github.com>

> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context.  This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803).
> 
> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo.

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

 - Merge branch 'master' into JDK-8325805
 - Merge branch 'master' into JDK-8325805
 - Fix cut & paste of bug ID and summary.
 - Avoid possible unwanted side effects from method Symbol.flags().
 - Add a few more test cases.
 - Fix bug where early assignments in lambda's were being allowed.
 - Add some more allowed assignment test cases.
 - Add test case for early assignment within a lambda.
 - Add comment.
 - Fix early ref logic by handling assign vs. reference separately.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4a11db8b...d2dd8bc1

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

Changes: https://git.openjdk.org/jdk/pull/18088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18088&range=01
  Stats: 418 lines in 11 files changed: 375 ins; 37 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18088/head:pull/18088

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

From duke at openjdk.org  Fri Apr  5 15:56:10 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 5 Apr 2024 15:56:10 GMT
Subject: RFR: JDK-8329717 Missing @since tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
 <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>
Message-ID: <-rVscrk4thgCBpH3kQwbZ3lEBE7N9n7_gLgWv8uXenc=.d01bccce-ae9e-4bb9-874a-e271a4ff96eb@github.com>

On Fri, 5 Apr 2024 12:05:21 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions
>> 
>> - SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)
>> 
>> - isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)
>> 
>> This is similar to #18032
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add blank line

This PR is ready, I plan on integrating it at a later point.

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

PR Comment: https://git.openjdk.org/jdk/pull/18640#issuecomment-2040150871

From duke at openjdk.org  Fri Apr  5 15:57:01 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 5 Apr 2024 15:57:01 GMT
Subject: RFR: JDK-8328501 Incorrect @since` tags for java security
 interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <nql1zJGzN_4Xx0GxaDDHVqfkiEJ7Fv0uJ6H0kJ-wJG0=.b9793163-e294-4e5d-b119-18aa4390f697@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

This PR is ready, I plan on integrating it at a later point.

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2040152570

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: RFR: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <oxGgm-e1ERf84KUzrd4CNGYKE8uw1JVPyS5XnYAxqOk=.f277b54e-4f47-45ff-9c51-94d1d5be5282@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

The changes in this PR are being incorporated into the larger PR for derived record creation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18590#issuecomment-2040316977

From darcy at openjdk.org  Fri Apr  5 17:41:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 17:41:13 GMT
Subject: Withdrawn: JDK-8329556: javax.lang.model suppor for Derived Record
 Creation (Preview)
In-Reply-To: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
References: <WkaSvTmkCF8CWHTcmJxu8ywbalRmKevD3VnjigORYm4=.aa76f3f7-1953-484d-8a0d-3a8245d5f803@github.com>
Message-ID: <hgxJOeKQkdCfyi7oJ4s3lbCyeg9k2_oE_vcUUJR13ko=.e7b82340-1d47-4720-9608-b6e7b67527aa@github.com>

On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.org  Fri Apr  5 18:23:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 5 Apr 2024 18:23:01 GMT
Subject: RFR: JDK-8329717 Missing @since tags in elements in
 DocumentationTool and Taglet [v2]
In-Reply-To: <-rVscrk4thgCBpH3kQwbZ3lEBE7N9n7_gLgWv8uXenc=.d01bccce-ae9e-4bb9-874a-e271a4ff96eb@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
 <VEvyo6vxjjEbfMOLGwjFv4YNejAOmccAIx4Dh1cDmqk=.0d7d3240-dc21-4dcd-b40f-e291f1217f5a@github.com>
 <-rVscrk4thgCBpH3kQwbZ3lEBE7N9n7_gLgWv8uXenc=.d01bccce-ae9e-4bb9-874a-e271a4ff96eb@github.com>
Message-ID: <xicc_HfqMKOnwFnsG1YuR_GOepnxZAs4W0_PZrwUm3M=.da2aa98e-6c58-45b4-9b71-30cc89e06d58@github.com>

On Fri, 5 Apr 2024 15:53:40 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add blank line
>
> This PR is ready, I plan on integrating it at a later point.
> I won't make anymore changes, I just want to work on some things.

@nizarbenalla You need to fix the PR summary to agree with the JBS summary.

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

PR Comment: https://git.openjdk.org/jdk/pull/18640#issuecomment-2040377458

From jlahoda at openjdk.org  Fri Apr  5 18:35:37 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 18:35:37 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Reflecting review feedback:
  - pre-generating the JCVarDecls in Attr, to aid Flow
  - adding a note on how the desugared code looks like

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/c91e87fd..14651358

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

  Stats: 75 lines in 6 files changed: 30 ins; 11 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

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

From darcy at openjdk.org  Fri Apr  5 18:35:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 5 Apr 2024 18:35:38 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
Message-ID: <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>

On Fri, 5 Apr 2024 18:32:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - pre-generating the JCVarDecls in Attr, to aid Flow
>   - adding a note on how the desugared code looks like

src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 135:

> 133:     COMPONENT_LOCAL_VARIABLE;
> 134: 
> 135:     // Maintenance note: check if the default implementation of

>From a quick look, I don't think Elements.getOutermostTypeElement needs updating for COMPONENT_LOCAL_VARIABLE, but it would be good to add a test case.

src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java line 91:

> 89: 
> 90:     /**
> 91:      * {@inheritDoc ElementKindVisitor6}

If possible, would be good to add some minimal testing/use of the element kind visitors on component local variables.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554108944
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554113169

From jlahoda at openjdk.org  Fri Apr  5 18:35:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 Apr 2024 18:35:38 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
 <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
Message-ID: <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>

On Fri, 5 Apr 2024 13:09:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JavaCompiler cleanup
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2117:
> 
>> 2115:          *  position.
>> 2116:          */
>> 2117:         protected VarAndDeclarationTree[] vars;
> 
> So... normally, a `JCVariableDecl` would have a symbol attached, which is how the old code used to work. Is it correct that this change is needed because the `componentLocalVariables` list is a list of symbols and not of JCVariableDecl? Would it be too complex to create a declaration in Attr and save those in the derived creation tree?

Generating the `JCVariableDecl`s in Attr in https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b.
Thanks for the comment!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
> 
>> 4441:     }
>> 4442: 
>> 4443:     @Override
> 
> As usual, I suggest to add some brief comment with the shape of the generated code.

Done here:
https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR4445

Please let me know if that needs some tweaks.

Thanks for the comment!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554103472
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1554104437

From acobbs at openjdk.org  Sat Apr  6 14:11:40 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 6 Apr 2024 14:11:40 GMT
Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor
 Bodies (Second Preview) [v3]
In-Reply-To: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
References: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
Message-ID: <Q6ZIpbwW2DJf9EnCtV5-Z473pb5MKffplYkw8JfEdig=.e72e2c12-23c4-4695-891f-2a55c0bfecae@github.com>

> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context.  This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803).
> 
> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo.

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

  Disallow assignments to fields with initializers in constructor prologues.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18088/files
  - new: https://git.openjdk.org/jdk/pull/18088/files/d2dd8bc1..8b0dc26c

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

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

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

From djelinski at openjdk.org  Mon Apr  8 13:27:32 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 8 Apr 2024 13:27:32 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
Message-ID: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>

The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.

This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.

In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 

No new regression test. Existing langtools tests continue to pass.

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

Commit messages:
 - Use threadpool for socket communication

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

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

From cstein at openjdk.org  Mon Apr  8 13:45:09 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 8 Apr 2024 13:45:09 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <VYDdMwUHCoi6kq4hhps1pE16MlQXfZri-V0qmvGMorw=.d1cf9436-6a97-4668-86b1-37381eff5073@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

Less code, less threads: cleaner and less race-conditions. Looks good to me.

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18672#pullrequestreview-1986496132

From erikj at openjdk.org  Mon Apr  8 14:04:11 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Apr 2024 14:04:11 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <vsWTaIW-MtmB7TN4Ysm2TAPeRUF6O2GeNMbwYTb8vMo=.ff6ebc14-d9bd-465f-8cf3-5984deca9eb1@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

My understanding of the existing model is that we wanted to read the command on the socket without delay and then potentially wait until there was a free executor thread in the pool. With the new model, we won't read the input on the socket until there is a free thread. I don't know if this could ever be a problem, but it seems plausible.

The default size of the thread pool is number of CPUs in the system. The default number of jobs in the makefiles is never larger than this number, so in reality, we won't get more compile requests than number of CPUs from the makefiles when using default values. However, if the user manually increases the JOBS number in the makefiles, we could.

Perhaps it would be worth at least trying running make with a much larger JOBS value with this patch to see that it doesn't fall apart?

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

PR Review: https://git.openjdk.org/jdk/pull/18672#pullrequestreview-1986545820

From mcimadamore at openjdk.org  Mon Apr  8 14:06:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 Apr 2024 14:06:13 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v7]
In-Reply-To: <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <IT6tJf_kMGaMJIY8DTVD5OoP8pUPKxV0FTS_-U-uGKI=.b174a951-2a1b-4718-a656-92b43112e1de@github.com>
 <N88cWm47DXisDS82xRXJgAxx7_tLtunbiU-DTOtiJVk=.c5ddae1e-2402-4215-aa2a-092494b348c5@github.com>
 <zkm6nuZGWZ289iCgSfLwW45m_hUFxDrIZI4Ewgd9hUo=.33daff82-08d8-41d8-9339-9e0d3e206278@github.com>
Message-ID: <uB-LY_NfCJ1KO_xK6Lk1xt15lWk4EdppIPqQ4Nn37RE=.3493a23c-fb45-4d88-8908-2f9072c61f15@github.com>

On Fri, 5 Apr 2024 18:28:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 4443:
>> 
>>> 4441:     }
>>> 4442: 
>>> 4443:     @Override
>> 
>> As usual, I suggest to add some brief comment with the shape of the generated code.
>
> Done here:
> https://github.com/openjdk/jdk/pull/18509/commits/146513580f96abd5feb7886bd1191805cc93403b#diff-bc0df6dce7f74078bfca1e90bec75d7bb3d8b338933be725da78f0a8a7a0c78dR4445
> 
> Please let me know if that needs some tweaks.
> 
> Thanks for the comment!

Looks great!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1555902226

From djelinski at openjdk.org  Mon Apr  8 14:30:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 8 Apr 2024 14:30:10 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <-b30Ht4CtG_MmghcNBlO4J5B6VfPZ5BzVfejyJJkp00=.987af7b2-7dc2-4843-97df-14b292aaab10@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

It won't be a problem. The client side does not set timeout on socket read/write operations, so there's no risk of the operation timing out. Also, the OS usually buffers reads and writes, so the client write call probably won't block even if the server doesn't read. Other than that, we're using TCP sockets for communication, so no data will ever be lost.

Tried running make with JOBS=512, no problems observed. I might try that on mach5 too, just in case.

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

PR Comment: https://git.openjdk.org/jdk/pull/18672#issuecomment-2042901814

From jlahoda at openjdk.org  Mon Apr  8 16:21:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 8 Apr 2024 16:21:19 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Adding tests as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/14651358..e0930688

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

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

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

From erikj at openjdk.org  Mon Apr  8 16:28:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Apr 2024 16:28:10 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <YjocoGjm6XNtF9-4Ziz5RZKHPu9JGpKQli9CA8qHm6k=.d22e8ab5-dfe4-4512-90ef-f3fe0b197ff6@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18672#pullrequestreview-1986906076

From erikj at openjdk.org  Mon Apr  8 16:28:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Apr 2024 16:28:10 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <-b30Ht4CtG_MmghcNBlO4J5B6VfPZ5BzVfejyJJkp00=.987af7b2-7dc2-4843-97df-14b292aaab10@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
 <-b30Ht4CtG_MmghcNBlO4J5B6VfPZ5BzVfejyJJkp00=.987af7b2-7dc2-4843-97df-14b292aaab10@github.com>
Message-ID: <LtVnKdvVeqPyxT9233Q52uBbR4qOq_F7n6gtnCNALKc=.47c3bb37-b79a-4926-8e54-2cc117022c4c@github.com>

On Mon, 8 Apr 2024 14:27:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> It won't be a problem. The client side does not set timeout on socket read/write operations, so there's no risk of the operation timing out. Also, the OS usually buffers reads and writes, so the client write call probably won't block even if the server doesn't read. Other than that, we're using TCP sockets for communication, so no data will ever be lost.
> 
> Tried running make with JOBS=512, no problems observed. I might try that on mach5 too, just in case.

Thanks for confirming. Then this looks good to me!

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

PR Comment: https://git.openjdk.org/jdk/pull/18672#issuecomment-2043177438

From vromero at openjdk.org  Mon Apr  8 16:48:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 8 Apr 2024 16:48:12 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
Message-ID: <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>

On Mon, 8 Apr 2024 16:21:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests as suggested.

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

> 99: import com.sun.tools.javac.tree.JCTree.JCPattern;
> 100: import com.sun.tools.javac.tree.JCTree.JCPatternCaseLabel;
> 101: import com.sun.tools.javac.tree.JCTree.JCDerivedInstance;

changes to this file can be removed now

test/langtools/tools/javac/patterns/withers/Model.java line 2:

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

probably this test should be in another location not under `patterns`, same for other tests added inside `patterns` folder

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1556130188
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1556136586

From jjg at openjdk.org  Mon Apr  8 21:12:42 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 8 Apr 2024 21:12:42 GMT
Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation
 Comments [v55]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <48hbLsx6MHdQQNNWrPRs4C-7sB18MyPOLE0QeTTPSDg=.1c0bd28d-8bd0-4733-a257-2c0f60bef2eb@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  add support for JDK-8329296: Update Elements for '///' documentation comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/37646287..21f5b004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=53-54

  Stats: 331 lines in 10 files changed: 291 ins; 20 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From syan at openjdk.org  Tue Apr  9 01:47:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:47:13 GMT
Subject: RFR: 8326726: Problem list Exhaustiveness.java due to 8326616 [v2]
In-Reply-To: <Z2F-Cqpue7JNe2XFeNRQaT5OTmn4lOLM8xKdOzWRlF0=.51685d68-53fc-45d6-b73c-6147957c6525@github.com>
References: <9tC0IsdXrrHs8LcDOC1v4FXanyrG2_eSHFFZ3JuuHLk=.99a49188-4172-4e45-8212-38596717dffa@github.com>
 <7J4AtzLPYHrxYmOFPiVobHzBwjIrzdm4NWzaPYlKg8A=.cb36ba25-c1b1-4f9b-81e7-b5e9927d09e9@github.com>
 <Z2F-Cqpue7JNe2XFeNRQaT5OTmn4lOLM8xKdOzWRlF0=.51685d68-53fc-45d6-b73c-6147957c6525@github.com>
Message-ID: <GPV5K2Ux4oxjS42N4d1fb42TDpeqOrnovt7Jf8xImZM=.070cdcbd-81ad-4abd-86af-e72318880b65@github.com>

On Tue, 27 Feb 2024 12:16:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8326726: Problem list Exhaustiveness.java due to 8326616
>>    
>>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>>  - 8326726: Problem list Exhaustiveness.java due to 8326616
>>    
>>    Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>
>
> Looks reasonable. Thanks!

> Based on @lahodaj approval, I will sponsor this
> 
> /sponsor

@jonathan-gibbons @lahodaj Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17998#issuecomment-2043993888

From jlahoda at openjdk.org  Tue Apr  9 08:53:02 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 08:53:02 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v8]
In-Reply-To: <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <0k62PoyjaMG_YZw-xV9T1H2q7W9JYCeoCx6VOcZoVRQ=.2089eb99-3979-4b48-af9d-9dff89a4068a@github.com>
 <B36ahBT-Byi3Z52KLTRFFkYRH50jSeZGL7PW64WBE60=.4f62075d-1bc6-48f1-bbee-f3b76d1ecec3@github.com>
Message-ID: <R8bCspHnxSsNV11ojOSWCX4dxudzBzegG-igWV2_Dy4=.e6336225-dc16-46c8-ab9c-9af855d5990b@github.com>

On Fri, 5 Apr 2024 18:30:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback:
>>   - pre-generating the JCVarDecls in Attr, to aid Flow
>>   - adding a note on how the desugared code looks like
>
> src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java line 135:
> 
>> 133:     COMPONENT_LOCAL_VARIABLE;
>> 134: 
>> 135:     // Maintenance note: check if the default implementation of
> 
> From a quick look, I don't think Elements.getOutermostTypeElement needs updating for COMPONENT_LOCAL_VARIABLE, but it would be good to add a test case.

Tests added: https://github.com/openjdk/jdk/pull/18509/commits/e09306885e5c6cd2aba7779025fc7efcb8991e8e

Thanks!

> src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java line 91:
> 
>> 89: 
>> 90:     /**
>> 91:      * {@inheritDoc ElementKindVisitor6}
> 
> If possible, would be good to add some minimal testing/use of the element kind visitors on component local variables.

Tests added: https://github.com/openjdk/jdk/pull/18509/commits/e09306885e5c6cd2aba7779025fc7efcb8991e8e

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557243414
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557243525

From jlahoda at openjdk.org  Tue Apr  9 09:28:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:28:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

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

  Reflecting review feedback:
  - reverting unnecessary changes in TransPatterns
  - moving the patters/withers/Model test to a more appropriate place

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18509/files
  - new: https://git.openjdk.org/jdk/pull/18509/files/e0930688..a05480cd

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

  Stats: 37 lines in 4 files changed: 14 ins; 17 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

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

From jlahoda at openjdk.org  Tue Apr  9 09:28:23 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 09:28:23 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v9]
In-Reply-To: <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <HA2CicFGNm0tG_DC2OgKLFEtAg6Wv-kfAa3EAhUUd2o=.8e2abb3d-431b-4582-84f6-ef562054e49d@github.com>
 <sE8wdu-Ite3_AyTKaXFcr6b-GdJA8R5ZtGh08C4-Q-s=.f2c6b92b-2063-4c31-a181-643897110c8d@github.com>
Message-ID: <c2wx-XUPUDVyhBmf5bPyK7KR4HUd9zYqE_8EjoGB2Is=.c4fb87d3-3d66-466e-8b72-dcb03c4a5dee@github.com>

On Mon, 8 Apr 2024 16:36:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding tests as suggested.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 101:
> 
>> 99: import com.sun.tools.javac.tree.JCTree.JCPattern;
>> 100: import com.sun.tools.javac.tree.JCTree.JCPatternCaseLabel;
>> 101: import com.sun.tools.javac.tree.JCTree.JCDerivedInstance;
> 
> changes to this file can be removed now

Thanks, removed:
https://github.com/openjdk/jdk/pull/18509/commits/a05480cd1a436014ba00505db71d54d82a37ecd1

> test/langtools/tools/javac/patterns/withers/Model.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> probably this test should be in another location not under `patterns`, same for other tests added inside `patterns` folder

Thanks, moved:
https://github.com/openjdk/jdk/pull/18509/commits/a05480cd1a436014ba00505db71d54d82a37ecd1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557304771
PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1557304921

From prappo at openjdk.org  Tue Apr  9 11:11:18 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 9 Apr 2024 11:11:18 GMT
Subject: RFR: JDK-8298405: Implement JEP 467: Markdown Documentation
 Comments [v55]
In-Reply-To: <48hbLsx6MHdQQNNWrPRs4C-7sB18MyPOLE0QeTTPSDg=.1c0bd28d-8bd0-4733-a257-2c0f60bef2eb@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <48hbLsx6MHdQQNNWrPRs4C-7sB18MyPOLE0QeTTPSDg=.1c0bd28d-8bd0-4733-a257-2c0f60bef2eb@github.com>
Message-ID: <1uPEw9BTg1J92Zcw5bKKXcvc7Ula0WFLjFz0moN50U4=.752eb9c2-0a19-422d-adbb-79b71505be7f@github.com>

On Mon, 8 Apr 2024 21:12:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add support for JDK-8329296: Update Elements for '///' documentation comments

Changes for 21f5b00 mostly look good, but I'm not a compiler person.

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 443:

> 441:     @DefinedBy(Api.LANGUAGE_MODEL)
> 442:     public CommentKind getDocCommentKind(Element e) {
> 443:         return  getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

Nit:
Suggestion:

        return getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 443:

> 441:     @DefinedBy(Api.LANGUAGE_MODEL)
> 442:     public CommentKind getDocCommentKind(Element e) {
> 443:         return  getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

Again:
Suggestion:

        return getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocCommentTable.java line 55:

> 53: 
> 54:     /**
> 55:      * Get the plain text of the doc comment, if any, for a tree node.

This is likely a copy-pasted comment.

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

PR Review: https://git.openjdk.org/jdk/pull/16388#pullrequestreview-1988489764
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1557248565
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1557249290
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1557444619

From jlahoda at openjdk.org  Tue Apr  9 11:17:35 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 11:17:35 GMT
Subject: RFR: 8328481: Implement Module Imports [v3]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <jHYFkwh0r6Lfk31t4etDX0ZZv_5coHwTmFn7yNODlzk=.ec718d90-5b0f-4ca1-b6f2-36fdea20cd7c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - Cleanup.
 - Fixing CheckExamples.
 - Adding support for import modules to JShell.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/b9331cd2...c44031ed

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=02
  Stats: 1065 lines in 28 files changed: 989 ins; 11 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From mcimadamore at openjdk.org  Tue Apr  9 11:49:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Apr 2024 11:49:32 GMT
Subject: RFR: 8329948: Remove string template feature
Message-ID: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>

This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:

https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

Commit messages:
 - Drop spurious changes
 - Merge branch 'master' into template_removal
 - Drop string templates

Changes: https://git.openjdk.org/jdk/pull/18688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329948
  Stats: 7402 lines in 67 files changed: 135 ins; 7208 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18688/head:pull/18688

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

From jlahoda at openjdk.org  Tue Apr  9 13:38:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 9 Apr 2024 13:38:29 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Adding more tests for ambiguities.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c44031ed..0ca05b7d

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

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

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

From asotona at openjdk.org  Tue Apr  9 14:03:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 Apr 2024 14:03:13 GMT
Subject: RFR: 8323707: Adjust Classfile API's type arg model to better
 represent the embodied type [v4]
In-Reply-To: <1obW1-l1wFpTjbAlnhXqTlgr8i89LStvH8SmhqhniC0=.bf0763f6-bfb3-459b-aed1-a23835226615@github.com>
References: <MHOvwnWcnocbfiiIdkzyqB6qdt-f2HwiaTurds0p3Pg=.cda1d910-6ef4-4577-a539-10a959adcd1f@github.com>
 <1obW1-l1wFpTjbAlnhXqTlgr8i89LStvH8SmhqhniC0=.bf0763f6-bfb3-459b-aed1-a23835226615@github.com>
Message-ID: <3lJK9PIo3K3thIoGpQDR8_s7q4v5_8sLwPCQYJUUyeo=.6ae0006d-5dff-4c00-b4c7-7288dbcd4c02@github.com>

On Mon, 26 Feb 2024 17:48:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> API changes as discussed on the mailing list: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html
>> 
>> Additional questions:
>> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE`
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Missed renaming in tests, thanks to Adam Sotona
>    
>    Co-authored-by: Adam Sotona <10807609+asotona at users.noreply.github.com>
>  - Rename no wildcard indicator, improve docs slightly
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Merge branch 'master' into fix/typearg-model
>  - redundant line
>  - Fix a test in langtools, copyright year
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model
>  - Implementation cleanup, test update
>  - Merge branch 'master' into fix/typearg-model
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/f62b5789...839efabd

Looks good, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16517#pullrequestreview-1989125867

From djelinski at openjdk.org  Tue Apr  9 14:14:04 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 9 Apr 2024 14:14:04 GMT
Subject: RFR: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <K4dH31mBKuCe5-QqBfva3tK10IjtQaQhO4V1wWuZXn4=.29a7f267-218f-4c7d-925b-a3b7e8f0b022@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18672#issuecomment-2045276658

From djelinski at openjdk.org  Tue Apr  9 14:14:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 9 Apr 2024 14:14:05 GMT
Subject: Integrated: 8324673: javacserver failed during build:
 RejectedExecutionException
In-Reply-To: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
References: <1W72je45JGhBSNtpEHMr3SyWKf570x9AWKbGZkV0roE=.db6cd36e-3f8c-464a-bc4c-16697b3482fe@github.com>
Message-ID: <vwkYsplQ_qk3I20-ukB6puqQt2bL86jrwT5S35tiAbk=.84e1630f-21a9-4cd2-98be-48c6121e1ac8@github.com>

On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The RejectedExecutionException was thrown when the thread executing `Server.start` managed to shut down the `compilerThreadPool` before the thread executing `Server.handleRequest` submitted the compilation task.
> 
> This patch removes the extra thread used for `Server.handleRequest`, and executes that method directly in the thread pool. All `compilerThreadPool` uses happen on the `Server.start` thread now, and no new tasks are submitted after the thread pool is shut down.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. With that change the problem was occasionally reproducible without the patch from this PR. With the patch, the `RejectedExecutionException` problem did not reproduce. 
> 
> No new regression test. Existing langtools tests continue to pass.

This pull request has now been integrated.

Changeset: 3b6629ce
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b6629cec7a2ecec8dcb5b94d8ed3e169483aa97
Stats:     19 lines in 2 files changed: 1 ins; 10 del; 8 mod

8324673: javacserver failed during build: RejectedExecutionException

Reviewed-by: cstein, erikj

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

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

From acobbs at openjdk.org  Tue Apr  9 15:36:27 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 9 Apr 2024 15:36:27 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

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

 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Merge branch 'master' into JDK-8317376
 - Javadoc++
 - Merge branch 'master' into JDK-8317376
 - Several improvements to the 'this' escape analyzer.
   
   - Track direct, indirect, and outer references for all Ref types.
   - Keep type information about all references to improve tracking precision.
   - Track enhanced for() invocations of iterator(), hasNext(), and next().
   - Don't report an escape of a non-public outer instances as a leak.
   - Fix omitted tracking of references from newly instantiated instances.
   - Fix omitted tracking of leaks via lambda return values.
   - Remove unneccesary suppressions of this-escape lint warning.

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

Changes: https://git.openjdk.org/jdk/pull/16208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16208&range=03
  Stats: 869 lines in 19 files changed: 513 ins; 146 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From liach at openjdk.org  Tue Apr  9 20:34:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Apr 2024 20:34:11 GMT
Subject: RFR: 8329948: Remove string template feature
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>

On Tue, 9 Apr 2024 11:34:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

> 118:      * @since 21
> 119:      */
> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;

May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.

src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 44:

> 42:  *
> 43:  * @since 21
> 44:  */

Spurious javadoc

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1558241809
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1558250463

From prappo at openjdk.org  Tue Apr  9 21:17:09 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 9 Apr 2024 21:17:09 GMT
Subject: RFR: JDK-8328501 Incorrect @since` tags for java security
 interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <gI7floE5lBPDchH7R9VtXrGOwVMvq3nMeHK-2mi-Z2w=.46a4366f-e7bb-4b15-85bf-b4ab37375196@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

The PR title needs attention: missing `

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2046063891

From jjg at openjdk.org  Tue Apr  9 23:22:00 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 9 Apr 2024 23:22:00 GMT
Subject: RFR: JDK-8328501 Incorrect @since` tags for java security
 interfaces [v3]
In-Reply-To: <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
Message-ID: <hyMnQevaWpJm6_2gLC643oQC46XiJxGEN3l6dEUdubQ=.b751ee40-2ce9-4b09-ab69-4e1d1703d74c@github.com>

On Mon, 25 Mar 2024 22:51:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
>> We're following these rules for now:
>> 
>> ### Rule 1: Introduction of New Elements
>> 
>> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
>> 
>> ### Rule 2: Existing Elements in Subsequent JDK Versions
>> 
>> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
>> 
>> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
>> 
>> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
>> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
>> 
>>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
>> 
>> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
>> 
>> As pointed out by my mentor Jan, 
>> 
>> 
>> import javax.crypto.interfaces.DHPublicKey;
>> 
>> public class DhkeyTest {
>> 
>>     public static void main(DHPublicKey key) {
>>         System.err.println(key.getParams());
>>     }
>>     
>> }
>> 
>> 
>> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
>> 
>> 
>> - the same goes for these other interfaces 
>> 
>> java.security.interfaces.DSAPublicKey
>> java.security.interfaces.XECPublicKey
>> java.security.interfaces.DSAPrivateKey
>> java.security.interfaces.ECPrivateKey
>> java.security.interfaces.XECPrivateKey
>> java.security.interfaces.EdECPrivateKey
>> java.security.interfaces.ECPublicKey
>> java.security.interfaces.EdECPublicKey
>> javax.crypto.interfaces.DHPrivateKey
>> javax.crypto.interfaces.DHPublicKey
>> java.security.interfaces.RSAPublicKey
>> java.security.interfaces.RSAPrivateKey
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year to 2024

[wangweij](https://github.com/wangweij) commented [3 weeks ago](https://github.com/openjdk/jdk/pull/18373#issuecomment-2007161883)
I'd like to hear opinions from compiler experts.

@wangweij you probably mean javadoc experts, not compiler experts ;-)

The rules are currently quite simple, and can be expressed in effectively two ways.   Ignoring preview API and nested classes for now:

1. `javadoc` is very simple minded when it comes to handling `@since` tags -- 
    *  if a `@since` tag is present in a documentation comment, it will result in a `Since:` entry in the generated documentation.   
    * if there is no `@since` tag in the documentation comment, there will be no `Since:` info in the generated documentation
    
2. Every declaration should have an `@since` tag indicating when it was first introduced -- except for members of a class or interface if the `@since` value would be the same as for the enclosing class or interface.

* There are no special rules for inferring values for overriding methods.
* There are some special rules for Preview API outlines in [JEP 12](https://openjdk.org/jeps/12)
* There is a PR in progress for `javadoc`, such that if a nested class or interface has no `@since` tag of its own, the info from its enclosing class or interface will be used to generate `Since:` info fir the generate API docs for the nested class.

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2046188650

From weijun at openjdk.org  Tue Apr  9 23:59:08 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 9 Apr 2024 23:59:08 GMT
Subject: RFR: JDK-8328501 Incorrect @since` tags for java security
 interfaces [v3]
In-Reply-To: <hyMnQevaWpJm6_2gLC643oQC46XiJxGEN3l6dEUdubQ=.b751ee40-2ce9-4b09-ab69-4e1d1703d74c@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
 <a4xxIr7-Wis7ByAj7od2xW8GbyZqNqS-oE4iGilHFAI=.35c1076b-385e-4b01-8aa5-16e1173dbbf7@github.com>
 <hyMnQevaWpJm6_2gLC643oQC46XiJxGEN3l6dEUdubQ=.b751ee40-2ce9-4b09-ab69-4e1d1703d74c@github.com>
Message-ID: <zuS0h3k7eLzlYV--N-yn8OHMiKCcUDaLwM09VSiEKTo=.6dae100d-d2be-477e-a30f-5740bf3f2b0e@github.com>

On Tue, 9 Apr 2024 23:19:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year to 2024
>
> [wangweij](https://github.com/wangweij) commented [3 weeks ago](https://github.com/openjdk/jdk/pull/18373#issuecomment-2007161883)
> I'd like to hear opinions from compiler experts.
> 
> @wangweij you probably mean javadoc experts, not compiler experts ;-)
> 
> The rules are currently quite simple, and can be expressed in effectively two ways.   Ignoring preview API and nested classes for now:
> 
> 1. `javadoc` is very simple minded when it comes to handling `@since` tags -- 
>     *  if a `@since` tag is present in a documentation comment, it will result in a `Since:` entry in the generated documentation.   
>     * if there is no `@since` tag in the documentation comment, there will be no `Since:` info in the generated documentation
>     
> 2. Every declaration should have an `@since` tag indicating when it was first introduced -- except for members of a class or interface if the `@since` value would be the same as for the enclosing class or interface.
> 
> * There are no special rules for inferring values for overriding methods.
> * There are some special rules for Preview API outlines in [JEP 12](https://openjdk.org/jeps/12)
> * There is a PR in progress for `javadoc`, such that if a nested class or interface has no `@since` tag of its own, the info from its enclosing class or interface will be used to generate `Since:` info fir the generate API docs for the nested class.

@jonathan-gibbons Perhaps I was looking for a JSR export. To clarify, I don't have the authority to definitively say what the `@since` tag for an overridden method should represent. I'm here to listen to those who do have that authority. Maybe I should have removed the `security` label when I added `compiler`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18373#issuecomment-2046215624

From cstein at openjdk.org  Wed Apr 10 08:44:11 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 10 Apr 2024 08:44:11 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:

> 3551: # 0: symbol
> 3552: compiler.err.import.module.does.not.read=\
> 3553:     current modules does not read: {0}

Suggestion:

    current module does not read: {0}


It would even be better to print the name of the "current" module, so that the user-facing message reads:
`current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559074245

From mcimadamore at openjdk.org  Wed Apr 10 10:38:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:38:12 GMT
Subject: RFR: 8329948: Remove string template feature [v2]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <7L60G7fcdc2dZz5fMZJ3J9vE2QzE8_hePNjxLSCh7ls=.335d46ea-07c2-43bb-be55-e69dff55ed0c@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Address review comments
  Drop redundant imports in digit classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/99e940f6..da5b32c9

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

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

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

From mcimadamore at openjdk.org  Wed Apr 10 10:48:38 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:48:38 GMT
Subject: RFR: 8329948: Remove string template feature [v3]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <FyY9fKVFpzoGfhsEVa0f21rjVFf1Cl6whkJqWJ0u8Pw=.7595911c-c7e5-4241-b3a4-4960be540c5e@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Revert StringConcatFactory field to before string template

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/da5b32c9..a7396ce0

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

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

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

From mcimadamore at openjdk.org  Wed Apr 10 10:48:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:48:39 GMT
Subject: RFR: 8329948: Remove string template feature [v3]
In-Reply-To: <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
Message-ID: <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>

On Tue, 9 Apr 2024 20:22:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert StringConcatFactory field to before string template
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 120:
> 
>> 118:      * @since 21
>> 119:      */
>> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 
> May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.

Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).

> src/java.base/share/classes/jdk/internal/util/OctalDigits.java line 44:
> 
>> 42:  *
>> 43:  * @since 21
>> 44:  */
> 
> Spurious javadoc

fixed, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559228274
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559228920

From mcimadamore at openjdk.org  Wed Apr 10 10:59:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 10:59:25 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Fix issues in digit classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/a7396ce0..51e261bd

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

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

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

From mcimadamore at openjdk.org  Wed Apr 10 11:55:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 11:55:10 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
Message-ID: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>

On Tue, 9 Apr 2024 13:38:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more tests for ambiguities.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:

> 717:     public static class JCModuleImport extends JCImportBase {
> 718:         /** The module name. */
> 719:         public JCExpression module;

Does it need to be an expression? Or is a name enough?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559303562

From djelinski at openjdk.org  Wed Apr 10 12:27:29 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 10 Apr 2024 12:27:29 GMT
Subject: RFR: 8201183: sjavac build failures:
 "Connection attempt failed: Connection refused"
Message-ID: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>

The "Connection attempt failed: Connection refused" error may happen if the client tries to connect to a server that is no longer listening, which in turn may happen if the server shuts down without removing the port file. I added a check that the delete operation succeeded, and retry as necessary.

I removed the comment about asynchronous deletes on Windows. I don't think it's correct; it's more likely that the file existed because the delete operation failed.

I added a 1 second delay after deleting the port file; this delay is intended to allow any clients that managed to read the port file before it was deleted to finish connecting. It should also take care of the "IOException caught during compilation: Connection reset" issue.

And finally, the portfile is now closed when not in use. This was necessary to fix the failures on Windows, where the file cannot be deleted as long as it is open in any process.

In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. Without the changes from this PR this resulted in at least a few failures in every mach5 run. With this PR I was able to build tier1-5 with no failures.

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

Commit messages:
 - Close port file after use
 - Check delete result

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

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

From erikj at openjdk.org  Wed Apr 10 13:18:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Apr 2024 13:18:09 GMT
Subject: RFR: 8201183: sjavac build failures:
 "Connection attempt failed: Connection refused"
In-Reply-To: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
References: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
Message-ID: <v1tnIIB0vjXmahuIbE0wT8rEF38kcfljFW_ekhjLFBg=.15e1192e-d02f-4943-994b-67fe455b7134@github.com>

On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The "Connection attempt failed: Connection refused" error may happen if the client tries to connect to a server that is no longer listening, which in turn may happen if the server shuts down without removing the port file. I added a check that the delete operation succeeded, and retry as necessary.
> 
> I removed the comment about asynchronous deletes on Windows. I don't think it's correct; it's more likely that the file existed because the delete operation failed.
> 
> I added a 1 second delay after deleting the port file; this delay is intended to allow any clients that managed to read the port file before it was deleted to finish connecting. It should also take care of the "IOException caught during compilation: Connection reset" issue.
> 
> And finally, the portfile is now closed when not in use. This was necessary to fix the failures on Windows, where the file cannot be deleted as long as it is open in any process.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. Without the changes from this PR this resulted in at least a few failures in every mach5 run. With this PR I was able to build tier1-5 with no failures.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18712#pullrequestreview-1991663738

From jlahoda at openjdk.org  Wed Apr 10 13:32:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 13:32:00 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <BohOYyF4w-dUcVGpURKSBBX3MaxxL_tXQx7SyW8yP8k=.8cdf4e7f-065a-409f-bfc3-3d838b96b0d8@github.com>
Message-ID: <dykimHLkPTQ3DOlg_958nShX_C6jg2R8LyYiYty9dvo=.8e80a4d4-50d4-476b-9c99-7caabe850c93@github.com>

On Wed, 10 Apr 2024 11:52:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 719:
> 
>> 717:     public static class JCModuleImport extends JCImportBase {
>> 718:         /** The module name. */
>> 719:         public JCExpression module;
> 
> Does it need to be an expression? Or is a name enough?

Expression is more consistent with e.g. the module directives (`JCRequires` has `JCExpression moduleName`). Also allows us to keep positions for the name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559440577

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v5]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Uaz4XY4xMPhWtROJwJZXvj3xTpaLM9PkENBv2I7a5v0=.05e6dd91-b210-44b5-bdf9-55956ddb02d3@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Including current module name as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/0ca05b7d..7cfaff80

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

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

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

From jlahoda at openjdk.org  Wed Apr 10 15:06:30 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:06:30 GMT
Subject: RFR: 8328481: Implement Module Imports [v4]
In-Reply-To: <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZO64tdNTBrJ_M1b86ysagoAhO8XmAxiW497jgm1nyMs=.c9a223d1-89ca-4aff-8155-263ca6f74e1c@github.com>
 <X1fgv83ISFt7b_vEoGduYxDygxgKv9vB2WvI0TpWAGg=.8067fed6-f3cd-4335-844e-bb5889f1caef@github.com>
Message-ID: <ppdqge1epw5D3i0ClDI94dSJEhzgUcnGhSxGYGZoiWU=.8f834464-b2c7-441b-85f0-520ba637c8ef@github.com>

On Wed, 10 Apr 2024 08:41:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more tests for ambiguities.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3553:
> 
>> 3551: # 0: symbol
>> 3552: compiler.err.import.module.does.not.read=\
>> 3553:     current modules does not read: {0}
> 
> Suggestion:
> 
>     current module does not read: {0}
> 
> 
> It would even be better to print the name of the "current" module, so that the user-facing message reads:
> `current module foo does not read module bar - possible fix: add "requires bar;" to foo's module descriptor `

Thanks. I've tweaked the error to include the module name here:
https://github.com/openjdk/jdk/pull/18614/commits/7cfaff80eac6261b62c5cdb9614a0e708bce7e33

Regarding possible fix(es) - it may be better to introduce some framework for that, and convert the most typical errors, separately. (As I don't think we do that for other errors.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1559616761

From jlahoda at openjdk.org  Wed Apr 10 15:20:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Apr 2024 15:20:00 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
 <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
Message-ID: <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>

On Wed, 10 Apr 2024 10:44:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 120:
>> 
>>> 118:      * @since 21
>>> 119:      */
>>> 120:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 
>> May this value change in the future? If yes, we might change this to a method to avoid incorrect eager inlining by the java compiler, or drop this with string templates.
>
> Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).

Just for completeness - note the field is not initialized in its initializator, but using a static init below. Fields like this are not inlined as constants by javac - that would require the value to be provided in the field initializator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559643723

From mcimadamore at openjdk.org  Wed Apr 10 15:38:59 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Apr 2024 15:38:59 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <zRcBjiefx-xBhl6_LSFdu-cKh3FDRUGZXFKqfb0U2dM=.8238dec1-adec-481e-b7f3-18efe3a8388b@github.com>
 <5RuKC7OJFsFyaUYkks205sl6QlaU1-W7owcjpgwb0bE=.63df07df-6793-45fe-a999-2e5128487022@github.com>
 <sLe7LwlNZ0tmjHahjRp9_K_TJ5bt5x5P7YxohEm21tA=.3a43d9ec-f93d-4add-a2f5-d0903af6030f@github.com>
Message-ID: <an8ZYi4YGqnB6GIu7hFYUbuTRiPW0TrAOkAgwPhQCAI=.8bad2ef8-6827-492c-9d6f-b636d58fbc84@github.com>

On Wed, 10 Apr 2024 15:17:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Good catch. Since this was tweaked to be a public API as part of the string template feature, I've reverted this code to what it was prior to string template. That is, now this is a private static final constant, with initializer set to 200 (no need to inhibit javac constant folding, since all uses are from this file).
>
> Just for completeness - note the field is not initialized in its initializator, but using a static init below. Fields like this are not inlined as constants by javac - that would require the value to be provided in the field initializator.

@lahodaj - I understand that - but I reverted to use the initializer, since the initializer was used before string templates (when the field was private).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1559676399

From abimpoudis at openjdk.org  Thu Apr 11 07:02:43 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 11 Apr 2024 07:02:43 GMT
Subject: RFR: 8326404: Assertion error when trying to compile switch with
 fallthrough with pattern
In-Reply-To: <TDLuY-fw0oPT_HwQeMtBNn61l-cxlSKTlbmPQB78xMQ=.a716585a-23cd-4fbf-b990-a142e2bc431a@github.com>
References: <TDLuY-fw0oPT_HwQeMtBNn61l-cxlSKTlbmPQB78xMQ=.a716585a-23cd-4fbf-b990-a142e2bc431a@github.com>
Message-ID: <rUjXWrGWEzUQ3Nf7gB8GOkrR8luFm6gMFhCHAmoPLcQ=.486a43b8-2808-495a-af5f-e7c84b88154b@github.com>

On Fri, 23 Feb 2024 12:31:01 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> The assertion error that was raised in the bug report is a result of local variables not being defined in the case of switches that mix type patterns and record patterns with fall-through. e.g., a print after the `TransPatterns` phase:
> 
> 
> private static int run(Object o) {
>   int i = 0;
>   /*synthetic*/ Object selector2$temp = <*nullchk*>(o);
>   /*synthetic*/ int index$3 = 0;
>   switch (java.lang.runtime.SwitchBootstraps.typeSwitch(selector2$temp, index$3)) {
>     case 0:
>       String s;
>       if (!(let s = (String)selector2$temp; in true)) {
>         index$3 = 1;
>         continue;
>       }
>       i++;
>     case 1:
>       {
>       /*synthetic*/ Object selector4$temp = $b$O.a(); // $b$O appears undefined here 
>       ...
>       }
>     ...
>   }
> }
> 
> 
> The code for unrolling a case label into local variable declaration statements appears in `handleSwitch` here: https://github.com/openjdk/jdk/pull/17981/files#diff-e50bbfa8783f3bc8f5542452740b78f3167bee19be7365a87da2298c6333cca6L593-L606
> 
> `patchCompletingNormallyCases` takes care of statement block propagation for code that completes normally. Unfortunately this code is called late (after the optimization that merges common type tests together e.g., `case R(...): .... case R(...): ....`). 
> 
> The fix bails out of this optimization in the presence of fall-through. For example in the `run3_break1` included, the optimization is triggered. In the rest, not.
> 
> Additionally, this patch elides the unnecessary binding generation of unnamed pattern variables from the binding context.
> 
> Thanks @lahodaj for contributing this solution ?

Keep it open.

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

PR Comment: https://git.openjdk.org/jdk/pull/17981#issuecomment-2049044437

From jlahoda at openjdk.org  Thu Apr 11 09:18:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 Apr 2024 09:18:43 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
Message-ID: <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>

On Wed, 10 Apr 2024 10:59:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issues in digit classes

javac and JShell changes look good to me (with a nit in JShell tests).

For consideration: using `{` will now produce the "illegal escape character" error. Which is technically correct, but maybe we could add a special error, saying that StringTemplates are removed for now? So that if someone will try to compile source code with StringTemplates, they would now this was intentional. Just for consideration.

test/langtools/jdk/jshell/CompletionSuggestionTest.java line 327:

> 325:         assertSignature("String.format(|",
> 326:                 "String String.format(String, Object...)",
> 327:                 "String String.format(java.util.Locale, String, Object...)"

Nit: this change appears to be unnecessary?

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18688#pullrequestreview-1993673798
PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1560692978

From mcimadamore at openjdk.org  Thu Apr 11 10:11:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 10:11:43 GMT
Subject: RFR: 8329948: Remove string template feature [v4]
In-Reply-To: <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <pQ7KfrIBPSZz0ktsYzF1_7tUsCfWErjze-3Ez8kNGYE=.79b45003-ad90-4e6a-8ff4-aca7a7386fa1@github.com>
 <j_XuSoJzBAz3AW8nG95sI8kEU0JtNB_F-B1dBReMTDk=.5d5c7e6a-bd58-4d9a-b77e-fe062a55d368@github.com>
Message-ID: <MBks6WmEM3S73bv3iI6XMo8EpAkIEhljv6ScZk63vdM=.eda7ef3d-cb10-4a41-b92e-9896a4cc6f91@github.com>

On Thu, 11 Apr 2024 09:12:06 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issues in digit classes
>
> test/langtools/jdk/jshell/CompletionSuggestionTest.java line 327:
> 
>> 325:         assertSignature("String.format(|",
>> 326:                 "String String.format(String, Object...)",
>> 327:                 "String String.format(java.util.Locale, String, Object...)"
> 
> Nit: this change appears to be unnecessary?

I'll revert - thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18688#discussion_r1560775208

From mcimadamore at openjdk.org  Thu Apr 11 10:15:54 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 10:15:54 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

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

  Drop spurious jshell test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18688/files
  - new: https://git.openjdk.org/jdk/pull/18688/files/51e261bd..bbe05c97

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

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

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

From ihse at openjdk.org  Thu Apr 11 10:20:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Apr 2024 10:20:41 GMT
Subject: RFR: 8201183: sjavac build failures:
 "Connection attempt failed: Connection refused"
In-Reply-To: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
References: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
Message-ID: <dEpjaj3hN0C8F8EFItJilzI1Sgi397ooeXZ-X1eVrJw=.dc5bae0a-f454-4766-a275-42ea1e0ab5eb@github.com>

On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The "Connection attempt failed: Connection refused" error may happen if the client tries to connect to a server that is no longer listening, which in turn may happen if the server shuts down without removing the port file. I added a check that the delete operation succeeded, and retry as necessary.
> 
> I removed the comment about asynchronous deletes on Windows. I don't think it's correct; it's more likely that the file existed because the delete operation failed.
> 
> I added a 1 second delay after deleting the port file; this delay is intended to allow any clients that managed to read the port file before it was deleted to finish connecting. It should also take care of the "IOException caught during compilation: Connection reset" issue.
> 
> And finally, the portfile is now closed when not in use. This was necessary to fix the failures on Windows, where the file cannot be deleted as long as it is open in any process.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. Without the changes from this PR this resulted in at least a few failures in every mach5 run. With this PR I was able to build tier1-5 with no failures.

Thank you very much for spending the time and effort of fixing these intermittent javac server issues!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18712#pullrequestreview-1993815955

From djelinski at openjdk.org  Thu Apr 11 12:45:51 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 11 Apr 2024 12:45:51 GMT
Subject: RFR: 8201183: sjavac build failures:
 "Connection attempt failed: Connection refused"
In-Reply-To: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
References: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
Message-ID: <fr8xb3QswMgU9lZoyJSTHUlQmGpb04x0eIeHgJ2ihA0=.bb531a12-2957-45f4-83ea-1b13f906a0bd@github.com>

On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The "Connection attempt failed: Connection refused" error may happen if the client tries to connect to a server that is no longer listening, which in turn may happen if the server shuts down without removing the port file. I added a check that the delete operation succeeded, and retry as necessary.
> 
> I removed the comment about asynchronous deletes on Windows. I don't think it's correct; it's more likely that the file existed because the delete operation failed.
> 
> I added a 1 second delay after deleting the port file; this delay is intended to allow any clients that managed to read the port file before it was deleted to finish connecting. It should also take care of the "IOException caught during compilation: Connection reset" issue.
> 
> And finally, the portfile is now closed when not in use. This was necessary to fix the failures on Windows, where the file cannot be deleted as long as it is open in any process.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. Without the changes from this PR this resulted in at least a few failures in every mach5 run. With this PR I was able to build tier1-5 with no failures.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18712#issuecomment-2049609810

From djelinski at openjdk.org  Thu Apr 11 12:45:51 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 11 Apr 2024 12:45:51 GMT
Subject: Integrated: 8201183: sjavac build failures:
 "Connection attempt failed: Connection refused"
In-Reply-To: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
References: <wecjYrt46Jb6dkqiR7Y0QH_Key4NTfNI7THvY0vcj2s=.3dbca270-1103-4526-b409-9477405c119d@github.com>
Message-ID: <9jYQacqsc5L9f7pVydZRkwocvfo8nvdnRPLLhrmgGc8=.87798cc5-54f7-41df-b654-9ab4d69b689e@github.com>

On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The "Connection attempt failed: Connection refused" error may happen if the client tries to connect to a server that is no longer listening, which in turn may happen if the server shuts down without removing the port file. I added a check that the delete operation succeeded, and retry as necessary.
> 
> I removed the comment about asynchronous deletes on Windows. I don't think it's correct; it's more likely that the file existed because the delete operation failed.
> 
> I added a 1 second delay after deleting the port file; this delay is intended to allow any clients that managed to read the port file before it was deleted to finish connecting. It should also take care of the "IOException caught during compilation: Connection reset" issue.
> 
> And finally, the portfile is now closed when not in use. This was necessary to fix the failures on Windows, where the file cannot be deleted as long as it is open in any process.
> 
> In order to verify the fix, I modified `IdleMonitor.KEEPALIVE` to 1 second. Without the changes from this PR this resulted in at least a few failures in every mach5 run. With this PR I was able to build tier1-5 with no failures.

This pull request has now been integrated.

Changeset: ecc603ca
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecc603ca9b441cbb7ad27fbc2529fcb0b1da1992
Stats:     32 lines in 1 file changed: 12 ins; 8 del; 12 mod

8201183: sjavac build failures: "Connection attempt failed: Connection refused"

Reviewed-by: erikj, ihse

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

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

From liach at openjdk.org  Thu Apr 11 14:50:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Apr 2024 14:50:43 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <get1Vfs3KfPmTX8GCk3daxcCw8opzfeYUHVc-b08b3E=.1736e7b8-4ef0-454f-8a5b-c9c250089340@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

Also, is `java.lang.runtime.Carriers` to be kept? This utility is really helpful, but it probably should be moved to `jdk.internal` if String Templates is dropped.

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

PR Comment: https://git.openjdk.org/jdk/pull/18688#issuecomment-2049870402

From jjg at openjdk.org  Thu Apr 11 17:42:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 17:42:57 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v55]
In-Reply-To: <1uPEw9BTg1J92Zcw5bKKXcvc7Ula0WFLjFz0moN50U4=.752eb9c2-0a19-422d-adbb-79b71505be7f@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <48hbLsx6MHdQQNNWrPRs4C-7sB18MyPOLE0QeTTPSDg=.1c0bd28d-8bd0-4733-a257-2c0f60bef2eb@github.com>
 <1uPEw9BTg1J92Zcw5bKKXcvc7Ula0WFLjFz0moN50U4=.752eb9c2-0a19-422d-adbb-79b71505be7f@github.com>
Message-ID: <oXQpJBD-ik0VdK_m5UXEGiznQQk7PSuN4G1HEm1p_2c=.31a8da35-4adc-4372-b019-37fb257b9755@github.com>

On Tue, 9 Apr 2024 08:53:10 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add support for JDK-8329296: Update Elements for '///' documentation comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 443:
> 
>> 441:     @DefinedBy(Api.LANGUAGE_MODEL)
>> 442:     public CommentKind getDocCommentKind(Element e) {
>> 443:         return  getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));
> 
> Nit:
> Suggestion:
> 
>         return getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

Fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java line 443:
> 
>> 441:     @DefinedBy(Api.LANGUAGE_MODEL)
>> 442:     public CommentKind getDocCommentKind(Element e) {
>> 443:         return  getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));
> 
> Again:
> Suggestion:
> 
>         return getDocCommentItem(e, ((docCommentTable, tree) -> docCommentTable.getCommentKind(tree)));

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1561382358
PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1561382835

From jjg at openjdk.org  Thu Apr 11 17:52:14 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 17:52:14 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v56]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <AO9I9d0P1PDuc5Kjg4Kpy3Tqhg1lMW1oerlPTRFK3Bs=.da684167-eb91-4886-8196-7b866da3ba92@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  address review feedback for updates to Elements and friends

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/21f5b004..d4c2c73b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=54-55

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

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

From jlaskey at openjdk.org  Thu Apr 11 18:47:44 2024
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 Apr 2024 18:47:44 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <AUuq0A99nrPYaYWrZp2S-OCYR-JVjOJx_QeOpKfVFg4=.7606f4c3-1478-40f5-b544-c8094c6e0d2b@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

Carriers is used by pattern matching as well and should remain in runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/18688#issuecomment-2050304721

From jjg at openjdk.org  Thu Apr 11 20:55:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 20:55:24 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <au6_FZORG1xVh5VnfoMMR60a_2oa1qny0ElKeIGpvFI=.94ed31a5-a875-4bc6-927b-da0f512ad43e@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  adjust call for `saveDanglingDocComments` for enum members

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3d6f1f95..56d6dcac

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

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

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

From jjg at openjdk.org  Fri Apr 12 17:24:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 17:24:43 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
Message-ID: <yoXk0XJ1mo_6lFPzenTjynOJmM2R8GNROFOTwN4p00g=.dcedceac-6d2a-4b1f-99ee-57d060b8a69b@github.com>

On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay. 
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

@magicus 
> The build changes look okay.
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up `java.base`, to keep that one free of any warnings, and I can see that the lang tools modules will get cleaner up as well. It will be up to other component teams to decide if and when to clean up other parts of the system.  Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like `this-escape`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2052174696

From darcy at openjdk.org  Fri Apr 12 17:41:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 12 Apr 2024 17:41:56 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v56]
In-Reply-To: <AO9I9d0P1PDuc5Kjg4Kpy3Tqhg1lMW1oerlPTRFK3Bs=.da684167-eb91-4886-8196-7b866da3ba92@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
 <AO9I9d0P1PDuc5Kjg4Kpy3Tqhg1lMW1oerlPTRFK3Bs=.da684167-eb91-4886-8196-7b866da3ba92@github.com>
Message-ID: <5BLnTYx2hjFyOvw3_RQWLDcPwvREkTII1AaLhdQUB7I=.84043d72-429a-4b9a-a119-57f45d239950@github.com>

On Thu, 11 Apr 2024 17:52:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
>> 
>> Notable features:
>> 
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
>> * updates to `DocCommentParser` to treat `///` comments as Markdown
>> * updates to the standard doclet to render Markdown comments in HTML
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review feedback for updates to Elements and friends

There should be some quick testing of the new default method on Elements using the VacuousElements implementation; see
`test/langtools/tools/javac/processing/model/util/elements`
for some examples.

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

PR Comment: https://git.openjdk.org/jdk/pull/16388#issuecomment-2052196439

From cushon at openjdk.org  Fri Apr 12 18:40:16 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 12 Apr 2024 18:40:16 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations [v4]
In-Reply-To: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
Message-ID: <piFbmjLAxbrmlbscYWbNmteNAHXDx4wGe2aMLTar9aQ=.71dabcf7-bbd2-4a49-83aa-bf8274356519@github.com>

> Hi,
> 
> Please consider this improvement to diagnostics on inadmissable type annotations.
> 
> [JDK-8057683: clarify error messages trying to annotate scoping](https://bugs.openjdk.org/browse/JDK-8057683) is closely related to JDK-8043226 and I think could be made a duplicate of that bug. [JDK-8057683: improve ordering of errors with type annotations](https://bugs.openjdk.org/browse/JDK-8057683) is also closely related, and this PR partially fixes the issues described in that bug.
> 
> I have some notes on details of the proposed changes below.
> 
> ---
> 
> Currently javac reports 'scoping construct cannot be annotated' diagnostics for type annotations at locations where they are not admissable. 
> 
> As discussed in [JDK-8043226](https://bugs.openjdk.org/browse/JDK-8043226) and [JDK-8057683](https://bugs.openjdk.org/browse/JDK-8057683), the current language is unclear. The 'scoping construct' language was used in JSR-308 discussions but didn't end up in the final specification, JLS ?9.7.4 talks about where annotations are 'admissable', and that language is mirrored in JVMS ?4.7.20.2.
> 
> This change updates the diagnostics to state that type annotations 'not admissible at this location' and removed the reference to 'scoping constructs'. Additionally, the diagnostic now includes an explanation of a location in the type where annotations would be admissible, to make it easier to understand how to annotate qualified type names.
> 
> Before:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: scoping construct cannot be annotated with type-use annotation: @TA
>     @TA Outer.SInner osi;
>              ^
> 
> 
> After:
> 
> 
> test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java:38: error: type annotations are not admissible at this location: @TA
>     @TA Outer.SInner osi;
>              ^
>   (to annotate a qualified type, write Outer. at TA SInner)
> 
> 
> ---
> 
> Attribution currently assumes `@TA java.lang.Object` in `List<@TA java.lang.Object>` will be a type (not a package), and reports a resolution failure when it can't find a class named `java`.
> 
> This change modifies attribution to search for packages as well as types when resolving annotated types, and relies on the subsequent error checking for annotated types to report that type annotations are not admissible at that location.
> 
> This also improves the ordering of the diagnostic in the output, since attribution errors are report before type annotation validation errors in the l...

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

 - Merge branch 'master' into JDK-8043226
 - Merge branch 'master' into JDK-8043226
 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
   
   Co-authored-by: Werner Dietl <wdietl at gmail.com>
 - 8043226: Better diagnostics for non-applicable type annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16592/files
  - new: https://git.openjdk.org/jdk/pull/16592/files/77aca669..1bf7ca7c

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

  Stats: 483803 lines in 4634 files changed: 46515 ins; 103446 del; 333842 mod
  Patch: https://git.openjdk.org/jdk/pull/16592.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16592/head:pull/16592

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

From cushon at openjdk.org  Fri Apr 12 18:42:42 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 12 Apr 2024 18:42:42 GMT
Subject: RFR: 8043226: Better diagnostics for non-applicable type
 annotations [v2]
In-Reply-To: <dtaFadLmFzKtDVwu1bgZDiL46IXHkwGG4GhN-TQRKXw=.5e9d8427-1d56-4a28-8711-2c3430c87492@github.com>
References: <Dlj5Ndm_XOgoPcjQPtoIjpHoCAYkZk_AFv4ETPG0sig=.efa2961d-7e2c-423e-852b-48155c944543@github.com>
 <4ymqDKx7z9VqfAjr93Dx7tVCUnJDoz_1TIY4oarSkoc=.26f92336-85b6-4549-a4a1-cb1d5a424d78@github.com>
 <dtaFadLmFzKtDVwu1bgZDiL46IXHkwGG4GhN-TQRKXw=.5e9d8427-1d56-4a28-8711-2c3430c87492@github.com>
Message-ID: <T3LkUlfhXcuQKvq6b875obfjx4KIsvJv_tbcQSwYA08=.416b33b0-dfea-4511-bfa1-ec75b9190a6b@github.com>

On Tue, 5 Mar 2024 20:27:39 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Feel free to ask for assistance if you need help with progressing this pull request towards integration!

I am still interested in pursuing this, and would welcome any input on progressing the PR

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

PR Comment: https://git.openjdk.org/jdk/pull/16592#issuecomment-2052278689

From jjg at openjdk.org  Fri Apr 12 21:04:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 21:04:06 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v3]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <3Ynu_D2CcFh3usjCkWQVk7VFhTlxVzD4f2nVhvZrP50=.f1c29740-ff73-4a0c-a63b-3e00ece05bbf@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  call `saveDanglingDocComments` for local variable declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/56d6dcac..3f745431

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

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

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

From darcy at openjdk.org  Sat Apr 13 00:12:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 13 Apr 2024 00:12:50 GMT
Subject: RFR: 8330197: Make javac/diags/example release agnostic
Message-ID: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>

Make recently added test cases release agnostic.

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

Commit messages:
 - JDK-8330197: Make javac/diags/example release agnostic

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

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

From davidalayachew at gmail.com  Mon Apr 15 03:32:42 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 14 Apr 2024 23:32:42 -0400
Subject: Could we add a lint warning for when the type parameter name
 overloads an existing type name?
Message-ID: <CAA9v-_OfFwCHMMufOFLzr5bsJMbDWN5Y877si=jhvHLeSpR6bg@mail.gmail.com>

Hello Amber Dev Team, Client Lib Team, and Compiler Dev Team,

In the vein of smoothing the on-ramp for beginners, one of the biggest pain
points I have found when tutoring beginners is when they start to learn
generics, and then do something like this.
import java.util.*;

public class abc
{

    public static void main(final String[] args)
    {

        final Map<String, Integer> cache = new HashMap<>();

        final int result = updateCache(cache, "abc", 123);

        System.out.println(result);

    }

    public static <String, Integer> Integer updateCache(final Map<String,
Integer> cache, final String key, final int value)
    {

        return cache.put(key, Integer.valueOf(value));

    }

}

$ javac abc.java
abc.java:21: error: cannot find symbol
                return cache.put(key, Integer.valueOf(value));
                                             ^
  symbol:   method valueOf(int)
  location: class Object
1 error

This type of error is the worst because it sends them on the wildest goose
chase. They start coming up with the most eldritch deductions as to what
could possibly be wrong, and they start actively unlearning stuff that they
know to be true. When I finally show them what is wrong, it's already too
late because (1) they start doubting the foundations because the "clearly
correct" solution doesn't work for a non-obvious reason, and (2) they
usually picked up some incorrect assumptions along the way that neither of
us have realized yet.

And the worst part is that, if you removed the "Integer.valueOf", and then
changed the third parameter to be final Integer value instead of final int
value, then the code compiles and works as expected. So, the student can
actually go pretty far before code starts breaking. That is the absolute
worst because they start turning this style of coding into a habit and then
when it finally blows up, all of their progress has to be undone. They feel
defeated, they hate the feature, they lose motivation, and now I have to
work triple time to rebuild all of that. It's a terrible time for everyone
involved.

Could we add a lint option that turns this into a warning? Basically says,
if you put an alias for a parameterized type that also happens to be an
exact match for an already imported class, throw a warning upon compile?
Then, this issue can be caught at compile time the second that they
introduce it. When they ask me about the warning, I can immediately explain
the problem, and this entire fiasco is avoided.

Finally, I also type up this email because this can be kind of easy to miss
when you are quickly cycling back and forth between students, trying to
make sure everyone is good. I don't have that many now, but back when it
was double digits, I distinctly remember falling into this pothole multiple
times.

Any thoughts on this feature?

Thank you for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240414/ab8cc00f/attachment.htm>

From davidalayachew at gmail.com  Mon Apr 15 03:56:38 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 14 Apr 2024 23:56:38 -0400
Subject: Could we add a lint warning for when the type parameter name
 overloads an existing type name?
In-Reply-To: <CAA9v-_OfFwCHMMufOFLzr5bsJMbDWN5Y877si=jhvHLeSpR6bg@mail.gmail.com>
References: <CAA9v-_OfFwCHMMufOFLzr5bsJMbDWN5Y877si=jhvHLeSpR6bg@mail.gmail.com>
Message-ID: <CAA9v-_ORrBYiTzvHt4fkPOojCeksysWiu5+oi9dg-djpP085gQ@mail.gmail.com>

Whoops, I meant core-libs, not client libs. I always mix up the 2.

Copy pasting below, so that people don't have to read the butchered version
that pipermail spits out.

Hello Amber Dev Team, Client Lib Team, and Compiler Dev Team,

In the vein of smoothing the on-ramp for beginners, one of the biggest pain
points I have found when tutoring beginners is when they start to learn
generics, and then do something like this.
import java.util.*;

public class abc
{

    public static void main(final String[] args)
    {

        final Map<String, Integer> cache = new HashMap<>();

        final int result = updateCache(cache, "abc", 123);

        System.out.println(result);

    }

    public static <String, Integer> Integer updateCache(final Map<String,
Integer> cache, final String key, final int value)
    {

        return cache.put(key, Integer.valueOf(value));

    }

}

$ javac abc.java
abc.java:21: error: cannot find symbol
                return cache.put(key, Integer.valueOf(value));
                                             ^
  symbol:   method valueOf(int)
  location: class Object
1 error

This type of error is the worst because it sends them on the wildest goose
chase. They start coming up with the most eldritch deductions as to what
could possibly be wrong, and they start actively unlearning stuff that they
know to be true. When I finally show them what is wrong, it's already too
late because (1) they start doubting the foundations because the "clearly
correct" solution doesn't work for a non-obvious reason, and (2) they
usually picked up some incorrect assumptions along the way that neither of
us have realized yet.

And the worst part is that, if you removed the "Integer.valueOf", and then
changed the third parameter to be final Integer value instead of final int
value, then the code compiles and works as expected. So, the student can
actually go pretty far before code starts breaking. That is the absolute
worst because they start turning this style of coding into a habit and then
when it finally blows up, all of their progress has to be undone. They feel
defeated, they hate the feature, they lose motivation, and now I have to
work triple time to rebuild all of that. It's a terrible time for everyone
involved.

Could we add a lint option that turns this into a warning? Basically says,
if you put an alias for a parameterized type that also happens to be an
exact match for an already imported class, throw a warning upon compile?
Then, this issue can be caught at compile time the second that they
introduce it. When they ask me about the warning, I can immediately explain
the problem, and this entire fiasco is avoided.

Finally, I also type up this email because this can be kind of easy to miss
when you are quickly cycling back and forth between students, trying to
make sure everyone is good. I don't have that many now, but back when it
was double digits, I distinctly remember falling into this pothole multiple
times.

Any thoughts on this feature?

Thank you for your time and consideration!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240414/093d41ca/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Apr 15 06:56:41 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 15 Apr 2024 06:56:41 GMT
Subject: RFR: 8330197: Make javac/diags/example release agnostic
In-Reply-To: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
References: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
Message-ID: <e9kwP8M6xyC6JpSXqPNtGowKhr4SggBv_0waK9BBSiQ=.f4d0e3ea-7a78-4975-b1bd-1fce2661f18f@github.com>

On Sat, 13 Apr 2024 00:08:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make recently added test cases release agnostic.

Looks good, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18770#pullrequestreview-2000145122

From abimpoudis at openjdk.org  Mon Apr 15 13:50:41 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 15 Apr 2024 13:50:41 GMT
Subject: RFR: 8330197: Make javac/diags/example release agnostic
In-Reply-To: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
References: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
Message-ID: <wSzyZGi-DV7gSNUH1hwzRqQKOtCUp7UsAW2R1YJHDq8=.09efdc10-da05-4d58-a7ea-159fe47d98d0@github.com>

On Sat, 13 Apr 2024 00:08:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make recently added test cases release agnostic.

Thank you @jddarcy

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

PR Comment: https://git.openjdk.org/jdk/pull/18770#issuecomment-2056908314

From darcy at openjdk.org  Mon Apr 15 15:14:48 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 15:14:48 GMT
Subject: Integrated: 8330197: Make javac/diags/example release agnostic
In-Reply-To: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
References: <1ThvQofQqcb0f-k8E6iBvt-T71LFnLLMcGp-dk0Msxg=.dfde7af7-301e-45d3-81c7-c0f61e84c522@github.com>
Message-ID: <YuG3u0_6Z4Rk6cV65CJiBoJCsy2qVbf8uQsNLEwZrHk=.88f30744-b3f8-4078-a3f4-aea92b841316@github.com>

On Sat, 13 Apr 2024 00:08:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make recently added test cases release agnostic.

This pull request has now been integrated.

Changeset: a293bdff
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a293bdff91f7bcc0deece6bed3151a40fad42a64
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8330197: Make javac/diags/example release agnostic

Reviewed-by: jlahoda

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

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

From darcy at openjdk.org  Mon Apr 15 19:07:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 19:07:31 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
Message-ID: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>

Get JDK 24 underway.

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

Commit messages:
 - JDK-8330182: Start of release updates for JDK 24

Changes: https://git.openjdk.org/jdk/pull/18787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330182
  Stats: 101 lines in 37 files changed: 43 ins; 3 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

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

From darcy at openjdk.org  Mon Apr 15 19:09:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 19:09:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <qZnKYgjUvvMiD9WCCV0lbTTyFKAymG1KEVKRZWkhIW4=.ef7a12de-81a5-48cd-af70-78a6f4253d4e@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

This initial version of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057615983

From iris at openjdk.org  Mon Apr 15 20:00:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 15 Apr 2024 20:00:43 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

The copyright year was  not updated in all files *14.java.  I assume that's intentional. 

I've also Reviewed the associated CSRs.

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2024-03-17

"2024-03-17"?  I thought that the expected date was "2025-03-18"?

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2002002355
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566336599

From darcy at openjdk.org  Mon Apr 15 20:23:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 Apr 2024 20:23:41 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <7kb9r7YhLGd33spkclLkTdBCaN0d6nZ7h1z52Hhv4rs=.bffedb51-7144-4706-a4a8-34460959534a@github.com>
Message-ID: <TfadiV_C_pOGf2x7nI1pH2xU5UlQUF05uhZoD0bnCLg=.12de8d7a-cc14-4e63-a7ad-142da183d3b2@github.com>

On Mon, 15 Apr 2024 19:57:49 GMT, Iris Clark <iris at openjdk.org> wrote:

> The copyright year was not updated in all files *14.java. I assume that's intentional.

I'll run my copyright update script before pushing.

> I've also Reviewed the associated CSRs.

Thanks.

> make/conf/version-numbers.conf line 36:
> 
>> 34: DEFAULT_VERSION_EXTRA2=0
>> 35: DEFAULT_VERSION_EXTRA3=0
>> 36: DEFAULT_VERSION_DATE=2024-03-17
> 
> "2024-03-17"?  I thought that the expected date was "2025-03-18"?

Thanks for catching that; yes, I'll correct and double-check the expected GA date in the next push.

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

PR Comment: https://git.openjdk.org/jdk/pull/18787#issuecomment-2057735741
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1566383373

From duke at openjdk.org  Mon Apr 15 21:22:01 2024
From: duke at openjdk.org (Andrey Kuleshov)
Date: Mon, 15 Apr 2024 21:22:01 GMT
Subject: RFR: 8329948: Remove string template feature [v5]
In-Reply-To: <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
 <UMw3tIzxpV8N6nbDCxZPnziYLxkeYRAt2VnNTO3v9Ic=.6cdd72fe-d34b-49de-b635-cc00346d2bb8@github.com>
Message-ID: <EMJ8ppBhQWWzp9ZWwzWCIbkM0WvVwbl5lHdQQJAJnTE=.168b3b2c-1d26-40b8-9269-512087a7ca04@github.com>

On Thu, 11 Apr 2024 10:15:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
>> 
>> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious jshell test change

Marked as reviewed by akuleshov7 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/18688#pullrequestreview-2002188648

From vromero at openjdk.org  Mon Apr 15 21:26:02 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Apr 2024 21:26:02 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
Message-ID: <LT3WcKs7Ad4ZCVttofKzOGQwSbvaZT0CuJkweYo7jyM=.fb2f6940-90cf-45fb-87f8-5e861836a247@github.com>

On Tue, 9 Apr 2024 09:28:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - reverting unnecessary changes in TransPatterns
>   - moving the patters/withers/Model test to a more appropriate place

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-2002193598

From vromero at openjdk.org  Tue Apr 16 13:48:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 13:48:41 GMT
Subject: RFR: 8329595: spurious variable "might not have been initialized"
 on static final field
In-Reply-To: <sH-ZiQYOeLi7YOl8Wd7IIi8arNrLgyPHUUImi3GKbIs=.0978e242-0f44-4abd-b2e4-0dfe7209d508@github.com>
References: <sH-ZiQYOeLi7YOl8Wd7IIi8arNrLgyPHUUImi3GKbIs=.0978e242-0f44-4abd-b2e4-0dfe7209d508@github.com>
Message-ID: <lpy2ftJRn5RA2e4_T51qIn4eTnqOsYmEQ1hh5153GVU=.1d79f5ee-29ff-441f-bfa9-2cae9ee53ed2@github.com>

On Wed, 3 Apr 2024 23:24:21 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This bug causes the compiler to generate a bogus error `variable NAME might not have been initialized` for the following program:
> 
> public class StaticFinalNestedClass {
>     public class Inner {
>         public static final String NAME;
>         static {
>             try {
>                 NAME = "bob";
>             } catch (Exception e) {
>                 throw new Error(e);
>             }
>         }
>     }
> }
> 
> An interesting fact is that if you make the class `Inner` a `static` inner class, then the bug disappears. The oddness of that fact is indicative of the oddness of the underlying problem, some of which I probably contributed to and which I'll try to summarize...
> 
> First some background. The various flow analyzers are written to recurse through the entire AST including nested classes in one go. So for example if there is an inner class, the analysis of the outer class is paused while the inner class is analyzed, and then the former state is restored and the outer class analysis proceeds. This causes a bit of chaos in situations where the analyzer needs to "jump around" for whatever reason. For example, when `super()` is encountered while analyzing a constructor, we need to analyze any field initializers because that's when they execute.
> 
> As a result, there are several cases where the same code gets visited more than once, which is not harmful but is obviously inefficient. But it also leads to this bug.
> 
> So what is the actual bug? The bug is that (one of the times) the inner class static initializer was being checked for uninitialized variables was when the outer class constructor was being analyzed, and that analysis recursed into the inner class. Because the outer class constructor was being analyzed, and no other method had been entered yet, the `isConstructor` flag was still set to `true`, so the code that marks all fields as initialized when an exception is thrown from a constructor or static initializer (because the instance or class is unusable so don't bother complaining about uninitialized fields) was only marking the instance fields.
> 
> In commit 12e983a72e72 I did some refactoring to create a method `forEachInitializer()` for analyzing initializers, but the existing behavior of recursing into nested classes was preserved in order to not break things. With this commit, in order to impose some order, `forEachInitializer()` is being changed to not recurse into nested classes. Instead, the various bits of code that use `forEachInitializer()` and also need t...

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18610#pullrequestreview-2003706191

From vromero at openjdk.org  Tue Apr 16 18:05:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:05:06 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
Message-ID: <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>

On Tue, 9 Apr 2024 15:36:27 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
>> 
>> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
>> 
>> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
>> 
>> The changes are summarized here:
>> 
>> #### 1. Generalize how we categorize references
>> 
>> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
>> 
>> Previously the `Ref` categories were:
>> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
>> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
>> * `VarRef` - A local variable or method parameter currently in scope
>> * `ExprRef` - An object reference sitting on top of the Java execution stack
>> * `YieldRef` - The current switch expression's yield value(s)
>> * `ReturnRef` - The current method's return value(s)
>> 
>> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
>> 
>> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
>> 
>> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
>> 
>> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
>> 
>> #### 2. Track the types...
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Merge branch 'master' into JDK-8317376
>  - Javadoc++
>  - Merge branch 'master' into JDK-8317376
>  - Several improvements to the 'this' escape analyzer.
>    
>    - Track direct, indirect, and outer references for all Ref types.
>    - Keep type information about all references to improve tracking precision.
>    - Track enhanced for() invocations of iterator(), hasNext(), and next().
>    - Don't report an escape of a non-public outer instances as a leak.
>    - Fix omitted tracking of references from newly instantiated instances.
>    - Fix omitted tracking of leaks via lambda return values.
>    - Remove unneccesary suppressions of this-escape lint warning.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1343:

> 1341:      *    but also NOT an enclosing outer class of 'currentClass'.
> 1342:      */
> 1343:     private boolean isExplicitThisReference(Types types, Type.ClassType currentClass, JCFieldAccess select) {

suggestion: why not moving this method to TreeInfo already in preparation for the changes coming with flexible constructor bodies?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16208#discussion_r1567757547

From vromero at openjdk.org  Tue Apr 16 18:17:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Apr 2024 18:17:42 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <8gjzk6jIhtLXgFgNO4udYRJaCCZkto2IE9ETZYZeSig=.04b09b83-0299-440f-bffa-b6da681fb462@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2004323374

From acobbs at openjdk.org  Tue Apr 16 19:15:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Apr 2024 19:15:14 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v5]
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

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

  Synchronize TreeInfo.isExplicitThisReference() with PR #18088.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16208/files
  - new: https://git.openjdk.org/jdk/pull/16208/files/e09e4229..304a92b6

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

  Stats: 57 lines in 2 files changed: 35 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16208/head:pull/16208

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

From acobbs at openjdk.org  Tue Apr 16 19:15:18 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 16 Apr 2024 19:15:18 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v4]
In-Reply-To: <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <qtjsShzhgQEKyiwIbZ4ihv1xT7wIwZsWJ6bpqsVbjwg=.305c91fe-5b83-426c-ac82-ca6c34a8cb61@github.com>
 <5H9FriMwHXEi75SibY_zoPVu8LcLFmLgVrHKGL58Vh0=.cc3bbbc7-669b-471c-b4d2-ac54cf6df44c@github.com>
Message-ID: <2Uim0unYk6q6KQnNsOM68Ki8vWom0I4nnIcxGonJP9U=.69837268-3b52-45fc-a6f9-71086608142a@github.com>

On Tue, 16 Apr 2024 18:00:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Merge branch 'master' into JDK-8317376
>>  - Javadoc++
>>  - Merge branch 'master' into JDK-8317376
>>  - Several improvements to the 'this' escape analyzer.
>>    
>>    - Track direct, indirect, and outer references for all Ref types.
>>    - Keep type information about all references to improve tracking precision.
>>    - Track enhanced for() invocations of iterator(), hasNext(), and next().
>>    - Don't report an escape of a non-public outer instances as a leak.
>>    - Fix omitted tracking of references from newly instantiated instances.
>>    - Fix omitted tracking of leaks via lambda return values.
>>    - Remove unneccesary suppressions of this-escape lint warning.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java line 1343:
> 
>> 1341:      *    but also NOT an enclosing outer class of 'currentClass'.
>> 1342:      */
>> 1343:     private boolean isExplicitThisReference(Types types, Type.ClassType currentClass, JCFieldAccess select) {
> 
> suggestion: why not moving this method to TreeInfo already in preparation for the changes coming with flexible constructor bodies?

Good idea - thanks. Done in 304a92b619e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16208#discussion_r1567832080

From jjg at openjdk.org  Tue Apr 16 20:59:23 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Apr 2024 20:59:23 GMT
Subject: RFR: 8330179: Clean up non-standard use of /** comments in
 `jdk.compiler`
Message-ID: <NVwoWKF1kQllSwNEf689da2MP_0l4J6G2Q6SetJAldY=.d4c4075a-cd3f-4cf2-be67-722228a655ec@github.com>

Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new `javac` lint warning to detect documentation comments in unusual places.

The majority of the warnings are caused by "box comments" beginning with `/*****`. To minimize change and to address these, the second `*` is replaced by a space. An alternative solution might be to change the overall style of the box comment to use something like `/*---------`

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

Commit messages:
 - JDK-8330179: Clean up non-standard use of /** comments in `jdk.compiler`

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

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

From darcy at openjdk.org  Tue Apr 16 21:07:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Apr 2024 21:07:59 GMT
Subject: RFR: 8330179: Clean up non-standard use of /** comments in
 `jdk.compiler`
In-Reply-To: <NVwoWKF1kQllSwNEf689da2MP_0l4J6G2Q6SetJAldY=.d4c4075a-cd3f-4cf2-be67-722228a655ec@github.com>
References: <NVwoWKF1kQllSwNEf689da2MP_0l4J6G2Q6SetJAldY=.d4c4075a-cd3f-4cf2-be67-722228a655ec@github.com>
Message-ID: <J9TNF38xkj-3girEQwttfSAbE6hB7G7oKovOKFsRRvs=.2247b81c-3a96-463d-88a4-d1dc5ea7c41f@github.com>

On Fri, 12 Apr 2024 21:45:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new `javac` lint warning to detect documentation comments in unusual places.
> 
> The majority of the warnings are caused by "box comments" beginning with `/*****`. To minimize change and to address these, the second `*` is replaced by a space. An alternative solution might be to change the overall style of the box comment to use something like `/*---------`

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18767#pullrequestreview-2004597666

From liach at openjdk.org  Tue Apr 16 21:24:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Apr 2024 21:24:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>

On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Get JDK 24 underway.

src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:

> 1479:     int JAVA_23_VERSION = 67;
> 1480: 
> 1481:     /** 68 */

We need `@since 24` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1567955182

From darcy at openjdk.org  Tue Apr 16 23:43:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Apr 2024 23:43:11 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <tm66JUGL5KBrBx15RsW4qc2x5TebCJhytH-ALQMtc8U=.6f7fde4e-323c-480c-89bc-9c4eeffc69cb@github.com>

On Tue, 16 Apr 2024 23:34:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

The intention of this PR is to should approximate code diffs that would be needed to add support for new language features in the javax.lang.model visitors. Since the escaped code may be difficult to read, I'll cut and paste the generated javadoc output below:

API Note:
    Expected visitor evolution Link icon
    As the Java programming language evolves, the visitor interfaces of the language model also evolve as do the concrete visitors in this package. A preview language feature in JDK N may have API elements added in the set of visitors for the preview language level.

    The remainder of this note will show two examples of the API changes in the model and visitors that can be added to support a language feature. The examples will uses additions to the elements portion of the language model, but the updates to visitors for types or annotation values would be analogous. Two distinct cases are:

        the preview language construct has a corresponding new modeling interface
        the preview language construct only triggers the introduction of a new kind without a new modeling interface. 

    Adding visitor support for a top-level language construct Link icon
    Consider a new language feature, preview feature 1, in JDK N. This feature has a top-level element interface to model it:


     package javax.lang.model.element;
     /**
      * Represents a preview feature 1.
      *
      * @since N
      */
      public interface PreviewFeature1Element extends Element {
      // Methods to retrieve information specific to the preview feature...
      }
     


    A new element kind would also be introduce to model such a feature:


      //  Sample diff of ElementKind.java
      +    /**
      +     * A preview feature 1.
      +     * @since N
      +     */
      +     PREVIEW_FEATURE_1,
     

    A default method is added to ElementVisitor to accommodate the new construct:

     //  Sample diff for ElementVisitor.java
      +    /**
      +     * Visits a preview feature 1.
      +     *
      +     * @implSpec The default implementation visits a {@code
      +     * PreviewFeature1Element} by calling {@code visitUnknown(e, p)}.
      +     *
      +     * @param e  the element to visit
      +     * @param p  a visitor-specified parameter
      +     * @return a visitor-specified result
      +     * @since N
      +     */
      +    default R visitPreviewFeature1(PreviewFeature1Element e, P p) {
      +        return visitUnknown(e, p);
      +    }

     

    Given the default method on the visitor interface, the preview visitor classes need to override this method and take an appropriate action for the visitor's semantics:


     //  Sample diff for AbstractElementVisitorPreview.java
     //  Re-abstract visitPreviewFeature1.
      +    /**
      +     * {@inheritDoc ElementVisitor}
      +     *
      +     * @implSpec Visits a {@code PreviewFeature1Element} in a manner
      +     * defined by a subclass.
      +     *
      +     * @param e {@inheritDoc ElementVisitor}
      +     * @param p {@inheritDoc ElementVisitor}
      +     * @return a visitor-specified result
      +     * @since N
      +     */
      +    @Override
      +    public abstract R visitPreviewFeature1(PreviewFeature1Element e, P p);

     //  Sample diff for ElementKindVisitorPreview.java
     //  Take the default action for a preview feature 1.
      +
      +    /**
      +     * {@inheritDoc ElementVisitor}
      +     *
      +     * @implSpec This implementation calls {@code defaultAction}.
      +     *
      +     * @param e {@inheritDoc ElementVisitor}
      +     * @param p {@inheritDoc ElementVisitor}
      +     * @return  the result of {@code defaultAction}
      +     * @since N
      +     */
      +    @Override
      +    public R visitPreviewFeature1(PreviewFeature1Element e, P p) {
      +        return defaultAction(e, p);
      +    }

     //  Sample diff for ElementScannerPreview.java
     //  Scan the enclosed elements of a preview feature 1.
      +
      +    /**
      +     * {@inheritDoc ElementVisitor}
      +     *
      +     * @implSpec This implementation scans the enclosed elements.
      +     *
      +     * @param e {@inheritDoc ElementVisitor}
      +     * @param p {@inheritDoc ElementVisitor}
      +     * @return  {@inheritDoc ElementScanner6}
      +     * @since N
      +     */
      +    @Override
      +    public R visitPreviewFeature1(PreviewFeature1Element e, P p) {
      +        return scan(e.getEnclosedElements(), p);
      +    }

     //  Sample diff for SimpleElementVisitorPreview.java
     //  Take the default action for a preview feature 1.
      +    /**
      +     * {@inheritDoc ElementVisitor}
      +     *
      +     * @implSpec Visits a {@code PreviewFeature1Element} by calling
      +     * defaultAction.
      +     *
      +     * @param e {@inheritDoc ElementVisitor}
      +     * @param p {@inheritDoc ElementVisitor}
      +     * @return  {@inheritDoc ElementVisitor}
      +     * @since N
      +     */
      +    @Override
      +    public R visitPreviewFeature1(PreviewFeature1Element e, P p) {
      +        return defaultAction(e, p);
      +    }

     

    When preview feature 1 exits preview in JDK (N+k), a set of visitors for language level (N+k) would be added with the methods operating over the feature pulled in from the preview visitors. Each preview visitor would then have its direct superclass changed to the new corresponding (N+k) visitor.
    Adding visitor support for a language construct that is a new kind of an existing construct Link icon
    Consider a new language feature, preview feature 2, in JDK N. This feature has a new element kind without a new top-level element interface needed to model it. Concretely, assume a preview feature 2 is a new kind of variable; the changes would be analogous if the feature were a new kind of executable instead or new kind of another existing top-level construct. In that case, the API changes are more limited:


      //  Sample diff for ElementKind.java
      +    /**
      +     * A preview feature 2.
      +     * @since N
      +     */
      +     PREVIEW_FEATURE_2,
      ...
      // Update existing methods as needed
           public boolean isVariable() {
               return switch(this) {
               case ENUM_CONSTANT, FIELD, PARAMETER,
                    LOCAL_VARIABLE, EXCEPTION_PARAMETER, RESOURCE_VARIABLE,
      -             BINDING_VARIABLE -> true;
      +            BINDING_VARIABLE, PREVIEW_FEATURE_2 -> true;
               default -> false;
               };
           }

     

    The kind visitors need support for the new variety of element:


     // Update visitVariable in ElementKindVisitor6:
            ...
            * @implSpec This implementation dispatches to the visit method for
            * the specific {@linkplain ElementKind kind} of variable, {@code
            * ENUM_CONSTANT}, {@code EXCEPTION_PARAMETER}, {@code FIELD},
      -     * {@code LOCAL_VARIABLE}, {@code PARAMETER}, or {@code RESOURCE_VARIABLE}.
      +     * {@code LOCAL_VARIABLE}, {@code PARAMETER}, or {@code RESOURCE_VARIABLE},
      +     * or {@code PREVIEW_FEATURE_2}.
            *
            * @param e {@inheritDoc ElementVisitor}
            * @param p {@inheritDoc ElementVisitor}
            * @return  the result of the kind-specific visit method
            */
            @Override
            public R visitVariable(VariableElement e, P p) {
            ...
               case BINDING_VARIABLE:
                   return visitVariableAsBindingVariable(e, p);
       
      +        case PREVIEW_FEATURE_2:
      +            return visitVariableAsPreviewFeature2(e, p);
      +
               default:
                   throw new AssertionError("Bad kind " + k + " for VariableElement" + e);
            ...
      +    /**
      +     * Visits a {@code PREVIEW_FEATURE_2} variable element.
      +     *
      +     * @implSpec This implementation calls {@code visitUnknown}.
      +     *
      +     * @param e the element to visit
      +     * @param p a visitor-specified parameter
      +     * @return  the result of {@code visitUnknown}
      +     *
      +     * @since N
      +     */
      +    public R visitVariableAsPreviewFeature2(VariableElement e, P p) {
      +        return visitUnknown(e, p);
      +    }

     

    The preview element kind visitor in turn overrides visitVariableAsPreviewFeature2:


     // Sample diff for ElementKindVisitorPreview:
      +    /**
      +     * {@inheritDoc ElementKindVisitor6}
      +     *
      +     * @implSpec This implementation calls {@code defaultAction}.
      +     *
      +     * @param e {@inheritDoc ElementKindVisitor6}
      +     * @param p {@inheritDoc ElementKindVisitor6}
      +     * @return  the result of {@code defaultAction}
      +     *
      +     * @since N
      +     */
      +    public R visitVariableAsPreviewFeature2(VariableElement e, P p) {
      +        return defaultAction(e, p);
      +    }

     

    As in the case where a new interface is introduced, when preview feature 2 exits preview in JDK (N+k), a set of visitors for language level (N+k) would be added with the methods operating over the new feature in the kind visitors pulled in from the preview visitors. Each preview visitor would then have its direct superclass changed to the new corresponding (N+k) visitor.

I didn't use javadoc snippets because for the purposes of this PR it is important to present javadoc comments to the reader. Likewise, I only use a pre HTML tag and not pre and code allow the HTML escapes to be used to represent "/" and "@".

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2060074382
PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2060075682

From darcy at openjdk.org  Tue Apr 16 23:43:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Apr 2024 23:43:11 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
Message-ID: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>

Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

Commit messages:
 - Fix whitespace.
 - JDK-8329644: Discuss expected visitor evolution patterns in javax.lang.model.util

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

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

From darcy at openjdk.org  Tue Apr 16 23:49:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 Apr 2024 23:49:59 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <oR5RsolumsTSWjOb3KMU5QSv9ryKwphiKPvSlZSNHB4=.410addfb-92e0-4ed3-ab92-9cb1907248d1@github.com>

On Tue, 16 Apr 2024 23:34:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

The code diffs were extracted from change temporary made in a repo to add support for a preview feature 1 and preview feature 2.

The two paths of adding API support are consistent with past practice when API support was added for previous language features; see issues linked to in JDK-8329644 for prior examples.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2060081069

From darcy at openjdk.org  Wed Apr 17 05:27:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 05:27:59 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24
In-Reply-To: <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <j-pc_fiMLIMlwoQZKmhkJ1ie7FEmlyhkFwJqJ-ZY3ec=.e279fc9e-895a-4b17-85c8-f79635539145@github.com>
Message-ID: <fWBlbS1URCHC3BnuvEYl2Z3OXrbnkEFeGtQgUEW5MuQ=.6037d137-015a-46de-b1ef-4fb44c9d95f5@github.com>

On Tue, 16 Apr 2024 21:21:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
> 
>> 1479:     int JAVA_23_VERSION = 67;
>> 1480: 
>> 1481:     /** 68 */
> 
> We need `@since 24` here.

Ah, good catch; looks like I was treating that as an internal API element when it is indeed a public API element. I've filed JDK-8330458 to fix-up the Java 23 constant as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1568231344

From darcy at openjdk.org  Wed Apr 17 05:43:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 05:43:12 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>

> Get JDK 24 underway.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/dcec9e96..dc488f21

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

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

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

From asotona at openjdk.org  Wed Apr 17 09:23:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 Apr 2024 09:23:42 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <nOjs6B6AtCkTvGxO2FN_89dFz4vA9d5Od9_gzq0X7p4=.d903e6fa-1774-4ff0-b676-86ac53df3449@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

ClassFile changes are OK.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2005504192

From prappo at openjdk.org  Wed Apr 17 11:16:01 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Apr 2024 11:16:01 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>

On Tue, 16 Apr 2024 23:34:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

I have a few inline comments and a dumb question. The question: what happens if a preview feature exits the preview stage without being promoted to the standard, i.e. the preview feature is dropped?

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 50:

> 48:  * <p>The remainder of this note will show two examples of the API
> 49:  * changes in the model and visitors that can be added to support a
> 50:  * language feature. The examples will uses additions to the

Suggestion:

 * language feature. The examples will use additions to the

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 82:

> 80:  *  }
> 81:  * </pre>
> 82:  * A new element kind would also be introduce to model such a feature:

Suggestion:

 * A new element kind would also be introduced to model such a feature:

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 114:

> 112:  * Given the {@code default} method on the visitor interface, the
> 113:  * preview visitor classes need to override this method and take an
> 114:  * appropriate action for the visitor's semantics:

Suggestion:

 * action appropriate for the visitor's semantics:

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 192:

> 190:  * methods operating over the feature pulled in from the preview
> 191:  * visitors. Each preview visitor would then have its direct
> 192:  * superclass changed to the new corresponding (<i>N+k</i>) visitor.

"Added with" sounds weird, consider rephrasing:

Suggestion:

 * When preview feature 1 exits preview in JDK (<i>N+k</i>), the
 * methods operating over the feature pulled in from the preview
 * visitors, would be added to a set of visitors for language level
 * (<i>N+k</i>). Each preview visitor would then have its direct
 * superclass changed to the new corresponding (<i>N+k</i>) visitor.

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 291:

> 289:  * As in the case where a new interface is introduced, when preview
> 290:  * feature 2 exits preview in JDK (<i>N+k</i>), a set of visitors for
> 291:  * language level (<i>N+k</i>) would be added with the methods

Ditto for "added with".

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

PR Review: https://git.openjdk.org/jdk/pull/18804#pullrequestreview-2005553569
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1568547989
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1568557360
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1568564158
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1568607957
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1568619649

From mcimadamore at openjdk.org  Wed Apr 17 12:59:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Apr 2024 12:59:44 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v10]
In-Reply-To: <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <BanePBXbAaK5DrtX6c0iCdCWumc5HJCOVhkBxyzS_IE=.b2e41346-cc71-41c7-9e4a-53ab927cecd7@github.com>
Message-ID: <5bFbFOp51jPYrMgvk5AfQ4Zh7YMn5dU8pURyaL_MfFc=.13663ea3-1300-4d6b-b52c-78e140b71bca@github.com>

On Tue, 9 Apr 2024 09:28:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>> 
>> The current CSR is here:
>> https://bugs.openjdk.org/browse/JDK-8328637
>> 
>> The patch is mostly straightforward, with two notable changes:
>>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - reverting unnecessary changes in TransPatterns
>   - moving the patters/withers/Model test to a more appropriate place

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18509#pullrequestreview-2005974556

From abimpoudis at openjdk.org  Wed Apr 17 13:18:09 2024
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 17 Apr 2024 13:18:09 GMT
Subject: RFR: 8330387: Crash with a different types patterns (primitive vs
 generic) in instanceof
Message-ID: <fFdzCScagDLUPcXaPB27nmPe7dwCF5DbQh4Q7PiU950=.a94c0e50-4c2a-4732-bbfd-e41fd11d962e@github.com>

Prior to this PR those three tests were accepted correctly (and still do). However the conversion after unboxing was unconditionally exact so no further test was generated. The first two cover a widening reference conversion followed by unboxing and the third a widening reference conversion followed by unboxing followed by a widening primitive primitive conversion (which was unconditionally exact, notice `int` to `double`). 


    public static <T extends Integer> boolean wideningReferenceConversionUnboxing(T i) {
        return i instanceof int ii;
    }

    public static <T extends Byte> boolean wideningReferenceConversionUnboxing2(T i) {
        return i instanceof byte bb;
    }

    public static <T extends Integer> boolean wideningReferenceConversionUnboxingAndWideningPrimitive(T i) {
        return i instanceof double ii;
    }


What was missing was a widening reference conversion followed by unboxing followed by widening primitive conversion that was not unconditionally exact. `int` to `float` is a widening primitive conversion that is possibly not exact.


    public static <T extends Integer> boolean wideningReferenceConversionUnboxing3(T i) {
        return i instanceof float ff;
    }


That reveals that the type of the synthetic variable prior to binding needed to be erased to a type. After Lowering:


    public static boolean wideningReferenceConversionUnboxing(Integer i) {
        return (let int ii in (let /*synthetic*/ final Integer tmp4646$ = i in tmp4646$ != null) && (let ii = (int)i.intValue(); in true));
    }
    
    public static boolean wideningReferenceConversionUnboxing2(Byte i) {
        return (let byte bb in (let /*synthetic*/ final Byte tmp4776$ = i in tmp4776$ != null) && (let bb = (byte)i.byteValue(); in true));
    }
    
    public static boolean wideningReferenceConversionUnboxing3(Integer i) {
        return (let float ff in (let /*synthetic*/ final Integer tmp4910$ = i in tmp4910$ != null && java.lang.runtime.ExactConversionsSupport.isIntToFloatExact(tmp4910$.intValue())) && (let ff = (float)i.intValue(); in true));
    }
    
    public static boolean wideningReferenceConversionUnboxingAndWideningPrimitive(Integer i) {
        return (let double ii in (let /*synthetic*/ final Integer tmp5064$ = i in tmp5064$ != null) && (let ii = (double)i.intValue(); in true));
    }

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

Commit messages:
 - 8330387: Crash with a different types patterns (primitive vs generic) in instanceof

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

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

From mcimadamore at openjdk.org  Wed Apr 17 14:13:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Apr 2024 14:13:04 GMT
Subject: Integrated: 8329948: Remove string template feature
In-Reply-To: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
References: <GkUE93QCxSoFbu4d8-jAG80zYHg3Gj5e5RQfIkWplE4=.c5e95b3a-a72a-45af-adb8-aa6a4532cf22@github.com>
Message-ID: <rmBDb3IR8plIXZHBlJcUKN5WpnXKYbaPBH3NsnpW9I8=.da4f79cf-7ce8-4a25-9872-1faa0bd86e35@github.com>

On Tue, 9 Apr 2024 11:34:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR removes support for the string template feature from the Java compiler and the Java SE API, as discussed here:
> 
> https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html

This pull request has now been integrated.

Changeset: 03e84178
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03e84178ebfd2ca48b89d65d8f3c291e0c622fb5
Stats:     7400 lines in 66 files changed: 122 ins; 7217 del; 61 mod

8329948: Remove string template feature

Reviewed-by: jlahoda

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

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

From jlahoda at openjdk.org  Wed Apr 17 14:18:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 14:18:00 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
Message-ID: <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>

On Wed, 17 Apr 2024 11:13:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I have a few inline comments and a dumb question. The question: what happens if a preview feature exits the preview stage without being promoted to the standard, i.e. the preview feature is dropped?

When the preview feature is dropped, I would assume the API elements related to it would be removed. The `Preview` help with that, as they stay, only the methods are removed. At least, this is what I would expect.

Overall, looks reasonable to me. I wonder if the text should say the newly-added API entry points should be marked as preview? I assume it may be difficult to talk explicitly about `@jdk.internal.javac.PreviewFeature` here, but maybe a general note that it should be ensured the entry points are recognized as preview? Or did I miss that? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2061367197

From acobbs at openjdk.org  Wed Apr 17 14:35:04 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Apr 2024 14:35:04 GMT
Subject: Integrated: 8329595: spurious  variable
 "might not have been initialized" on static final field
In-Reply-To: <sH-ZiQYOeLi7YOl8Wd7IIi8arNrLgyPHUUImi3GKbIs=.0978e242-0f44-4abd-b2e4-0dfe7209d508@github.com>
References: <sH-ZiQYOeLi7YOl8Wd7IIi8arNrLgyPHUUImi3GKbIs=.0978e242-0f44-4abd-b2e4-0dfe7209d508@github.com>
Message-ID: <69-HM-kazp9ZVacUWInU17hVRcudSAmC_ahcZimf64k=.c3d32c7e-2a8f-4d9d-87c7-0425a128f38e@github.com>

On Wed, 3 Apr 2024 23:24:21 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This bug causes the compiler to generate a bogus error `variable NAME might not have been initialized` for the following program:
> 
> public class StaticFinalNestedClass {
>     public class Inner {
>         public static final String NAME;
>         static {
>             try {
>                 NAME = "bob";
>             } catch (Exception e) {
>                 throw new Error(e);
>             }
>         }
>     }
> }
> 
> An interesting fact is that if you make the class `Inner` a `static` inner class, then the bug disappears. The oddness of that fact is indicative of the oddness of the underlying problem, some of which I probably contributed to and which I'll try to summarize...
> 
> First some background. The various flow analyzers are written to recurse through the entire AST including nested classes in one go. So for example if there is an inner class, the analysis of the outer class is paused while the inner class is analyzed, and then the former state is restored and the outer class analysis proceeds. This causes a bit of chaos in situations where the analyzer needs to "jump around" for whatever reason. For example, when `super()` is encountered while analyzing a constructor, we need to analyze any field initializers because that's when they execute.
> 
> As a result, there are several cases where the same code gets visited more than once, which is not harmful but is obviously inefficient. But it also leads to this bug.
> 
> So what is the actual bug? The bug is that (one of the times) the inner class static initializer was being checked for uninitialized variables was when the outer class constructor was being analyzed, and that analysis recursed into the inner class. Because the outer class constructor was being analyzed, and no other method had been entered yet, the `isConstructor` flag was still set to `true`, so the code that marks all fields as initialized when an exception is thrown from a constructor or static initializer (because the instance or class is unusable so don't bother complaining about uninitialized fields) was only marking the instance fields.
> 
> In commit 12e983a72e72 I did some refactoring to create a method `forEachInitializer()` for analyzing initializers, but the existing behavior of recursing into nested classes was preserved in order to not break things. With this commit, in order to impose some order, `forEachInitializer()` is being changed to not recurse into nested classes. Instead, the various bits of code that use `forEachInitializer()` and also need t...

This pull request has now been integrated.

Changeset: 192ec387
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/192ec387bc074b25465decf598a4dd87651cbcbb
Stats:     86 lines in 2 files changed: 71 ins; 13 del; 2 mod

8329595: spurious  variable "might not have been initialized" on static final field

Reviewed-by: vromero

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

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

From liach at openjdk.org  Wed Apr 17 14:41:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Apr 2024 14:41:59 GMT
Subject: RFR: 8325324: Implement Implicitly Declared Classes and Instance
 Main Methods (Third Preview)
In-Reply-To: <5ys3-6c31Pr82nxjqd6ARD9YhA7PkBOdvl7lm62snSA=.35e20dba-9758-44fc-8302-6bb7893b3f39@github.com>
References: <5ys3-6c31Pr82nxjqd6ARD9YhA7PkBOdvl7lm62snSA=.35e20dba-9758-44fc-8302-6bb7893b3f39@github.com>
Message-ID: <xtV9XKftNR20a_ZrAzIqTnimwpo-vEd8VsMvhSzMGKU=.9a48e1ad-e2cb-4845-8619-22c06014c50d@github.com>

On Thu, 4 Apr 2024 16:36:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an implementation of a change for JEP draft: Implicitly Declared Classes and Instance Main Methods (Third Preview)[1]. The primary change here is that implicitly declared classes have two new implicit imports:
> 
> import module java.base;
> import static java.io.SimpleIO.*;
> 
> 
> Both of these depend on other changes, the first one on https://github.com/openjdk/jdk/pull/18614, and the second one on https://bugs.openjdk.org/browse/JDK-8305457. This PR depends on 18614, and the patch here can should be able to work both in the presence and absence of `java.io.SimpleIO`, including testing. Some tweaking may still be necessary when `java.io.SimpleIO` is introduced. But, overall the patch should be fairly straightforward - the imports are injected at the same time the long-existing import for `java.lang` is added.
> 
> There is also an obvious relation to String Templates, which may need tweaking/simplification.
> 
> Additional tweak will be needed once the JEP is Candidate, to updated the proper JEP number.
> 
> [1] https://openjdk.org/jeps/8323335

This needs to update now that String Template is removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18633#issuecomment-2061421524

From jlahoda at openjdk.org  Wed Apr 17 14:45:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 14:45:13 GMT
Subject: RFR: 8328481: Implement Module Imports [v6]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Pzfi6LRqRSvUmAhqepfBUhXdEQfahOOHhadOqRvQndY=.b1f3db3d-8d9e-414e-9a13-f256072a1642@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

 - Merge branch 'master' into module-imports
 - Including current module name as suggested.
 - Adding more tests for ambiguities.
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Merge branch 'master' into module-imports
 - Fixing test.
 - Fixing disambiguation of module imports.
 - Fixing file name computation.
 - Merge branch 'master' into module-imports
 - ... and 10 more: https://git.openjdk.org/jdk/compare/03e84178...c75b8b7a

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

Changes: https://git.openjdk.org/jdk/pull/18614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18614&range=05
  Stats: 1198 lines in 29 files changed: 1130 ins; 9 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/18614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18614/head:pull/18614

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

From prappo at openjdk.org  Wed Apr 17 15:12:41 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Apr 2024 15:12:41 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
 <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>
Message-ID: <GL6Zmkwca4OmDqjLMrDiXnFP1xB9DnV-NrXivw_uNA0=.aa8316ab-2190-4811-b797-5b4c9f3b2b25@github.com>

On Wed, 17 Apr 2024 14:14:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > I have a few inline comments and a dumb question. The question: what happens if a preview feature exits the preview stage without being promoted to the standard, i.e. the preview feature is dropped?
> 
> When the preview feature is dropped, I would assume the API elements related to it would be removed. The `Preview` help with that, as they stay, only the methods are removed. At least, this is what I would expect.
> 
> Overall, looks reasonable to me. I wonder if the text should say the newly-added API entry points should be marked as preview? I assume it may be difficult to talk explicitly about `@jdk.internal.javac.PreviewFeature` here, but maybe a general note that it should be ensured the entry points are recognized as preview? Or did I miss that? Thanks.

Your latter paragraph is why I asked my question in the first place. If you reflect on an element of a preview feature Y, one could say that you indirectly use that preview feature Y, and so all the terms and conditions for preview features apply. If Y then goes away, you weren't warned/reminded that your code will no longer compile, and that's bad.

Let's wait for Joe to respond.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2061502185

From jlahoda at openjdk.org  Wed Apr 17 15:27:00 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 15:27:00 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <GL6Zmkwca4OmDqjLMrDiXnFP1xB9DnV-NrXivw_uNA0=.aa8316ab-2190-4811-b797-5b4c9f3b2b25@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
 <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>
 <GL6Zmkwca4OmDqjLMrDiXnFP1xB9DnV-NrXivw_uNA0=.aa8316ab-2190-4811-b797-5b4c9f3b2b25@github.com>
Message-ID: <gKvJdWKsUf4E7-iTJAL6x4Og1h4unJwd_73NitJHBTo=.a428267e-4486-4510-a4f9-13f3df2f33c0@github.com>

On Wed, 17 Apr 2024 15:10:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > > I have a few inline comments and a dumb question. The question: what happens if a preview feature exits the preview stage without being promoted to the standard, i.e. the preview feature is dropped?
> > 
> > 
> > When the preview feature is dropped, I would assume the API elements related to it would be removed. The `Preview` help with that, as they stay, only the methods are removed. At least, this is what I would expect.
> > Overall, looks reasonable to me. I wonder if the text should say the newly-added API entry points should be marked as preview? I assume it may be difficult to talk explicitly about `@jdk.internal.javac.PreviewFeature` here, but maybe a general note that it should be ensured the entry points are recognized as preview? Or did I miss that? Thanks.
> 
> Your latter paragraph is why I asked my question in the first place. If you reflect on an element of a preview feature Y, one could say that you indirectly use that preview feature Y, and so all the terms and conditions for preview features apply. If Y then goes away, you weren't warned/reminded that your code will no longer compile, and that's bad.

We mark the preview-related entry points of the javax.lang.model and Trees API with `@PreviewFeature(..., reflective=true)`, and this then produces warnings like:


$ javac  /tmp/TestPreview.java
/tmp/TestPreview.java:3: warning: [preview] COMPONENT_LOCAL_VARIABLE is a reflective preview API and may be removed in a future release.
        System.err.println(javax.lang.model.element.ElementKind.COMPONENT_LOCAL_VARIABLE);
                                                               ^
1 warning


I.e. the potential removal is not without a warning. (The difference between "reflective" and non-"reflective" Preview API is that the reflective API can be used without `--enable-preview`.)

> 
> Let's wait for Joe to respond.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2061533572

From vromero at openjdk.org  Wed Apr 17 15:28:03 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Apr 2024 15:28:03 GMT
Subject: RFR: 8317376: Minor improvements to the 'this' escape analyzer
 [v5]
In-Reply-To: <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
 <yZaMBdiWd8Q641dDm-qYoeY2I1_JOGZZwwjjIFRXE4A=.7db825b2-6abd-4a42-ae82-b1c6fcea12bd@github.com>
Message-ID: <bHcrbCnG4ke4q1RmIyc3ktxba8FKsqUf_H9eVKs2Pc0=.190776a8-df6c-4a1d-ac32-9359171c0114@github.com>

On Tue, 16 Apr 2024 19:15:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
>> 
>> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
>> 
>> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
>> 
>> The changes are summarized here:
>> 
>> #### 1. Generalize how we categorize references
>> 
>> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
>> 
>> Previously the `Ref` categories were:
>> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
>> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
>> * `VarRef` - A local variable or method parameter currently in scope
>> * `ExprRef` - An object reference sitting on top of the Java execution stack
>> * `YieldRef` - The current switch expression's yield value(s)
>> * `ReturnRef` - The current method's return value(s)
>> 
>> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
>> 
>> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
>> 
>> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
>> 
>> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
>> 
>> #### 2. Track the types...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Synchronize TreeInfo.isExplicitThisReference() with PR #18088.

looks sensible to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16208#pullrequestreview-2006363434

From jlahoda at openjdk.org  Wed Apr 17 15:36:01 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 15:36:01 GMT
Subject: RFR: 8328481: Implement Module Imports [v7]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <4Vd-LkZgxXvfoTGWJrlYVbIW-k1NCU3-HgCoa_y5MTU=.480aeb7e-e73e-4ab1-bdc4-4b5fb8ae9b5e@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/c75b8b7a..27f9cfb5

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

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

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

From jlahoda at openjdk.org  Wed Apr 17 15:39:33 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 15:39:33 GMT
Subject: RFR: 8325324: Implement Implicitly Declared Classes and Instance
 Main Methods (Third Preview) [v2]
In-Reply-To: <5ys3-6c31Pr82nxjqd6ARD9YhA7PkBOdvl7lm62snSA=.35e20dba-9758-44fc-8302-6bb7893b3f39@github.com>
References: <5ys3-6c31Pr82nxjqd6ARD9YhA7PkBOdvl7lm62snSA=.35e20dba-9758-44fc-8302-6bb7893b3f39@github.com>
Message-ID: <myicIlWAnUmJ0WJAsnDPHs7mxdS2lOQV5Tt6lZ85ed0=.79927e83-06d2-4927-bff2-a821de48720d@github.com>

> This is an implementation of a change for JEP draft: Implicitly Declared Classes and Instance Main Methods (Third Preview)[1]. The primary change here is that implicitly declared classes have two new implicit imports:
> 
> import module java.base;
> import static java.io.SimpleIO.*;
> 
> 
> Both of these depend on other changes, the first one on https://github.com/openjdk/jdk/pull/18614, and the second one on https://bugs.openjdk.org/browse/JDK-8305457. This PR depends on 18614, and the patch here can should be able to work both in the presence and absence of `java.io.SimpleIO`, including testing. Some tweaking may still be necessary when `java.io.SimpleIO` is introduced. But, overall the patch should be fairly straightforward - the imports are injected at the same time the long-existing import for `java.lang` is added.
> 
> There is also an obvious relation to String Templates, which may need tweaking/simplification.
> 
> Additional tweak will be needed once the JEP is Candidate, to updated the proper JEP number.
> 
> [1] https://openjdk.org/jeps/8323335

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'module-imports' into JDK-8325324
 - Merge branch 'module-imports' into JDK-8325324
 - Merge branch 'module-imports' into JDK-8325324
 - Adding test verifying that the new implicit imports are not used for ordinary classes.
 - Merge branch 'module-imports' into JDK-8325324
 - Fixing test.
 - Merge branch 'master' into JDK-8325324
 - Disabling the preview check when working with the STR.
 - Cleanup StringTemplate.STR import.
 - Implicitly importing SimpleIO.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/27f9cfb5...ca64419f

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

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

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

From prappo at openjdk.org  Wed Apr 17 15:50:00 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Apr 2024 15:50:00 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <gKvJdWKsUf4E7-iTJAL6x4Og1h4unJwd_73NitJHBTo=.a428267e-4486-4510-a4f9-13f3df2f33c0@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
 <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>
 <GL6Zmkwca4OmDqjLMrDiXnFP1xB9DnV-NrXivw_uNA0=.aa8316ab-2190-4811-b797-5b4c9f3b2b25@github.com>
 <gKvJdWKsUf4E7-iTJAL6x4Og1h4unJwd_73NitJHBTo=.a428267e-4486-4510-a4f9-13f3df2f33c0@github.com>
Message-ID: <_vw61mAJo1v_MhHbKgs-MTihIKKfAlEr7lVl4xr0svY=.7423dc64-7bf8-4af9-9e22-bae0578d69d6@github.com>

On Wed, 17 Apr 2024 15:23:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> We mark the preview-related entry points of the javax.lang.model and Trees API with `@PreviewFeature(..., reflective=true)`, and this then produces warnings like:
> 
> ```
> $ javac  /tmp/TestPreview.java
> /tmp/TestPreview.java:3: warning: [preview] COMPONENT_LOCAL_VARIABLE is a reflective preview API and may be removed in a future release.
>         System.err.println(javax.lang.model.element.ElementKind.COMPONENT_LOCAL_VARIABLE);
>                                                                ^
> 1 warning
> ```
> 
> I.e. the potential removal is not without a warning. (The difference between "reflective" and non-"reflective" Preview API is that the reflective API can be used without `--enable-preview`.)

Ah! I didn't notice that `*(Visitor|Scanner)*Preview` classes were annotated with `@PreviewFeature(feature=PreviewFeature.Feature.LANGUAGE_MODEL, reflective=true)` because the diffs _in_ the doc comment didn't contain them. Good to know this has been taken care of, thanks! But what about constants and methods this PR proposes to add to `ElementKind`, `ElementVisitor`, and the likes? How does that work?

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2061611092

From iris at openjdk.org  Wed Apr 17 16:51:43 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 17 Apr 2024 16:51:43 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <zb0rhfphJD1OpHKxYZM7uCUs18_TVM-0N0lyFxvHgj0=.5bd1fb4c-09e1-49b3-b314-dfaee73d85fc@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2006604933

From darcy at openjdk.org  Wed Apr 17 16:57:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 16:57:52 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v2]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <h56yRdq16UjqoxtobrOc50irqqgT17Pw1SnGNMDIG2c=.bd4c539f-2b3c-4753-8efd-826236360e38@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/2840d01c..7df2fa6c

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

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

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

From darcy at openjdk.org  Wed Apr 17 17:04:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 17:04:04 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v2]
In-Reply-To: <_vw61mAJo1v_MhHbKgs-MTihIKKfAlEr7lVl4xr0svY=.7423dc64-7bf8-4af9-9e22-bae0578d69d6@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
 <lJB6d6JvMkaCcDRCH7hDoa5xS6pPfvksibiisnkOt4Q=.c29e915b-744f-47ef-8151-ebeac87f8b6e@github.com>
 <GL6Zmkwca4OmDqjLMrDiXnFP1xB9DnV-NrXivw_uNA0=.aa8316ab-2190-4811-b797-5b4c9f3b2b25@github.com>
 <gKvJdWKsUf4E7-iTJAL6x4Og1h4unJwd_73NitJHBTo=.a428267e-4486-4510-a4f9-13f3df2f33c0@github.com>
 <_vw61mAJo1v_MhHbKgs-MTihIKKfAlEr7lVl4xr0svY=.7423dc64-7bf8-4af9-9e22-bae0578d69d6@github.com>
Message-ID: <osriQeSU5Wm-19UguwSIT65ohOi7NpSc1WfBu5BoerY=.b5cace4d-7f9c-4f13-b30c-a9bb12fbb3d1@github.com>

On Wed, 17 Apr 2024 15:45:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > We mark the preview-related entry points of the javax.lang.model and Trees API with `@PreviewFeature(..., reflective=true)`, and this then produces warnings like:
> > ```
> > $ javac  /tmp/TestPreview.java
> > /tmp/TestPreview.java:3: warning: [preview] COMPONENT_LOCAL_VARIABLE is a reflective preview API and may be removed in a future release.
> >         System.err.println(javax.lang.model.element.ElementKind.COMPONENT_LOCAL_VARIABLE);
> >                                                                ^
> > 1 warning
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I.e. the potential removal is not without a warning. (The difference between "reflective" and non-"reflective" Preview API is that the reflective API can be used without `--enable-preview`.)
> 
> Ah! I didn't notice that `*(Visitor|Scanner)*Preview` classes were annotated with `@PreviewFeature(feature=PreviewFeature.Feature.LANGUAGE_MODEL, reflective=true)` because the diffs _in_ the doc comment didn't contain them. Good to know this has been taken care of, thanks! But what about constants and methods this PR proposes to add to `ElementKind`, `ElementVisitor`, and the likes? How does that work?

I'll add some text in the start of this note to indicate:

Any new API elements are marked as reflective preview (without saying how this is done). And any existing methods that are updated to support the new feature are *not* marked as preview.

If the feature is eventually withdrawn instead of being added to the platform, any API elements associated with it are expected to be removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2061778213

From darcy at openjdk.org  Wed Apr 17 17:37:29 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 17:37:29 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v3]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <5Khzk8drB03xSK1GhP88fAR3O2C9aV8JgGkqBfc3mVk=.54687673-fa0a-4b91-9912-5de6cb8f022e@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Discuss withdrawing a preview feature, respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/7df2fa6c..2cb03252

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

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

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

From acobbs at openjdk.org  Wed Apr 17 17:38:02 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Apr 2024 17:38:02 GMT
Subject: Integrated: 8317376: Minor improvements to the 'this' escape analyzer
In-Reply-To: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
References: <BBO-U3RwIUINQuQ3OGLpoHlwiQ2OutqJV-d0Y6AsUlc=.2fba21cd-5967-4469-9f9e-070aa2ed990e@github.com>
Message-ID: <OCy_Jt1nyXDmhu4LCQwGMemjEozXSCkHJU42eT0Y7EA=.c631a5cb-efec-405f-9d0d-bdd169515cc9@github.com>

On Mon, 16 Oct 2023 22:08:53 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review several fixes and improvements to the `this-escape` lint warning analyzer.
> 
> The goal here is to apply some relatively simple logical fixes that improve the precision and accuracy of the analyzer, and capture the remaining low-hanging fruit so we can consider the analyzer relatively complete with respect to what's feasible with its current design.
> 
> Although the changes are small from a logical point of view, they generate a fairly large patch due to impact of refactoring (sorry!). Most of the patch derives from the first two changes listed below.
> 
> The changes are summarized here:
> 
> #### 1. Generalize how we categorize references
> 
> The `Ref` class hierarchy models the various ways in which, at any point during the execution of a constructor or some other method/constructor that it invokes, there can be live references to the original object under construction lying around. We then look for places where one of these `Ref`'s might be passed to a subclass method. In other words, the analyzer keeps track of these references and watches what happens to them as the code executes so it can catch them trying to "escape".
> 
> Previously the `Ref` categories were:
> * `ThisRef` - The current instance of the (non-static) method or constructor being analyzed
> * `OuterRef` - The current outer instance of the (non-static) method or constructor being analyzed
> * `VarRef` - A local variable or method parameter currently in scope
> * `ExprRef` - An object reference sitting on top of the Java execution stack
> * `YieldRef` - The current switch expression's yield value(s)
> * `ReturnRef` - The current method's return value(s)
> 
> For each of those types, we further classified the "indirection" of the reference, i.e., whether the reference was direct (from the thing itself) or indirect (from something the thing referenced).
> 
> The problem with that hierarchy is that we could only track outer instance references that happened to be associated with the current instance. So we might know that `this` had an outer instance reference, but if we said `var x = this` we wouldn't know that `x` had an outer instance reference.
> 
> In other words, we should be treating "via an outer instance" as just another flavor of indirection along with "direct" and "indirect".
> 
> As a result, with this patch the `OuterRef` class goes away and a new `Indirection` enum has been created, with values `DIRECT`, `INDIRECT`, and `OUTER`.
> 
> #### 2. Track the types of all references
> 
> By keeping track of the actual type of...

This pull request has now been integrated.

Changeset: 06462847
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/064628471b83616b4463baa78618d1b7a66d0c7c
Stats:     915 lines in 20 files changed: 552 ins; 171 del; 192 mod

8317376: Minor improvements to the 'this' escape analyzer

Reviewed-by: vromero

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

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

From acobbs at openjdk.org  Wed Apr 17 17:54:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Apr 2024 17:54:14 GMT
Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor
 Bodies (Second Preview) [v4]
In-Reply-To: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
References: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
Message-ID: <hpox7wWOkTfg1g5vq5wFD2ulM-QYYgn5YxBhnExNwaU=.144f78f4-e046-44fa-a999-2c012a620816@github.com>

> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context.  This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803).
> 
> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo.

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

 - Merge branch 'master' into JDK-8325805
 - Disallow assignments to fields with initializers in constructor prologues.
 - Merge branch 'master' into JDK-8325805
 - Merge branch 'master' into JDK-8325805
 - Fix cut & paste of bug ID and summary.
 - Avoid possible unwanted side effects from method Symbol.flags().
 - Add a few more test cases.
 - Fix bug where early assignments in lambda's were being allowed.
 - Add some more allowed assignment test cases.
 - Add test case for early assignment within a lambda.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/06462847...b8b12f62

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

Changes: https://git.openjdk.org/jdk/pull/18088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18088&range=03
  Stats: 413 lines in 11 files changed: 408 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18088/head:pull/18088

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

From darcy at openjdk.org  Wed Apr 17 18:49:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 18:49:18 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v4]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <9kjyIRwKYMdhvZxaPa0Fx6VnX2O9Rf6j5lISL2YaujY=.e0e9206d-189b-48b3-94e1-83e26cbc88fa@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Add missing Override annotation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/2cb03252..ccf84b3e

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

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

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

From darcy at openjdk.org  Wed Apr 17 18:52:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 18:52:25 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v5]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <h0xEFEJH-5KWLKNPhz6esz2_n0VIbVJJZlY7RWgTq9Y=.74420fbe-c69c-440f-9b7a-3205ef72ec2e@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Update copyrigth.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/ccf84b3e..4859b385

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

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

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

From jlahoda at openjdk.org  Wed Apr 17 19:33:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Apr 2024 19:33:09 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Fixing ListModuleDeps test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/27f9cfb5..7fa0ad51

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

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

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

From darcy at openjdk.org  Wed Apr 17 19:58:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 19:58:10 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v6]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Implement off-list feedback on HTML id syntax; add trial @see link.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/4859b385..2bdbdf43

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

  Stats: 8 lines in 2 files changed: 2 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18804/head:pull/18804

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

From darcy at openjdk.org  Wed Apr 17 20:01:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Apr 2024 20:01:00 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v5]
In-Reply-To: <h0xEFEJH-5KWLKNPhz6esz2_n0VIbVJJZlY7RWgTq9Y=.74420fbe-c69c-440f-9b7a-3205ef72ec2e@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <h0xEFEJH-5KWLKNPhz6esz2_n0VIbVJJZlY7RWgTq9Y=.74420fbe-c69c-440f-9b7a-3205ef72ec2e@github.com>
Message-ID: <sNPjutx2eu_30ClpD4HdyYfV79xR_ozs4Hnv9jZQcWk=.1b74ab10-1bbe-45c4-bb42-d9303b4270ca@github.com>

On Wed, 17 Apr 2024 18:52:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrigth.

I added an `@see` link in AbstractElementVisitorPreview.java to the new section. Once we agree on wording/syntax, I'll add a corresponding link in all the preview visitor classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18804#issuecomment-2062111291

From vromero at openjdk.org  Thu Apr 18 01:30:21 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Apr 2024 01:30:21 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks
Message-ID: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>

This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.

This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.

TIA

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

Commit messages:
 - 8322992: Javac fails with StackOverflowError when compiling deeply nested synchronized blocks

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

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

From alanb at openjdk.org  Thu Apr 18 05:45:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 05:45:58 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
Message-ID: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>

On Wed, 17 Apr 2024 19:33:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing ListModuleDeps test.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:

> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
> 83:         STREAM_GATHERERS,
> 84:         @JEP(number=0, title="Module Imports", status="Preview")

I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570018046

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Updating JEP number and caption.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/7fa0ad51..432393ab

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

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

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

From jlahoda at openjdk.org  Thu Apr 18 06:34:22 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 06:34:22 GMT
Subject: RFR: 8328481: Implement Module Imports [v8]
In-Reply-To: <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <Np0t8qFIiD4q8G1yP4pjWtU6MUiBLQhamWYx5tQ_Q8U=.b82c98e9-04c3-4538-b9f7-ec8e6667c76f@github.com>
 <pcHCSoByFsEMxVs87MzuoicQi21Lte2-_opzULwHUac=.a31d6439-a489-489e-8526-345da4802694@github.com>
Message-ID: <G-3sx5-oNAcuWzF5Y26QXZuX_DvmgPJRqfMV6uF7ufI=.1fc21a6a-fa90-4f9f-baab-ba800a46a9e0@github.com>

On Thu, 18 Apr 2024 05:43:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing ListModuleDeps test.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 84:
> 
>> 82:         @JEP(number=461, title="Stream Gatherers", status="Preview")
>> 83:         STREAM_GATHERERS,
>> 84:         @JEP(number=0, title="Module Imports", status="Preview")
> 
> I see this has been assigned JEP 476 so I assume you can set the number for the first integration.

Done, thanks:
https://github.com/openjdk/jdk/pull/18614/commits/432393abb4ac1f5c4730d982a3911284fe866318

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570071215

From mcimadamore at openjdk.org  Thu Apr 18 10:50:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 10:50:04 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
Message-ID: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>

On Thu, 18 Apr 2024 06:34:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating JEP number and caption.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:

> 3539: # 0: symbol, 1: symbol
> 3540: compiler.err.import.module.does.not.read=\
> 3541:     {1} module does not read: {0}

shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

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

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2008496026
PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570474076

From jlahoda at openjdk.org  Thu Apr 18 12:11:19 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:19 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Reflecting review feedback - improving the 'module (current) does not read (target).

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/432393ab..846b038e

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

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

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

From jlahoda at openjdk.org  Thu Apr 18 12:11:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 12:11:20 GMT
Subject: RFR: 8328481: Implement Module Imports [v9]
In-Reply-To: <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <XLzA3-xDeG74MOYKdNm3gIh5xZIVS3s11i2G23GUjRM=.08c6c058-f409-4c5a-ac74-fe798fd7bb4c@github.com>
 <YwbNlIidOZdYI8_O8e6NA9d1LnXEjXm8z_Db-HxWYoI=.0b38d8cf-8397-4ae1-a003-803a6354e82c@github.com>
Message-ID: <w6eHmke7hUSdWcDyIABENw8qivz2txDkTEPDgq8uycw=.b0705162-0183-4840-89c0-259347ef83f8@github.com>

On Thu, 18 Apr 2024 10:47:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating JEP number and caption.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3541:
> 
>> 3539: # 0: symbol, 1: symbol
>> 3540: compiler.err.import.module.does.not.read=\
>> 3541:     {1} module does not read: {0}
> 
> shouldn't it be `module {1} does not read: {0}` ? Also, maybe worth reordering the params?

Thanks! Fixed:
https://github.com/openjdk/jdk/pull/18614/commits/846b038ed8145ede9c419daddedb794a429dafac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1570597292

From hannesw at openjdk.org  Thu Apr 18 12:16:52 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 18 Apr 2024 12:16:52 GMT
Subject: RFR: 8294880: Review running time of
 jdk/internal/shellsupport/doc/JavadocHelperTest.java
Message-ID: <f1InD5kPf0hXmiR6kpFCKl4j2iO8QIuhT6KLDcS1YmU=.d5f19994-7281-42d0-81f8-caec7454d851@github.com>

Please review a change to move a long-running shellsupport test from langtools tier1 to tier2, while modifying the tier1 test to only retrieve doc comments for members of `java.lang.StringBuilder`, which is where [the original bug](https://bugs.openjdk.org/browse/JDK-8189778) occurred.  This reduces the running time in the tier1 test from around 90 seconds to 2 seconds on my computer. The tier1 test also adds a non-null check for retrieved doc comments.

I used the existing `langtools_jshell_unstable` test group to add the new test in langtools tier2, which is not a perfect match for the test, but close enough and helps to keep langtools `TEST.groups` file simple.

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

Commit messages:
 - JDK-8294880: Review running time of jdk/internal/shellsupport/doc/JavadocHelperTest.java

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

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

From vromero at openjdk.org  Thu Apr 18 14:44:19 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Apr 2024 14:44:19 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v2]
In-Reply-To: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
Message-ID: <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>

> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
> 
> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
> 
> TIA

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

  adding regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18832/files
  - new: https://git.openjdk.org/jdk/pull/18832/files/739cf493..24c7e37c

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

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

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

From jlahoda at openjdk.org  Thu Apr 18 15:15:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Apr 2024 15:15:57 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v6]
In-Reply-To: <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>
Message-ID: <A64_OgDU_sHYW6pPh35We6p6tvx_Fv_GXyWz2i6TcBw=.be4113a4-e1da-4ccd-b62c-21e292ff3cdd@github.com>

On Wed, 17 Apr 2024 19:58:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement off-list feedback on HTML id syntax; add trial @see link.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18804#pullrequestreview-2009195870

From vromero at openjdk.org  Thu Apr 18 16:57:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Apr 2024 16:57:06 GMT
Subject: RFR: 8328481: Implement Module Imports [v10]
In-Reply-To: <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <ZSHhn9CLboAAWl4enJqdLNH7ZUGyGHm48eMdI8oZWaE=.6b11ee55-2ac1-4a3c-816d-6fde35724386@github.com>
Message-ID: <EyeV6PzOrKSObimFKpPpHvzFyg14LXpQAnguXscbuNQ=.38261d09-3c7d-4652-a4e7-c83a758ce8a3@github.com>

On Thu, 18 Apr 2024 12:11:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback - improving the 'module (current) does not read (target).

src/jdk.compiler/share/classes/com/sun/source/tree/ImportTree.java line 57:

> 55:      */
> 56:     @PreviewFeature(feature=PreviewFeature.Feature.MODULE_IMPORTS, reflective=true)
> 57:     boolean isModule();

we are not including any test that stresses this new method

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18614#discussion_r1571091780

From duke at openjdk.org  Thu Apr 18 18:38:58 2024
From: duke at openjdk.org (sciwhiz12)
Date: Thu, 18 Apr 2024 18:38:58 GMT
Subject: RFR: 8305007: Within-lambda subclass of local class using method
 param causes compiler crash
In-Reply-To: <XmbtXmlFtgU5pAJhOWJdcJjkUc4NopHvuAHSLeBivX8=.0829ca7d-9ed8-41dc-8582-82e424d17db0@github.com>
References: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>
 <XmbtXmlFtgU5pAJhOWJdcJjkUc4NopHvuAHSLeBivX8=.0829ca7d-9ed8-41dc-8582-82e424d17db0@github.com>
Message-ID: <XYTo-GUJMNUJ-dmHjvXIhTGN6-7deQCfjE1Rnly9ZM4=.47f759b0-7e24-405e-9bb2-adf05ec5e595@github.com>

On Sat, 23 Dec 2023 00:15:42 GMT, ExE Boss <duke at openjdk.org> wrote:

>> javac is crashing while compiling code like:
>> 
>> 
>> public abstract class CompilerCrashLambdaPlusLocalClass {
>>     public abstract void consume(Runnable r);
>> 
>>     public void doThing(String parameter) {
>>         class LocalClass {
>>             @Override
>>             public String toString() {
>>                 return parameter;
>>             }
>>         }
>>         consume(() -> {
>>             class LambdaLocalClass extends LocalClass {}
>>             new LocalClass();
>>         });
>>     }
>> }
>> 
>> the reason for the issue is that the mappings for captured variables created by LambdaToMethod are not copying the `adr`, local address, field of the original VarSymbol it is mapping. Later on during code generation an assertion was being triggered due to a variable with an `adr < 0` this patch fixes this issue.
>> 
>> Thanks,
>> Vicente
>
> test/langtools/tools/javac/lambda/CompilerCrashLambdaPlusLocalClass.java line 43:
> 
>> 41:         consume(() -> {
>> 42:             class LambdaLocalClass extends LocalClass {}
>> 43:             new LocalClass();
> 
> Shouldn?t this construct a?`LambdaLocalClass` instance instead?
> Suggestion:
> 
>             new LambdaLocalClass();

Constructing an instance of either `LocalClass` or `LambdaLocalClass` class triggers the issue, as described in the original issue report. (I was the one who wrote the issue report.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17151#discussion_r1435792707

From duke at openjdk.org  Thu Apr 18 18:38:58 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 18 Apr 2024 18:38:58 GMT
Subject: RFR: 8305007: Within-lambda subclass of local class using method
 param causes compiler crash
In-Reply-To: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>
References: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>
Message-ID: <XmbtXmlFtgU5pAJhOWJdcJjkUc4NopHvuAHSLeBivX8=.0829ca7d-9ed8-41dc-8582-82e424d17db0@github.com>

On Mon, 18 Dec 2023 23:38:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is crashing while compiling code like:
> 
> 
> public abstract class CompilerCrashLambdaPlusLocalClass {
>     public abstract void consume(Runnable r);
> 
>     public void doThing(String parameter) {
>         class LocalClass {
>             @Override
>             public String toString() {
>                 return parameter;
>             }
>         }
>         consume(() -> {
>             class LambdaLocalClass extends LocalClass {}
>             new LocalClass();
>         });
>     }
> }
> 
> the reason for the issue is that the mappings for captured variables created by LambdaToMethod are not copying the `adr`, local address, field of the original VarSymbol it is mapping. Later on during code generation an assertion was being triggered due to a variable with an `adr < 0` this patch fixes this issue.
> 
> Thanks,
> Vicente

test/langtools/tools/javac/lambda/CompilerCrashLambdaPlusLocalClass.java line 43:

> 41:         consume(() -> {
> 42:             class LambdaLocalClass extends LocalClass {}
> 43:             new LocalClass();

Shouldn?t this construct a?`LambdaLocalClass` instance instead?
Suggestion:

            new LambdaLocalClass();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17151#discussion_r1435405123

From jjg at openjdk.org  Thu Apr 18 20:52:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:52:29 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v4]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <p1Ldsyr_hNrd7LEhoThBxZzXEtMZk3siO_ZLFZp43vY=.c61e1870-2db1-4ee8-b157-f6f2b0be1715@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 five additional commits since the last revision:

 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3f745431..f3670e7a

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

  Stats: 42074 lines in 1058 files changed: 18282 ins; 15937 del; 7855 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 18 21:34:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:34:13 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v5]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <Pw-vAt9fBf-s7YcdBbtzbYdcM49PkNcmvIfbSmYdjYI=.a94e6477-30de-463b-b509-d4cd38f26cd7@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/f3670e7a..8ad8b818

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

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

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

From jjg at openjdk.org  Thu Apr 18 21:56:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:56:16 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v6]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <_EMQ8vgc0hQdgeWdnqirLLAN8Cj6jcxP0belwJffD8A=.2c536c2b-f0e1-49b4-8fc7-e3a9252e20e2@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=05
  Stats: 488 lines in 61 files changed: 389 ins; 3 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From duke at openjdk.org  Thu Apr 18 22:00:13 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:13 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
Message-ID: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>

**Subject**
Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`

**Motivation**
The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.

The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.

Here is a brief overview of the changes made in this pull request:

1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
3. Implemented these methods in all non-abstract classes that implement the `List` interface.

The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.

For example, consider the following test case:

List<String> list = new ArrayList<>();
list.add("Object one");
list.add("NotObject two");
list.add("NotObject three");

int index1 = list.indexOf(s -> s.contains("ct t"));
System.out.println(index1); // Expected output: 1
int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
System.out.println(index2); // Expected output: 2


Currently, to achieve the same result, we would have to use a more verbose approach:

int index1 = IntStream.range(0, list.size())
                     .filter(i -> list.get(i).contains("ct t"))
                     .findFirst()
                     .orElse(-1);
System.out.println(index1); // Output: 1
int index2 = IntStream.range(0, list.size())
                         .filter(i -> list.get(i).startsWith("NotObject"))
                         .reduce((first, second) -> second)
                         .orElse(-1);
System.out.println(index2); // Output: 2


I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.

Thank you for considering this proposal.

Best regards

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

Commit messages:
 - did some renaming of internal methods utilized by findIndex
 - fixed ReverseOrderLinkedListView
 - fixed javadocs in List and ArrayList
 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
 - Removed unused import in AbstractList
 - Also moved to List interface
 - Moved from AbstractList
 - Removed implementation from AbstractList, moving it to List
 - Renamed indexOf(Predicate) and lastIndexOf(Predicate) to findIndex(Predicate) and findLastIndex(Predicate) respectively
 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
 - ... and 25 more: https://git.openjdk.org/jdk/compare/16576b87...025bcf39

Changes: https://git.openjdk.org/jdk/pull/18639/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18639&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329760
  Stats: 882 lines in 13 files changed: 570 ins; 47 del; 265 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

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

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

Newly?added?methods to?existing widely?implemented non?sealed and?non?preview interfaces in?`java.base` must?be?`default` to?avoid source?incompatibilities and?runtime?errors, so?move the?implementations from?`AbstractList` to?`List`:

I?m?in?favour of?using?`findIndex`, which?also?avoids the?issue with?`List<Predicate<?>>::indexOf` being?ambiguous and?having binary?incompatible bridge?methods.

src/java.base/share/classes/java/util/AbstractList.java line 29:

> 27: 
> 28: import java.util.function.Consumer;
> 29: import java.util.function.Predicate;

This?is now?unused:
Suggestion:

src/java.base/share/classes/java/util/AbstractList.java line 221:

> 219:         return -1;
> 220:     }
> 221: 

Suggestion:

src/java.base/share/classes/java/util/AbstractList.java line 269:

> 267:         return -1;
> 268:     }
> 269: 

Suggestion:

src/java.base/share/classes/java/util/List.java line 702:

> 700:      *         (<a href="Collection.html#optional-restrictions">optional</a>)
> 701:      */
> 702:     int lastIndexOf(Predicate<? super E> filter);

Suggestion:

    /**
     * Returns the index of the first occurrence of matching element
     * in this list, or -1 if this list does not contain the element.
     * More formally, returns the lowest index {@code i} such that
     * {@code filter.test(get(i))},
     * or -1 if there is no such index.
     *
     * @implSpec
     * This implementation first gets a list iterator (with
     * {@code listIterator()}).  Then, it iterates over the list until a
     * matching element is found or the beginning of the list is reached.
     *
     * @param filter a predicate to search for
     * @return the index of the first occurrence of the specified element in
     *         this list, or -1 if this list does not contain the element
     * @throws NullPointerException if passed filter is null
     */
    default int indexOf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        ListIterator<E> it = listIterator();
        while (it.hasNext()) {
            E e = it.next();
            if (filter.test(e)) {
                return it.previousIndex();
            }
        }
        return -1;
    }

    /**
     * Returns the index of the last occurrence of matching element
     * in this list, or -1 if this list does not contain the element.
     * More formally, returns the highest index {@code i} such that
     * {@code Objects.equals(o, get(i))},
     * or -1 if there is no such index.
     *
     * @implSpec
     * This implementation first gets a list iterator that points to the end
     * of the list (with {@code listIterator(size())}).  Then, it iterates
     * backwards over the list until the matching element is found, or the
     * beginning of the list is reached.
     *
     * @param filter a predicate to search for
     * @return the index of the last occurrence of the specified element in
     *         this list, or -1 if this list does not contain the element
     * @throws NullPointerException if passed filter is null
     */
    default int lastIndexOf(Predicate<? super E> filter) {
        Objects.requireNonNull(filter);
        ListIterator<E> it = listIterator(size());
        while (it.hasPrevious()) {
            E e = it.previous();
            if (filter.test(e)) {
                return it.nextIndex();
            }
        }
        return -1;
    }

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

Changes requested by ExE-Boss at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/18639#pullrequestreview-1985396823
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046339464
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555586424
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555192600
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555192654
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1555194862

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

currently awaiting for initial issue triage to complete

side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

> Won't this make some calls ambiguous? For example, passing `null`:
> 
> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf(null); // Now fails to compile
> ```
> 
> Edit: I'm not a reviewer, but I decided to point this out.

I`ve tested it. Now calling indexOf with null as literal calls indexOf(Predicate) instead, as Predicate is lower in class hierarchy than Object (ofc it does not apply to varibles that store null, those works just as usual)

If you want to call indexOf(Object) instead, you will have to cast null to desired type manually

> ```java
> List<String> l;
> l.indexOf(""); // Fine
> l.indexOf((String)null); // Will invoke indexOf(Object)
> ```

Question to reviewers: what do you think would be the best way to handle issue discussed above?

PS: converted PR to draft untill the issue is resolved

PPS: The idea I came up with is to possibly rename indexOf(Predicate) to something like findIndex(Predicate) or indexOfMatching(Predicate) as a way to both avoid unexpected behaviour and preserve source compatibility

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038490998
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2038506989
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045522079
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046196342

From liach at openjdk.org  Thu Apr 18 22:00:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
Message-ID: <UlXEKecrn2AWrJ9RSHAuk0Ute-X8g2Al68WNzAWUtaI=.48d23f3e-a28b-49b3-9d9e-e33366cfbb58@github.com>

On Fri, 5 Apr 2024 00:31:22 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

Hello @Evemose, if we add an API we should also consider if implementation can efficiently implement it. How is this new API better than using a ListIterator directly so it's worth the additional methods?

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2039920614

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <OfShBP7AzznrppB4zxxvfSKOvW5IJTvKk5UAauqPWFU=.1a74a86b-8f83-4309-a697-315859b6498a@github.com>
Message-ID: <MWR9MEHsOXEwsrP4zm62PGkjhNVJAfdQGPk6eelU-Ns=.93e29b66-f70a-4dad-9603-495e9da40e59@github.com>

On Fri, 5 Apr 2024 00:31:22 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> side note: looks like this code have been reformated and some unused imports has been reformated. jdk compiles and works just fine, so i guess its not a big deal

> Hello @Evemose, if we add an API we should also consider if implementation can efficiently implement it. How is this new API better than using a ListIterator directly so it's worth the additional methods?

Hi, @liach ! The implementations i provided in this pull requests are pretty much imitating behaviour of indexOf(Object). Every class that has overriden indexOf(Object) recieved implementation of indexOf(Predicate) that works the same way except for search is based on predicate and not equality. Therefore, the effectiveness of implementation is straight up depends on effectiveness of indexOf(Object) for each separate java.util.List impl.

As for ListIterator, where suitable, it has already been used in implementations in classes where it was considered suitable for indexOf(Object) (to be more precise, in AbstractList). The main goal of this pull requst is to provide shorthand for developers as search for index of element that match predicate is very common task and providing way to do it as comfortable as possible should vastly enhance development expirience.

For ListIterator specifically: the main downside of its direct usage for developer is inability to use it fluently (as method call argument, for example), which forces to either implement method to find index separately or find it in same method as invocation but before invocation explicitly. Both cases are pretty frustraiting and, in my opinion, shouldn`t be neccessary for high-level language like Java.

Summarizing, its not that in current stdlib there are no ways to search for index of element based on condition, but this addition would be a great way to make Java development more comfortable and fast.

PS:
Also implementing indexOf with predicate is a common practice for many high level languages: C#/.NET has FindIndex, Kotlin has indexOfFirst, Swift has firstIndex etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2040025647

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <LdKp00uLPajiG6bSky2nSSuPek7KAcJhij-QJRyXuiA=.af7c9303-4715-43f0-8107-42198df9d7d1@github.com>
Message-ID: <1yxDq6ci-69V6ti1JGa8sfc4qSl5h9Ute6UcARrQqIY=.c0eafeb2-6039-41d5-b801-a7132a9d0969@github.com>

On Mon, 8 Apr 2024 03:57:33 GMT, ExE Boss <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Newly?added?methods to?existing widely?implemented non?sealed and?non?preview interfaces in?`java.base` must?be?`default` to?avoid source?incompatibilities and?runtime?errors, so?move the?implementations from?`AbstractList` to?`List`:

@ExE-Boss Commited changes. Also, i see you have added not-null assertion at the beginning of methods inside List. If this is a desired behaviour, I could also add this to other impls

@ExE-Boss removed unused import

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2042094028
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2042910322

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

Won't this make some calls ambiguous?
For example, passing `null`:

List<String> l;
l.indexOf(""); // Fine
l.indexOf(null); // Now fails to compile

Edit: I'm not a reviewer, but I decided to point this out.

src/java.base/share/classes/java/util/LinkedList.java line 1519:

> 1517: 
> 1518:         public int findIndex(Predicate<? super E> filter) {
> 1519:             return rlist.indexOf(filter);

Should be `findIndex`? Similarly with `findLastIndex`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2045324794
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1559268478

From liach at openjdk.org  Thu Apr 18 22:00:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>

On Fri, 5 Apr 2024 00:00:58 GMT, Evemose <duke at openjdk.org> wrote:

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

A few remarks:
1. The concern on `indexOf(Object)` and `indexOf(Predicate)` is valid; `Optional` has `orElse` vs. `orElseGet` to avoid these clashes. The behavior change of `indexOf(null)` is a source incompatibility.
2. Have you considered `indexOf(predicate/object, startIndex)` like the indexOf for `String`?

Also, a significant difference between String/arrays and `List` is that `List` is structurally modifiable; the index may be no longer valid after a modification. Thus the index is not as useful. 

For example, in an [unrolled linked list](https://en.wikipedia.org/wiki/Unrolled_linked_list) implementation, each block can be independently locked for read/write access, maybe like this:
`[1, 2, 3] -> [4, 5] -> [6, 7, 8, 9]`
An index would be useless if any part of this list updates, but if the position information is stored in a `ListIterator` and we add an `beforeNext(predicate)` that moves the cursor to right before the next element that matches the predicate (or the tail if there's no match), this would be much more useful.

Just a side note, this patch won't be reviewed by official JDK engineers until it has rfr tag (means this PR is not draft and the automatic checks of issue, whitespace, oca etc. are passed)

You should post on `core-libs-dev at openjdk.org` to get feedbacks on the API design, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046023822
PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2047602713

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
Message-ID: <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>

On Tue, 9 Apr 2024 20:48:19 GMT, Chen Liang <liach at openjdk.org> wrote:

> A few remarks:
> 
> 1. The concern on `indexOf(Object)` and `indexOf(Predicate)` is valid; `Optional` has `orElse` vs. `orElseGet` to avoid these clashes. The behavior change of `indexOf(null)` is a source incompatibility.
> 2. Have you considered `indexOf(predicate/object, startIndex)` like the indexOf for `String`?
> 
> Also, a significant difference between String/arrays and `List` is that `List` is structurally modifiable; the index may be no longer valid after a modification. Thus the index is not as useful.
> 
> For example, in an [unrolled linked list](https://en.wikipedia.org/wiki/Unrolled_linked_list) implementation, each block can be independently locked for read/write access, maybe like this: `[1, 2, 3] -> [4, 5] -> [6, 7, 8, 9]` An index would be useless if any part of this list updates, but if the position information is stored in a `ListIterator` and we add an `beforeNext(predicate)` that moves the cursor to right before the next element that matches the predicate (or the tail if there's no match), this would be much more useful.

The concern about change in behaviour of indexOf(null) is completely valid, although indexOf(null) is kind of exotic scenario. One possible workaround is to temporally (for an intermidiate period) or permanently delegate null value handing to indexOf(Object), which seems odd for me to me tbh, although it preserves source compatibility.

Regarding to indexOf(predicate/object, startIndex), i thought about this, but firstly I would like to have a final and approved version of indexOf(predicate) to have a reference I`m certain in.

As for beforeNext(Predicate) for ListIterator, I havent thought about that, but now that you`ve mentioned it, I could also consider implementing such thing. However, concern about possible index invalidation is more applicable to the nature of indexOf itself rather then this proposal. This method is primarly used when index is needed right here and now or passed to operation that is not supposed to modify list. I guess ListIterator.beforeNext and List.indexOf serve different, altough alike purpose, and therefore, in my opinion, there are place for both in Java

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046103546

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (xxDark)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
 <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
Message-ID: <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>

On Tue, 9 Apr 2024 21:48:23 GMT, Evemose <duke at openjdk.org> wrote:

> One possible workaround is to temporally (for an intermidiate period) or permanently delegate null value handing to indexOf(Object), which seems odd for me to me tbh, although it preserves source compatibility.

This does not solve the problem though. Source compatibility would still be broken as one would still need to add casts everywhere, or am I misinterpreting something?
> he concern about change in behaviour of indexOf(null) is completely valid, although indexOf(null) is kind of exotic scenario.

See [this](https://github.com/search?q=%22indexOf%28null%29%22+language%3AJava+&type=code) and [that](https://github.com/search?q=%22lastIndexOf%28null%29%22+language%3AJava+&type=code) query.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046118678

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <iQ8RB8JYwM8UvczWtI6yW4e1_E5mj63MiMEkzzysWrM=.8f765312-7cd3-424a-afa3-afd7407d97bb@github.com>
 <k8JkKsq8vLuBse-uluQbjlKEROI52Aw6jyN9cqNnMmI=.a7346c37-0cb5-412e-9c10-25e824eaea98@github.com>
 <s2TwCBxX5fqo44tU9VLn8tMW09Q_cvun37Ekie_45t0=.1e3c7b44-0fb8-4fc0-b828-56b9ed114f2c@github.com>
Message-ID: <5UyLqOV-5aORewjtxLQjiWBRRdhVXJ_LpdOffFOFpBI=.8ea655b6-100e-49df-970e-d6d5b3957d0a@github.com>

On Tue, 9 Apr 2024 22:02:56 GMT, xxDark <duke at openjdk.org> wrote:

> This does not solve the problem though. Source compatibility would still be broken as one would still need to add casts everywhere, or am I misinterpreting something?

The code you have provided in example is still valid and non-ambigous, even without cast. The default behaviour of java compiler is to choose method where parameter at corresponding position is closest type upwards in class hierarchy. null is considered "bottom" type, which means it is at the bottom of simultaneously every class hierarchy. Compiler looks upward in class hierarchy and first class it encounters is Predicate, as Object is superclass of Predicate, and chooses indexOf(Predicate) as method to invoke. When casting null to type, compiler treats null as object of casted type rather then bottom type. However, if changes are delivered as is, default behaviour of indexOf(null) will be changed, which is not desired, of course, and, although delegation to indexOf(Object) in case of null as passed value is counterintuitive, it will preserve the current state of things.

> See [this](https://github.com/search?q=%22indexOf%28null%29%22+language%3AJava+&type=code) and [that](https://github.com/search?q=%22lastIndexOf%28null%29%22+language%3AJava+&type=code) query.

Thats a valid point, haven`t though about qurying where null is valid value.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2046174903

From duke at openjdk.org  Thu Apr 18 22:00:14 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:00:14 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface
In-Reply-To: <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <6LsOn4MSuIs2TcuU5FCYKGM4bje2IEYxQl_PypZAbFg=.68f8fbd5-9609-4d40-9784-3d20905e35ef@github.com>
Message-ID: <v5LIszsyYVnq3CK0IzmdFHDuKQ0lWjZl8EkY0IYeEa8=.ea7829bd-7d92-43e1-97fd-84a3a8da9138@github.com>

On Wed, 10 Apr 2024 11:20:32 GMT, xxDark <duke at openjdk.org> wrote:

> Should be `findIndex`? Similarly with `findLastIndex`.

Yeah i guess IDE didnt do a great job with refactor. I will review aall changes manually a bit later

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1559373902

From duke at openjdk.org  Thu Apr 18 22:21:11 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 18 Apr 2024 22:21:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards

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

  empty commit to trigger check rerun

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/025bcf39..21ce4892

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

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

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

From jjg at openjdk.org  Thu Apr 18 22:28:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 22:28:57 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v6]
In-Reply-To: <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>
Message-ID: <Wp9RQMnxhRIFD54h7ifoDenUiniuKSYn4eXILPsbd2Q=.77bfb66f-65a7-4b9b-9cc0-c3102d359eee@github.com>

On Wed, 17 Apr 2024 19:58:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement off-list feedback on HTML id syntax; add trial @see link.

Two minor editorial suggestions

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 63:

> 61:  *
> 62:  * <li>the preview language construct only triggers the introduction
> 63:  * of a new kind <em>without</em> a new modeling interface.

There are many kinds of kind. Can you qualify which kind you mean here?

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 242:

> 240:  *        * ENUM_CONSTANT}, {&commat;code EXCEPTION_PARAMETER}, {&commat;code FIELD},
> 241:  *  -     * {&commat;code LOCAL_VARIABLE}, {&commat;code PARAMETER}, or {&commat;code RESOURCE_VARIABLE}.
> 242:  *  +     * {&commat;code LOCAL_VARIABLE}, {&commat;code PARAMETER}, or {&commat;code RESOURCE_VARIABLE},

delete `or` at this position in the list

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18804#pullrequestreview-2010017570
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1571451041
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1571453618

From darcy at openjdk.org  Fri Apr 19 00:30:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 00:30:16 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v7]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <NVsUbOsPt0aaBauME-Wj-MPspA5tKwAosnzKq2zaqe4=.94576a9b-31e5-4dff-a07d-9c7395c74b0b@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/2bdbdf43..26160b42

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

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

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

From darcy at openjdk.org  Fri Apr 19 00:34:58 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 00:34:58 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v6]
In-Reply-To: <Wp9RQMnxhRIFD54h7ifoDenUiniuKSYn4eXILPsbd2Q=.77bfb66f-65a7-4b9b-9cc0-c3102d359eee@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <TliiNnV4rCL0ksgCFBn9S_ddSVdwcYkUzdAv368gPb4=.814103b5-0553-4b57-bd20-5eb56b230544@github.com>
 <Wp9RQMnxhRIFD54h7ifoDenUiniuKSYn4eXILPsbd2Q=.77bfb66f-65a7-4b9b-9cc0-c3102d359eee@github.com>
Message-ID: <yw3XCkkFg580a5GTvyVd94P5IorAYfTyePIsHRkKYHc=.0be227b0-82e7-4313-b712-873f60ed26bc@github.com>

On Thu, 18 Apr 2024 22:20:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement off-list feedback on HTML id syntax; add trial @see link.
>
> src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 63:
> 
>> 61:  *
>> 62:  * <li>the preview language construct only triggers the introduction
>> 63:  * of a new kind <em>without</em> a new modeling interface.
> 
> There are many kinds of kind. Can you qualify which kind you mean here?

Add some more explicit information; thanks for the suggestion.

> src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 242:
> 
>> 240:  *        * ENUM_CONSTANT}, {&commat;code EXCEPTION_PARAMETER}, {&commat;code FIELD},
>> 241:  *  -     * {&commat;code LOCAL_VARIABLE}, {&commat;code PARAMETER}, or {&commat;code RESOURCE_VARIABLE}.
>> 242:  *  +     * {&commat;code LOCAL_VARIABLE}, {&commat;code PARAMETER}, or {&commat;code RESOURCE_VARIABLE},
> 
> delete `or` at this position in the list

Fixed; thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1571554258
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1571554092

From pminborg at openjdk.org  Fri Apr 19 09:42:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 19 Apr 2024 09:42:02 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
Message-ID: <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>

On Thu, 18 Apr 2024 22:21:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   empty commit to trigger check rerun

Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066206801

From duke at openjdk.org  Fri Apr 19 10:29:26 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 19 Apr 2024 10:29:26 GMT
Subject: RFR: 8328501: Incorrect `@since` tags for java security interfaces
 [v4]
In-Reply-To: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
Message-ID: <0daETMk_HKPcieXYneDVU2vVo5tMAbXEb22NBTiLJCc=.a3336c0d-4fe0-4163-992a-9b5b673acde9@github.com>

> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
> 
> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
> 
> As pointed out by my mentor Jan, 
> 
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
> 
> 
> - the same goes for these other interfaces 
> 
> java.security.interfaces.DSAPublicKey
> java.security.interfaces.XECPublicKey
> java.security.interfaces.DSAPrivateKey
> java.security.interfaces.ECPrivateKey
> java.security.interfaces.XECPrivateKey
> java.security.interfaces.EdECPrivateKey
> java.security.interfaces.ECPublicKey
> java.security.interfaces.EdECPublicKey
> javax.crypto.interfaces.DHPrivateKey
> javax.crypto.interfaces.DHPublicKey
> java.security.interfaces.RSAPublicKey
> java.security.interfaces.RSAPrivateKey

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

  removed change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18373/files
  - new: https://git.openjdk.org/jdk/pull/18373/files/b04a75e5..ebe37b03

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

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

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

From duke at openjdk.org  Fri Apr 19 10:46:31 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 19 Apr 2024 10:46:31 GMT
Subject: RFR: 8328501: Incorrect `@since` tags for java security interfaces
 [v5]
In-Reply-To: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
References: <f2NMiCtE2DUSwSu6hR8mmincd1IJSq4BT4KpZPub-V0=.dbbe76d5-bea4-467e-a650-7811aabee38f@github.com>
Message-ID: <p35mTbs1qYxfMzMH7C5oLHUN8cVvSlQqv0IfR0RD9B8=.eb572b58-458d-4c3f-9623-9db6f548aafc@github.com>

> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.
> 
> The override of `getParams` in these interfaces was done in in JDK 22 and an `@since 22` was, but this method has been inherited to these interfaces for a long time.
> 
> As pointed out by my mentor Jan, 
> 
> 
> import javax.crypto.interfaces.DHPublicKey;
> 
> public class DhkeyTest {
> 
>     public static void main(DHPublicKey key) {
>         System.err.println(key.getParams());
>     }
>     
> }
> 
> 
> this compiles using JDK 8 without any compile-time errors. The @ since tag shouldn't be here
> 
> 
> - the same goes for these other interfaces 
> 
> java.security.interfaces.DSAPublicKey
> java.security.interfaces.XECPublicKey
> java.security.interfaces.DSAPrivateKey
> java.security.interfaces.ECPrivateKey
> java.security.interfaces.XECPrivateKey
> java.security.interfaces.EdECPrivateKey
> java.security.interfaces.ECPublicKey
> java.security.interfaces.EdECPublicKey
> javax.crypto.interfaces.DHPrivateKey
> javax.crypto.interfaces.DHPublicKey
> java.security.interfaces.RSAPublicKey
> java.security.interfaces.RSAPrivateKey

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - removed change
 - Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18373/files
  - new: https://git.openjdk.org/jdk/pull/18373/files/ebe37b03..a312a369

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

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

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

From prappo at openjdk.org  Fri Apr 19 11:03:59 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:03:59 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v7]
In-Reply-To: <NVsUbOsPt0aaBauME-Wj-MPspA5tKwAosnzKq2zaqe4=.94576a9b-31e5-4dff-a07d-9c7395c74b0b@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <NVsUbOsPt0aaBauME-Wj-MPspA5tKwAosnzKq2zaqe4=.94576a9b-31e5-4dff-a07d-9c7395c74b0b@github.com>
Message-ID: <oCoJT8lODkpWfTswZbEOpTcqI8g_uknfKs-IXzs9-60=.7a50560c-3922-4044-a4cd-6b599095db6b@github.com>

On Fri, 19 Apr 2024 00:30:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks good; thanks.

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 44:

> 42:  * As the Java programming language evolves, the visitor interfaces of
> 43:  * the language model also evolve as do the concrete visitors in this
> 44:  * package. A preview language feature in JDK <i>N</i> may have API

Consider adding this or similar unobtrusive link:

Suggestion:

 * package. A <a href="https://openjdk.org/jeps/12">preview language feature</a> in JDK <i>N</i> may have API

src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 229:

> 227:  *                LOCAL_VARIABLE, EXCEPTION_PARAMETER, RESOURCE_VARIABLE,
> 228:  *  -             BINDING_VARIABLE -> true;
> 229:  *  +            BINDING_VARIABLE, PREVIEW_FEATURE_2 -> true;

Nit:
Suggestion:

 *  +             BINDING_VARIABLE, PREVIEW_FEATURE_2 -> true;

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18804#pullrequestreview-2010962237
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572095363
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572198106

From prappo at openjdk.org  Fri Apr 19 11:04:00 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:04:00 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v7]
In-Reply-To: <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <-VKlEr3WTG6AOxW218RWjHSdCsWvnfSsDo30mBvalM8=.dffc3bfb-7af8-464e-8682-dc8ac58317ed@github.com>
Message-ID: <iBwO04BWBIpR5MHPTKylgYkm9RNAvRoSje1sAn3jOlI=.0b576550-a471-4f95-9290-c47c0242c08f@github.com>

On Wed, 17 Apr 2024 10:27:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.compiler/share/classes/javax/lang/model/util/package-info.java line 291:
> 
>> 289:  * As in the case where a new interface is introduced, when preview
>> 290:  * feature 2 exits preview in JDK (<i>N+k</i>), a set of visitors for
>> 291:  * language level (<i>N+k</i>) would be added with the methods
> 
> Ditto for "added with".

Thanks for rephrasing this and the other occurrence of "added with".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572194409

From duke at openjdk.org  Fri Apr 19 11:37:00 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:37:00 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
Message-ID: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>

On Fri, 19 Apr 2024 09:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   empty commit to trigger check rerun
>
> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.

@minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066385281

From liach at openjdk.org  Fri Apr 19 11:47:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 11:47:58 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <WotAqbPlhMshNG_r0nj0USOKfcyYqCif4PnaDklbSqM=.40ff1445-ade4-4cff-ab58-f6ad665b91b6@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

>> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.
>
> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

@Evemose CSR requests can only be filed by users who have a JBS account. I am glad to help you file one, but before that, you need to ensure that the API surface (the public method/fields' names, modifiers, types, and javadocs) are all finalized and won't change.

The CSR looks like this:
Summary: A concise summary about the changes, like "Add findIndex(Predicate) to List"
Problem: Description of the problem, as in why this CSR is needed
Solution: The solution to the said problem, i.e. what your task did
Specification: The git diff, but you only need to include changes to public method/field/classes' names, modifiers, types, and javadocs; you don't need to include any implementation code changes
Also, you might include things like "alternatives" describing alternative approaches and why you elect not to choose them, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066402038

From duke at openjdk.org  Fri Apr 19 11:54:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:54:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v3]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <HF4w-OW5WeyXhFoVQzF1vsVXD5jcZOvT4rzhMJPTvjQ=.dacde753-a475-440d-bccf-f85e4bb98aa5@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Removed extra line from previous commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/21ce4892..5fcdfd87

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

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

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

From duke at openjdk.org  Fri Apr 19 11:57:27 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 11:57:27 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v4]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <43ivjl5_vgCBp1dxypZ8s6xqhubFHu8BOdy8wttjsG0=.1050fc33-313e-43a7-b8e5-1e9a982d11e6@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Fixed javadocs in ArrayList

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/5fcdfd87..34b3695f

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

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

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

From duke at openjdk.org  Fri Apr 19 12:04:26 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:04:26 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v5]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <RXaPyUqwCk0loiELpVFvGD3zNJpNzk6VFwRqbekljtw=.ba738ace-b766-41ce-aa83-f80cfe733c17@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Fixed javadocs in LinkedList.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/34b3695f..5beec920

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

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

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

From duke at openjdk.org  Fri Apr 19 12:32:19 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v6]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <kBLC_EIFpo96Bkhi3V2kSNRTdZeu7oZKgEDrEDdRsfo=.1edeab77-936d-42f0-8b28-e286ce8b9b3e@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with 14 additional commits since the last revision:

 - Update LinkedList.java
 - Update LinkedList.java
 - Reformat LinkedList.java
 - Removed trailing whitespace in Collections.java
 - Update CopyOnWriteArrayList.java
 - Reformated imports in Vector.java
 - Reformated imports in CopyOnWriteArrayList.java
 - Removed on-demand import from SpliteratorTraversingAndSplittingTest.java
 - Update ListFactories.java
 - Update ReverseOrderListView.java
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5beec920...d7f5e97e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/5beec920..d7f5e97e

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

  Stats: 59 lines in 7 files changed: 33 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

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

From alanb at openjdk.org  Fri Apr 19 12:32:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <dh7EZA0fPuyxngUs-RM9_S_i9ullQ41SIbZK4XMD-y8=.11ecf394-d815-4886-8deb-d7fa667e427d@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

> but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

I think you can ignore CSR for now, the first step when proposing an API in this area is to start a discussion on core-libs-dev to make the case and get support. The java.util.List interface dates from JDK 1.2 and there are many implementations. Even if the proposal has some merit, I think a big part of the work required will be doing analysis on implementations to see what compatibility issues might come up.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066437418

From liach at openjdk.org  Fri Apr 19 12:32:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 12:32:19 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
Message-ID: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose <duke at openjdk.org> wrote:

>> Adding (default) methods to `List` would have significant compatibility ramifications. Also, the PR needs to contain significant testing of the new proposed methods.
>
> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?

@Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066439080

From duke at openjdk.org  Fri Apr 19 12:39:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:39:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v7]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <CJ_dERFrPCQEQFrHKQNd2oBMpxL8I2PTY0M1DGMoarU=.abe3f9d1-6ca1-44ac-97b0-33ac26f8f911@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

 - Update CopyOnWriteArrayList.java
 - Reformat LinkedList.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/d7f5e97e..625c5b46

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

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

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

From duke at openjdk.org  Fri Apr 19 12:39:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:39:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v2]
In-Reply-To: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
 <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
Message-ID: <28cKraYF4xWkM_A32j3iwxTdaaNDRD1F9hI9EJRUFGI=.b94e4be6-4ffc-44ac-b3d0-5783f1918302@github.com>

On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?
>
> @Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

@liach i did revert changes where it was possible but in few files it will be just too resource-consuming to revert indentations to previous state. If this will be crucial, ill deal with it before merging

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066480208

From duke at openjdk.org  Fri Apr 19 12:47:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:47:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v8]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

 - Update SpliteratorTraversingAndSplittingTest.java
 - Update Arrays.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/625c5b46..49c4993b

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

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

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

From duke at openjdk.org  Fri Apr 19 12:52:03 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:52:03 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v8]
In-Reply-To: <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <9HprdOQ-TujeBVtMHLdDOYeIGMyeiHw6PsAm7siC5no=.beef0dc3-5a2f-4bcd-b188-85ad222befa4@github.com>
Message-ID: <rneh9yXGZQCWiogRN58LBlBwv8zj27l0ypkfCiw0sTM=.18744eb7-4207-467a-beef-1d3bc104514c@github.com>

On Fri, 19 Apr 2024 12:47:12 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update SpliteratorTraversingAndSplittingTest.java
>  - Update Arrays.java

I requested post in core-libs-dev. I guess I will wait a week or two to gather feedback of community before filing for CSR

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066509181

From duke at openjdk.org  Fri Apr 19 12:59:24 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 12:59:24 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Update Vector.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/49c4993b..97b9bff4

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

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

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

From jlahoda at openjdk.org  Fri Apr 19 13:17:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:17:18 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Adding test for ImportTree.isModule, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/846b038e..cbc363ab

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

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

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

From jlahoda at openjdk.org  Fri Apr 19 13:44:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 Apr 2024 13:44:28 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v11]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <RUP3cDwtavZWUcF7V8Pq69_mJRwXfxxYiam3TBYRfpg=.9dec63e0-bb60-4e76-b0b4-ecaf068f198e@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Post-merge fixes.
 - Merge branch 'master' into wthexp
 - Reflecting review feedback:
   - reverting unnecessary changes in TransPatterns
   - moving the patters/withers/Model test to a more appropriate place
 - Adding tests as suggested.
 - Reflecting review feedback:
   - pre-generating the JCVarDecls in Attr, to aid Flow
   - adding a note on how the desugared code looks like
 - JavaCompiler cleanup
 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - Fixing tests.
 - ... and 25 more: https://git.openjdk.org/jdk/compare/177092b9...e8499df1

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

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=10
  Stats: 2023 lines in 51 files changed: 1965 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

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

From rriggs at openjdk.org  Fri Apr 19 14:14:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Apr 2024 14:14:00 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
Message-ID: <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>

On Fri, 19 Apr 2024 12:59:24 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Vector.java

Please revert the formatting as soon as possible; its noise as far as reviewers are concerned. 
You want reviewers to focus on the suitability of the API and clarity of the specification first, then later on the implementation.  Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066673266

From duke at openjdk.org  Fri Apr 19 15:39:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:39:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v10]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

 - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
   
   # Conflicts:
   #	src/java.base/share/classes/java/util/LinkedList.java
   #	src/java.base/share/classes/java/util/ReverseOrderListView.java
   #	src/java.base/share/classes/java/util/Vector.java
   #	test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
 - reverted code style changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/97b9bff4..2c37ecef

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

  Stats: 210 lines in 6 files changed: 11 ins; 44 del; 155 mod
  Patch: https://git.openjdk.org/jdk/pull/18639.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18639/head:pull/18639

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

From duke at openjdk.org  Fri Apr 19 15:49:11 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:11 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v11]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  reverted code style changes in Vector

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/2c37ecef..de6e18e7

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

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

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

From duke at openjdk.org  Fri Apr 19 15:49:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v9]
In-Reply-To: <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <vjm5kqMml0JMATtkFoM1zAvriqn8jbhp0mwIx39qmyU=.d4768ef6-7551-41dc-a2c3-f9d6e195702d@github.com>
 <RpCWwvirm7rTB8Nn2n1OUGDM3HqrMM5EkoSc3K0AWKo=.0ba483c5-7a4e-4f85-88fb-4278d9dfcb9f@github.com>
Message-ID: <vDWzpdcJDAYK8PQyO4_JmueMnS_UuZ7_NRF7wIptRSc=.d12871a5-9b4c-48ef-bbcf-7545e11af51f@github.com>

On Fri, 19 Apr 2024 14:11:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Vector.java
>
> Please revert the formatting as soon as possible; its noise as far as reviewers are concerned. 
> You want reviewers to focus on the suitability of the API and clarity of the specification first, then later on the implementation.  Thanks

@RogerRiggs Been done. It turned out much easier then i though it would

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066838257

From duke at openjdk.org  Fri Apr 19 15:49:12 2024
From: duke at openjdk.org (Evemose)
Date: Fri, 19 Apr 2024 15:49:12 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java..util.List interface [v10]
In-Reply-To: <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <R4A9wZCFMqBKHw84nfreiL3FgJmpYWvqx6hS7ViieQI=.4ec286d8-fd7f-4626-82c8-7a015e850dec@github.com>
Message-ID: <-tsyKK8DMn5A2zhkxWpei5eTnwRIeB4mDvkzKeg57pM=.8f59c9c9-623e-4878-a425-9ed2703d2cc3@github.com>

On Fri, 19 Apr 2024 15:39:12 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/feature/indexOf-with-predicate' into feature/indexOf-with-predicate
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/util/LinkedList.java
>    #	src/java.base/share/classes/java/util/ReverseOrderListView.java
>    #	src/java.base/share/classes/java/util/Vector.java
>    #	test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>  - reverted code style changes

Also regarding tests. Not sure if they are needed at all as implementations are no longer then 15 lines, but if it is mandatory step, I guess i will add them after I finished collecting feedback so I will have final version of what this methods behaviour should look like

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2066841853

From vromero at openjdk.org  Fri Apr 19 17:20:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Apr 2024 17:20:59 GMT
Subject: RFR: 8328481: Implement Module Imports [v11]
In-Reply-To: <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
 <7XRhp6hqZlq4QvPh1URc9o1g4ptrl0nPUBZL-LMAyvw=.905f995d-a826-47f1-80d3-fa1216d126b2@github.com>
Message-ID: <ep0BYQNQSPvUeV-zPB0MGvuIWrdSc3huoK0IXhuU3Uc=.e531e4bf-d2f5-4956-b07f-51f292308600@github.com>

On Fri, 19 Apr 2024 13:17:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
>> https://bugs.openjdk.org/browse/JDK-8315129
>> 
>> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
>> There is a few notable aspects, however:
>> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
>> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test for ImportTree.isModule, as suggested.

lgtm, thanks!

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18614#pullrequestreview-2011974781

From darcy at openjdk.org  Fri Apr 19 18:54:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 18:54:32 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v8]
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <1xwrFzKyLWQElmDE6VwoUIdLDG5jx21mRQkD-iUW8l4=.cb977dc2-f149-4165-b38e-71c3bfcfa3d2@github.com>

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

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

  Implement review feedback; add link in remainder of preview visitor classes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18804/files
  - new: https://git.openjdk.org/jdk/pull/18804/files/26160b42..75493492

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

  Stats: 23 lines in 9 files changed: 17 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18804/head:pull/18804

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

From darcy at openjdk.org  Fri Apr 19 19:04:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 19:04:04 GMT
Subject: Integrated: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util
In-Reply-To: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
Message-ID: <2UBN1p699DXUILZ_QKUxhm5A2QpsrGVxo5ZsBc8lU0E=.59dac142-1fef-46a8-b9c1-57df7579afb5@github.com>

On Tue, 16 Apr 2024 23:34:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.

This pull request has now been integrated.

Changeset: c1dd82b4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1dd82b4d2393b2095cfd2365a806b74e9adf92e
Stats:     289 lines in 10 files changed: 288 ins; 0 del; 1 mod

8329644: Discuss expected visitor evolution patterns in javax.lang.model.util

Reviewed-by: prappo, jlahoda, jjg

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

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

From jjg at openjdk.org  Fri Apr 19 19:04:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:04:04 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v8]
In-Reply-To: <1xwrFzKyLWQElmDE6VwoUIdLDG5jx21mRQkD-iUW8l4=.cb977dc2-f149-4165-b38e-71c3bfcfa3d2@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <1xwrFzKyLWQElmDE6VwoUIdLDG5jx21mRQkD-iUW8l4=.cb977dc2-f149-4165-b38e-71c3bfcfa3d2@github.com>
Message-ID: <4hbiFp60gYGpdlXTlHpkxcwE21HDI5hbBxm1DREabpg=.c5b2b739-86c9-47b2-a217-59acddcaa2f6@github.com>

On Fri, 19 Apr 2024 18:54:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Provide more concrete discussion of how the preview visitors are expected to evolve for different categories of language changes.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement review feedback; add link in remainder of preview visitor classes.

Marked as reviewed by jjg (Reviewer).

src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java line 43:

> 41:  * @param <P> the type of the additional parameter to this visitor's methods.
> 42:  *
> 43: * @see <a href="package-summary.html#expectedEvolution">

FWIW, I would expect that you could write this as


@see package-name##id   description

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

PR Review: https://git.openjdk.org/jdk/pull/18804#pullrequestreview-2012155914
PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572794286

From jjg at openjdk.org  Fri Apr 19 19:06:01 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:06:01 GMT
Subject: Integrated: 8330179: Clean up non-standard use of /** comments in
 `jdk.compiler`
In-Reply-To: <NVwoWKF1kQllSwNEf689da2MP_0l4J6G2Q6SetJAldY=.d4c4075a-cd3f-4cf2-be67-722228a655ec@github.com>
References: <NVwoWKF1kQllSwNEf689da2MP_0l4J6G2Q6SetJAldY=.d4c4075a-cd3f-4cf2-be67-722228a655ec@github.com>
Message-ID: <kRDAqlTLTlEMvHHLG3_kr_KROLd8OfzdCH3eCS_tNpE=.a908c05e-bd64-417f-8ec4-ed6cba15ba4d@github.com>

On Fri, 12 Apr 2024 21:45:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a fix to preempt warnings that would otherwise be introduced by [JDK-8303689](https://bugs.openjdk.org/browse/JDK-8303689), which introduces a new `javac` lint warning to detect documentation comments in unusual places.
> 
> The majority of the warnings are caused by "box comments" beginning with `/*****`. To minimize change and to address these, the second `*` is replaced by a space. An alternative solution might be to change the overall style of the box comment to use something like `/*---------`

This pull request has now been integrated.

Changeset: df043582
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df04358223e8ae24009187d9c5a7e12701f4191f
Stats:     51 lines in 15 files changed: 0 ins; 0 del; 51 mod

8330179: Clean up non-standard use of /** comments in `jdk.compiler`

Reviewed-by: darcy

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

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

From darcy at openjdk.org  Fri Apr 19 19:20:02 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 19:20:02 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v8]
In-Reply-To: <4hbiFp60gYGpdlXTlHpkxcwE21HDI5hbBxm1DREabpg=.c5b2b739-86c9-47b2-a217-59acddcaa2f6@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <1xwrFzKyLWQElmDE6VwoUIdLDG5jx21mRQkD-iUW8l4=.cb977dc2-f149-4165-b38e-71c3bfcfa3d2@github.com>
 <4hbiFp60gYGpdlXTlHpkxcwE21HDI5hbBxm1DREabpg=.c5b2b739-86c9-47b2-a217-59acddcaa2f6@github.com>
Message-ID: <ulbjVWmTZjqXYEwtVgYKgi2PrzvW5tKYmHi4Z5ytSqI=.7df3cd88-f822-4ffd-8734-7256334a415f@github.com>

On Fri, 19 Apr 2024 19:00:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement review feedback; add link in remainder of preview visitor classes.
>
> src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java line 43:
> 
>> 41:  * @param <P> the type of the additional parameter to this visitor's methods.
>> 42:  *
>> 43: * @see <a href="package-summary.html#expectedEvolution">
> 
> FWIW, I would expect that you could write this as
> 
> 
> @see package-name##id   description

I tried something like

`@see package-info##foo Description of Foo`

but that didn't work, hence the use of HTML. I'll try out the variation you suggested here and if it works file a quick follow-up bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572822214

From jjg at openjdk.org  Fri Apr 19 19:29:03 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:29:03 GMT
Subject: RFR: 8329644: Discuss expected visitor evolution patterns in
 javax.lang.model.util [v8]
In-Reply-To: <ulbjVWmTZjqXYEwtVgYKgi2PrzvW5tKYmHi4Z5ytSqI=.7df3cd88-f822-4ffd-8734-7256334a415f@github.com>
References: <HyZR8wnFoRLMMG6nmZfZRS6aIEOy5nKFQo3Di-9-ttU=.fb18bf56-878c-4cf9-b624-ba6c2ba36cac@github.com>
 <1xwrFzKyLWQElmDE6VwoUIdLDG5jx21mRQkD-iUW8l4=.cb977dc2-f149-4165-b38e-71c3bfcfa3d2@github.com>
 <4hbiFp60gYGpdlXTlHpkxcwE21HDI5hbBxm1DREabpg=.c5b2b739-86c9-47b2-a217-59acddcaa2f6@github.com>
 <ulbjVWmTZjqXYEwtVgYKgi2PrzvW5tKYmHi4Z5ytSqI=.7df3cd88-f822-4ffd-8734-7256334a415f@github.com>
Message-ID: <jro9uwLricmkLmyzsPZPvVau1Tii7BTLOt4dl-qx10E=.006fe42c-ca6d-4969-89ac-0519702efdc8@github.com>

On Fri, 19 Apr 2024 19:16:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java line 43:
>> 
>>> 41:  * @param <P> the type of the additional parameter to this visitor's methods.
>>> 42:  *
>>> 43: * @see <a href="package-summary.html#expectedEvolution">
>> 
>> FWIW, I would expect that you could write this as
>> 
>> 
>> @see package-name##id   description
>
> I tried something like
> 
> `@see package-info##foo Description of Foo`
> 
> but that didn't work, hence the use of HTML. I'll try out the variation you suggested here and if it works file a quick follow-up bug.

Yes, it needs to be an element name before the `##`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18804#discussion_r1572830786

From darcy at openjdk.org  Fri Apr 19 20:33:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 20:33:21 GMT
Subject: RFR: 8330703: Improve link syntax in javax.lang.model.util
Message-ID: <GHDYJpZxCfxAkerfeemyF3wS7FL3R1JRi0_D5hj4wYc=.c5fb76b9-b54e-4b0f-bcc6-9283fd1b6420@github.com>

Use javadoc-based from than HTML-based syntax for `@see` tags.

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

Commit messages:
 - JDK-8330703: Improve link syntax in javax.lang.model.util

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

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

From jjg at openjdk.org  Fri Apr 19 20:33:22 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 20:33:22 GMT
Subject: RFR: 8330703: Improve link syntax in javax.lang.model.util
In-Reply-To: <GHDYJpZxCfxAkerfeemyF3wS7FL3R1JRi0_D5hj4wYc=.c5fb76b9-b54e-4b0f-bcc6-9283fd1b6420@github.com>
References: <GHDYJpZxCfxAkerfeemyF3wS7FL3R1JRi0_D5hj4wYc=.c5fb76b9-b54e-4b0f-bcc6-9283fd1b6420@github.com>
Message-ID: <JjlcwG2NShWcRdIx0_WcsmBab4U_FLQCnfjG7CLEGho=.8b353d9f-923d-4ed9-8a42-f29841e1505e@github.com>

On Fri, 19 Apr 2024 20:11:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use javadoc-based from than HTML-based syntax for `@see` tags.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18869#pullrequestreview-2012322395

From darcy at openjdk.org  Fri Apr 19 20:35:32 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 19 Apr 2024 20:35:32 GMT
Subject: Integrated: 8330703: Improve link syntax in javax.lang.model.util
In-Reply-To: <GHDYJpZxCfxAkerfeemyF3wS7FL3R1JRi0_D5hj4wYc=.c5fb76b9-b54e-4b0f-bcc6-9283fd1b6420@github.com>
References: <GHDYJpZxCfxAkerfeemyF3wS7FL3R1JRi0_D5hj4wYc=.c5fb76b9-b54e-4b0f-bcc6-9283fd1b6420@github.com>
Message-ID: <yd2fVxPXJm9aNgFIK33kkqpZgsANUWxQMFzTu8aRhR4=.ae85374c-c9b7-4679-93df-7080ea61f2d4@github.com>

On Fri, 19 Apr 2024 20:11:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use javadoc-based from than HTML-based syntax for `@see` tags.

This pull request has now been integrated.

Changeset: f6feeb03
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6feeb03bbe9024b609ae6a4795255128581d53c
Stats:     36 lines in 9 files changed: 1 ins; 0 del; 35 mod

8330703: Improve link syntax in javax.lang.model.util

Reviewed-by: jjg

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

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

From rotan.olexandr at gmail.com  Fri Apr 19 20:48:14 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Fri, 19 Apr 2024 23:48:14 +0300
Subject: Allowed type of expression as default value of method parameter
Message-ID: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>

Greetings to the Java developers community.

I am currently working on default parameter value support for java.
Surprisingly, implementation of this feature turned out really simple and
non-invasive, no more than a few hundred lines of new code.

The question I am asking is, should default parameter values be only
compile-time constants (or null), or should expressions be also allowed? My
opinion is, although this is not a popular choice among existing
programming languages, any kind of expression that could be used in
variable initializer, should be allowed as default value.

The reasoning behind this is pretty simple. The main goal of default
parameter values, as for me, is to eliminate loads of boilerplate method
overloads and problems they bring during development. In almost all popular
languages today, for various reasons, if a developer wants to make default
parameter value runtime-evaluated, they just have to manually overload
method explicitly and pass runtime-evaluated expression as parameter, which
essentially is opposite to what default parameter values are needed for

On the other hand, runtime-evaluated default parameter values seem to be an
unpopular option in currently most popular languages, and I am wondering
maybe I am missing the point why, because for me, there virtually isn't any
reason to forbid them.

That's why I am reaching out to a Java community to gather opinions on this
topic.

PS: Regarding the way to implement default values, I decided to go with an
overload-based approach. This will help to preserve backward compatibility,
and also is much easier to implement then call-side parameter injection,
which reduces chances of unexpected errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240419/0da8f8ad/attachment.htm>

From duke at openjdk.org  Fri Apr 19 21:39:32 2024
From: duke at openjdk.org (xxDark)
Date: Fri, 19 Apr 2024 21:39:32 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
Message-ID: <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>

On Fri, 19 Apr 2024 15:49:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted code style changes in Vector

I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067312328

From davidalayachew at gmail.com  Fri Apr 19 21:43:29 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 17:43:29 -0400
Subject: Allowed type of expression as default value of method parameter
In-Reply-To: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>
References: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>
Message-ID: <CAA9v-_MqA9nkHuLJnA0U54ZaKW_+m-3VZ38czUVBTOM6AWb=fQ@mail.gmail.com>

Hello again,

Default parameter values, while maintaining backwards compatibility with
regards to overload selection, is a very difficult task. I don't see a way
that it can be done while maintaining backwards compatibility and without
turning all methods into virtual dispatch. Brian Goetz spoke of it in this
video. He is talking about named arguments at first, but then he addresses
default values later.

https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619

But yes, if it can be accomplished, it would be an incredibly valuable
feature to have. I would like it.

On Fri, Apr 19, 2024 at 4:49?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Greetings to the Java developers community.
>
> I am currently working on default parameter value support for java.
> Surprisingly, implementation of this feature turned out really simple and
> non-invasive, no more than a few hundred lines of new code.
>
> The question I am asking is, should default parameter values be only
> compile-time constants (or null), or should expressions be also allowed? My
> opinion is, although this is not a popular choice among existing
> programming languages, any kind of expression that could be used in
> variable initializer, should be allowed as default value.
>
> The reasoning behind this is pretty simple. The main goal of default
> parameter values, as for me, is to eliminate loads of boilerplate method
> overloads and problems they bring during development. In almost all popular
> languages today, for various reasons, if a developer wants to make default
> parameter value runtime-evaluated, they just have to manually overload
> method explicitly and pass runtime-evaluated expression as parameter, which
> essentially is opposite to what default parameter values are needed for
>
> On the other hand, runtime-evaluated default parameter values seem to be
> an unpopular option in currently most popular languages, and I am wondering
> maybe I am missing the point why, because for me, there virtually isn't any
> reason to forbid them.
>
> That's why I am reaching out to a Java community to gather opinions on
> this topic.
>
> PS: Regarding the way to implement default values, I decided to go with an
> overload-based approach. This will help to preserve backward compatibility,
> and also is much easier to implement then call-side parameter injection,
> which reduces chances of unexpected errors.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240419/4e82d8ff/attachment.htm>

From davidalayachew at gmail.com  Fri Apr 19 23:03:56 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 19 Apr 2024 19:03:56 -0400
Subject: Allowed type of expression as default value of method parameter
In-Reply-To: <CAP=Y=q8ya67OjcTF-++OEd_dPwcSJmvrFU__vRNOdtBt3GRDNg@mail.gmail.com>
References: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>
 <CAA9v-_MqA9nkHuLJnA0U54ZaKW_+m-3VZ38czUVBTOM6AWb=fQ@mail.gmail.com>
 <CAP=Y=q8ya67OjcTF-++OEd_dPwcSJmvrFU__vRNOdtBt3GRDNg@mail.gmail.com>
Message-ID: <CAA9v-_OQS+M73yMJe9Htdb990ZLSY8EQpcSDk-eX=V3jq3mQnQ@mail.gmail.com>

Unfortunately, I don't have too much more to say, as this is a subject I am
not very knowledgeable about. I only know enough to say what I have
already, as well as point to videos that discuss this subject.

As for your working implementation, link it if you are willing. Maybe some
more knowledgeable folks would have insight.

On Fri, Apr 19, 2024 at 6:02?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Hello! Named arguments are much more complex as they require both
> declaration-site and invocation-site manipulations. Just default values are
> much easier, if deal with them in a way kotlin does using compile-time
> overload generation. The only question I am thinking on right now is should
> they appear in AST (like default constructor), or added after ( during
> Enter phase or along with synthetic methods). Second option would be a bit
> harder to implement, while the first one took me just 100 lines of code (i
> have a working implementation right now).
>
> ??, 20 ???. 2024??. ? 00:44, David Alayachew <davidalayachew at gmail.com>:
>
>> Hello again,
>>
>> Default parameter values, while maintaining backwards compatibility with
>> regards to overload selection, is a very difficult task. I don't see a way
>> that it can be done while maintaining backwards compatibility and without
>> turning all methods into virtual dispatch. Brian Goetz spoke of it in this
>> video. He is talking about named arguments at first, but then he addresses
>> default values later.
>>
>> https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619
>>
>> But yes, if it can be accomplished, it would be an incredibly valuable
>> feature to have. I would like it.
>>
>> On Fri, Apr 19, 2024 at 4:49?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Greetings to the Java developers community.
>>>
>>> I am currently working on default parameter value support for java.
>>> Surprisingly, implementation of this feature turned out really simple and
>>> non-invasive, no more than a few hundred lines of new code.
>>>
>>> The question I am asking is, should default parameter values be only
>>> compile-time constants (or null), or should expressions be also allowed? My
>>> opinion is, although this is not a popular choice among existing
>>> programming languages, any kind of expression that could be used in
>>> variable initializer, should be allowed as default value.
>>>
>>> The reasoning behind this is pretty simple. The main goal of default
>>> parameter values, as for me, is to eliminate loads of boilerplate method
>>> overloads and problems they bring during development. In almost all popular
>>> languages today, for various reasons, if a developer wants to make default
>>> parameter value runtime-evaluated, they just have to manually overload
>>> method explicitly and pass runtime-evaluated expression as parameter, which
>>> essentially is opposite to what default parameter values are needed for
>>>
>>> On the other hand, runtime-evaluated default parameter values seem to be
>>> an unpopular option in currently most popular languages, and I am wondering
>>> maybe I am missing the point why, because for me, there virtually isn't any
>>> reason to forbid them.
>>>
>>> That's why I am reaching out to a Java community to gather opinions on
>>> this topic.
>>>
>>> PS: Regarding the way to implement default values, I decided to go with
>>> an overload-based approach. This will help to preserve backward
>>> compatibility, and also is much easier to implement then call-side
>>> parameter injection, which reduces chances of unexpected errors.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240419/4df49c40/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 00:11:58 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 03:11:58 +0300
Subject: Allowed type of expression as default value of method parameter
In-Reply-To: <CAP=Y=q_0pcSdJBp6hyanxmL5+6CugDMt2O94bNdaw78F2uBDTg@mail.gmail.com>
References: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>
 <CAA9v-_MqA9nkHuLJnA0U54ZaKW_+m-3VZ38czUVBTOM6AWb=fQ@mail.gmail.com>
 <CAP=Y=q8ya67OjcTF-++OEd_dPwcSJmvrFU__vRNOdtBt3GRDNg@mail.gmail.com>
 <CAA9v-_OQS+M73yMJe9Htdb990ZLSY8EQpcSDk-eX=V3jq3mQnQ@mail.gmail.com>
 <CAP=Y=q_v5tUbW5wATwQD5Cc4MFoLoa+tZ0jOoEh+udZ=iX8SQA@mail.gmail.com>
 <CAA9v-_NtCqkEedLH+X7Qiyb1TDZBF1OBYZVYrU0TYX8bqH2L7Q@mail.gmail.com>
 <CAP=Y=q9u9LnZ=eL2Q7KjoKAu4bQG8L0ESRFnsdC6Nx0JXDRzWg@mail.gmail.com>
 <CAP=Y=q-C3NA+OMaYMTHee3nyqWWadYgeBH79JVyNAw0u11tFWw@mail.gmail.com>
 <CAA9v-_MK1=LQaxtWJuW1-dFDAFUdVaWgTcVQ+yTBv4Czkn9r9w@mail.gmail.com>
 <CAP=Y=q_0pcSdJBp6hyanxmL5+6CugDMt2O94bNdaw78F2uBDTg@mail.gmail.com>
Message-ID: <CAP=Y=q98hy1U2pO_bP5afUMBg41AQ8GcAOvQ1jagkxRwvM-6Vw@mail.gmail.com>

Here is a link: https://github.com/Evemose/jdk/tree/default-parameter-values

On Sat, Apr 20, 2024, 03:11 ??-24 ????????? ?????? <rotan.olexandr at gmail.com>
wrote:

> Oh, thank you. I was wondering why "reply all" didn't work
>
> On Sat, Apr 20, 2024, 03:09 David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> You have sent it to only me again. You have not included the mailing list.
>>
>> If your email client is automatically only including me, you can manually
>> include all recipients you wanted to include. For example, you can just put
>> compiler-dev at openjdk.org into the TO section of the email.
>>
>> And btw, here is how our discussion on this thread looks to the outside
>> community. Click Next message on the top of the page.
>>
>> https://mail.openjdk.org/pipermail/compiler-dev/2024-April/026123.html
>>
>> And here is how our other discussion looks.
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/121787.html
>>
>> Notice how most of your responses are not visible? You can use the
>> archive to make sure that your reply is visible. Here is a list of all
>> mailing lists.
>>
>> https://mail.openjdk.org/mailman/listinfo
>>
>>
>> On Fri, Apr 19, 2024 at 8:04?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Here is a link:
>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>
>>> On Sat, Apr 20, 2024, 02:59 ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Oh, I see. Still learning about how this mailing stuff works. Thank you!
>>>>
>>>> On Sat, Apr 20, 2024, 02:58 David Alayachew <davidalayachew at gmail.com>
>>>> wrote:
>>>>
>>>>> You only responded to me. You must click Respond All, otherwise, only
>>>>> I will see it. Reply to my message again, but do Reply All.
>>>>>
>>>>> In fact, through all of the conversations we have been having, you
>>>>> have only been responding directly to me, which means that only I could see
>>>>> it. I did Reply All in my responses so that the rest of the community could
>>>>> see the discussion.
>>>>>
>>>>> Make sure to do Reply All from now on when sending anything on these
>>>>> mailing lists.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 7:32?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Here is a link:
>>>>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>>>>
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 02:04, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>> Unfortunately, I don't have too much more to say, as this is a
>>>>>>> subject I am not very knowledgeable about. I only know enough to say what I
>>>>>>> have already, as well as point to videos that discuss this subject.
>>>>>>>
>>>>>>> As for your working implementation, link it if you are willing.
>>>>>>> Maybe some more knowledgeable folks would have insight.
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024 at 6:02?PM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello! Named arguments are much more complex as they require both
>>>>>>>> declaration-site and invocation-site manipulations. Just default values are
>>>>>>>> much easier, if deal with them in a way kotlin does using compile-time
>>>>>>>> overload generation. The only question I am thinking on right now is should
>>>>>>>> they appear in AST (like default constructor), or added after ( during
>>>>>>>> Enter phase or along with synthetic methods). Second option would be a bit
>>>>>>>> harder to implement, while the first one took me just 100 lines of code (i
>>>>>>>> have a working implementation right now).
>>>>>>>>
>>>>>>>> ??, 20 ???. 2024??. ? 00:44, David Alayachew <
>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>
>>>>>>>>> Hello again,
>>>>>>>>>
>>>>>>>>> Default parameter values, while maintaining backwards
>>>>>>>>> compatibility with regards to overload selection, is a very difficult task.
>>>>>>>>> I don't see a way that it can be done while maintaining backwards
>>>>>>>>> compatibility and without turning all methods into virtual dispatch. Brian
>>>>>>>>> Goetz spoke of it in this video. He is talking about named arguments at
>>>>>>>>> first, but then he addresses default values later.
>>>>>>>>>
>>>>>>>>> https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619
>>>>>>>>>
>>>>>>>>> But yes, if it can be accomplished, it would be an incredibly
>>>>>>>>> valuable feature to have. I would like it.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 19, 2024 at 4:49?PM ??-24 ????????? ?????? <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings to the Java developers community.
>>>>>>>>>>
>>>>>>>>>> I am currently working on default parameter value support for
>>>>>>>>>> java. Surprisingly, implementation of this feature turned out really simple
>>>>>>>>>> and non-invasive, no more than a few hundred lines of new code.
>>>>>>>>>>
>>>>>>>>>> The question I am asking is, should default parameter values be
>>>>>>>>>> only compile-time constants (or null), or should expressions be also
>>>>>>>>>> allowed? My opinion is, although this is not a popular choice among
>>>>>>>>>> existing programming languages, any kind of expression that could be used
>>>>>>>>>> in variable initializer, should be allowed as default value.
>>>>>>>>>>
>>>>>>>>>> The reasoning behind this is pretty simple. The main goal of
>>>>>>>>>> default parameter values, as for me, is to eliminate loads of boilerplate
>>>>>>>>>> method overloads and problems they bring during development. In almost all
>>>>>>>>>> popular languages today, for various reasons, if a developer wants to make
>>>>>>>>>> default parameter value runtime-evaluated, they just have to manually
>>>>>>>>>> overload method explicitly and pass runtime-evaluated expression as
>>>>>>>>>> parameter, which essentially is opposite to what default parameter values
>>>>>>>>>> are needed for
>>>>>>>>>>
>>>>>>>>>> On the other hand, runtime-evaluated default parameter values
>>>>>>>>>> seem to be an unpopular option in currently most popular languages, and I
>>>>>>>>>> am wondering maybe I am missing the point why, because for me, there
>>>>>>>>>> virtually isn't any reason to forbid them.
>>>>>>>>>>
>>>>>>>>>> That's why I am reaching out to a Java community to gather
>>>>>>>>>> opinions on this topic.
>>>>>>>>>>
>>>>>>>>>> PS: Regarding the way to implement default values, I decided to
>>>>>>>>>> go with an overload-based approach. This will help to preserve backward
>>>>>>>>>> compatibility, and also is much easier to implement then call-side
>>>>>>>>>> parameter injection, which reduces chances of unexpected errors.
>>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240420/67b2c991/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 00:13:15 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 03:13:15 +0300
Subject: Allowed type of expression as default value of method parameter
In-Reply-To: <CAP=Y=q_0pcSdJBp6hyanxmL5+6CugDMt2O94bNdaw78F2uBDTg@mail.gmail.com>
References: <CAP=Y=q_tssir-M8-0UuqS=yaYaqMaKNsxrcVsiNTiLDnuPFkyg@mail.gmail.com>
 <CAA9v-_MqA9nkHuLJnA0U54ZaKW_+m-3VZ38czUVBTOM6AWb=fQ@mail.gmail.com>
 <CAP=Y=q8ya67OjcTF-++OEd_dPwcSJmvrFU__vRNOdtBt3GRDNg@mail.gmail.com>
 <CAA9v-_OQS+M73yMJe9Htdb990ZLSY8EQpcSDk-eX=V3jq3mQnQ@mail.gmail.com>
 <CAP=Y=q_v5tUbW5wATwQD5Cc4MFoLoa+tZ0jOoEh+udZ=iX8SQA@mail.gmail.com>
 <CAA9v-_NtCqkEedLH+X7Qiyb1TDZBF1OBYZVYrU0TYX8bqH2L7Q@mail.gmail.com>
 <CAP=Y=q9u9LnZ=eL2Q7KjoKAu4bQG8L0ESRFnsdC6Nx0JXDRzWg@mail.gmail.com>
 <CAP=Y=q-C3NA+OMaYMTHee3nyqWWadYgeBH79JVyNAw0u11tFWw@mail.gmail.com>
 <CAA9v-_MK1=LQaxtWJuW1-dFDAFUdVaWgTcVQ+yTBv4Czkn9r9w@mail.gmail.com>
 <CAP=Y=q_0pcSdJBp6hyanxmL5+6CugDMt2O94bNdaw78F2uBDTg@mail.gmail.com>
Message-ID: <CAP=Y=q_dqDehNNp91EfUn4f3y+oUQQagHsBJ6zPnS_iHOTEmpw@mail.gmail.com>

Here is a link: https://github.com/Evemose/jdk/tree/default-parameter-values

On Sat, Apr 20, 2024, 03:11 ??-24 ????????? ?????? <rotan.olexandr at gmail.com>
wrote:

> Oh, thank you. I was wondering why "reply all" didn't work
>
> On Sat, Apr 20, 2024, 03:09 David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> You have sent it to only me again. You have not included the mailing list.
>>
>> If your email client is automatically only including me, you can manually
>> include all recipients you wanted to include. For example, you can just put
>> compiler-dev at openjdk.org into the TO section of the email.
>>
>> And btw, here is how our discussion on this thread looks to the outside
>> community. Click Next message on the top of the page.
>>
>> https://mail.openjdk.org/pipermail/compiler-dev/2024-April/026123.html
>>
>> And here is how our other discussion looks.
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/121787.html
>>
>> Notice how most of your responses are not visible? You can use the
>> archive to make sure that your reply is visible. Here is a list of all
>> mailing lists.
>>
>> https://mail.openjdk.org/mailman/listinfo
>>
>>
>> On Fri, Apr 19, 2024 at 8:04?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Here is a link:
>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>
>>> On Sat, Apr 20, 2024, 02:59 ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Oh, I see. Still learning about how this mailing stuff works. Thank you!
>>>>
>>>> On Sat, Apr 20, 2024, 02:58 David Alayachew <davidalayachew at gmail.com>
>>>> wrote:
>>>>
>>>>> You only responded to me. You must click Respond All, otherwise, only
>>>>> I will see it. Reply to my message again, but do Reply All.
>>>>>
>>>>> In fact, through all of the conversations we have been having, you
>>>>> have only been responding directly to me, which means that only I could see
>>>>> it. I did Reply All in my responses so that the rest of the community could
>>>>> see the discussion.
>>>>>
>>>>> Make sure to do Reply All from now on when sending anything on these
>>>>> mailing lists.
>>>>>
>>>>> On Fri, Apr 19, 2024 at 7:32?PM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Here is a link:
>>>>>> https://github.com/Evemose/jdk/tree/default-parameter-values
>>>>>>
>>>>>>
>>>>>> ??, 20 ???. 2024??. ? 02:04, David Alayachew <
>>>>>> davidalayachew at gmail.com>:
>>>>>>
>>>>>>> Unfortunately, I don't have too much more to say, as this is a
>>>>>>> subject I am not very knowledgeable about. I only know enough to say what I
>>>>>>> have already, as well as point to videos that discuss this subject.
>>>>>>>
>>>>>>> As for your working implementation, link it if you are willing.
>>>>>>> Maybe some more knowledgeable folks would have insight.
>>>>>>>
>>>>>>> On Fri, Apr 19, 2024 at 6:02?PM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello! Named arguments are much more complex as they require both
>>>>>>>> declaration-site and invocation-site manipulations. Just default values are
>>>>>>>> much easier, if deal with them in a way kotlin does using compile-time
>>>>>>>> overload generation. The only question I am thinking on right now is should
>>>>>>>> they appear in AST (like default constructor), or added after ( during
>>>>>>>> Enter phase or along with synthetic methods). Second option would be a bit
>>>>>>>> harder to implement, while the first one took me just 100 lines of code (i
>>>>>>>> have a working implementation right now).
>>>>>>>>
>>>>>>>> ??, 20 ???. 2024??. ? 00:44, David Alayachew <
>>>>>>>> davidalayachew at gmail.com>:
>>>>>>>>
>>>>>>>>> Hello again,
>>>>>>>>>
>>>>>>>>> Default parameter values, while maintaining backwards
>>>>>>>>> compatibility with regards to overload selection, is a very difficult task.
>>>>>>>>> I don't see a way that it can be done while maintaining backwards
>>>>>>>>> compatibility and without turning all methods into virtual dispatch. Brian
>>>>>>>>> Goetz spoke of it in this video. He is talking about named arguments at
>>>>>>>>> first, but then he addresses default values later.
>>>>>>>>>
>>>>>>>>> https://youtu.be/mE4iTvxLTC4?si=lGQ8Y4Oo_YRVXrvr&t=619
>>>>>>>>>
>>>>>>>>> But yes, if it can be accomplished, it would be an incredibly
>>>>>>>>> valuable feature to have. I would like it.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 19, 2024 at 4:49?PM ??-24 ????????? ?????? <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings to the Java developers community.
>>>>>>>>>>
>>>>>>>>>> I am currently working on default parameter value support for
>>>>>>>>>> java. Surprisingly, implementation of this feature turned out really simple
>>>>>>>>>> and non-invasive, no more than a few hundred lines of new code.
>>>>>>>>>>
>>>>>>>>>> The question I am asking is, should default parameter values be
>>>>>>>>>> only compile-time constants (or null), or should expressions be also
>>>>>>>>>> allowed? My opinion is, although this is not a popular choice among
>>>>>>>>>> existing programming languages, any kind of expression that could be used
>>>>>>>>>> in variable initializer, should be allowed as default value.
>>>>>>>>>>
>>>>>>>>>> The reasoning behind this is pretty simple. The main goal of
>>>>>>>>>> default parameter values, as for me, is to eliminate loads of boilerplate
>>>>>>>>>> method overloads and problems they bring during development. In almost all
>>>>>>>>>> popular languages today, for various reasons, if a developer wants to make
>>>>>>>>>> default parameter value runtime-evaluated, they just have to manually
>>>>>>>>>> overload method explicitly and pass runtime-evaluated expression as
>>>>>>>>>> parameter, which essentially is opposite to what default parameter values
>>>>>>>>>> are needed for
>>>>>>>>>>
>>>>>>>>>> On the other hand, runtime-evaluated default parameter values
>>>>>>>>>> seem to be an unpopular option in currently most popular languages, and I
>>>>>>>>>> am wondering maybe I am missing the point why, because for me, there
>>>>>>>>>> virtually isn't any reason to forbid them.
>>>>>>>>>>
>>>>>>>>>> That's why I am reaching out to a Java community to gather
>>>>>>>>>> opinions on this topic.
>>>>>>>>>>
>>>>>>>>>> PS: Regarding the way to implement default values, I decided to
>>>>>>>>>> go with an overload-based approach. This will help to preserve backward
>>>>>>>>>> compatibility, and also is much easier to implement then call-side
>>>>>>>>>> parameter injection, which reduces chances of unexpected errors.
>>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240420/d58ea201/attachment.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 20:43:31 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 23:43:31 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>
Message-ID: <CAP=Y=q_F3xf3mCY2Q_VY0oghye54juixe7hXrJ-sipGFLCVZ_g@mail.gmail.com>

I agree with the point made in the FAQ about the popularity of such
problems. That said, I don't think that it is that unpopular to be ignored.

Regarding Map.values(), this is the case, but, In my experience, one of the
main advantages of using TreeMultiset was O(long n) modification
complexity. Collection views returned by map, for obvious reasons, forbid
modification. Also, correct me if I`m wrong, but while TreeMultiset is an
unpopular requirement, it is at least as popular as TreeSet.

Also, I may not have a full view of how such Bag collections can be
implemented and used, however, I feel like there could be more to it.

I am not insisting on anything, I just feel that if there is someone (like
me lol) who is willing to take on full development and integration cycle,
there aren't much reason to reject such enhancements.

??, 20 ???. 2024??. ? 23:31, David Alayachew <davidalayachew at gmail.com>:

> Your Bag suggestion has been asked so frequently that there is an FAQ
> entry in the official Java Docs.
>
>
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
>
> On Sat, Apr 20, 2024 at 4:25?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> In this letter I would like to express some of my thoughts regarding the
>> potential Multiset interface.
>>
>> I, personally, have encountered a few situations where such an interface
>> could come in handy, mostly when I needed an ordered collection that
>> permits duplicates. That time I used guava`s TreeMultiset, but I think Java
>> itself should have such a collection in its std library. While it is not a
>> very common problem, there are still a bunch of use cases where such things
>> could come in handy.
>>
>> I am willing to take on development of such thing, but there are a few
>> concerns about Multiset:
>>
>> 1. Is there any other use for this besides ordered collection that
>> permits duplicates? I can't remember anything else from the top of my head.
>>
>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>> class hierarchy, while not being directly connected. I think introducing
>> any other ordered collection will require some refactoring of existing
>> collection interfaces (for example extract SortedCollection from SortedSet,
>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>> code, this would be the right decision, but I feel like this will be a very
>> complex task to accomplish.
>>
>> 3. Maybe there should be few versions of Tree collection (for example,
>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>> have some expirience implementing both, but is it really needed in standard
>> library?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240420/15e749a2/attachment-0001.htm>

From rotan.olexandr at gmail.com  Sat Apr 20 20:45:00 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sat, 20 Apr 2024 23:45:00 +0300
Subject: Bag (Multiset) Collection
In-Reply-To: <CAP=Y=q9_uBTOJuhMUFQi5rSSdRQtuHQahXit3j1L9eYJd9EZ0g@mail.gmail.com>
References: <CAP=Y=q9bGZH3Jm=L4CXEmbgjajFh76ySv5_E2+m7QG=-=D+wTQ@mail.gmail.com>
 <CAA9v-_MJvipucEQnPHrMzm3r971Zb4NbdxrZMCTAO8ouK9dN2Q@mail.gmail.com>
 <CAP=Y=q_F3xf3mCY2Q_VY0oghye54juixe7hXrJ-sipGFLCVZ_g@mail.gmail.com>
 <CAP=Y=q9_uBTOJuhMUFQi5rSSdRQtuHQahXit3j1L9eYJd9EZ0g@mail.gmail.com>
Message-ID: <CAP=Y=q92CRKGpGLLfNXtnH2wuT1v6AYc_r8QFUfSyZUfgStidQ@mail.gmail.com>

I am terribly sorry, last message went to wrong mailing list

??, 20 ???. 2024??. ? 23:44, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> I agree with the point made in the FAQ about the popularity of such
> problems. That said, I don't think that it is that unpopular to be ignored.
>
> Regarding Map.values(), this is the case, but, In my experience, one of
> the main advantages of using TreeMultiset was O(long n) modification
> complexity. Collection views returned by map, for obvious reasons, forbid
> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
> unpopular requirement, it is at least as popular as TreeSet.
>
> Also, I may not have a full view of how such Bag collections can be
> implemented and used, however, I feel like there could be more to it.
>
> I am not insisting on anything, I just feel that if there is someone (like
> me lol) who is willing to take on full development and integration cycle,
> there aren't much reason to reject such enhancements.
>
> ??, 20 ???. 2024??. ? 23:43, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> I agree with the point made in the FAQ about the popularity of such
>> problems. That said, I don't think that it is that unpopular to be ignored.
>>
>> Regarding Map.values(), this is the case, but, In my experience, one of
>> the main advantages of using TreeMultiset was O(long n) modification
>> complexity. Collection views returned by map, for obvious reasons, forbid
>> modification. Also, correct me if I`m wrong, but while TreeMultiset is an
>> unpopular requirement, it is at least as popular as TreeSet.
>>
>> Also, I may not have a full view of how such Bag collections can be
>> implemented and used, however, I feel like there could be more to it.
>>
>> I am not insisting on anything, I just feel that if there is someone
>> (like me lol) who is willing to take on full development and integration
>> cycle, there aren't much reason to reject such enhancements.
>>
>> ??, 20 ???. 2024??. ? 23:31, David Alayachew <davidalayachew at gmail.com>:
>>
>>> Your Bag suggestion has been asked so frequently that there is an FAQ
>>> entry in the official Java Docs.
>>>
>>>
>>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/doc-files/coll-designfaq.html#a3
>>>
>>> On Sat, Apr 20, 2024 at 4:25?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> In this letter I would like to express some of my thoughts regarding
>>>> the potential Multiset interface.
>>>>
>>>> I, personally, have encountered a few situations where such an
>>>> interface could come in handy, mostly when I needed an ordered collection
>>>> that permits duplicates. That time I used guava`s TreeMultiset, but I think
>>>> Java itself should have such a collection in its std library. While it is
>>>> not a very common problem, there are still a bunch of use cases where such
>>>> things could come in handy.
>>>>
>>>> I am willing to take on development of such thing, but there are a few
>>>> concerns about Multiset:
>>>>
>>>> 1. Is there any other use for this besides ordered collection that
>>>> permits duplicates? I can't remember anything else from the top of my head.
>>>>
>>>> 2. Guava's TreeMultiset class hierarchy pretty much imitates TreeSet
>>>> class hierarchy, while not being directly connected. I think introducing
>>>> any other ordered collection will require some refactoring of existing
>>>> collection interfaces (for example extract SortedCollection from SortedSet,
>>>> Navigable Collection from NavigableSet etc.). From the perspective of clean
>>>> code, this would be the right decision, but I feel like this will be a very
>>>> complex task to accomplish.
>>>>
>>>> 3. Maybe there should be few versions of Tree collection (for example,
>>>> for regular tasks red-black tree and B-Tree for large amounts of data). I
>>>> have some expirience implementing both, but is it really needed in standard
>>>> library?
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240420/f4483004/attachment.htm>

From hgreule at openjdk.org  Sun Apr 21 08:22:38 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Sun, 21 Apr 2024 08:22:38 GMT
Subject: Withdrawn: 8325936: jshell - crash on 'new Object().""'
In-Reply-To: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
References: <mmk7Z4PwD60HiIIDF7CyLwT_AuebEU861BQ7doT9jx4=.048e01de-431f-4693-acd7-01e8a5a6dc32@github.com>
Message-ID: <qcGLtgDOR-Ni65WoPDOXTQ-guTXkl-EXFTV7BrE7e10=.aa944f61-9ffa-44f9-9bd6-330073401471@github.com>

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

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

This pull request has been closed without being integrated.

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

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

From rotan.olexandr at gmail.com  Sun Apr 21 19:13:26 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Sun, 21 Apr 2024 22:13:26 +0300
Subject: Issues with modifying JCTree classes
Message-ID: <CAP=Y=q_FSmPaUO6NtDOC6LqK6-4mn2ynv=nXfBMTyKjpzHp0gg@mail.gmail.com>

Greetings to a community. Not sure if that's the right place to ask this
question, but the internet doesn't seem to have an answer to my question.

I am having issues with modifying JCTree subclasses structure, That
involves introducing new members or changing signatures of existing. While
there aren't any syntax errors in code, make refuses to compile the project
indicating that it can't find a symbol.

In fact, I also have encountered the same issue when trying to modify the
constructor of Symbol subclasses.

If that's important, I am building using x86-64 windows jdk 22 and using
default make target. If code is relevant, I could also provide a link to
the repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240421/0da0ad83/attachment-0001.htm>

From jlahoda at openjdk.org  Mon Apr 22 14:20:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 Apr 2024 14:20:29 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v2]
In-Reply-To: <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
 <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>
Message-ID: <KHsTUDUyC32UnQ6bgcsMxfrdUpmrMy5Y42E-sbuHv7M=.295b9d20-d3d7-47c2-a681-a13c5f9c850a@github.com>

On Thu, 18 Apr 2024 14:44:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
>> 
>> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding regression test

The solution seems reasonable to me. Maybe a comment in the `visitBlock` could help, but the a test may be enough.

Although this is probably not critical, I don't see a good reason to not include it - this should help with any deeply nested blocks, not only for synchronized statements.

Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18832#pullrequestreview-2014902453

From vromero at openjdk.org  Mon Apr 22 15:02:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 15:02:28 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v2]
In-Reply-To: <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
 <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>
Message-ID: <GfS2YRpG82cE-HDykUZ8gaFJmLDG30tlcptrFuR8C2k=.3dfb32fa-8b68-42b1-a41f-8c912f3a5f75@github.com>

On Thu, 18 Apr 2024 14:44:19 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
>> 
>> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding regression test

sure I will add a comment to `visitBlock`

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

PR Comment: https://git.openjdk.org/jdk/pull/18832#issuecomment-2069781934

From vromero at openjdk.org  Mon Apr 22 15:20:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 15:20:56 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v3]
In-Reply-To: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
Message-ID: <YNatn63_L1jgRftltzYc_Hskun7QYq6vGlgAy9JViTk=.6f60f90b-6760-48a3-93f8-5ebe681819fe@github.com>

> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
> 
> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
> 
> TIA

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

  adding a comment to Gen::visitBlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18832/files
  - new: https://git.openjdk.org/jdk/pull/18832/files/24c7e37c..59f77da7

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

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

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

From vromero at openjdk.org  Mon Apr 22 15:28:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 15:28:57 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v4]
In-Reply-To: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
Message-ID: <z-nvDcabEkKB9ikU2oGuPgwjgZzZ0LC6nxom2XQOeog=.6da08847-ccca-44b7-91cc-ef6ebcc856d6@github.com>

> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
> 
> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
> 
> TIA

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

  updating the comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18832/files
  - new: https://git.openjdk.org/jdk/pull/18832/files/59f77da7..48d01555

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

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

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

From vromero at openjdk.org  Mon Apr 22 16:34:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 16:34:34 GMT
Subject: Integrated: 8322992: Javac fails with StackOverflowError when
 compiling deeply nested synchronized blocks
In-Reply-To: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
Message-ID: <pzoX647ygxSVmo5mAxDbjhgC2TfJ-RgtpLq8WIqpQmc=.95e15aef-3488-49c8-93b8-88fcf47fce17@github.com>

On Thu, 18 Apr 2024 01:24:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> This is a fix to a memory issue but I'm not totally sure we should apply it. Basically the issue here is that javac is failing because of lack of resources for a very deeply nested sequence of blocks. I was tracing the root cause and I found the fix for: [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) to be the one starting from which the stack overflow issue started to happen. Basically method Gen::visitBlock as refactored by fix for [JDK-8291769](https://bugs.openjdk.org/browse/JDK-8291769) occupies more memory than before, at execution time space for local variables is reserved regardless and after the mentioned fix the method has more local variables.
> 
> This refactoring proposed here fixes the stack overflow for the reproductor provided in the bug entry but it could be that if we add more nested blocks then we can make the compiler fail at some point. So the merit of this fix is arguable. Still the bug could be valid for the reporter so let's discuss if this fix should be pushed or not.
> 
> TIA

This pull request has now been integrated.

Changeset: 0b9350e8
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b9350e8b619bc556f36652cde6f73211be5b85b
Stats:     1229 lines in 2 files changed: 1211 ins; 15 del; 3 mod

8322992: Javac fails with StackOverflowError when compiling deeply nested synchronized blocks

Reviewed-by: jlahoda

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

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

From jonathan.gibbons at oracle.com  Mon Apr 22 17:14:42 2024
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 10:14:42 -0700
Subject: Issues with modifying JCTree classes
In-Reply-To: <CAP=Y=q_FSmPaUO6NtDOC6LqK6-4mn2ynv=nXfBMTyKjpzHp0gg@mail.gmail.com>
References: <CAP=Y=q_FSmPaUO6NtDOC6LqK6-4mn2ynv=nXfBMTyKjpzHp0gg@mail.gmail.com>
Message-ID: <3568b01c-32ed-413a-b088-3682cfe10b92@oracle.com>

In general, any code in the `jdk.compiler` module must be compilable by 
the "previous" release, meaning the latest available GA release.? This 
is a fundamental requirement of the bootstrap process for building JDK.

-- Jon

On 4/21/24 12:13 PM, ??-24 ????????? ?????? wrote:
> Greetings to a community. Not sure if that's?the right place to ask 
> this question, but the internet doesn't?seem to have an answer to my 
> question.
>
> I am having issues with modifying JCTree subclasses structure, That 
> involves introducing new members?or changing signatures of existing. 
> While there aren't?any syntax errors in code, make refuses to compile 
> the project indicating that it can't?find a symbol.
>
> In fact, I also have?encountered the same issue when trying?to modify 
> the constructor of Symbol subclasses.
>
> If that's important, I am building using x86-64 windows jdk 22 and 
> using default make target. If code is relevant, I could also provide a 
> link to the repository.

From duke at openjdk.org  Mon Apr 22 20:39:34 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 22 Apr 2024 20:39:34 GMT
Subject: Integrated: 8329717: Missing `@since` tags in elements in
 DocumentationTool and Taglet
In-Reply-To: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
References: <sae2j5_gFtbHwxGmLOcq-lgULN__rRexQCLENmaWKLc=.728b447f-43d6-4656-a1b4-99f46fa50fb0@github.com>
Message-ID: <55hGiIOZnYdpgk2Jm4Jc-v1Auqh4U7B3WrJgTmoZnkg=.8362875e-9d0a-48a8-9d06-8c25eaf76c96@github.com>

On Fri, 5 Apr 2024 00:02:00 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> In this PR I added an `@since` tag to SNIPPET_PATH and isBlockTag() as they were added in later versions
> 
> - SNIPPET_PATH was added in JDK 18 [here](https://github.com/openjdk/jdk/commit/0fc47e99d20a1ee886df878f1302769bdd913aab#diff-8f73114f8b0d0d5229231541d5583382c8e8d33147e285f3d90ed8801ce9228bR192)
> 
> - isBlockTag() was added in JDK 15 [here](https://github.com/openjdk/jdk/commit/3c0e2b4e16d8fb2f96741bc8d4188aa47f58dd15#diff-3ee1b6e2a11b201a39ce3f2ac14ea9832900d8a3a581bf26577064173d0c9082R101)
> 
> This is similar to #18032

This pull request has now been integrated.

Changeset: 83c74d73
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83c74d7307e258441abb171552e953f1c6d9b98a
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8329717: Missing `@since` tags in elements in DocumentationTool and Taglet

Reviewed-by: prappo

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

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

From vromero at openjdk.org  Mon Apr 22 22:48:54 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 22 Apr 2024 22:48:54 GMT
Subject: RFR: 8305007: Within-lambda subclass of local class using method
 param causes compiler crash [v2]
In-Reply-To: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>
References: <k2fPgixMUYsKFz9SHC0PBkmwvWiOQwa6D33-XPuEH88=.4182054f-e102-4bfe-83d8-33bcb46ed06b@github.com>
Message-ID: <QLkpNUGBSje86BuQLuDawEBVncOshgbHkTPJK0Zu90I=.1b6fdb94-132a-47ae-8fc1-1affdd8ae309@github.com>

> javac is crashing while compiling code like:
> 
> 
> public abstract class CompilerCrashLambdaPlusLocalClass {
>     public abstract void consume(Runnable r);
> 
>     public void doThing(String parameter) {
>         class LocalClass {
>             @Override
>             public String toString() {
>                 return parameter;
>             }
>         }
>         consume(() -> {
>             class LambdaLocalClass extends LocalClass {}
>             new LocalClass();
>         });
>     }
> }
> 
> the reason for the issue is that the mappings for captured variables created by LambdaToMethod are not copying the `adr`, local address, field of the original VarSymbol it is mapping. Later on during code generation an assertion was being triggered due to a variable with an `adr < 0` this patch fixes this issue.
> 
> Thanks,
> Vicente

Vicente Romero 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 five additional commits since the last revision:

 - Merge branch 'master' into JDK-8305007
 - jans proposal
 - keeping address of original VarSymbol
 - Merge branch 'master' into JDK-8305007
 - 8305007: Within-lambda subclass of local class using method param causes compiler crash

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17151/files
  - new: https://git.openjdk.org/jdk/pull/17151/files/e956528d..7352fd3c

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

  Stats: 670431 lines in 8381 files changed: 143259 ins; 163664 del; 363508 mod
  Patch: https://git.openjdk.org/jdk/pull/17151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17151/head:pull/17151

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

From fferrari at openjdk.org  Mon Apr 22 22:58:32 2024
From: fferrari at openjdk.org (Francisco Ferrari Bihurriet)
Date: Mon, 22 Apr 2024 22:58:32 GMT
Subject: RFR: 8322992: Javac fails with StackOverflowError when compiling
 deeply nested synchronized blocks [v2]
In-Reply-To: <GfS2YRpG82cE-HDykUZ8gaFJmLDG30tlcptrFuR8C2k=.3dfb32fa-8b68-42b1-a41f-8c912f3a5f75@github.com>
References: <JgQXeF0vrxbIrOXLx35V50aqVHgM7yYOEseZOQXLyKk=.51b9cee9-75b3-41e5-bc1f-dcc8056d1058@github.com>
 <hQ3A5QxdqYU3NtpdH_7HG3KY0rEQXl0KjfP9MLj9TbI=.1c219ea1-f6dd-422f-af75-e69559755410@github.com>
 <GfS2YRpG82cE-HDykUZ8gaFJmLDG30tlcptrFuR8C2k=.3dfb32fa-8b68-42b1-a41f-8c912f3a5f75@github.com>
Message-ID: <ydIV4-dV19CNXShFTSSE3l4Lju2v6Gr2CFqpRE8cJ5w=.5b447269-072b-44f7-8aef-c430c55333ca@github.com>

On Mon, 22 Apr 2024 14:59:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adding regression test
>
> sure I will add a comment to `visitBlock`

Hi @vicente-romero-oracle, it looks like the new `SOEDeeplyNestedBlocksTest` is not passing in GitHub actions' [execution of langtools/tier1 for linux-x86](https://github.com/vicente-romero-oracle/jdk/actions/runs/8786696145/job/24111450455#step:9:17883).

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

PR Comment: https://git.openjdk.org/jdk/pull/18832#issuecomment-2071086879

From rotan.olexandr at gmail.com  Mon Apr 22 23:23:42 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 02:23:42 +0300
Subject: Extension methods
Message-ID: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>

Subject: Proposal for Introducing Extension Methods to Java

Dear Java Development Team,

I hope this email finds you all in good spirits. I am writing to propose
the integration of extension methods into the Java programming language, a
feature that I believe holds considerable promise in enhancing code
readability and maintainability.

Extension methods offer a means to extend the functionality of existing
classes in a manner that aligns with Java's principles of static typing and
object-oriented design. The proposed syntax, exemplified as follows:

public static void extensionMethod(extends String s) { ... }

adheres to established conventions while providing a concise and intuitive
means of extending class behavior. Notably, the use of the `extends`
keyword preceding the type parameter clearly denotes the class to be
extended, while the method itself is declared as a static member of a class.

I wish to emphasize several advantages of extension methods over
traditional utility functions. Firstly, extension methods offer a more
cohesive approach to code organization by associating functionality
directly with the class it extends. This promotes code clarity and reduces
cognitive overhead for developers, particularly when working with complex
codebases.

Secondly, extension methods enhance code discoverability and usability by
integrating seamlessly into the class they extend. This integration allows
developers to leverage IDE features such as auto-completion and
documentation tooltips, thereby facilitating more efficient code
exploration and utilization.

Lastly, extension methods promote code reusability without the need for
subclassing or inheritance, thereby mitigating the risks associated with
tight coupling and inheritance hierarchies. This modularity encourages a
more flexible and adaptable codebase, conducive to long-term
maintainability and scalability.

In light of these benefits, I believe that the integration of extension
methods into Java would represent a significant step forward for the
language, aligning it more closely with modern programming paradigms while
retaining its core strengths.

I am eager to discuss this proposal further and collaborate with you all on
its implementation. Your insights and feedback would be invaluable in
shaping the future direction of Java development.

Thank you for considering this proposal. I look forward to our discussion.

The draft implementation can be found in the following branch of the
repository: https://github.com/Evemose/jdk/tree/extension-methods. I am new
to Java compiler development, so any tips or remarks about what I have done
in the wrong way or in the wrong place. I will add complete test coverage a
bit later, but for now, there is "jdk" archive in the root directory of
repo, which contains built in jdk for windows x86-64. If someone is willing
to participate in testing as user, I would appreciate any help.

Best regards

PS: Note about internal implementation: it introduces a new flag -
EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
bit in a long value type that has not been taken by flags. Not sure what
the compiler development community should do about this, but it feels like
it could be an obstacle to new features that might be introduced later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/377aa57c/attachment.htm>

From rotan.olexandr at gmail.com  Tue Apr 23 00:00:59 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 03:00:59 +0300
Subject: Extensions JDK
Message-ID: <CAP=Y=q-JXjQYZw3v+KUHUXXa3Jfq3BzbHY-nVKoiYgew=Lb4dA@mail.gmail.com>

Unfortunately, Github doesn't allow to upload files larger then 25 mb, so I
left link to jdk in readme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/769715a4/attachment.htm>

From ethan at mccue.dev  Tue Apr 23 04:00:57 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 23 Apr 2024 00:00:57 -0400
Subject: Extension methods
In-Reply-To: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
References: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
Message-ID: <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>

This subject has been addressed publicly by the language team at
various points. These are just a few I found, I'm sure there is more
elaboration out there.

Implementation choices aside, the API of "add a static method and mark it
as an "extension method", call like instance method" seems to have been
rejected.

> C# extension methods have some very serious drawbacks compared to Java's
default methods (for example, poor reflective discoverability, poor
discoverability through documentation, not overrideable, require ad-hoc
conflict-management rules)

https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio

> What I believe you are hoping for is the ability to "monkey-patch" a
method into a class you do not control, but Java does not give you that (by
design; it was considered and rejected.)

https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class


On Mon, Apr 22, 2024 at 7:24?PM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Subject: Proposal for Introducing Extension Methods to Java
>
> Dear Java Development Team,
>
> I hope this email finds you all in good spirits. I am writing to propose
> the integration of extension methods into the Java programming language, a
> feature that I believe holds considerable promise in enhancing code
> readability and maintainability.
>
> Extension methods offer a means to extend the functionality of existing
> classes in a manner that aligns with Java's principles of static typing and
> object-oriented design. The proposed syntax, exemplified as follows:
>
> public static void extensionMethod(extends String s) { ... }
>
> adheres to established conventions while providing a concise and intuitive
> means of extending class behavior. Notably, the use of the `extends`
> keyword preceding the type parameter clearly denotes the class to be
> extended, while the method itself is declared as a static member of a class.
>
> I wish to emphasize several advantages of extension methods over
> traditional utility functions. Firstly, extension methods offer a more
> cohesive approach to code organization by associating functionality
> directly with the class it extends. This promotes code clarity and reduces
> cognitive overhead for developers, particularly when working with complex
> codebases.
>
> Secondly, extension methods enhance code discoverability and usability by
> integrating seamlessly into the class they extend. This integration allows
> developers to leverage IDE features such as auto-completion and
> documentation tooltips, thereby facilitating more efficient code
> exploration and utilization.
>
> Lastly, extension methods promote code reusability without the need for
> subclassing or inheritance, thereby mitigating the risks associated with
> tight coupling and inheritance hierarchies. This modularity encourages a
> more flexible and adaptable codebase, conducive to long-term
> maintainability and scalability.
>
> In light of these benefits, I believe that the integration of extension
> methods into Java would represent a significant step forward for the
> language, aligning it more closely with modern programming paradigms while
> retaining its core strengths.
>
> I am eager to discuss this proposal further and collaborate with you all
> on its implementation. Your insights and feedback would be invaluable in
> shaping the future direction of Java development.
>
> Thank you for considering this proposal. I look forward to our discussion.
>
> The draft implementation can be found in the following branch of the
> repository: https://github.com/Evemose/jdk/tree/extension-methods. I am
> new to Java compiler development, so any tips or remarks about what I have
> done in the wrong way or in the wrong place. I will add complete test
> coverage a bit later, but for now, there is "jdk" archive in the root
> directory of repo, which contains built in jdk for windows x86-64. If
> someone is willing to participate in testing as user, I would appreciate
> any help.
>
> Best regards
>
> PS: Note about internal implementation: it introduces a new flag -
> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
> bit in a long value type that has not been taken by flags. Not sure what
> the compiler development community should do about this, but it feels like
> it could be an obstacle to new features that might be introduced later.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/e0fb8eb4/attachment-0001.htm>

From dholmes at openjdk.org  Tue Apr 23 07:07:31 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Apr 2024 07:07:31 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
Message-ID: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>

On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.

LGTM

Thanks

test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 1:

> 1: /*

There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2016422206
PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1575750313

From rotan.olexandr at gmail.com  Tue Apr 23 07:35:17 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 10:35:17 +0300
Subject: Extension methods
In-Reply-To: <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>
References: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
 <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>
Message-ID: <CAP=Y=q-G-ZmT0Hc-OxopB_up6nZfV3HefwOmN=-qsKnbYT5MQg@mail.gmail.com>

Well that's just really frustrating for me.

I am pretty sure the point I will provide as advantages has already been
brought up here numerous times, but I will take some time and would
appreciate it if someone from API designers, who once rejected this
proposal, would spare some time to discuss this topic with me.

1. "Poor reflective discoverability" essentially means extension methods
are not accessible when inspecting class members. That is not some
inherent issue of this feature, this is just the way it should be. I'm
not really sure if there is someone who has ever been hurt by this, besides
maybe some parser-based solutions, but let's be honest, this is a:
solvable, b: ridiculously exotic to consider.

2. Documentation accessibility is a strange point for me to be fair. Every
IDE nowadays is capable of fetching the right documentation, as well as
explicitly mentioning where the method comes from, as it is done in C#,
kotlin, swift and many other languages. I don't think anyone has ever heard
complaints about poor documentation of LinQ. Unless someone is writing in
notepad, this is poorly applicable.

3. Not overridable. Should they be? I don't think there is a way to achieve
some kind of "polymorphic" extensions, and I don't think there should be:
extension methods should provide polymorphic target handling, floow LSP
etc., not the other way around.

4. C# extension methods indeed have some very serious drawbacks compared to
Java's, but doesn't this also go the other way around? Canonical utility
functions breach object-oriented code-style, making users write procedural
code like Utils.doSome(obj, params) instead of obj.doSome(params). Its
common issue users just aren't aware of the existence of certain utility
classes and end up with nonoptimal code.
Code without extension methods is always much more verbose, if the API is
supposed to be fluent developer could end up with deep nested invocations.
This brings numerous problems, such as majorly reduced readability, as the
utility methods wrap each other and the developer reads the processing
pipeline "from the end". Also reduced readability always means increased
change of errors.
Writing code using utility methods instead of extensions is just slower,
developers have to waste more time writing a statement than it would be
with extension methods.
Some other advantages I will list below, after this list is ended.

5. One of the answers from the first thread you provided (
https://stackoverflow.com/a/29494337) states that omitting extension
methods is a "philosophical choice", as API developers should define
the API. I have to strongly disagree with that. Extension methods are NOT
part of the API, they are EXTENSION to it. It does not breach
encapsulation as it can't access any internal members of API classes.
Extensions have to be imported explicitly (not the containing class), so
they are explicitly mentioned in the imports list. Also, are utility
methods also breaching this rule then? The only real difference I see is
differences in notation, and extension methods are clearly much more
concise.

Now moving on to some of my personal points. I am also developing some core
libs APIs, and sometimes extension methods are just craving to be used.
Modifying widely-used interfaces is always painful, but that's the only way
to provide a concise way to communicate with existing APIs. Moreover, Java
is an old language and some internal implementations of APIs, like Stream
implementations, are so juncted that adding something new to these classes
directly becomes a spec-ops task. Some APIs, like Gatherer API or Collector
API, arise just from this simple necessity to introduce new behaviour
without modifying extended class itself.

Extension methods are de-facto standard for modern languages: C#, Kotlin,
Swift, Rust and any other modern language provide this option. JS also has
its own unique way of extending APIs. The only modern widely-used language
that does not have extension methods is Python, but that only applies to
built-ins, custom classes could be extended as well. When Java refuses to
introduce this feature, I suffer major damage in the eyes of potential
switchers from ANY other language available right now, which is retrograde
and, as for me and any other supporter of Java, really upsetting.

Introduction of extension will not invalidate previously written code: if
one wants, they can still use utilities as earlier and pretend that nothing
happened. However, for other, significant, if not to say major, part of the
community, this would be a valuable addition..Virtually every Java utility
library: lombok, manifold, xtend - provide extension method functionality,
which clearly shows there is a demand for a feature.

The extension methods are just syntax sugar, nothing more. They provide
better developer experience, make code less verbose and more readable,
which reduces chance of errors and helps to develop apps faster, while not
affecting performance in any way, which is crucial in today's world and may
be a major concurrent advantage.

Also, last but not least, noone from Java developers teams will have to put
efforts into implementation. I am willing to take one full feature
development lifecycle, from drafts to testing and integration. Of course,
final changes will need to be reviewed, but I don't think this will be an
unbearable burden. Regarding implementation, these changes are really
non-invasive, and are really unlikely to introduce any issues, it already
passes all existing tests.

I sincerely hope this letter will bring up this discussion once again, as I
am open for dialogue, but I am standing my ground about numerous advantages
this feature has. If that's possible, I may file a draft JEP and let the
community vote for or against it, to see what Java users think about this
proposal.

Best regards,
Hoping to receive some feedback

??, 23 ???. 2024??. ? 07:01, Ethan McCue <ethan at mccue.dev>:

> This subject has been addressed publicly by the language team at
> various points. These are just a few I found, I'm sure there is more
> elaboration out there.
>
> Implementation choices aside, the API of "add a static method and mark it
> as an "extension method", call like instance method" seems to have been
> rejected.
>
> > C# extension methods have some very serious drawbacks compared to Java's
> default methods (for example, poor reflective discoverability, poor
> discoverability through documentation, not overrideable, require ad-hoc
> conflict-management rules)
>
>
> https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio
>
> > What I believe you are hoping for is the ability to "monkey-patch" a
> method into a class you do not control, but Java does not give you that (by
> design; it was considered and rejected.)
>
>
> https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class
>
>
> On Mon, Apr 22, 2024 at 7:24?PM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Subject: Proposal for Introducing Extension Methods to Java
>>
>> Dear Java Development Team,
>>
>> I hope this email finds you all in good spirits. I am writing to propose
>> the integration of extension methods into the Java programming language, a
>> feature that I believe holds considerable promise in enhancing code
>> readability and maintainability.
>>
>> Extension methods offer a means to extend the functionality of existing
>> classes in a manner that aligns with Java's principles of static typing and
>> object-oriented design. The proposed syntax, exemplified as follows:
>>
>> public static void extensionMethod(extends String s) { ... }
>>
>> adheres to established conventions while providing a concise and
>> intuitive means of extending class behavior. Notably, the use of the
>> `extends` keyword preceding the type parameter clearly denotes the class to
>> be extended, while the method itself is declared as a static member of a
>> class.
>>
>> I wish to emphasize several advantages of extension methods over
>> traditional utility functions. Firstly, extension methods offer a more
>> cohesive approach to code organization by associating functionality
>> directly with the class it extends. This promotes code clarity and reduces
>> cognitive overhead for developers, particularly when working with complex
>> codebases.
>>
>> Secondly, extension methods enhance code discoverability and usability by
>> integrating seamlessly into the class they extend. This integration allows
>> developers to leverage IDE features such as auto-completion and
>> documentation tooltips, thereby facilitating more efficient code
>> exploration and utilization.
>>
>> Lastly, extension methods promote code reusability without the need for
>> subclassing or inheritance, thereby mitigating the risks associated with
>> tight coupling and inheritance hierarchies. This modularity encourages a
>> more flexible and adaptable codebase, conducive to long-term
>> maintainability and scalability.
>>
>> In light of these benefits, I believe that the integration of extension
>> methods into Java would represent a significant step forward for the
>> language, aligning it more closely with modern programming paradigms while
>> retaining its core strengths.
>>
>> I am eager to discuss this proposal further and collaborate with you all
>> on its implementation. Your insights and feedback would be invaluable in
>> shaping the future direction of Java development.
>>
>> Thank you for considering this proposal. I look forward to our discussion.
>>
>> The draft implementation can be found in the following branch of the
>> repository: https://github.com/Evemose/jdk/tree/extension-methods. I am
>> new to Java compiler development, so any tips or remarks about what I have
>> done in the wrong way or in the wrong place. I will add complete test
>> coverage a bit later, but for now, there is "jdk" archive in the root
>> directory of repo, which contains built in jdk for windows x86-64. If
>> someone is willing to participate in testing as user, I would appreciate
>> any help.
>>
>> Best regards
>>
>> PS: Note about internal implementation: it introduces a new flag -
>> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
>> bit in a long value type that has not been taken by flags. Not sure what
>> the compiler development community should do about this, but it feels like
>> it could be an obstacle to new features that might be introduced later.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/19792072/attachment-0001.htm>

From duke at openjdk.org  Tue Apr 23 13:54:42 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:42 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

Evemose has updated the pull request incrementally with three additional commits since the last revision:

 - Added Objects import to sun List
 - Replaced on-demand import in com.sun....List
 - added non-null assertions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/de6e18e7..349ee6bd

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

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

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

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
Message-ID: <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>

On Fri, 19 Apr 2024 21:36:42 GMT, xxDark <duke at openjdk.org> wrote:

> I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.

Yeah, thats true. not sure if it has to throw NPE even if list is emply

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067350248

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (xxDark)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
 <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
Message-ID: <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>

On Fri, 19 Apr 2024 22:20:48 GMT, Evemose <duke at openjdk.org> wrote:

> > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
> 
> Yeah, thats true. not sure if it has to throw NPE even if list is emply

Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:

default int findIndex(Predicate<? super T> filter) {
	ListIterator<T> iterator = listIterator();
	if (!iterator.hasNext()) return -1;
	Objects.requireNonNull(filter);
	int index = 0;
	do {
		if (filter.test(iterator.next()))
			return index;
		index++;
	} while (iterator.hasNext());
	return -1;
}

Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067354358

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
Message-ID: <oAk-msZ9ZOnUYgDlBRhg3HNxWulyaW5dAvCKBW7x8Rc=.e046fe83-fee9-4490-ba81-06a519f09f59@github.com>

On Fri, 19 Apr 2024 15:49:11 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted code style changes in Vector

> > > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
> > 
> > 
> > Yeah, thats true. not sure if it has to throw NPE even if list is emply
> 
> Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:
> 
> ```java
> default int findIndex(Predicate<? super T> filter) {
> 	ListIterator<T> iterator = listIterator();
> 	if (!iterator.hasNext()) return -1;
> 	Objects.requireNonNull(filter);
> 	int index = 0;
> 	do {
> 		if (filter.test(iterator.next()))
> 			return index;
> 		index++;
> 	} while (iterator.hasNext());
> 	return -1;
> }
> ```
> 
> Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

ok, i will fix this in a while

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067357432

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v11]
In-Reply-To: <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <SUN2s-4G4EN_1nkdarShOb4mngWejRty4SJgc7KblDY=.2e4534e2-e499-4dd3-8b5c-476fb1b16329@github.com>
 <ix0PD0A5tEWnJippyqSSBQ7UP6W7PU2ZlfFInOVopfs=.8a86123a-1617-40de-bd83-71573946cff1@github.com>
 <AfO9z_yJbNex4WQE2wfAdhONBy5z8g3jANcZXnUkWw0=.ef8fcd94-9e7c-4685-bcd2-0f3381058191@github.com>
 <DAqbpSx_7kViagt7QXgN9nq_gMnS6wMGpvYLmJPVnw0=.690312db-6d76-4d74-8cf2-8c104339ab5b@github.com>
Message-ID: <ktLVMlLG87BOTOl0qzPZNUWZga6HTOYzFsmNCLS8x6w=.669e525b-acf3-4fd2-8c6b-ea2ad59092f8@github.com>

On Fri, 19 Apr 2024 22:27:15 GMT, xxDark <duke at openjdk.org> wrote:

>>> I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
>> 
>> Yeah, thats true. not sure if it has to throw NPE even if list is emply
>
>> > I noticed that most (if not all) methods don't ensure non-nullability of `filter` so NPE would only be thrown if the list is not empty.
>> 
>> Yeah, thats true. not sure if it has to throw NPE even if list is emply
> 
> Yes, it does. If it shouldn't, then why isn't code in the java.util.List is like this:
> 
> default int findIndex(Predicate<? super T> filter) {
> 	ListIterator<T> iterator = listIterator();
> 	if (!iterator.hasNext()) return -1;
> 	Objects.requireNonNull(filter);
> 	int index = 0;
> 	do {
> 		if (filter.test(iterator.next()))
> 			return index;
> 		index++;
> 	} while (iterator.hasNext());
> 	return -1;
> }
> 
> Also see methods like `removveIf`. All methods should do checks even if they essentially do nothing.

@xxDark Added null asserions everywhere except sublists that delegate execution to other lists, except for SynchroziedLsit so it doesnt acquire monitor with invalid predicate. I think this would be the best choice

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2067762652

From duke at openjdk.org  Tue Apr 23 13:54:43 2024
From: duke at openjdk.org (Evemose)
Date: Tue, 23 Apr 2024 13:54:43 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v2]
In-Reply-To: <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <DeQ1jbkbXI2txXDgudASqD9VJqGUGVqz0Y1JBj2G3F4=.83d92b0d-c12d-4f8a-ae2f-45cd93d64a0b@github.com>
 <fA-y3C494CDNK7kWw5j9JFh0jcb6SpWQ1mBt5kQo1bc=.8f4c77e6-bb98-485f-8d9e-c0b6328f4381@github.com>
 <tZrjrywoJJhwz7vUU9aywc51YYrxuSumqX4brlAj3FI=.86912793-7bf3-44b6-b54d-c964699c6681@github.com>
 <B3LFaJy2uS5bLEbUrpjlxmfFp2w-oEepAEkfTT-T6Vw=.207c7b38-cc6a-4520-be2c-0f547ff0350e@github.com>
Message-ID: <caLOGzz22aydXw3QajcmbXc_VzsPn7uWektkzCVYi9c=.9c71ee3d-cb92-4e4c-9ddf-69f287e713b5@github.com>

On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @minborg Sorry to bother you with this kind of question, but i cant manage to find where exactly and how I can file CSR review request. Could you help me out?
>
> @Evemose Please revert formatting changes in existing classes. Unfortunately there's no single code style across all of JDK, but you shouldn't try to format code/methods that's not touched by your new method addition.

@liach Seems like discussion in mails has came to some conclusion (or people just arent interested in it anymore). Therefore, i think its time to file for csr. Here is a draft request text, but Im not sure how to fill in some fields:
Summary: Add findIndex(Predicate) and findLastIndex(Predicate) to List
Problem: Modification of java.utilList interface by adding findIndex(Predicate) and findLastIndex(Predicate) methods might introduce behavioural or byteecode incompatibilities
Solution: // dont know what to write here tbh
Specification: // do i have to paste changed code here, or provide links, or what?
Alternatives: syntax line indexOf(Predicate) and lastIndexOf(Predicate) was concidered, but discarded due to behavioural incompatibilities with invokation indexOf(null)

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2072079213

From liach at openjdk.org  Tue Apr 23 13:54:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Apr 2024 13:54:44 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>

On Tue, 23 Apr 2024 13:51:54 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

src/java.base/share/classes/java/util/LinkedList.java line 1507:

> 1505: 
> 1506:         public int findLastIndex(Predicate<? super E> filter) {
> 1507:             return rlist.findLastIndex(filter);

Hmm, this view is supposed to be reversed... so last and first need a swap. This is a bug in the current codebase, a good bug to fix indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1573456708

From liach at openjdk.org  Tue Apr 23 13:54:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 Apr 2024 13:54:44 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <psjMozqRXs2O-4JfHdX4nGN3DNvDT2ji_LkGsNBfgd0=.c17d4f2b-8c56-4411-9b74-df517553db62@github.com>
Message-ID: <ntUATYnt_2faBDaVTQ8XQeM6_kisttUjgo97xtzQ8gI=.1d31af92-b479-41de-b7f0-67c1120115ba@github.com>

On Sat, 20 Apr 2024 23:11:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Added Objects import to sun List
>>  - Replaced on-demand import in com.sun....List
>>  - added non-null assertions
>
> src/java.base/share/classes/java/util/LinkedList.java line 1507:
> 
>> 1505: 
>> 1506:         public int findLastIndex(Predicate<? super E> filter) {
>> 1507:             return rlist.findLastIndex(filter);
> 
> Hmm, this view is supposed to be reversed... so last and first need a swap. This is a bug in the current codebase, a good bug to fix indeed.

Ignore my fault, it's just delegating methods to 2 different, already reversed views...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1573458008

From ethan at mccue.dev  Tue Apr 23 14:01:29 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 23 Apr 2024 10:01:29 -0400
Subject: Extension methods
In-Reply-To: <CAP=Y=q-G-ZmT0Hc-OxopB_up6nZfV3HefwOmN=-qsKnbYT5MQg@mail.gmail.com>
References: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
 <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>
 <CAP=Y=q-G-ZmT0Hc-OxopB_up6nZfV3HefwOmN=-qsKnbYT5MQg@mail.gmail.com>
Message-ID: <CA+NR86iZM3BZmcz93rLHjpxrgX1FYP5cZyaH=duPkeHmP6qjaA@mail.gmail.com>

> if someone from API designers, who once rejected this proposal, would
spare some time to discuss this topic with me.

I am not that - you'll find I have no particular influence - but while I'm
here.

* This is a very commonly requested feature, they are aware of the desire
for it.
* A change like this would probably live under the banner of the amber
project (feel free to forward the thread to amber-dev for a higher chance
at a response, maybe)
* There are more ways to address the tension than extension methods

To elaborate on that last point, consider this program

import org.apache.commons.lang3.StringUtils;

import java.util.Locale;

void main(String[] args) {
    String speech = """
            Four score and seven years ago our fathers brought forth on
this continent, a new nation, conceived in Liberty, and dedicated to the
proposition that all men are created equal.
            """;

    String drunkFriendSpeech = StringUtils.abbreviate(
            speech.toUpperCase(Locale.US),
            20
    ).replace("OUR", "OUR (*burp*)");

    System.out.println(drunkFriendSpeech);
}

$ FOUR (*burp*) SCORE AND SE...

What extension methods are syntax sugar for is making logic like
org.apache.commons.lang3.StringUtils#abbreviate appear in code as if it
were an instance method.

    String drunkFriendSpeech = speech.toUpperCase(Locale.US)
            .abbreviate(20)
            .replace("OUR", "OUR (*burp*)");

But the downsides are what has been pointed out.

* You no longer know if `.abbreviate` is a method call or a call to
StringUtils.abbreviate from local analysis.
* Whether it is valid code is determined by an import of some kind.
* Hey, what if they actually added an abbreviate method to String...would
this code change meaning?
* ...etc.

But if there was an alternative syntax for invoking static methods you
could resolve the tension that way.

    String drunkFriendSpeech = speech.toUpperCase(Locale.US)
            |> StringUtils.abbreviate(_, 20)
            .replace("OUR", "OUR (*burp*)");

Infinite bikesheds notwithstanding, If the amber project ever adds
something to address the "Static Methods Ugly to Chain" problem I
personally think it will be something in this direction. That would also
probably come well after pattern matching and probably also after valhalla,
if it comes at all, so I wouldn't hold your breath.

> Writing code using utility methods instead of extensions is just slower,
developers have to waste more time writing a statement than it would be
with extension methods.

What's going to suck to hear, but I think that you'll come around
eventually, is that extension methods do not improve code readability. They
make it harder to read o.method() since it would be ambiguous whether
.method is an instance method or an extension method.*

They *do* make it easier to write programs though. Without them you do have
to write more characters and you do sometimes have to break up method
chains.

Historically, given a choice between code readability and code
writability/terseness, Java has erred towards the first.

* Technically it's already ambiguous, but calling static methods through an
instance variable is uncommon so we don't do a double take on it. Extension
methods would be used commonly enough that you would have to think about it.

On Tue, Apr 23, 2024 at 3:35?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Well that's just really frustrating for me.
>
> I am pretty sure the point I will provide as advantages has already been
> brought up here numerous times, but I will take some time and would
> appreciate it if someone from API designers, who once rejected this
> proposal, would spare some time to discuss this topic with me.
>
> 1. "Poor reflective discoverability" essentially means extension methods
> are not accessible when inspecting class members. That is not some
> inherent issue of this feature, this is just the way it should be. I'm
> not really sure if there is someone who has ever been hurt by this, besides
> maybe some parser-based solutions, but let's be honest, this is a:
> solvable, b: ridiculously exotic to consider.
>
> 2. Documentation accessibility is a strange point for me to be fair. Every
> IDE nowadays is capable of fetching the right documentation, as well as
> explicitly mentioning where the method comes from, as it is done in C#,
> kotlin, swift and many other languages. I don't think anyone has ever heard
> complaints about poor documentation of LinQ. Unless someone is writing in
> notepad, this is poorly applicable.
>
> 3. Not overridable. Should they be? I don't think there is a way to
> achieve some kind of "polymorphic" extensions, and I don't think there
> should be: extension methods should provide polymorphic target handling,
> floow LSP etc., not the other way around.
>
> 4. C# extension methods indeed have some very serious drawbacks compared
> to Java's, but doesn't this also go the other way around? Canonical utility
> functions breach object-oriented code-style, making users write procedural
> code like Utils.doSome(obj, params) instead of obj.doSome(params). Its
> common issue users just aren't aware of the existence of certain utility
> classes and end up with nonoptimal code.
> Code without extension methods is always much more verbose, if the API is
> supposed to be fluent developer could end up with deep nested invocations.
> This brings numerous problems, such as majorly reduced readability, as the
> utility methods wrap each other and the developer reads the processing
> pipeline "from the end". Also reduced readability always means increased
> change of errors.
> Writing code using utility methods instead of extensions is just slower,
> developers have to waste more time writing a statement than it would be
> with extension methods.
> Some other advantages I will list below, after this list is ended.
>
> 5. One of the answers from the first thread you provided (
> https://stackoverflow.com/a/29494337) states that omitting extension
> methods is a "philosophical choice", as API developers should define
> the API. I have to strongly disagree with that. Extension methods are NOT
> part of the API, they are EXTENSION to it. It does not breach
> encapsulation as it can't access any internal members of API classes.
> Extensions have to be imported explicitly (not the containing class), so
> they are explicitly mentioned in the imports list. Also, are utility
> methods also breaching this rule then? The only real difference I see is
> differences in notation, and extension methods are clearly much more
> concise.
>
> Now moving on to some of my personal points. I am also developing some
> core libs APIs, and sometimes extension methods are just craving to be
> used. Modifying widely-used interfaces is always painful, but that's the
> only way to provide a concise way to communicate with existing APIs.
> Moreover, Java is an old language and some internal implementations of
> APIs, like Stream implementations, are so juncted that adding something new
> to these classes directly becomes a spec-ops task. Some APIs, like Gatherer
> API or Collector API, arise just from this simple necessity to introduce
> new behaviour without modifying extended class itself.
>
> Extension methods are de-facto standard for modern languages: C#, Kotlin,
> Swift, Rust and any other modern language provide this option. JS also has
> its own unique way of extending APIs. The only modern widely-used language
> that does not have extension methods is Python, but that only applies to
> built-ins, custom classes could be extended as well. When Java refuses to
> introduce this feature, I suffer major damage in the eyes of potential
> switchers from ANY other language available right now, which is retrograde
> and, as for me and any other supporter of Java, really upsetting.
>
> Introduction of extension will not invalidate previously written code: if
> one wants, they can still use utilities as earlier and pretend that nothing
> happened. However, for other, significant, if not to say major, part of the
> community, this would be a valuable addition..Virtually every Java utility
> library: lombok, manifold, xtend - provide extension method functionality,
> which clearly shows there is a demand for a feature.
>
> The extension methods are just syntax sugar, nothing more. They provide
> better developer experience, make code less verbose and more readable,
> which reduces chance of errors and helps to develop apps faster, while not
> affecting performance in any way, which is crucial in today's world and may
> be a major concurrent advantage.
>
> Also, last but not least, noone from Java developers teams will have to
> put efforts into implementation. I am willing to take one full feature
> development lifecycle, from drafts to testing and integration. Of course,
> final changes will need to be reviewed, but I don't think this will be an
> unbearable burden. Regarding implementation, these changes are really
> non-invasive, and are really unlikely to introduce any issues, it already
> passes all existing tests.
>
> I sincerely hope this letter will bring up this discussion once again, as
> I am open for dialogue, but I am standing my ground about numerous
> advantages this feature has. If that's possible, I may file a draft JEP and
> let the community vote for or against it, to see what Java users think
> about this proposal.
>
> Best regards,
> Hoping to receive some feedback
>
> ??, 23 ???. 2024??. ? 07:01, Ethan McCue <ethan at mccue.dev>:
>
>> This subject has been addressed publicly by the language team at
>> various points. These are just a few I found, I'm sure there is more
>> elaboration out there.
>>
>> Implementation choices aside, the API of "add a static method and mark it
>> as an "extension method", call like instance method" seems to have been
>> rejected.
>>
>> > C# extension methods have some very serious drawbacks compared to
>> Java's default methods (for example, poor reflective discoverability, poor
>> discoverability through documentation, not overrideable, require ad-hoc
>> conflict-management rules)
>>
>>
>> https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio
>>
>> > What I believe you are hoping for is the ability to "monkey-patch" a
>> method into a class you do not control, but Java does not give you that (by
>> design; it was considered and rejected.)
>>
>>
>> https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class
>>
>>
>> On Mon, Apr 22, 2024 at 7:24?PM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Subject: Proposal for Introducing Extension Methods to Java
>>>
>>> Dear Java Development Team,
>>>
>>> I hope this email finds you all in good spirits. I am writing to propose
>>> the integration of extension methods into the Java programming language, a
>>> feature that I believe holds considerable promise in enhancing code
>>> readability and maintainability.
>>>
>>> Extension methods offer a means to extend the functionality of existing
>>> classes in a manner that aligns with Java's principles of static typing and
>>> object-oriented design. The proposed syntax, exemplified as follows:
>>>
>>> public static void extensionMethod(extends String s) { ... }
>>>
>>> adheres to established conventions while providing a concise and
>>> intuitive means of extending class behavior. Notably, the use of the
>>> `extends` keyword preceding the type parameter clearly denotes the class to
>>> be extended, while the method itself is declared as a static member of a
>>> class.
>>>
>>> I wish to emphasize several advantages of extension methods over
>>> traditional utility functions. Firstly, extension methods offer a more
>>> cohesive approach to code organization by associating functionality
>>> directly with the class it extends. This promotes code clarity and reduces
>>> cognitive overhead for developers, particularly when working with complex
>>> codebases.
>>>
>>> Secondly, extension methods enhance code discoverability and usability
>>> by integrating seamlessly into the class they extend. This integration
>>> allows developers to leverage IDE features such as auto-completion and
>>> documentation tooltips, thereby facilitating more efficient code
>>> exploration and utilization.
>>>
>>> Lastly, extension methods promote code reusability without the need for
>>> subclassing or inheritance, thereby mitigating the risks associated with
>>> tight coupling and inheritance hierarchies. This modularity encourages a
>>> more flexible and adaptable codebase, conducive to long-term
>>> maintainability and scalability.
>>>
>>> In light of these benefits, I believe that the integration of extension
>>> methods into Java would represent a significant step forward for the
>>> language, aligning it more closely with modern programming paradigms while
>>> retaining its core strengths.
>>>
>>> I am eager to discuss this proposal further and collaborate with you all
>>> on its implementation. Your insights and feedback would be invaluable in
>>> shaping the future direction of Java development.
>>>
>>> Thank you for considering this proposal. I look forward to our
>>> discussion.
>>>
>>> The draft implementation can be found in the following branch of the
>>> repository: https://github.com/Evemose/jdk/tree/extension-methods. I am
>>> new to Java compiler development, so any tips or remarks about what I have
>>> done in the wrong way or in the wrong place. I will add complete test
>>> coverage a bit later, but for now, there is "jdk" archive in the root
>>> directory of repo, which contains built in jdk for windows x86-64. If
>>> someone is willing to participate in testing as user, I would appreciate
>>> any help.
>>>
>>> Best regards
>>>
>>> PS: Note about internal implementation: it introduces a new flag -
>>> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
>>> bit in a long value type that has not been taken by flags. Not sure what
>>> the compiler development community should do about this, but it feels like
>>> it could be an obstacle to new features that might be introduced later.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/2f80ab20/attachment-0001.htm>

From rotan.olexandr at gmail.com  Tue Apr 23 14:29:25 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 17:29:25 +0300
Subject: Extension methods
In-Reply-To: <CA+NR86iZM3BZmcz93rLHjpxrgX1FYP5cZyaH=duPkeHmP6qjaA@mail.gmail.com>
References: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
 <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>
 <CAP=Y=q-G-ZmT0Hc-OxopB_up6nZfV3HefwOmN=-qsKnbYT5MQg@mail.gmail.com>
 <CA+NR86iZM3BZmcz93rLHjpxrgX1FYP5cZyaH=duPkeHmP6qjaA@mail.gmail.com>
Message-ID: <CAP=Y=q_oZv+urUcq--=E-2+Sje4R3JMmJ44fjR0bp5ZkwQkoQw@mail.gmail.com>

Thanks for forwarding to Amber, I'll make sure to propose.

One thing I really don't like about extensions is when people say "you
never know where it comes from". Firstly, if extension is really an
extension and not just a utility method that has been made extension for
fun (which is just bad code design and language shouldn't really assume
that when designing features), its name should describe what it does just
like regular instance method describes. Secondly,  If you require more
elaboration, any IDE is capable of fetching docs for extensions correctly
nowadays, as well as pointing out scope where it comes from, which I guess
should be taken into account.

Regarding ambiguity, the common practice (which also is applied in my
design) is to prioritize members over extensions, there is no ambiguity if
behaviour is well defined.This "potentially" could sometimes result in
source incompatibility with some third-party libraries, but as soon as this
is not conflicting with anything from stdlib, that's not really our
concern. Also, I think it's kind of exotic scenario, and may crash only
with utilities from stdlib classes, which cuts off virtually all production
code from the risk group.And as you mentioned earlier, this problem has
already been present long enough, just not that widely.

Syntax that you have provided, to be fair, smells a bit like PHP to me for
some reason. I don't see why not to use dot notation along with static
imports instead of lists. For me the statement you provided was not that
easy to understand at a first glance, however that's still much better
then traditional utilities.

Also I guess worth mentioning that other languages like C# and kotlin and
many other leave with the same dot notation invocation and I never really
heard that updating language version was really a trouble, especially in
kotlin, even though extension methods have been part of the language for a
very long time already.

Appreciate your feedback though, It's always pleasant to discuss something
with experienced developer.

??, 23 ???. 2024??. ? 17:02, Ethan McCue <ethan at mccue.dev>:

> > if someone from API designers, who once rejected this proposal, would
> spare some time to discuss this topic with me.
>
> I am not that - you'll find I have no particular influence - but while I'm
> here.
>
> * This is a very commonly requested feature, they are aware of the desire
> for it.
> * A change like this would probably live under the banner of the amber
> project (feel free to forward the thread to amber-dev for a higher chance
> at a response, maybe)
> * There are more ways to address the tension than extension methods
>
> To elaborate on that last point, consider this program
>
> import org.apache.commons.lang3.StringUtils;
>
> import java.util.Locale;
>
> void main(String[] args) {
>     String speech = """
>             Four score and seven years ago our fathers brought forth on
> this continent, a new nation, conceived in Liberty, and dedicated to the
> proposition that all men are created equal.
>             """;
>
>     String drunkFriendSpeech = StringUtils.abbreviate(
>             speech.toUpperCase(Locale.US),
>             20
>     ).replace("OUR", "OUR (*burp*)");
>
>     System.out.println(drunkFriendSpeech);
> }
>
> $ FOUR (*burp*) SCORE AND SE...
>
> What extension methods are syntax sugar for is making logic like
> org.apache.commons.lang3.StringUtils#abbreviate appear in code as if it
> were an instance method.
>
>     String drunkFriendSpeech = speech.toUpperCase(Locale.US)
>             .abbreviate(20)
>             .replace("OUR", "OUR (*burp*)");
>
> But the downsides are what has been pointed out.
>
> * You no longer know if `.abbreviate` is a method call or a call to
> StringUtils.abbreviate from local analysis.
> * Whether it is valid code is determined by an import of some kind.
> * Hey, what if they actually added an abbreviate method to String...would
> this code change meaning?
> * ...etc.
>
> But if there was an alternative syntax for invoking static methods you
> could resolve the tension that way.
>
>     String drunkFriendSpeech = speech.toUpperCase(Locale.US)
>             |> StringUtils.abbreviate(_, 20)
>             .replace("OUR", "OUR (*burp*)");
>
> Infinite bikesheds notwithstanding, If the amber project ever adds
> something to address the "Static Methods Ugly to Chain" problem I
> personally think it will be something in this direction. That would also
> probably come well after pattern matching and probably also after valhalla,
> if it comes at all, so I wouldn't hold your breath.
>
> > Writing code using utility methods instead of extensions is just
> slower, developers have to waste more time writing a statement than it
> would be with extension methods.
>
> What's going to suck to hear, but I think that you'll come around
> eventually, is that extension methods do not improve code readability. They
> make it harder to read o.method() since it would be ambiguous whether
> .method is an instance method or an extension method.*
>
> They *do* make it easier to write programs though. Without them you do
> have to write more characters and you do sometimes have to break up method
> chains.
>
> Historically, given a choice between code readability and code
> writability/terseness, Java has erred towards the first.
>
> * Technically it's already ambiguous, but calling static methods through
> an instance variable is uncommon so we don't do a double take on it.
> Extension methods would be used commonly enough that you would have to
> think about it.
>
> On Tue, Apr 23, 2024 at 3:35?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Well that's just really frustrating for me.
>>
>> I am pretty sure the point I will provide as advantages has already been
>> brought up here numerous times, but I will take some time and would
>> appreciate it if someone from API designers, who once rejected this
>> proposal, would spare some time to discuss this topic with me.
>>
>> 1. "Poor reflective discoverability" essentially means extension methods
>> are not accessible when inspecting class members. That is not some
>> inherent issue of this feature, this is just the way it should be. I'm
>> not really sure if there is someone who has ever been hurt by this, besides
>> maybe some parser-based solutions, but let's be honest, this is a:
>> solvable, b: ridiculously exotic to consider.
>>
>> 2. Documentation accessibility is a strange point for me to be fair.
>> Every IDE nowadays is capable of fetching the right documentation, as well
>> as explicitly mentioning where the method comes from, as it is done in C#,
>> kotlin, swift and many other languages. I don't think anyone has ever heard
>> complaints about poor documentation of LinQ. Unless someone is writing in
>> notepad, this is poorly applicable.
>>
>> 3. Not overridable. Should they be? I don't think there is a way to
>> achieve some kind of "polymorphic" extensions, and I don't think there
>> should be: extension methods should provide polymorphic target handling,
>> floow LSP etc., not the other way around.
>>
>> 4. C# extension methods indeed have some very serious drawbacks compared
>> to Java's, but doesn't this also go the other way around? Canonical utility
>> functions breach object-oriented code-style, making users write procedural
>> code like Utils.doSome(obj, params) instead of obj.doSome(params). Its
>> common issue users just aren't aware of the existence of certain utility
>> classes and end up with nonoptimal code.
>> Code without extension methods is always much more verbose, if the API is
>> supposed to be fluent developer could end up with deep nested invocations.
>> This brings numerous problems, such as majorly reduced readability, as the
>> utility methods wrap each other and the developer reads the processing
>> pipeline "from the end". Also reduced readability always means increased
>> change of errors.
>> Writing code using utility methods instead of extensions is just slower,
>> developers have to waste more time writing a statement than it would be
>> with extension methods.
>> Some other advantages I will list below, after this list is ended.
>>
>> 5. One of the answers from the first thread you provided (
>> https://stackoverflow.com/a/29494337) states that omitting extension
>> methods is a "philosophical choice", as API developers should define
>> the API. I have to strongly disagree with that. Extension methods are NOT
>> part of the API, they are EXTENSION to it. It does not breach
>> encapsulation as it can't access any internal members of API classes.
>> Extensions have to be imported explicitly (not the containing class), so
>> they are explicitly mentioned in the imports list. Also, are utility
>> methods also breaching this rule then? The only real difference I see is
>> differences in notation, and extension methods are clearly much more
>> concise.
>>
>> Now moving on to some of my personal points. I am also developing some
>> core libs APIs, and sometimes extension methods are just craving to be
>> used. Modifying widely-used interfaces is always painful, but that's the
>> only way to provide a concise way to communicate with existing APIs.
>> Moreover, Java is an old language and some internal implementations of
>> APIs, like Stream implementations, are so juncted that adding something new
>> to these classes directly becomes a spec-ops task. Some APIs, like Gatherer
>> API or Collector API, arise just from this simple necessity to introduce
>> new behaviour without modifying extended class itself.
>>
>> Extension methods are de-facto standard for modern languages: C#, Kotlin,
>> Swift, Rust and any other modern language provide this option. JS also has
>> its own unique way of extending APIs. The only modern widely-used language
>> that does not have extension methods is Python, but that only applies to
>> built-ins, custom classes could be extended as well. When Java refuses to
>> introduce this feature, I suffer major damage in the eyes of potential
>> switchers from ANY other language available right now, which is retrograde
>> and, as for me and any other supporter of Java, really upsetting.
>>
>> Introduction of extension will not invalidate previously written code: if
>> one wants, they can still use utilities as earlier and pretend that nothing
>> happened. However, for other, significant, if not to say major, part of the
>> community, this would be a valuable addition..Virtually every Java utility
>> library: lombok, manifold, xtend - provide extension method functionality,
>> which clearly shows there is a demand for a feature.
>>
>> The extension methods are just syntax sugar, nothing more. They provide
>> better developer experience, make code less verbose and more readable,
>> which reduces chance of errors and helps to develop apps faster, while not
>> affecting performance in any way, which is crucial in today's world and may
>> be a major concurrent advantage.
>>
>> Also, last but not least, noone from Java developers teams will have to
>> put efforts into implementation. I am willing to take one full feature
>> development lifecycle, from drafts to testing and integration. Of course,
>> final changes will need to be reviewed, but I don't think this will be an
>> unbearable burden. Regarding implementation, these changes are really
>> non-invasive, and are really unlikely to introduce any issues, it already
>> passes all existing tests.
>>
>> I sincerely hope this letter will bring up this discussion once again, as
>> I am open for dialogue, but I am standing my ground about numerous
>> advantages this feature has. If that's possible, I may file a draft JEP and
>> let the community vote for or against it, to see what Java users think
>> about this proposal.
>>
>> Best regards,
>> Hoping to receive some feedback
>>
>> ??, 23 ???. 2024??. ? 07:01, Ethan McCue <ethan at mccue.dev>:
>>
>>> This subject has been addressed publicly by the language team at
>>> various points. These are just a few I found, I'm sure there is more
>>> elaboration out there.
>>>
>>> Implementation choices aside, the API of "add a static method and mark
>>> it as an "extension method", call like instance method" seems to have been
>>> rejected.
>>>
>>> > C# extension methods have some very serious drawbacks compared to
>>> Java's default methods (for example, poor reflective discoverability, poor
>>> discoverability through documentation, not overrideable, require ad-hoc
>>> conflict-management rules)
>>>
>>>
>>> https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio
>>>
>>> > What I believe you are hoping for is the ability to "monkey-patch" a
>>> method into a class you do not control, but Java does not give you that (by
>>> design; it was considered and rejected.)
>>>
>>>
>>> https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class
>>>
>>>
>>> On Mon, Apr 22, 2024 at 7:24?PM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Subject: Proposal for Introducing Extension Methods to Java
>>>>
>>>> Dear Java Development Team,
>>>>
>>>> I hope this email finds you all in good spirits. I am writing to
>>>> propose the integration of extension methods into the Java programming
>>>> language, a feature that I believe holds considerable promise in enhancing
>>>> code readability and maintainability.
>>>>
>>>> Extension methods offer a means to extend the functionality of existing
>>>> classes in a manner that aligns with Java's principles of static typing and
>>>> object-oriented design. The proposed syntax, exemplified as follows:
>>>>
>>>> public static void extensionMethod(extends String s) { ... }
>>>>
>>>> adheres to established conventions while providing a concise and
>>>> intuitive means of extending class behavior. Notably, the use of the
>>>> `extends` keyword preceding the type parameter clearly denotes the class to
>>>> be extended, while the method itself is declared as a static member of a
>>>> class.
>>>>
>>>> I wish to emphasize several advantages of extension methods over
>>>> traditional utility functions. Firstly, extension methods offer a more
>>>> cohesive approach to code organization by associating functionality
>>>> directly with the class it extends. This promotes code clarity and reduces
>>>> cognitive overhead for developers, particularly when working with complex
>>>> codebases.
>>>>
>>>> Secondly, extension methods enhance code discoverability and usability
>>>> by integrating seamlessly into the class they extend. This integration
>>>> allows developers to leverage IDE features such as auto-completion and
>>>> documentation tooltips, thereby facilitating more efficient code
>>>> exploration and utilization.
>>>>
>>>> Lastly, extension methods promote code reusability without the need for
>>>> subclassing or inheritance, thereby mitigating the risks associated with
>>>> tight coupling and inheritance hierarchies. This modularity encourages a
>>>> more flexible and adaptable codebase, conducive to long-term
>>>> maintainability and scalability.
>>>>
>>>> In light of these benefits, I believe that the integration of extension
>>>> methods into Java would represent a significant step forward for the
>>>> language, aligning it more closely with modern programming paradigms while
>>>> retaining its core strengths.
>>>>
>>>> I am eager to discuss this proposal further and collaborate with you
>>>> all on its implementation. Your insights and feedback would be invaluable
>>>> in shaping the future direction of Java development.
>>>>
>>>> Thank you for considering this proposal. I look forward to our
>>>> discussion.
>>>>
>>>> The draft implementation can be found in the following branch of the
>>>> repository: https://github.com/Evemose/jdk/tree/extension-methods. I
>>>> am new to Java compiler development, so any tips or remarks about what I
>>>> have done in the wrong way or in the wrong place. I will add complete test
>>>> coverage a bit later, but for now, there is "jdk" archive in the root
>>>> directory of repo, which contains built in jdk for windows x86-64. If
>>>> someone is willing to participate in testing as user, I would appreciate
>>>> any help.
>>>>
>>>> Best regards
>>>>
>>>> PS: Note about internal implementation: it introduces a new flag -
>>>> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
>>>> bit in a long value type that has not been taken by flags. Not sure what
>>>> the compiler development community should do about this, but it feels like
>>>> it could be an obstacle to new features that might be introduced later.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/1e7c3678/attachment-0001.htm>

From asotona at openjdk.org  Tue Apr 23 14:46:43 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 Apr 2024 14:46:43 GMT
Subject: RFR: 8309881: Qualified name of a type element depends on its origin
 (source vs class)
Message-ID: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>

`javax.lang.model.type.TypeMirror::toString` says: "Any names embedded in the result are qualified if possible."
However in reality the form of the names depends on the source vs.class origin.

This patch enforces qualified name to be used.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8309881: Qualified name of a type element depends on its origin (source vs class)

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

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

From rotan.olexandr at gmail.com  Tue Apr 23 14:49:46 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Tue, 23 Apr 2024 17:49:46 +0300
Subject: Extension methods
In-Reply-To: <CAP=Y=q_oZv+urUcq--=E-2+Sje4R3JMmJ44fjR0bp5ZkwQkoQw@mail.gmail.com>
References: <CAP=Y=q8jNd2RmW2D_KcpHe+np_D4S6sK-kXXOP-pB5h00K0eEg@mail.gmail.com>
 <CA+NR86gRohZHJfMSNLrHZbf=fpujTq6BVpwNM-UBJCyR7+OzQw@mail.gmail.com>
 <CAP=Y=q-G-ZmT0Hc-OxopB_up6nZfV3HefwOmN=-qsKnbYT5MQg@mail.gmail.com>
 <CA+NR86iZM3BZmcz93rLHjpxrgX1FYP5cZyaH=duPkeHmP6qjaA@mail.gmail.com>
 <CAP=Y=q_oZv+urUcq--=E-2+Sje4R3JMmJ44fjR0bp5ZkwQkoQw@mail.gmail.com>
Message-ID: <CAP=Y=q9hxkwMeGLxLUTBympuHT=dH1FoKe2K_6Pu=F7uFuRfeA@mail.gmail.com>

And one more remark: when updating Java version, if there are potential
ambiguities is source files of some dependencies for new version, but it
compiled fine for older, code will still work as it was, because my
implementation relies on compile-time code transformation and therefore,
already compiled code won't suddenly start invoking some other methods

??, 23 ???. 2024??. ? 17:29, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> Thanks for forwarding to Amber, I'll make sure to propose.
>
> One thing I really don't like about extensions is when people say "you
> never know where it comes from". Firstly, if extension is really an
> extension and not just a utility method that has been made extension for
> fun (which is just bad code design and language shouldn't really assume
> that when designing features), its name should describe what it does just
> like regular instance method describes. Secondly,  If you require more
> elaboration, any IDE is capable of fetching docs for extensions correctly
> nowadays, as well as pointing out scope where it comes from, which I guess
> should be taken into account.
>
> Regarding ambiguity, the common practice (which also is applied in my
> design) is to prioritize members over extensions, there is no ambiguity if
> behaviour is well defined.This "potentially" could sometimes result in
> source incompatibility with some third-party libraries, but as soon as this
> is not conflicting with anything from stdlib, that's not really our
> concern. Also, I think it's kind of exotic scenario, and may crash only
> with utilities from stdlib classes, which cuts off virtually all production
> code from the risk group.And as you mentioned earlier, this problem has
> already been present long enough, just not that widely.
>
> Syntax that you have provided, to be fair, smells a bit like PHP to me for
> some reason. I don't see why not to use dot notation along with static
> imports instead of lists. For me the statement you provided was not that
> easy to understand at a first glance, however that's still much better
> then traditional utilities.
>
> Also I guess worth mentioning that other languages like C# and kotlin and
> many other leave with the same dot notation invocation and I never really
> heard that updating language version was really a trouble, especially in
> kotlin, even though extension methods have been part of the language for a
> very long time already.
>
> Appreciate your feedback though, It's always pleasant to discuss something
> with experienced developer.
>
> ??, 23 ???. 2024??. ? 17:02, Ethan McCue <ethan at mccue.dev>:
>
>> > if someone from API designers, who once rejected this proposal, would
>> spare some time to discuss this topic with me.
>>
>> I am not that - you'll find I have no particular influence - but while
>> I'm here.
>>
>> * This is a very commonly requested feature, they are aware of the desire
>> for it.
>> * A change like this would probably live under the banner of the amber
>> project (feel free to forward the thread to amber-dev for a higher chance
>> at a response, maybe)
>> * There are more ways to address the tension than extension methods
>>
>> To elaborate on that last point, consider this program
>>
>> import org.apache.commons.lang3.StringUtils;
>>
>> import java.util.Locale;
>>
>> void main(String[] args) {
>>     String speech = """
>>             Four score and seven years ago our fathers brought forth on
>> this continent, a new nation, conceived in Liberty, and dedicated to the
>> proposition that all men are created equal.
>>             """;
>>
>>     String drunkFriendSpeech = StringUtils.abbreviate(
>>             speech.toUpperCase(Locale.US),
>>             20
>>     ).replace("OUR", "OUR (*burp*)");
>>
>>     System.out.println(drunkFriendSpeech);
>> }
>>
>> $ FOUR (*burp*) SCORE AND SE...
>>
>> What extension methods are syntax sugar for is making logic like
>> org.apache.commons.lang3.StringUtils#abbreviate appear in code as if it
>> were an instance method.
>>
>>     String drunkFriendSpeech = speech.toUpperCase(Locale.US)
>>             .abbreviate(20)
>>             .replace("OUR", "OUR (*burp*)");
>>
>> But the downsides are what has been pointed out.
>>
>> * You no longer know if `.abbreviate` is a method call or a call to
>> StringUtils.abbreviate from local analysis.
>> * Whether it is valid code is determined by an import of some kind.
>> * Hey, what if they actually added an abbreviate method to String...would
>> this code change meaning?
>> * ...etc.
>>
>> But if there was an alternative syntax for invoking static methods you
>> could resolve the tension that way.
>>
>>     String drunkFriendSpeech = speech.toUpperCase(Locale.US)
>>             |> StringUtils.abbreviate(_, 20)
>>             .replace("OUR", "OUR (*burp*)");
>>
>> Infinite bikesheds notwithstanding, If the amber project ever adds
>> something to address the "Static Methods Ugly to Chain" problem I
>> personally think it will be something in this direction. That would also
>> probably come well after pattern matching and probably also after valhalla,
>> if it comes at all, so I wouldn't hold your breath.
>>
>> > Writing code using utility methods instead of extensions is just
>> slower, developers have to waste more time writing a statement than it
>> would be with extension methods.
>>
>> What's going to suck to hear, but I think that you'll come around
>> eventually, is that extension methods do not improve code readability. They
>> make it harder to read o.method() since it would be ambiguous whether
>> .method is an instance method or an extension method.*
>>
>> They *do* make it easier to write programs though. Without them you do
>> have to write more characters and you do sometimes have to break up method
>> chains.
>>
>> Historically, given a choice between code readability and code
>> writability/terseness, Java has erred towards the first.
>>
>> * Technically it's already ambiguous, but calling static methods through
>> an instance variable is uncommon so we don't do a double take on it.
>> Extension methods would be used commonly enough that you would have to
>> think about it.
>>
>> On Tue, Apr 23, 2024 at 3:35?AM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Well that's just really frustrating for me.
>>>
>>> I am pretty sure the point I will provide as advantages has already been
>>> brought up here numerous times, but I will take some time and would
>>> appreciate it if someone from API designers, who once rejected this
>>> proposal, would spare some time to discuss this topic with me.
>>>
>>> 1. "Poor reflective discoverability" essentially means extension methods
>>> are not accessible when inspecting class members. That is not some
>>> inherent issue of this feature, this is just the way it should be. I'm
>>> not really sure if there is someone who has ever been hurt by this, besides
>>> maybe some parser-based solutions, but let's be honest, this is a:
>>> solvable, b: ridiculously exotic to consider.
>>>
>>> 2. Documentation accessibility is a strange point for me to be fair.
>>> Every IDE nowadays is capable of fetching the right documentation, as well
>>> as explicitly mentioning where the method comes from, as it is done in C#,
>>> kotlin, swift and many other languages. I don't think anyone has ever heard
>>> complaints about poor documentation of LinQ. Unless someone is writing in
>>> notepad, this is poorly applicable.
>>>
>>> 3. Not overridable. Should they be? I don't think there is a way to
>>> achieve some kind of "polymorphic" extensions, and I don't think there
>>> should be: extension methods should provide polymorphic target handling,
>>> floow LSP etc., not the other way around.
>>>
>>> 4. C# extension methods indeed have some very serious drawbacks compared
>>> to Java's, but doesn't this also go the other way around? Canonical utility
>>> functions breach object-oriented code-style, making users write procedural
>>> code like Utils.doSome(obj, params) instead of obj.doSome(params). Its
>>> common issue users just aren't aware of the existence of certain utility
>>> classes and end up with nonoptimal code.
>>> Code without extension methods is always much more verbose, if the API
>>> is supposed to be fluent developer could end up with deep nested
>>> invocations. This brings numerous problems, such as majorly reduced
>>> readability, as the utility methods wrap each other and the developer reads
>>> the processing pipeline "from the end". Also reduced readability always
>>> means increased change of errors.
>>> Writing code using utility methods instead of extensions is just slower,
>>> developers have to waste more time writing a statement than it would be
>>> with extension methods.
>>> Some other advantages I will list below, after this list is ended.
>>>
>>> 5. One of the answers from the first thread you provided (
>>> https://stackoverflow.com/a/29494337) states that omitting extension
>>> methods is a "philosophical choice", as API developers should define
>>> the API. I have to strongly disagree with that. Extension methods are NOT
>>> part of the API, they are EXTENSION to it. It does not breach
>>> encapsulation as it can't access any internal members of API classes.
>>> Extensions have to be imported explicitly (not the containing class), so
>>> they are explicitly mentioned in the imports list. Also, are utility
>>> methods also breaching this rule then? The only real difference I see is
>>> differences in notation, and extension methods are clearly much more
>>> concise.
>>>
>>> Now moving on to some of my personal points. I am also developing some
>>> core libs APIs, and sometimes extension methods are just craving to be
>>> used. Modifying widely-used interfaces is always painful, but that's the
>>> only way to provide a concise way to communicate with existing APIs.
>>> Moreover, Java is an old language and some internal implementations of
>>> APIs, like Stream implementations, are so juncted that adding something new
>>> to these classes directly becomes a spec-ops task. Some APIs, like Gatherer
>>> API or Collector API, arise just from this simple necessity to introduce
>>> new behaviour without modifying extended class itself.
>>>
>>> Extension methods are de-facto standard for modern languages: C#,
>>> Kotlin, Swift, Rust and any other modern language provide this option. JS
>>> also has its own unique way of extending APIs. The only modern widely-used
>>> language that does not have extension methods is Python, but that only
>>> applies to built-ins, custom classes could be extended as well. When Java
>>> refuses to introduce this feature, I suffer major damage in the eyes of
>>> potential switchers from ANY other language available right now, which is
>>> retrograde and, as for me and any other supporter of Java, really upsetting.
>>>
>>> Introduction of extension will not invalidate previously written code:
>>> if one wants, they can still use utilities as earlier and pretend that
>>> nothing happened. However, for other, significant, if not to say major,
>>> part of the community, this would be a valuable addition..Virtually every
>>> Java utility library: lombok, manifold, xtend - provide extension method
>>> functionality, which clearly shows there is a demand for a feature.
>>>
>>> The extension methods are just syntax sugar, nothing more. They provide
>>> better developer experience, make code less verbose and more readable,
>>> which reduces chance of errors and helps to develop apps faster, while not
>>> affecting performance in any way, which is crucial in today's world and may
>>> be a major concurrent advantage.
>>>
>>> Also, last but not least, noone from Java developers teams will have to
>>> put efforts into implementation. I am willing to take one full feature
>>> development lifecycle, from drafts to testing and integration. Of course,
>>> final changes will need to be reviewed, but I don't think this will be an
>>> unbearable burden. Regarding implementation, these changes are really
>>> non-invasive, and are really unlikely to introduce any issues, it already
>>> passes all existing tests.
>>>
>>> I sincerely hope this letter will bring up this discussion once again,
>>> as I am open for dialogue, but I am standing my ground about numerous
>>> advantages this feature has. If that's possible, I may file a draft JEP and
>>> let the community vote for or against it, to see what Java users think
>>> about this proposal.
>>>
>>> Best regards,
>>> Hoping to receive some feedback
>>>
>>> ??, 23 ???. 2024??. ? 07:01, Ethan McCue <ethan at mccue.dev>:
>>>
>>>> This subject has been addressed publicly by the language team at
>>>> various points. These are just a few I found, I'm sure there is more
>>>> elaboration out there.
>>>>
>>>> Implementation choices aside, the API of "add a static method and mark
>>>> it as an "extension method", call like instance method" seems to have been
>>>> rejected.
>>>>
>>>> > C# extension methods have some very serious drawbacks compared to
>>>> Java's default methods (for example, poor reflective discoverability, poor
>>>> discoverability through documentation, not overrideable, require ad-hoc
>>>> conflict-management rules)
>>>>
>>>>
>>>> https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio
>>>>
>>>> > What I believe you are hoping for is the ability to "monkey-patch" a
>>>> method into a class you do not control, but Java does not give you that (by
>>>> design; it was considered and rejected.)
>>>>
>>>>
>>>> https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class
>>>>
>>>>
>>>> On Mon, Apr 22, 2024 at 7:24?PM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> Subject: Proposal for Introducing Extension Methods to Java
>>>>>
>>>>> Dear Java Development Team,
>>>>>
>>>>> I hope this email finds you all in good spirits. I am writing to
>>>>> propose the integration of extension methods into the Java programming
>>>>> language, a feature that I believe holds considerable promise in enhancing
>>>>> code readability and maintainability.
>>>>>
>>>>> Extension methods offer a means to extend the functionality of
>>>>> existing classes in a manner that aligns with Java's principles of static
>>>>> typing and object-oriented design. The proposed syntax, exemplified as
>>>>> follows:
>>>>>
>>>>> public static void extensionMethod(extends String s) { ... }
>>>>>
>>>>> adheres to established conventions while providing a concise and
>>>>> intuitive means of extending class behavior. Notably, the use of the
>>>>> `extends` keyword preceding the type parameter clearly denotes the class to
>>>>> be extended, while the method itself is declared as a static member of a
>>>>> class.
>>>>>
>>>>> I wish to emphasize several advantages of extension methods over
>>>>> traditional utility functions. Firstly, extension methods offer a more
>>>>> cohesive approach to code organization by associating functionality
>>>>> directly with the class it extends. This promotes code clarity and reduces
>>>>> cognitive overhead for developers, particularly when working with complex
>>>>> codebases.
>>>>>
>>>>> Secondly, extension methods enhance code discoverability and usability
>>>>> by integrating seamlessly into the class they extend. This integration
>>>>> allows developers to leverage IDE features such as auto-completion and
>>>>> documentation tooltips, thereby facilitating more efficient code
>>>>> exploration and utilization.
>>>>>
>>>>> Lastly, extension methods promote code reusability without the need
>>>>> for subclassing or inheritance, thereby mitigating the risks associated
>>>>> with tight coupling and inheritance hierarchies. This modularity encourages
>>>>> a more flexible and adaptable codebase, conducive to long-term
>>>>> maintainability and scalability.
>>>>>
>>>>> In light of these benefits, I believe that the integration of
>>>>> extension methods into Java would represent a significant step forward for
>>>>> the language, aligning it more closely with modern programming paradigms
>>>>> while retaining its core strengths.
>>>>>
>>>>> I am eager to discuss this proposal further and collaborate with you
>>>>> all on its implementation. Your insights and feedback would be invaluable
>>>>> in shaping the future direction of Java development.
>>>>>
>>>>> Thank you for considering this proposal. I look forward to our
>>>>> discussion.
>>>>>
>>>>> The draft implementation can be found in the following branch of the
>>>>> repository: https://github.com/Evemose/jdk/tree/extension-methods. I
>>>>> am new to Java compiler development, so any tips or remarks about what I
>>>>> have done in the wrong way or in the wrong place. I will add complete test
>>>>> coverage a bit later, but for now, there is "jdk" archive in the root
>>>>> directory of repo, which contains built in jdk for windows x86-64. If
>>>>> someone is willing to participate in testing as user, I would appreciate
>>>>> any help.
>>>>>
>>>>> Best regards
>>>>>
>>>>> PS: Note about internal implementation: it introduces a new flag -
>>>>> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
>>>>> bit in a long value type that has not been taken by flags. Not sure what
>>>>> the compiler development community should do about this, but it feels like
>>>>> it could be an obstacle to new features that might be introduced later.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/c33ce5fa/attachment-0001.htm>

From hannesw at openjdk.org  Tue Apr 23 16:24:58 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 23 Apr 2024 16:24:58 GMT
Subject: RFR: 8294880: Review running time of
 jdk/internal/shellsupport/doc/JavadocHelperTest.java [v2]
In-Reply-To: <f1InD5kPf0hXmiR6kpFCKl4j2iO8QIuhT6KLDcS1YmU=.d5f19994-7281-42d0-81f8-caec7454d851@github.com>
References: <f1InD5kPf0hXmiR6kpFCKl4j2iO8QIuhT6KLDcS1YmU=.d5f19994-7281-42d0-81f8-caec7454d851@github.com>
Message-ID: <coDzpvjtRPquOBXYaA125lAVBOi5uR4oC4j7Cly5apw=.ea33846f-00c7-414d-80b5-c96e532ac3e4@github.com>

> Please review a change to move a long-running shellsupport test from langtools tier1 to tier2, while modifying the tier1 test to only retrieve doc comments for members of `java.lang.StringBuilder`, which is where [the original bug](https://bugs.openjdk.org/browse/JDK-8189778) occurred.  This reduces the running time in the tier1 test from around 90 seconds to 2 seconds on my computer. The tier1 test also adds a non-null check for retrieved doc comments.
> 
> I used the existing `langtools_jshell_unstable` test group to add the new test in langtools tier2, which is not a perfect match for the test, but close enough and helps to keep langtools `TEST.groups` file simple.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Move FullJavaDocHelperTest.java into its own group

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18837/files
  - new: https://git.openjdk.org/jdk/pull/18837/files/340a3b4f..7a45c94d

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

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

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

From darcy at openjdk.org  Tue Apr 23 19:37:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Apr 2024 19:37:28 GMT
Subject: RFR: 8309881: Qualified name of a type element depends on its
 origin (source vs class)
In-Reply-To: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
References: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
Message-ID: <4ZaFgjTp1VyD3nAD1yfv_Y6a-EMXWXjc9q5SXbUO8FA=.be784e38-7eea-4a58-9ec8-e35866b1d32a@github.com>

On Tue, 23 Apr 2024 14:41:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `javax.lang.model.type.TypeMirror::toString` says: "Any names embedded in the result are qualified if possible."
> However in reality the form of the names depends on the source vs.class origin.
> 
> This patch enforces qualified name to be used.
> 
> Please review.
> 
> Thanks,
> Adam

Hi @asotona ,
The change looks fine, but please file a quick CSR for this issue to note the behavioral change. For completeness, I think this issue should get a release note.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18917#pullrequestreview-2018142912

From jlahoda at openjdk.org  Tue Apr 23 20:06:43 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 23 Apr 2024 20:06:43 GMT
Subject: RFR: 8328481: Implement Module Imports [v12]
In-Reply-To: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
References: <qyvysdjU6Gx6waBESJl8_UoLbZtYmIaALDWzTzmee80=.c60cc9a8-2061-4c68-886c-57823084a941@github.com>
Message-ID: <-ouD9nIv2qwF1P1KJmrFi8K-WKx3wdrzx4qcT5BxN6M=.19abc97e-05b9-47ac-8620-aa0121bbb27c@github.com>

> This is an implementation of JEP JDK-8315129: Module Import Declarations (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
> 
> It is mostly straightforward - the module imports are parsed, and then expanded to import-on-demand in `TypeEnter`.
> There is a few notable aspects, however:
> - the AST node for import (`JCImport`) is holding the imported element as a field access, because so far, the imported element always had to have a '.' (even for import-on-demand). But for module imports, it is permissible to import from a module whose name does not have a dot (`import module m;`). The use of field access for ordinary import seems very useful, so I preferred to keep that, and created a new internal-only AST node for module imports. There is still only one public API AST node/interface, so this is purely an implementation choice.
> - JShell now supports module imports as well; and the default, implicit, script is changed to use it to import all of `java.base` if preview is enabled. It is expected that the default would be changed if/when the module imports feature is finalized.

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

  Fixing Imports test on Windows.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18614/files
  - new: https://git.openjdk.org/jdk/pull/18614/files/cbc363ab..1a621447

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

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

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

From jjg at openjdk.org  Tue Apr 23 20:26:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 20:26:57 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v7]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <RHregxT5ye-XTQEWzPqLPVZXgm2Id82FV--QqNLAJMc=.4c5c4e64-3a6c-438f-a877-e6f9689986fd@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=06
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From duke at openjdk.org  Tue Apr 23 20:35:33 2024
From: duke at openjdk.org (ExE Boss)
Date: Tue, 23 Apr 2024 20:35:33 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>

On Tue, 23 Apr 2024 13:54:42 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

These?can be?`private` as?they?re not?used?outside the?`ArrayList` class?nest:

src/java.base/share/classes/java/util/ArrayList.java line 324:

> 322:     }
> 323: 
> 324:     int findIndexInRange(Predicate<? super E> filter, int start, int end) {

Suggestion:

    private int findIndexInRange(Predicate<? super E> filter, int start, int end) {

src/java.base/share/classes/java/util/ArrayList.java line 380:

> 378:     }
> 379: 
> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

Suggestion:

    private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

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

PR Review: https://git.openjdk.org/jdk/pull/18639#pullrequestreview-2018246257
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1576858232
PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1576858391

From asotona at openjdk.org  Wed Apr 24 06:19:44 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 24 Apr 2024 06:19:44 GMT
Subject: RFR: 8309881: Qualified name of a type element depends on its
 origin (source vs class) [v2]
In-Reply-To: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
References: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
Message-ID: <al0zXd5J7Q_YIrNN3P_RXtKbNNl1TZkjyLw9yMy6Rpo=.cd9f9c4a-0748-453c-a4c6-e238aae5a326@github.com>

> `javax.lang.model.type.TypeMirror::toString` says: "Any names embedded in the result are qualified if possible."
> However in reality the form of the names depends on the source vs.class origin.
> 
> This patch enforces qualified name to be used.
> 
> Please review.
> 
> Thanks,
> Adam

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

  Suggested test revealed the fix is not sufficient
  
  Co-authored-by: jlahoda

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18917/files
  - new: https://git.openjdk.org/jdk/pull/18917/files/1023edfe..16b72b98

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

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

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

From duke at openjdk.org  Wed Apr 24 08:32:37 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 08:32:37 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
Message-ID: <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>

On Tue, 23 Apr 2024 20:30:22 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Evemose has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Added Objects import to sun List
>>  - Replaced on-demand import in com.sun....List
>>  - added non-null assertions
>
> src/java.base/share/classes/java/util/ArrayList.java line 380:
> 
>> 378:     }
>> 379: 
>> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
> 
> Suggestion:
> 
>     private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {

Yeah i though about it but indexOfRange arent private here so either there is a point in it or its just legacy without any particular meaning

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1577501340

From rotan.olexandr at gmail.com  Wed Apr 24 09:24:36 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 12:24:36 +0300
Subject: Properties
Message-ID: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>

As I see extension methods haven't been accepted as gladly as expected, I
decided to put them in stash for now and work on some other features that I
think Java lacks for now.

I think properties (seamless access to them to be precise) would be a great
addition, but having my previous experience, I want to ask were there any
discussions about that previously.

Also, if there wasn't, or at least properties were not rejected, I have a
few questions regarding implementation that I want to know community
opinion about.
Firstly, I think, having all the codebase populated with get and set
accessors, the best way to add such thing would be to treat getX as a get
accessor to property X and setX correspondingly.
Secondly, unlike C# for example, I think that absence of property accessor
should just imply direct access instead of forbidding it (in C#, int a
{get;} implies a is effectively immutable)
Lastly, for the sake of backward compatibility, I guess if a variable is
directly visible in scope, I think that it should be modified directly
rather than through an assessor. While that severely damages data
integrity, this will not introduce any source code incompatibilities
(bytecode incompatibilities isn't a thing here if properties will
be desugared in compile-time)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/536db468/attachment-0001.htm>

From ethan at mccue.dev  Wed Apr 24 11:26:44 2024
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 24 Apr 2024 07:26:44 -0400
Subject: Properties
In-Reply-To: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
Message-ID: <CA+NR86gSQtOC1tBgJiAs8UQHA3Xt2WjuGtKEApHhipO1YS3iAA@mail.gmail.com>

First few minutes of this video.

https://youtu.be/mE4iTvxLTC4?si=V9l0B6opxmkIFi7d

On Wed, Apr 24, 2024, 5:25 AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> As I see extension methods haven't been accepted as gladly as expected, I
> decided to put them in stash for now and work on some other features that I
> think Java lacks for now.
>
> I think properties (seamless access to them to be precise) would be a
> great addition, but having my previous experience, I want to ask were there
> any discussions about that previously.
>
> Also, if there wasn't, or at least properties were not rejected, I have a
> few questions regarding implementation that I want to know community
> opinion about.
> Firstly, I think, having all the codebase populated with get and set
> accessors, the best way to add such thing would be to treat getX as a get
> accessor to property X and setX correspondingly.
> Secondly, unlike C# for example, I think that absence of property accessor
> should just imply direct access instead of forbidding it (in C#, int a
> {get;} implies a is effectively immutable)
> Lastly, for the sake of backward compatibility, I guess if a variable is
> directly visible in scope, I think that it should be modified directly
> rather than through an assessor. While that severely damages data
> integrity, this will not introduce any source code incompatibilities
> (bytecode incompatibilities isn't a thing here if properties will
> be desugared in compile-time)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/84b4354e/attachment.htm>

From rotan.olexandr at gmail.com  Wed Apr 24 11:34:31 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 14:34:31 +0300
Subject: Properties
In-Reply-To: <CA+NR86gSQtOC1tBgJiAs8UQHA3Xt2WjuGtKEApHhipO1YS3iAA@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CA+NR86gSQtOC1tBgJiAs8UQHA3Xt2WjuGtKEApHhipO1YS3iAA@mail.gmail.com>
Message-ID: <CAP=Y=q8n1G-5yyaFPtnL5bKWH6VRQRSo6do3=4TGQqYXD8tOHw@mail.gmail.com>

So just to clarify: this would be a welcomed feature to add? Also this
would require some modification of records (or adjusting for them). As far
as I know they are part of Valhalla, so I better head there with such
proposal?

??, 24 ???. 2024??. ? 14:26, Ethan McCue <ethan at mccue.dev>:

> First few minutes of this video.
>
> https://youtu.be/mE4iTvxLTC4?si=V9l0B6opxmkIFi7d
>
> On Wed, Apr 24, 2024, 5:25 AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> As I see extension methods haven't been accepted as gladly as expected, I
>> decided to put them in stash for now and work on some other features that I
>> think Java lacks for now.
>>
>> I think properties (seamless access to them to be precise) would be a
>> great addition, but having my previous experience, I want to ask were there
>> any discussions about that previously.
>>
>> Also, if there wasn't, or at least properties were not rejected, I have a
>> few questions regarding implementation that I want to know community
>> opinion about.
>> Firstly, I think, having all the codebase populated with get and set
>> accessors, the best way to add such thing would be to treat getX as a get
>> accessor to property X and setX correspondingly.
>> Secondly, unlike C# for example, I think that absence of property
>> accessor should just imply direct access instead of forbidding it (in C#,
>> int a {get;} implies a is effectively immutable)
>> Lastly, for the sake of backward compatibility, I guess if a variable is
>> directly visible in scope, I think that it should be modified directly
>> rather than through an assessor. While that severely damages data
>> integrity, this will not introduce any source code incompatibilities
>> (bytecode incompatibilities isn't a thing here if properties will
>> be desugared in compile-time)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/780a02e1/attachment.htm>

From liach at openjdk.org  Wed Apr 24 11:53:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 Apr 2024 11:53:33 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
 <-0V3ZTaf1NcBXcx0uNaIwPEx8VH5fR0b8avQZTaxr2E=.d258b611-d6ab-4271-acd3-9a802026fe12@github.com>
 <dQpbKfwIB2lTj3HPrHmT-ts4LhUvA2LiHWJvEl3j71o=.0dade48e-407e-4f81-8002-23c3f705d106@github.com>
Message-ID: <i0i_w2N83Dr4fTr6Hsi_sE3gvpqzHmOEzn38Rg9MeBA=.919fd23d-1d94-4947-a475-ced2a3c9d38f@github.com>

On Wed, 24 Apr 2024 08:29:56 GMT, Evemose <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ArrayList.java line 380:
>> 
>>> 378:     }
>>> 379: 
>>> 380:     int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
>> 
>> Suggestion:
>> 
>>     private int findLastIndexInRange(Predicate<? super E> filter, int start, int end) {
>
> Yeah i thought about it but indexOfRange isnt private here so either there is a point in it or its just legacy without any particular meaning

It is legacy to avoid bridge generation from the SubList.

Before introduction of nestmates in JDK 11, private methods and fields called by inner classes should be declared package-private, as javac has to generate bridge methods at each call site to abide to JVM rules (inner classes are just another class in the package so couldn't call private methods).

This is also the reason you can see patterns like

private static class Holder {
    static final Value instance = Value.initialize();
}

where the `static final` is not `private` qualified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18639#discussion_r1577751899

From duke at openjdk.org  Wed Apr 24 12:00:47 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 12:00:47 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v13]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

 - ArrayList made findIndexInRange private
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ArrayList made findLastIndexInRange private
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/349ee6bd..d2f358b3

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

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

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

From duke at openjdk.org  Wed Apr 24 12:00:48 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 12:00:48 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v12]
In-Reply-To: <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <yREc13jIv1neUhXqzSPxNxFkL9b4xH-SDr6wpay5iaY=.7a981cd8-db38-4270-96ee-58250bc62ca5@github.com>
Message-ID: <f1IZW8YZtGsA3RlglXKwXy-ILXuvOUhHjpFS4ygmMNs=.c9c6b76b-8c0a-490c-b961-200333419414@github.com>

On Tue, 23 Apr 2024 13:54:42 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Added Objects import to sun List
>  - Replaced on-demand import in com.sun....List
>  - added non-null assertions

Commited proposed changes. Also still would appreciate any help about what to write it csr template (you can see what I figured a few messages above)

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2074774403

From liangchenblue at gmail.com  Wed Apr 24 12:18:21 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 07:18:21 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
Message-ID: <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>

Hi Oleksandr,
Such properties are an antipattern in Java nowadays. We should prefer
immutable objects and records/builders instead. Mutations should happen on
the stack as much as possible for thread safety. And record components
already accomplish the "property" feature in an immutable sense.

Regards

On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> As I see extension methods haven't been accepted as gladly as expected, I
> decided to put them in stash for now and work on some other features that I
> think Java lacks for now.
>
> I think properties (seamless access to them to be precise) would be a
> great addition, but having my previous experience, I want to ask were there
> any discussions about that previously.
>
> Also, if there wasn't, or at least properties were not rejected, I have a
> few questions regarding implementation that I want to know community
> opinion about.
> Firstly, I think, having all the codebase populated with get and set
> accessors, the best way to add such thing would be to treat getX as a get
> accessor to property X and setX correspondingly.
> Secondly, unlike C# for example, I think that absence of property accessor
> should just imply direct access instead of forbidding it (in C#, int a
> {get;} implies a is effectively immutable)
> Lastly, for the sake of backward compatibility, I guess if a variable is
> directly visible in scope, I think that it should be modified directly
> rather than through an assessor. While that severely damages data
> integrity, this will not introduce any source code incompatibilities
> (bytecode incompatibilities isn't a thing here if properties will
> be desugared in compile-time)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/b0b30f9b/attachment-0001.htm>

From rotan.olexandr at gmail.com  Wed Apr 24 12:22:29 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 15:22:29 +0300
Subject: Properties
In-Reply-To: <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
Message-ID: <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>

I am not fully getting it. So things like foo.prop = val is antipattern
while foo.setProp(val) is not? What about objects like entities, where
constant data mutations are inevitable and classes are mutable by spec?

On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:

> Hi Oleksandr,
> Such properties are an antipattern in Java nowadays. We should prefer
> immutable objects and records/builders instead. Mutations should happen on
> the stack as much as possible for thread safety. And record components
> already accomplish the "property" feature in an immutable sense.
>
> Regards
>
> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> As I see extension methods haven't been accepted as gladly as expected, I
>> decided to put them in stash for now and work on some other features that I
>> think Java lacks for now.
>>
>> I think properties (seamless access to them to be precise) would be a
>> great addition, but having my previous experience, I want to ask were there
>> any discussions about that previously.
>>
>> Also, if there wasn't, or at least properties were not rejected, I have a
>> few questions regarding implementation that I want to know community
>> opinion about.
>> Firstly, I think, having all the codebase populated with get and set
>> accessors, the best way to add such thing would be to treat getX as a get
>> accessor to property X and setX correspondingly.
>> Secondly, unlike C# for example, I think that absence of property
>> accessor should just imply direct access instead of forbidding it (in C#,
>> int a {get;} implies a is effectively immutable)
>> Lastly, for the sake of backward compatibility, I guess if a variable is
>> directly visible in scope, I think that it should be modified directly
>> rather than through an assessor. While that severely damages data
>> integrity, this will not introduce any source code incompatibilities
>> (bytecode incompatibilities isn't a thing here if properties will
>> be desugared in compile-time)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/552c0ad2/attachment.htm>

From liangchenblue at gmail.com  Wed Apr 24 12:29:50 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 07:29:50 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
Message-ID: <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>

No, field modification is an antipattern and should be avoided at best, so
both of the direct setfield instruction or a setter call are antipatterns,
as these can be made from other threads and cause unpredictable memory
effects. For entity mutations, it's recommended that they are only accessed
single threaded to avoid incorrect programs. However, you probably still
don't want setters, as this implies the fields are not related to each
other and all cartesian products of all fields are possible, which is
rarely the case and such usages are still better covered by records.

Regards

On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> I am not fully getting it. So things like foo.prop = val is antipattern
> while foo.setProp(val) is not? What about objects like entities, where
> constant data mutations are inevitable and classes are mutable by spec?
>
> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>
>> Hi Oleksandr,
>> Such properties are an antipattern in Java nowadays. We should prefer
>> immutable objects and records/builders instead. Mutations should happen on
>> the stack as much as possible for thread safety. And record components
>> already accomplish the "property" feature in an immutable sense.
>>
>> Regards
>>
>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> As I see extension methods haven't been accepted as gladly as expected,
>>> I decided to put them in stash for now and work on some other features that
>>> I think Java lacks for now.
>>>
>>> I think properties (seamless access to them to be precise) would be a
>>> great addition, but having my previous experience, I want to ask were there
>>> any discussions about that previously.
>>>
>>> Also, if there wasn't, or at least properties were not rejected, I have
>>> a few questions regarding implementation that I want to know community
>>> opinion about.
>>> Firstly, I think, having all the codebase populated with get and set
>>> accessors, the best way to add such thing would be to treat getX as a get
>>> accessor to property X and setX correspondingly.
>>> Secondly, unlike C# for example, I think that absence of property
>>> accessor should just imply direct access instead of forbidding it (in C#,
>>> int a {get;} implies a is effectively immutable)
>>> Lastly, for the sake of backward compatibility, I guess if a variable is
>>> directly visible in scope, I think that it should be modified directly
>>> rather than through an assessor. While that severely damages data
>>> integrity, this will not introduce any source code incompatibilities
>>> (bytecode incompatibilities isn't a thing here if properties will
>>> be desugared in compile-time)
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/86d257e2/attachment.htm>

From ron.pressler at oracle.com  Wed Apr 24 12:32:00 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 24 Apr 2024 12:32:00 +0000
Subject: Properties
In-Reply-To: <CAP=Y=q8n1G-5yyaFPtnL5bKWH6VRQRSo6do3=4TGQqYXD8tOHw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CA+NR86gSQtOC1tBgJiAs8UQHA3Xt2WjuGtKEApHhipO1YS3iAA@mail.gmail.com>
 <CAP=Y=q8n1G-5yyaFPtnL5bKWH6VRQRSo6do3=4TGQqYXD8tOHw@mail.gmail.com>
Message-ID: <FA5130DA-D8FB-4647-9413-7B072F1659AD@oracle.com>



> On 24 Apr 2024, at 12:34, ??-24 ????????? ?????? <rotan.olexandr at gmail.com> wrote:
> 
> So just to clarify: this would be a welcomed feature to add? Also this would require some modification of records (or adjusting for them). As far as I know they are part of Valhalla, so I better head there with such proposal?


As others have said, we (currently) consider properties an anti-feature. And, as you can probably tell, actually implementing new features in the compiler is quite easy ? that?s not where we need help. Most of our effort goes into identifying the right problems to solve. A feature that takes a single programmer a month or two to implement is usually preceded by some years of exploration and ?problem distillation? by more than a few people.

The best contribution to the JDK is not code ? which is the part that doesn?t take much time and effort ? but reporting experience that would help identify the biggest problems. It?s a more difficult kind of contribution, but a much more valuable one. A single programmer can implement a feature, but it takes input from many, of different levels of experience and working in different fields, to identify the right problems and understand them.

? Ron

From ron.pressler at oracle.com  Wed Apr 24 12:44:21 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 24 Apr 2024 12:44:21 +0000
Subject: Properties
In-Reply-To: <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
Message-ID: <687050FA-3D9A-4AA9-B120-AE9056A3FE9A@oracle.com>



> On 24 Apr 2024, at 13:22, ??-24 ????????? ?????? <rotan.olexandr at gmail.com> wrote:
> 
> I am not fully getting it. So things like foo.prop = val is antipattern while foo.setProp(val) is not? What about objects like entities, where constant data mutations are inevitable and classes are mutable by spec?
> 

The more code does the better way, the less of a problem setters become, and so the motivation for making writing them easier with properties is reduced (not to mention that making writing setters easier would only encourage their use and achieve the opposite of the effect we want). 

While some programmers like having lots of features, each addressing a specific problem ? and some programming languages choose to accommodate them ? we believe that most programmers prefer languages with fewer features, and so the trick is finding ways to *avoid* adding language features. The way to do that is to find a smaller number of powerful features that address multiple problems ? even if not perfectly ? rather than add a language feature for every problem. For example, records help make serialization safer, they help with deconstruction (through pattern matching), and at the same time they also *reduce* ? even if not eliminate ? the need for setters, making them a smaller problem. Not every problem merits a language feature (which complicates the language and thus creates a new problem).

? Ron


From rotan.olexandr at gmail.com  Wed Apr 24 12:54:50 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 15:54:50 +0300
Subject: Properties
In-Reply-To: <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
Message-ID: <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>

Well as a compromise between mutable and immutable objects there could be
init only fields. What is regarding to property mutations being
antipattern, it may have as many downsides as possible, but still is
inevitable in production, and, moreover, is one of the most popular tasks
to perform. Entities are mutable by specification, and there is nothing we
can really do about that.

I also appreciate Ron Pressler's clarifications, this makes everything a
lot more understandible for me.

What I would like to say on this topic is that while immutability is
understandible trend nowadays, when we are talking about production, the
major part of the work is working with entities, which are inheritandably
mutable (and in many cases at least some of their properties should remain
that way).

Current workarounds that exist to avoid undesired mutations is to expose
public constructor with required fields while making no-args constructor
protected, along with ommiting setters for such fields.

Init only fields would probably be fix to problems of mutability, I may
also do some research on them, but what I would like to say is that some
properties are just mutable by their nature (like email fields, or amount
of attempts left), and this is still a very widely encountered case and
will surely remain so.

Also, that's all discussion about set accessors. What about get accessors,
I don't really see downsides of them, and it would be a neat addition that
could freshen up a language

Edit: Ron, I saw your last message just now, so I will reply to some of the
points here.

Firstly, I have already addressed that setters are effectively inevitable,
init only fields could do the trick you are trying to do by disencouraging
setters (which is a great by the way, I also think that even for mutable
objects immutability should be preserved where possible).

About language complication, I get this point, concise syntax of Java is
why I fell in love with it in the first place. But as the time moves, it
becomes clear that some features just become industry standard: properties,
previously discarded extensions, object deconstruction etc. While I agree
that language should not just blindly accept every possible feature, wide
usage of some may indicate (and indicates) there is a demand for those. I
understand the desire to make language better by omitting the road that
once tricked languages like c++, but I think sometimes, when demand is high
enough, we should let users have what they want. At the end of the day,
trere isn't a problem in more flexible approaches, but some of the most
common problems, in my opinion, should be addressed specifically. This way
we could have a perfect balance between user experience and code quality.

On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:

> No, field modification is an antipattern and should be avoided at best, so
> both of the direct setfield instruction or a setter call are antipatterns,
> as these can be made from other threads and cause unpredictable memory
> effects. For entity mutations, it's recommended that they are only accessed
> single threaded to avoid incorrect programs. However, you probably still
> don't want setters, as this implies the fields are not related to each
> other and all cartesian products of all fields are possible, which is
> rarely the case and such usages are still better covered by records.
>
> Regards
>
> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> I am not fully getting it. So things like foo.prop = val is antipattern
>> while foo.setProp(val) is not? What about objects like entities, where
>> constant data mutations are inevitable and classes are mutable by spec?
>>
>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>
>>> Hi Oleksandr,
>>> Such properties are an antipattern in Java nowadays. We should prefer
>>> immutable objects and records/builders instead. Mutations should happen on
>>> the stack as much as possible for thread safety. And record components
>>> already accomplish the "property" feature in an immutable sense.
>>>
>>> Regards
>>>
>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> As I see extension methods haven't been accepted as gladly as expected,
>>>> I decided to put them in stash for now and work on some other features that
>>>> I think Java lacks for now.
>>>>
>>>> I think properties (seamless access to them to be precise) would be a
>>>> great addition, but having my previous experience, I want to ask were there
>>>> any discussions about that previously.
>>>>
>>>> Also, if there wasn't, or at least properties were not rejected, I have
>>>> a few questions regarding implementation that I want to know community
>>>> opinion about.
>>>> Firstly, I think, having all the codebase populated with get and set
>>>> accessors, the best way to add such thing would be to treat getX as a get
>>>> accessor to property X and setX correspondingly.
>>>> Secondly, unlike C# for example, I think that absence of property
>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>> int a {get;} implies a is effectively immutable)
>>>> Lastly, for the sake of backward compatibility, I guess if a variable
>>>> is directly visible in scope, I think that it should be modified directly
>>>> rather than through an assessor. While that severely damages data
>>>> integrity, this will not introduce any source code incompatibilities
>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>> be desugared in compile-time)
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/6cff7188/attachment-0001.htm>

From liangchenblue at gmail.com  Wed Apr 24 13:04:18 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 08:04:18 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
Message-ID: <CABe8uE39=6e6OUsfVUnocd7HYbe=HmpH4VFn=9C-ecTt6kL3mw@mail.gmail.com>

Hi Oleksandr,
Also a thing of note, if you have a mutable object, getter is dangerous...
An example being:
record IntArray(int[] value) {}
Is this record correct? No, the getter accesses the value array directly,
making it mutable by users. (Similarly, the record hashCode and equals are
improper as well)
You for sure have heard of other details for getters, such as deep copies,
or return an unmodifiable wrapper for collections.
Even for less controversial operations like getting the amount left, this
operation is most likely done across threads (say UI thread and worker
thread), so your variable read wouldn't be a plain read and would be
getAcquire/getVolatile, which requires an explicit getter behavior, too.

In conclusion, getter logic isn't as simple as returning a field; it has
various other actions and as a result, isn't well modeled by a simple
property.

Regards

On Wed, Apr 24, 2024 at 7:55?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Well as a compromise between mutable and immutable objects there could be
> init only fields. What is regarding to property mutations being
> antipattern, it may have as many downsides as possible, but still is
> inevitable in production, and, moreover, is one of the most popular tasks
> to perform. Entities are mutable by specification, and there is nothing we
> can really do about that.
>
> I also appreciate Ron Pressler's clarifications, this makes everything a
> lot more understandible for me.
>
> What I would like to say on this topic is that while immutability is
> understandible trend nowadays, when we are talking about production, the
> major part of the work is working with entities, which are inheritandably
> mutable (and in many cases at least some of their properties should remain
> that way).
>
> Current workarounds that exist to avoid undesired mutations is to expose
> public constructor with required fields while making no-args constructor
> protected, along with ommiting setters for such fields.
>
> Init only fields would probably be fix to problems of mutability, I may
> also do some research on them, but what I would like to say is that some
> properties are just mutable by their nature (like email fields, or amount
> of attempts left), and this is still a very widely encountered case and
> will surely remain so.
>
> Also, that's all discussion about set accessors. What about get accessors,
> I don't really see downsides of them, and it would be a neat addition that
> could freshen up a language
>
> Edit: Ron, I saw your last message just now, so I will reply to some of
> the points here.
>
> Firstly, I have already addressed that setters are effectively inevitable,
> init only fields could do the trick you are trying to do by disencouraging
> setters (which is a great by the way, I also think that even for mutable
> objects immutability should be preserved where possible).
>
> About language complication, I get this point, concise syntax of Java is
> why I fell in love with it in the first place. But as the time moves, it
> becomes clear that some features just become industry standard: properties,
> previously discarded extensions, object deconstruction etc. While I agree
> that language should not just blindly accept every possible feature, wide
> usage of some may indicate (and indicates) there is a demand for those. I
> understand the desire to make language better by omitting the road that
> once tricked languages like c++, but I think sometimes, when demand is high
> enough, we should let users have what they want. At the end of the day,
> trere isn't a problem in more flexible approaches, but some of the most
> common problems, in my opinion, should be addressed specifically. This way
> we could have a perfect balance between user experience and code quality.
>
> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>
>> No, field modification is an antipattern and should be avoided at best,
>> so both of the direct setfield instruction or a setter call are
>> antipatterns, as these can be made from other threads and cause
>> unpredictable memory effects. For entity mutations, it's recommended that
>> they are only accessed single threaded to avoid incorrect programs.
>> However, you probably still don't want setters, as this implies the fields
>> are not related to each other and all cartesian products of all fields are
>> possible, which is rarely the case and such usages are still better covered
>> by records.
>>
>> Regards
>>
>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> I am not fully getting it. So things like foo.prop = val is antipattern
>>> while foo.setProp(val) is not? What about objects like entities, where
>>> constant data mutations are inevitable and classes are mutable by spec?
>>>
>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>
>>>> Hi Oleksandr,
>>>> Such properties are an antipattern in Java nowadays. We should prefer
>>>> immutable objects and records/builders instead. Mutations should happen on
>>>> the stack as much as possible for thread safety. And record components
>>>> already accomplish the "property" feature in an immutable sense.
>>>>
>>>> Regards
>>>>
>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> As I see extension methods haven't been accepted as gladly as
>>>>> expected, I decided to put them in stash for now and work on some other
>>>>> features that I think Java lacks for now.
>>>>>
>>>>> I think properties (seamless access to them to be precise) would be a
>>>>> great addition, but having my previous experience, I want to ask were there
>>>>> any discussions about that previously.
>>>>>
>>>>> Also, if there wasn't, or at least properties were not rejected, I
>>>>> have a few questions regarding implementation that I want to know community
>>>>> opinion about.
>>>>> Firstly, I think, having all the codebase populated with get and set
>>>>> accessors, the best way to add such thing would be to treat getX as a get
>>>>> accessor to property X and setX correspondingly.
>>>>> Secondly, unlike C# for example, I think that absence of property
>>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>>> int a {get;} implies a is effectively immutable)
>>>>> Lastly, for the sake of backward compatibility, I guess if a variable
>>>>> is directly visible in scope, I think that it should be modified directly
>>>>> rather than through an assessor. While that severely damages data
>>>>> integrity, this will not introduce any source code incompatibilities
>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>> be desugared in compile-time)
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/16b44d63/attachment.htm>

From ron.pressler at oracle.com  Wed Apr 24 13:09:09 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 24 Apr 2024 13:09:09 +0000
Subject: Properties
In-Reply-To: <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
Message-ID: <91802EB7-3B33-4378-8164-677DBC34EC3B@oracle.com>



> On 24 Apr 2024, at 13:54, ??-24 ????????? ?????? <rotan.olexandr at gmail.com> wrote:
> 
> 
> Firstly, I have already addressed that setters are effectively inevitable, init only fields could do the trick you are trying to do by disencouraging setters (which is a great by the way, I also think that even for mutable objects immutability should be preserved where possible).

While setters remain inevitable, if the need for them drops, the problem of writing them more easily becomes smaller, and a smaller problem doesn?t justify a language feature as much as a bigger problem. It makes the cost in complexity of the feature higher with respect to its benefit.

> 
> About language complication, I get this point, concise syntax of Java is why I fell in love with it in the first place. But as the time moves, it becomes clear that some features just become industry standard: properties, previously discarded extensions, object deconstruction etc. While I agree that language should not just blindly accept every possible feature, wide usage of some may indicate (and indicates) there is a demand for those. I understand the desire to make language better by omitting the road that once tricked languages like c++, but I think sometimes, when demand is high enough, we should let users have what they want. At the end of the day, trere isn't a problem in more flexible approaches, but some of the most common problems, in my opinion, should be addressed specifically. This way we could have a perfect balance between user experience and code quality.

First, I don?t agree that properties have become an industry standard. Not all languages, even those newer than Java have them. Secondly, while there is certainly demand for richer languages, relatively speaking that demand is low. The two languages with similar or higher popularity to Java?s have fewer features than Java, not more. Also, I believe that the most popular languages have rarely been particularly rich compared to the alternative. While I don?t think this correlation necessarily implies causation, certainly not direct causation, it is evidence against causation in the opposite direction ? i.e. adding lots of features don?t seem to make languages more popular than languages with fewer features. Of course, as you say, some balance needs to be struck and different languages may address different audiences and find a different balance, our approach is largely focused on spending a lot of time finding the right feature that can address multiple problems. Again, the empirical evidence seems to suggest that a delay in adding features does not seem to adversely affect language adoption.

? Ron

From jlahoda at openjdk.org  Wed Apr 24 13:15:27 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 24 Apr 2024 13:15:27 GMT
Subject: RFR: 8309881: Qualified name of a type element depends on its
 origin (source vs class) [v2]
In-Reply-To: <4ZaFgjTp1VyD3nAD1yfv_Y6a-EMXWXjc9q5SXbUO8FA=.be784e38-7eea-4a58-9ec8-e35866b1d32a@github.com>
References: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
 <4ZaFgjTp1VyD3nAD1yfv_Y6a-EMXWXjc9q5SXbUO8FA=.be784e38-7eea-4a58-9ec8-e35866b1d32a@github.com>
Message-ID: <pnNRhbKoijI31PXMQjC0YdDyiyMYQ0lb-4ugo5U_s_U=.860993b9-5d61-46f2-a311-56fd09010231@github.com>

On Tue, 23 Apr 2024 19:35:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hi @asotona , The change looks fine, but please file a quick CSR for this issue to note the behavioral change. For completeness, I think this issue should get a release note.

FWIW, on a closer look, the problem is actually in Symbol completion - depending on whether the given Symbol (TypeElement) is completed or not, the output is either `java.lang.Runtime.Version` or `java.lang.Runtime$Version`. The change in behavior is therefore much smaller than originally expected, as, in many cases, the API clients were already getting the correct name.

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

PR Comment: https://git.openjdk.org/jdk/pull/18917#issuecomment-2074919932

From adinn at redhat.com  Wed Apr 24 13:22:01 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 24 Apr 2024 14:22:01 +0100
Subject: Properties
In-Reply-To: <687050FA-3D9A-4AA9-B120-AE9056A3FE9A@oracle.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <687050FA-3D9A-4AA9-B120-AE9056A3FE9A@oracle.com>
Message-ID: <9171c71a-0471-461b-82c1-8cd3786ce433@redhat.com>

On 24/04/2024 13:44, Ron Pressler wrote:
> While some programmers like having lots of features, each addressing
> a specific problem ? and some programming languages choose to
> accommodate them ? we believe that most programmers prefer languages
> with fewer features, and so the trick is finding ways to *avoid*
> adding language features. The way to do that is to find a smaller
> number of powerful features that address multiple problems ? even if
> not perfectly ? rather than add a language feature for every problem.
> For example, records help make serialization safer, they help with
> deconstruction (through pattern matching), and at the same time they
> also *reduce* ? even if not eliminate ? the need for setters, making
> them a smaller problem. Not every problem merits a language feature
> (which complicates the language and thus creates a new problem).

Just as an a fortiori to Ron's point I'll note that Java, like most 
managed language runtimes, profits enormously from the fact that it 
offers only a limited set of orthogonal, composable features. This 
design choice dramatically reduces the suite of basic operations that a 
program can employ and *combine*. As a result the circumstances in which 
certain operations and outcomes can occur during execution are much more 
sharply defined than in more feature-rich languages.

The result is a host of opportunities for Java to perform highly 
aggressive optimizations that would be incorrect or, at least, 
frequently have indeterminate validity if attempted in those other 
languages. When combined with the speculative optimization opportunities 
that come from dynamic compilation of an evolving code base (and the 
requisite flip-side of that speculative coin, the ability to 
de-optimize) this puts Java in its own league when it comes to optimized 
performance.

That is a major prize that many of your proposals to extend the language 
will run up against. It is also one that Brian Goetz and the other 
project (Amber/Panama/Loom/CoreLibs/etc) devs who consider, design and 
implement language and lib changes are very well aware of.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From duke at openjdk.org  Wed Apr 24 13:47:32 2024
From: duke at openjdk.org (Evemose)
Date: Wed, 24 Apr 2024 13:47:32 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v13]
In-Reply-To: <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
 <CM_IToa4rOZMEFp_FsVEorJ6u0R3_d4ORrlB-qxP-08=.7a7527e0-1a24-4d54-8944-4a13ce9dee09@github.com>
Message-ID: <qVDxVbDzhmsJ3jJmOlsVMusrzGK2fPpskzFD75r_OUI=.1e449c41-f235-4228-8fea-4cbc3758d621@github.com>

On Wed, 24 Apr 2024 12:00:47 GMT, Evemose <duke at openjdk.org> wrote:

>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
>> 
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
>> 
>> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
>> 
>> Here is a brief overview of the changes made in this pull request:
>> 
>> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
>> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
>> 
>> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
>> 
>> For example, consider the following test case:
>> 
>> List<String> list = new ArrayList<>();
>> list.add("Object one");
>> list.add("NotObject two");
>> list.add("NotObject three");
>> 
>> int index1 = list.indexOf(s -> s.contains("ct t"));
>> System.out.println(index1); // Expected output: 1
>> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
>> System.out.println(index2); // Expected output: 2
>> 
>> 
>> Currently, to achieve the same result, we would have to use a more verbose approach:
>> 
>> int index1 = IntStream.range(0, list.size())
>>                      .filter(i -> list.get(i).contains("ct t"))
>>                      .findFirst()
>>                      .orElse(-1);
>> System.out.println(index1); // Output: 1
>> int index2 = IntStream.range(0, list.size())
>>                          .filter(i -> list.get(i).startsWith("NotObject"))
>>                          .reduce((first, second) -> second)
>>                          .orElse(-1);
>> System.out.println(index2); // Output: 2
>> 
>> 
>> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes bas...
>
> Evemose has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ArrayList made findIndexInRange private
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ArrayList made findLastIndexInRange private
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Seems like run failed due to internal problems of openjdk. I will trigger rerun a bit later.

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

PR Comment: https://git.openjdk.org/jdk/pull/18639#issuecomment-2074989809

From rotan.olexandr at gmail.com  Wed Apr 24 14:13:30 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 17:13:30 +0300
Subject: Properties
In-Reply-To: <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
Message-ID: <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>

>  First, I don?t agree that properties have become an industry standard.
Not all languages, even those newer than Java have them. ....  The two
languages with similar or higher popularity to Java?s have fewer features
than Java, not more.

I have to agree with the point that JS, and Python (as I reckon that's the
ones you are referring to) have less features then Java. However, what I
would like to say is that, in my opinion, they are popular despite, not due
to it. Less features and simple syntax obviously make them easier for
learners, but that mostly comes from their interpreted nature, which comes
at the cost of dramatical performance differences. Still, what the market
currently indicates (I am not an analyst of any kind, this is just my
observations), is that most popular languages, especially for product
companies, are the ones that help *write* code faster at cost of support
terms. I agree with Java prioritizing second over first, but language
paradigms, as for me, should shift along with the market at least to some
extent. So to conclude, while most popular languages *do* have fewer
features, they still provide better developer experience due to their
interpreted nature, and their popularity is caused by better developer
experience, not by the amount of features in them.

> While setters remain inevitable, if the need for them drops, the problem
of writing them more easily becomes smaller, and a smaller problem doesn?t
justify a language feature as much as a bigger problem. It makes the cost
in complexity of the feature higher with respect to its benefit.

While it makes setters a lesser problem, does it make it that small for
pros to not outweigh cons? In modern applications, 99% of the time
concurrency is handled by controller pattern, while the
processing environment is single-threaded, and all possible problems are
covered by things like entity managers. Data mutations are non-concurrent
in the majority of situations, if we exclude race conditions at the
database level.

> I don?t agree that properties have become an industry standard.

I did some research on that. Let's consider only backend languages here so
we judge popularity across similar languages: I will use PYPL rankings as
it gives, as I think, the most accurate top 15. (Let's not refer to TIOBE
here for obvious reasons)

Out of 15 most popular programming languages, there are 6 languages that
are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
Languages that have properties: TS, C#, Kotlin.
Languages that don't: Python, Go (and Java).

Each of the languages that doesn't have properties has its reason to it:
python essentially doesn't have any encapsulation, Go just dont have
classes, only structs (same for Rust by the way). All languages that were
designed for OOP and server side (which essentially implies a simple domain
model), have properties. There aren't many languages to have comprehensive
statistics, but even now (especially if we weigh these languages with their
popularity), properties are much more popular then no properties. Also
judging by popularity now isn't the best way of doing measurements: best
languages now will be most popular in a decade at least. For example, I
have done more deep research for my country (Ukraine). With the start of
war, the market significantly shifted towards product companies from
outsource, and now, when it comes to building apps from scratch, C# is the
most popular choice. Concluding, while I might have really put too much
into saying it is an industry standard, this is clearly a popular choice.

Also, what I always point out is that developer experience is tightly
linked to measurements like TTM and errors per line of code in languages,
and while dropping into users demand completely like python or js do is
obviously not the best choice, In my opinion, optimal point is somewhere
closer to where C# currently is, not where Java is. (Although some features
of C# like arrays pattern matching are obviously redundant, so not that
close to C# :) )

Appreciate Andrew`s comment, I haven't looked at it from this perspective,
but when it comes to syntaxic sugar and not root features, I think that is
not really applicable as it is transformed to recognizable for JIT syntax
during compilation.

PS: I think I am not in a position to say what is right and wrong in
approach of many experienced developers that guide Java`s development, but
I think that when you are coming into discussion with mindset of trying to
find the reasoning why not to introduce something, it might be harder to
actually evaluate all pros and cons. As I understand, even if pros outweigh
cons, but not significantly enough, features are discarded. As for me,
that`s not the best way to go with requests that are popular in the
community.

PPS: I would appreciate any feedback on this. And also about init-only
fields, is there some thoughts regarding them in the community? I feel like
it aligns pretty well with where jdk developers are heading currently

??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> No, I am sorry, I had to write the last message from my phone and didn't
> notice the error. Thanks for letting me know
>
> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>
>> Is this intended to go to the mailing list or just to me?
>>
>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Also, what I always point out is that developer experience is tightly
>>> linked to measurements like TTM and errors per line of code in languages,
>>> and while dropping into users demand completely like python or js do is
>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>> closer to where C# currently is, not where Java is
>>>
>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Well as a compromise between mutable and immutable objects there could
>>>> be init only fields. What is regarding to property mutations being
>>>> antipattern, it may have as many downsides as possible, but still is
>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>> can really do about that.
>>>>
>>>> I also appreciate Ron Pressler's clarifications, this makes everything
>>>> a lot more understandible for me.
>>>>
>>>> What I would like to say on this topic is that while immutability is
>>>> understandible trend nowadays, when we are talking about production, the
>>>> major part of the work is working with entities, which are inheritandably
>>>> mutable (and in many cases at least some of their properties should remain
>>>> that way).
>>>>
>>>> Current workarounds that exist to avoid undesired mutations is to
>>>> expose public constructor with required fields while making no-args
>>>> constructor protected, along with ommiting setters for such fields.
>>>>
>>>> Init only fields would probably be fix to problems of mutability, I may
>>>> also do some research on them, but what I would like to say is that some
>>>> properties are just mutable by their nature (like email fields, or amount
>>>> of attempts left), and this is still a very widely encountered case and
>>>> will surely remain so.
>>>>
>>>> Also, that's all discussion about set accessors. What about get
>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>> addition that could freshen up a language
>>>>
>>>> Edit: Ron, I saw your last message just now, so I will reply to some of
>>>> the points here.
>>>>
>>>> Firstly, I have already addressed that setters are effectively
>>>> inevitable, init only fields could do the trick you are trying to do by
>>>> disencouraging setters (which is a great by the way, I also think that even
>>>> for mutable objects immutability should be preserved where possible).
>>>>
>>>> About language complication, I get this point, concise syntax of Java
>>>> is why I fell in love with it in the first place. But as the time moves, it
>>>> becomes clear that some features just become industry standard: properties,
>>>> previously discarded extensions, object deconstruction etc. While I agree
>>>> that language should not just blindly accept every possible feature, wide
>>>> usage of some may indicate (and indicates) there is a demand for those. I
>>>> understand the desire to make language better by omitting the road that
>>>> once tricked languages like c++, but I think sometimes, when demand is high
>>>> enough, we should let users have what they want. At the end of the day,
>>>> trere isn't a problem in more flexible approaches, but some of the most
>>>> common problems, in my opinion, should be addressed specifically. This way
>>>> we could have a perfect balance between user experience and code quality.
>>>>
>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>
>>>>> No, field modification is an antipattern and should be avoided at
>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>> antipatterns, as these can be made from other threads and cause
>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>> However, you probably still don't want setters, as this implies the fields
>>>>> are not related to each other and all cartesian products of all fields are
>>>>> possible, which is rarely the case and such usages are still better covered
>>>>> by records.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>> mutable by spec?
>>>>>>
>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Oleksandr,
>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>> features that I think Java lacks for now.
>>>>>>>>
>>>>>>>> I think properties (seamless access to them to be precise) would be
>>>>>>>> a great addition, but having my previous experience, I want to ask were
>>>>>>>> there any discussions about that previously.
>>>>>>>>
>>>>>>>> Also, if there wasn't, or at least properties were not rejected, I
>>>>>>>> have a few questions regarding implementation that I want to know community
>>>>>>>> opinion about.
>>>>>>>> Firstly, I think, having all the codebase populated with get and
>>>>>>>> set accessors, the best way to add such thing would be to treat getX as a
>>>>>>>> get accessor to property X and setX correspondingly.
>>>>>>>> Secondly, unlike C# for example, I think that absence of property
>>>>>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>>>>>> int a {get;} implies a is effectively immutable)
>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>> be desugared in compile-time)
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/4c2d7f29/attachment-0001.htm>

From rotan.olexandr at gmail.com  Wed Apr 24 14:21:28 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 17:21:28 +0300
Subject: Properties
In-Reply-To: <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
Message-ID: <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>

Also what I have to say on accessors is that getters and setters of any
kind have been GRASP antipatterns since the first day of their existence.
They breach encapsulation and information expert. Nevertheless, the fact
nowadays is that a simple domain model conquered the world, and it requires
accessors as it is essentially procedural programming. Fighting accessors
is like fighting windmills: we could either accept and acknowledge their
existence and adapt to actual environment or just try to pretend like some
day ther will be a clear OOP in the world and in this
fabulous world assessors will not be used at all

??, 24 ???. 2024??. ? 17:13, ??-24 ????????? ?????? <
rotan.olexandr at gmail.com>:

> >  First, I don?t agree that properties have become an industry standard.
> Not all languages, even those newer than Java have them. ....  The two
> languages with similar or higher popularity to Java?s have fewer features
> than Java, not more.
>
> I have to agree with the point that JS, and Python (as I reckon that's the
> ones you are referring to) have less features then Java. However, what I
> would like to say is that, in my opinion, they are popular despite, not due
> to it. Less features and simple syntax obviously make them easier for
> learners, but that mostly comes from their interpreted nature, which comes
> at the cost of dramatical performance differences. Still, what the market
> currently indicates (I am not an analyst of any kind, this is just my
> observations), is that most popular languages, especially for product
> companies, are the ones that help *write* code faster at cost of support
> terms. I agree with Java prioritizing second over first, but language
> paradigms, as for me, should shift along with the market at least to some
> extent. So to conclude, while most popular languages *do* have fewer
> features, they still provide better developer experience due to their
> interpreted nature, and their popularity is caused by better developer
> experience, not by the amount of features in them.
>
> > While setters remain inevitable, if the need for them drops, the problem
> of writing them more easily becomes smaller, and a smaller problem doesn?t
> justify a language feature as much as a bigger problem. It makes the cost
> in complexity of the feature higher with respect to its benefit.
>
> While it makes setters a lesser problem, does it make it that small for
> pros to not outweigh cons? In modern applications, 99% of the time
> concurrency is handled by controller pattern, while the
> processing environment is single-threaded, and all possible problems are
> covered by things like entity managers. Data mutations are non-concurrent
> in the majority of situations, if we exclude race conditions at the
> database level.
>
> > I don?t agree that properties have become an industry standard.
>
> I did some research on that. Let's consider only backend languages here so
> we judge popularity across similar languages: I will use PYPL rankings as
> it gives, as I think, the most accurate top 15. (Let's not refer to TIOBE
> here for obvious reasons)
>
> Out of 15 most popular programming languages, there are 6 languages that
> are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
> Languages that have properties: TS, C#, Kotlin.
> Languages that don't: Python, Go (and Java).
>
> Each of the languages that doesn't have properties has its reason to it:
> python essentially doesn't have any encapsulation, Go just dont have
> classes, only structs (same for Rust by the way). All languages that were
> designed for OOP and server side (which essentially implies a simple domain
> model), have properties. There aren't many languages to have comprehensive
> statistics, but even now (especially if we weigh these languages with their
> popularity), properties are much more popular then no properties. Also
> judging by popularity now isn't the best way of doing measurements: best
> languages now will be most popular in a decade at least. For example, I
> have done more deep research for my country (Ukraine). With the start of
> war, the market significantly shifted towards product companies from
> outsource, and now, when it comes to building apps from scratch, C# is the
> most popular choice. Concluding, while I might have really put too much
> into saying it is an industry standard, this is clearly a popular choice.
>
> Also, what I always point out is that developer experience is tightly
> linked to measurements like TTM and errors per line of code in languages,
> and while dropping into users demand completely like python or js do is
> obviously not the best choice, In my opinion, optimal point is somewhere
> closer to where C# currently is, not where Java is. (Although some features
> of C# like arrays pattern matching are obviously redundant, so not that
> close to C# :) )
>
> Appreciate Andrew`s comment, I haven't looked at it from this perspective,
> but when it comes to syntaxic sugar and not root features, I think that is
> not really applicable as it is transformed to recognizable for JIT syntax
> during compilation.
>
> PS: I think I am not in a position to say what is right and wrong in
> approach of many experienced developers that guide Java`s development, but
> I think that when you are coming into discussion with mindset of trying to
> find the reasoning why not to introduce something, it might be harder to
> actually evaluate all pros and cons. As I understand, even if pros outweigh
> cons, but not significantly enough, features are discarded. As for me,
> that`s not the best way to go with requests that are popular in the
> community.
>
> PPS: I would appreciate any feedback on this. And also about init-only
> fields, is there some thoughts regarding them in the community? I feel like
> it aligns pretty well with where jdk developers are heading currently
>
> ??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> No, I am sorry, I had to write the last message from my phone and didn't
>> notice the error. Thanks for letting me know
>>
>> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>>
>>> Is this intended to go to the mailing list or just to me?
>>>
>>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Also, what I always point out is that developer experience is tightly
>>>> linked to measurements like TTM and errors per line of code in languages,
>>>> and while dropping into users demand completely like python or js do is
>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>> closer to where C# currently is, not where Java is
>>>>
>>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> Well as a compromise between mutable and immutable objects there could
>>>>> be init only fields. What is regarding to property mutations being
>>>>> antipattern, it may have as many downsides as possible, but still is
>>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>>> can really do about that.
>>>>>
>>>>> I also appreciate Ron Pressler's clarifications, this makes everything
>>>>> a lot more understandible for me.
>>>>>
>>>>> What I would like to say on this topic is that while immutability is
>>>>> understandible trend nowadays, when we are talking about production, the
>>>>> major part of the work is working with entities, which are inheritandably
>>>>> mutable (and in many cases at least some of their properties should remain
>>>>> that way).
>>>>>
>>>>> Current workarounds that exist to avoid undesired mutations is to
>>>>> expose public constructor with required fields while making no-args
>>>>> constructor protected, along with ommiting setters for such fields.
>>>>>
>>>>> Init only fields would probably be fix to problems of mutability, I
>>>>> may also do some research on them, but what I would like to say is that
>>>>> some properties are just mutable by their nature (like email fields, or
>>>>> amount of attempts left), and this is still a very widely encountered case
>>>>> and will surely remain so.
>>>>>
>>>>> Also, that's all discussion about set accessors. What about get
>>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>>> addition that could freshen up a language
>>>>>
>>>>> Edit: Ron, I saw your last message just now, so I will reply to some
>>>>> of the points here.
>>>>>
>>>>> Firstly, I have already addressed that setters are effectively
>>>>> inevitable, init only fields could do the trick you are trying to do by
>>>>> disencouraging setters (which is a great by the way, I also think that even
>>>>> for mutable objects immutability should be preserved where possible).
>>>>>
>>>>> About language complication, I get this point, concise syntax of Java
>>>>> is why I fell in love with it in the first place. But as the time moves, it
>>>>> becomes clear that some features just become industry standard: properties,
>>>>> previously discarded extensions, object deconstruction etc. While I agree
>>>>> that language should not just blindly accept every possible feature, wide
>>>>> usage of some may indicate (and indicates) there is a demand for those. I
>>>>> understand the desire to make language better by omitting the road that
>>>>> once tricked languages like c++, but I think sometimes, when demand is high
>>>>> enough, we should let users have what they want. At the end of the day,
>>>>> trere isn't a problem in more flexible approaches, but some of the most
>>>>> common problems, in my opinion, should be addressed specifically. This way
>>>>> we could have a perfect balance between user experience and code quality.
>>>>>
>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>
>>>>>> No, field modification is an antipattern and should be avoided at
>>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>>> antipatterns, as these can be made from other threads and cause
>>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>>> However, you probably still don't want setters, as this implies the fields
>>>>>> are not related to each other and all cartesian products of all fields are
>>>>>> possible, which is rarely the case and such usages are still better covered
>>>>>> by records.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>>> mutable by spec?
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Oleksandr,
>>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>>> features that I think Java lacks for now.
>>>>>>>>>
>>>>>>>>> I think properties (seamless access to them to be precise) would
>>>>>>>>> be a great addition, but having my previous experience, I want to ask were
>>>>>>>>> there any discussions about that previously.
>>>>>>>>>
>>>>>>>>> Also, if there wasn't, or at least properties were not rejected, I
>>>>>>>>> have a few questions regarding implementation that I want to know community
>>>>>>>>> opinion about.
>>>>>>>>> Firstly, I think, having all the codebase populated with get and
>>>>>>>>> set accessors, the best way to add such thing would be to treat getX as a
>>>>>>>>> get accessor to property X and setX correspondingly.
>>>>>>>>> Secondly, unlike C# for example, I think that absence of property
>>>>>>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>>>>>>> int a {get;} implies a is effectively immutable)
>>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>>> be desugared in compile-time)
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/039e743a/attachment-0001.htm>

From liangchenblue at gmail.com  Wed Apr 24 14:23:09 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 09:23:09 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
Message-ID: <CABe8uE1b4es9vq6C=WKaw7CH6BL0N-=VBGWHPQ24CWNOrs+x7w@mail.gmail.com>

Hi Oleksandr,
Can you describe init-only fields in more detail? Like private final fields
that are only assigned via constructor and accessed in instance methods but
not exposed in getters otherwise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/0bd832b4/attachment.htm>

From liangchenblue at gmail.com  Wed Apr 24 14:25:27 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 09:25:27 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
 <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
Message-ID: <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>

If a bad practice is common, it doesn't mean we should go along that path.

> Nevertheless, the fact nowadays is that a simple domain model
conquered the world, and it requires accessors as it is essentially
procedural programming.

I don't know how you've reached that conclusion, but almost no Java core
library code after Java 5 exhibits such patterns. There are getters to
immutable properties, which are fine, but most setters are replaced by
builders or factory methods instead. Setters are bad for JVM's JIT
compilations too.

On Wed, Apr 24, 2024 at 9:21?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Also what I have to say on accessors is that getters and setters of any
> kind have been GRASP antipatterns since the first day of their existence.
> They breach encapsulation and information expert. Nevertheless, the fact
> nowadays is that a simple domain model conquered the world, and it requires
> accessors as it is essentially procedural programming. Fighting accessors
> is like fighting windmills: we could either accept and acknowledge their
> existence and adapt to actual environment or just try to pretend like some
> day ther will be a clear OOP in the world and in this
> fabulous world assessors will not be used at all
>
> ??, 24 ???. 2024??. ? 17:13, ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com>:
>
>> >  First, I don?t agree that properties have become an industry standard.
>> Not all languages, even those newer than Java have them. ....  The two
>> languages with similar or higher popularity to Java?s have fewer features
>> than Java, not more.
>>
>> I have to agree with the point that JS, and Python (as I reckon that's
>> the ones you are referring to) have less features then Java. However, what
>> I would like to say is that, in my opinion, they are popular despite, not
>> due to it. Less features and simple syntax obviously make them easier for
>> learners, but that mostly comes from their interpreted nature, which comes
>> at the cost of dramatical performance differences. Still, what the market
>> currently indicates (I am not an analyst of any kind, this is just my
>> observations), is that most popular languages, especially for product
>> companies, are the ones that help *write* code faster at cost of support
>> terms. I agree with Java prioritizing second over first, but language
>> paradigms, as for me, should shift along with the market at least to some
>> extent. So to conclude, while most popular languages *do* have fewer
>> features, they still provide better developer experience due to their
>> interpreted nature, and their popularity is caused by better developer
>> experience, not by the amount of features in them.
>>
>> > While setters remain inevitable, if the need for them drops, the
>> problem of writing them more easily becomes smaller, and a smaller problem
>> doesn?t justify a language feature as much as a bigger problem. It makes
>> the cost in complexity of the feature higher with respect to its benefit.
>>
>> While it makes setters a lesser problem, does it make it that small for
>> pros to not outweigh cons? In modern applications, 99% of the time
>> concurrency is handled by controller pattern, while the
>> processing environment is single-threaded, and all possible problems are
>> covered by things like entity managers. Data mutations are non-concurrent
>> in the majority of situations, if we exclude race conditions at the
>> database level.
>>
>> > I don?t agree that properties have become an industry standard.
>>
>> I did some research on that. Let's consider only backend languages here
>> so we judge popularity across similar languages: I will use PYPL rankings
>> as it gives, as I think, the most accurate top 15. (Let's not refer to
>> TIOBE here for obvious reasons)
>>
>> Out of 15 most popular programming languages, there are 6 languages that
>> are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
>> Languages that have properties: TS, C#, Kotlin.
>> Languages that don't: Python, Go (and Java).
>>
>> Each of the languages that doesn't have properties has its reason to it:
>> python essentially doesn't have any encapsulation, Go just dont have
>> classes, only structs (same for Rust by the way). All languages that were
>> designed for OOP and server side (which essentially implies a simple domain
>> model), have properties. There aren't many languages to have comprehensive
>> statistics, but even now (especially if we weigh these languages with their
>> popularity), properties are much more popular then no properties. Also
>> judging by popularity now isn't the best way of doing measurements: best
>> languages now will be most popular in a decade at least. For example, I
>> have done more deep research for my country (Ukraine). With the start of
>> war, the market significantly shifted towards product companies from
>> outsource, and now, when it comes to building apps from scratch, C# is the
>> most popular choice. Concluding, while I might have really put too much
>> into saying it is an industry standard, this is clearly a popular choice.
>>
>> Also, what I always point out is that developer experience is tightly
>> linked to measurements like TTM and errors per line of code in languages,
>> and while dropping into users demand completely like python or js do is
>> obviously not the best choice, In my opinion, optimal point is somewhere
>> closer to where C# currently is, not where Java is. (Although some features
>> of C# like arrays pattern matching are obviously redundant, so not that
>> close to C# :) )
>>
>> Appreciate Andrew`s comment, I haven't looked at it from this
>> perspective, but when it comes to syntaxic sugar and not root features, I
>> think that is not really applicable as it is transformed to recognizable
>> for JIT syntax during compilation.
>>
>> PS: I think I am not in a position to say what is right and wrong in
>> approach of many experienced developers that guide Java`s development, but
>> I think that when you are coming into discussion with mindset of trying to
>> find the reasoning why not to introduce something, it might be harder to
>> actually evaluate all pros and cons. As I understand, even if pros outweigh
>> cons, but not significantly enough, features are discarded. As for me,
>> that`s not the best way to go with requests that are popular in the
>> community.
>>
>> PPS: I would appreciate any feedback on this. And also about init-only
>> fields, is there some thoughts regarding them in the community? I feel like
>> it aligns pretty well with where jdk developers are heading currently
>>
>> ??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com>:
>>
>>> No, I am sorry, I had to write the last message from my phone and didn't
>>> notice the error. Thanks for letting me know
>>>
>>> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>>>
>>>> Is this intended to go to the mailing list or just to me?
>>>>
>>>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com> wrote:
>>>>
>>>>> Also, what I always point out is that developer experience is tightly
>>>>> linked to measurements like TTM and errors per line of code in languages,
>>>>> and while dropping into users demand completely like python or js do is
>>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>>> closer to where C# currently is, not where Java is
>>>>>
>>>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Well as a compromise between mutable and immutable objects there
>>>>>> could be init only fields. What is regarding to property mutations being
>>>>>> antipattern, it may have as many downsides as possible, but still is
>>>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>>>> can really do about that.
>>>>>>
>>>>>> I also appreciate Ron Pressler's clarifications, this makes
>>>>>> everything a lot more understandible for me.
>>>>>>
>>>>>> What I would like to say on this topic is that while immutability is
>>>>>> understandible trend nowadays, when we are talking about production, the
>>>>>> major part of the work is working with entities, which are inheritandably
>>>>>> mutable (and in many cases at least some of their properties should remain
>>>>>> that way).
>>>>>>
>>>>>> Current workarounds that exist to avoid undesired mutations is to
>>>>>> expose public constructor with required fields while making no-args
>>>>>> constructor protected, along with ommiting setters for such fields.
>>>>>>
>>>>>> Init only fields would probably be fix to problems of mutability, I
>>>>>> may also do some research on them, but what I would like to say is that
>>>>>> some properties are just mutable by their nature (like email fields, or
>>>>>> amount of attempts left), and this is still a very widely encountered case
>>>>>> and will surely remain so.
>>>>>>
>>>>>> Also, that's all discussion about set accessors. What about get
>>>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>>>> addition that could freshen up a language
>>>>>>
>>>>>> Edit: Ron, I saw your last message just now, so I will reply to some
>>>>>> of the points here.
>>>>>>
>>>>>> Firstly, I have already addressed that setters are effectively
>>>>>> inevitable, init only fields could do the trick you are trying to do by
>>>>>> disencouraging setters (which is a great by the way, I also think that even
>>>>>> for mutable objects immutability should be preserved where possible).
>>>>>>
>>>>>> About language complication, I get this point, concise syntax of Java
>>>>>> is why I fell in love with it in the first place. But as the time moves, it
>>>>>> becomes clear that some features just become industry standard: properties,
>>>>>> previously discarded extensions, object deconstruction etc. While I agree
>>>>>> that language should not just blindly accept every possible feature, wide
>>>>>> usage of some may indicate (and indicates) there is a demand for those. I
>>>>>> understand the desire to make language better by omitting the road that
>>>>>> once tricked languages like c++, but I think sometimes, when demand is high
>>>>>> enough, we should let users have what they want. At the end of the day,
>>>>>> trere isn't a problem in more flexible approaches, but some of the most
>>>>>> common problems, in my opinion, should be addressed specifically. This way
>>>>>> we could have a perfect balance between user experience and code quality.
>>>>>>
>>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>>
>>>>>>> No, field modification is an antipattern and should be avoided at
>>>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>>>> antipatterns, as these can be made from other threads and cause
>>>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>>>> However, you probably still don't want setters, as this implies the fields
>>>>>>> are not related to each other and all cartesian products of all fields are
>>>>>>> possible, which is rarely the case and such usages are still better covered
>>>>>>> by records.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>>>> mutable by spec?
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Oleksandr,
>>>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>>>> features that I think Java lacks for now.
>>>>>>>>>>
>>>>>>>>>> I think properties (seamless access to them to be precise) would
>>>>>>>>>> be a great addition, but having my previous experience, I want to ask were
>>>>>>>>>> there any discussions about that previously.
>>>>>>>>>>
>>>>>>>>>> Also, if there wasn't, or at least properties were not rejected,
>>>>>>>>>> I have a few questions regarding implementation that I want to know
>>>>>>>>>> community opinion about.
>>>>>>>>>> Firstly, I think, having all the codebase populated with get and
>>>>>>>>>> set accessors, the best way to add such thing would be to treat getX as a
>>>>>>>>>> get accessor to property X and setX correspondingly.
>>>>>>>>>> Secondly, unlike C# for example, I think that absence of property
>>>>>>>>>> accessor should just imply direct access instead of forbidding it (in C#,
>>>>>>>>>> int a {get;} implies a is effectively immutable)
>>>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>>>> be desugared in compile-time)
>>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/af77d4ac/attachment-0001.htm>

From rotan.olexandr at gmail.com  Wed Apr 24 14:37:16 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 17:37:16 +0300
Subject: Properties
In-Reply-To: <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
 <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
 <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>
Message-ID: <CAP=Y=q_8V63Cp7BBqJ88Ds+qj2mgX6dd9GE9j+Ba74=QYz-g1w@mail.gmail.com>

Firstly, about SDM. The only alternative to it is rich domain model. The
key difference is while entities in RDM execute business logic (and
sometimes database logic) on them itself, in SDM this is done with Services
and Repositories. If you have ever seen such architecture - it is a SDM
essentially. Currently, JPA promotes such approach with POJOS and
persitencee specifications, persistence providers along with spring expose
APIs like JpaRepositories and annotations like @Service. Modern Java
frameworks are harnessed to suit SDM.

About init-only fields. They usually are a compromise between legacy specs
and immutability, but could also have other usages. They are pretty much
like readonly fields but could be set from anywhere where setter is
exposed, *only for once* (initialization i nconstructor also counts as
intiialization of field). Then they become final. When it comes to
persistence specifically, they help to make some fields of entities
effectively immutable. Also the yare hepful if field cant be set by
constructor for some reason right away, so accessor should be exposed (it
is usually a bed design, but there are some exceptions like asyncronous
tasks ran in the background that initialize field, while response arent
dependent on it and has to be sent right away). Summarizing, its main
application is in the entities, which could seem narrow, but in fact covers
a significant part of commercial developers workflow.

??, 24 ???. 2024??. ? 17:25, - <liangchenblue at gmail.com>:

> If a bad practice is common, it doesn't mean we should go along that path.
>
> > Nevertheless, the fact nowadays is that a simple domain model
> conquered the world, and it requires accessors as it is essentially
> procedural programming.
>
> I don't know how you've reached that conclusion, but almost no Java core
> library code after Java 5 exhibits such patterns. There are getters to
> immutable properties, which are fine, but most setters are replaced by
> builders or factory methods instead. Setters are bad for JVM's JIT
> compilations too.
>
> On Wed, Apr 24, 2024 at 9:21?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Also what I have to say on accessors is that getters and setters of any
>> kind have been GRASP antipatterns since the first day of their existence.
>> They breach encapsulation and information expert. Nevertheless, the fact
>> nowadays is that a simple domain model conquered the world, and it requires
>> accessors as it is essentially procedural programming. Fighting accessors
>> is like fighting windmills: we could either accept and acknowledge their
>> existence and adapt to actual environment or just try to pretend like some
>> day ther will be a clear OOP in the world and in this
>> fabulous world assessors will not be used at all
>>
>> ??, 24 ???. 2024??. ? 17:13, ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com>:
>>
>>> >  First, I don?t agree that properties have become an industry
>>> standard. Not all languages, even those newer than Java have them. ....
>>> The two languages with similar or higher popularity to Java?s have fewer
>>> features than Java, not more.
>>>
>>> I have to agree with the point that JS, and Python (as I reckon that's
>>> the ones you are referring to) have less features then Java. However, what
>>> I would like to say is that, in my opinion, they are popular despite, not
>>> due to it. Less features and simple syntax obviously make them easier for
>>> learners, but that mostly comes from their interpreted nature, which comes
>>> at the cost of dramatical performance differences. Still, what the market
>>> currently indicates (I am not an analyst of any kind, this is just my
>>> observations), is that most popular languages, especially for product
>>> companies, are the ones that help *write* code faster at cost of support
>>> terms. I agree with Java prioritizing second over first, but language
>>> paradigms, as for me, should shift along with the market at least to some
>>> extent. So to conclude, while most popular languages *do* have fewer
>>> features, they still provide better developer experience due to their
>>> interpreted nature, and their popularity is caused by better developer
>>> experience, not by the amount of features in them.
>>>
>>> > While setters remain inevitable, if the need for them drops, the
>>> problem of writing them more easily becomes smaller, and a smaller problem
>>> doesn?t justify a language feature as much as a bigger problem. It makes
>>> the cost in complexity of the feature higher with respect to its benefit.
>>>
>>> While it makes setters a lesser problem, does it make it that small for
>>> pros to not outweigh cons? In modern applications, 99% of the time
>>> concurrency is handled by controller pattern, while the
>>> processing environment is single-threaded, and all possible problems are
>>> covered by things like entity managers. Data mutations are non-concurrent
>>> in the majority of situations, if we exclude race conditions at the
>>> database level.
>>>
>>> > I don?t agree that properties have become an industry standard.
>>>
>>> I did some research on that. Let's consider only backend languages here
>>> so we judge popularity across similar languages: I will use PYPL rankings
>>> as it gives, as I think, the most accurate top 15. (Let's not refer to
>>> TIOBE here for obvious reasons)
>>>
>>> Out of 15 most popular programming languages, there are 6 languages that
>>> are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
>>> Languages that have properties: TS, C#, Kotlin.
>>> Languages that don't: Python, Go (and Java).
>>>
>>> Each of the languages that doesn't have properties has its reason to it:
>>> python essentially doesn't have any encapsulation, Go just dont have
>>> classes, only structs (same for Rust by the way). All languages that were
>>> designed for OOP and server side (which essentially implies a simple domain
>>> model), have properties. There aren't many languages to have comprehensive
>>> statistics, but even now (especially if we weigh these languages with their
>>> popularity), properties are much more popular then no properties. Also
>>> judging by popularity now isn't the best way of doing measurements: best
>>> languages now will be most popular in a decade at least. For example, I
>>> have done more deep research for my country (Ukraine). With the start of
>>> war, the market significantly shifted towards product companies from
>>> outsource, and now, when it comes to building apps from scratch, C# is the
>>> most popular choice. Concluding, while I might have really put too much
>>> into saying it is an industry standard, this is clearly a popular choice.
>>>
>>> Also, what I always point out is that developer experience is tightly
>>> linked to measurements like TTM and errors per line of code in languages,
>>> and while dropping into users demand completely like python or js do is
>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>> closer to where C# currently is, not where Java is. (Although some features
>>> of C# like arrays pattern matching are obviously redundant, so not that
>>> close to C# :) )
>>>
>>> Appreciate Andrew`s comment, I haven't looked at it from this
>>> perspective, but when it comes to syntaxic sugar and not root features, I
>>> think that is not really applicable as it is transformed to recognizable
>>> for JIT syntax during compilation.
>>>
>>> PS: I think I am not in a position to say what is right and wrong in
>>> approach of many experienced developers that guide Java`s development, but
>>> I think that when you are coming into discussion with mindset of trying to
>>> find the reasoning why not to introduce something, it might be harder to
>>> actually evaluate all pros and cons. As I understand, even if pros outweigh
>>> cons, but not significantly enough, features are discarded. As for me,
>>> that`s not the best way to go with requests that are popular in the
>>> community.
>>>
>>> PPS: I would appreciate any feedback on this. And also about init-only
>>> fields, is there some thoughts regarding them in the community? I feel like
>>> it aligns pretty well with where jdk developers are heading currently
>>>
>>> ??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com>:
>>>
>>>> No, I am sorry, I had to write the last message from my phone and
>>>> didn't notice the error. Thanks for letting me know
>>>>
>>>> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>>>>
>>>>> Is this intended to go to the mailing list or just to me?
>>>>>
>>>>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>
>>>>>> Also, what I always point out is that developer experience is tightly
>>>>>> linked to measurements like TTM and errors per line of code in languages,
>>>>>> and while dropping into users demand completely like python or js do is
>>>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>>>> closer to where C# currently is, not where Java is
>>>>>>
>>>>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> Well as a compromise between mutable and immutable objects there
>>>>>>> could be init only fields. What is regarding to property mutations being
>>>>>>> antipattern, it may have as many downsides as possible, but still is
>>>>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>>>>> can really do about that.
>>>>>>>
>>>>>>> I also appreciate Ron Pressler's clarifications, this makes
>>>>>>> everything a lot more understandible for me.
>>>>>>>
>>>>>>> What I would like to say on this topic is that while immutability is
>>>>>>> understandible trend nowadays, when we are talking about production, the
>>>>>>> major part of the work is working with entities, which are inheritandably
>>>>>>> mutable (and in many cases at least some of their properties should remain
>>>>>>> that way).
>>>>>>>
>>>>>>> Current workarounds that exist to avoid undesired mutations is to
>>>>>>> expose public constructor with required fields while making no-args
>>>>>>> constructor protected, along with ommiting setters for such fields.
>>>>>>>
>>>>>>> Init only fields would probably be fix to problems of mutability, I
>>>>>>> may also do some research on them, but what I would like to say is that
>>>>>>> some properties are just mutable by their nature (like email fields, or
>>>>>>> amount of attempts left), and this is still a very widely encountered case
>>>>>>> and will surely remain so.
>>>>>>>
>>>>>>> Also, that's all discussion about set accessors. What about get
>>>>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>>>>> addition that could freshen up a language
>>>>>>>
>>>>>>> Edit: Ron, I saw your last message just now, so I will reply to some
>>>>>>> of the points here.
>>>>>>>
>>>>>>> Firstly, I have already addressed that setters are effectively
>>>>>>> inevitable, init only fields could do the trick you are trying to do by
>>>>>>> disencouraging setters (which is a great by the way, I also think that even
>>>>>>> for mutable objects immutability should be preserved where possible).
>>>>>>>
>>>>>>> About language complication, I get this point, concise syntax of
>>>>>>> Java is why I fell in love with it in the first place. But as the time
>>>>>>> moves, it becomes clear that some features just become industry standard:
>>>>>>> properties, previously discarded extensions, object deconstruction etc.
>>>>>>> While I agree that language should not just blindly accept every possible
>>>>>>> feature, wide usage of some may indicate (and indicates) there is a demand
>>>>>>> for those. I understand the desire to make language better by omitting the
>>>>>>> road that once tricked languages like c++, but I think sometimes, when
>>>>>>> demand is high enough, we should let users have what they want. At the end
>>>>>>> of the day, trere isn't a problem in more flexible approaches, but some of
>>>>>>> the most common problems, in my opinion, should be addressed specifically.
>>>>>>> This way we could have a perfect balance between user experience and code
>>>>>>> quality.
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>>>
>>>>>>>> No, field modification is an antipattern and should be avoided at
>>>>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>>>>> antipatterns, as these can be made from other threads and cause
>>>>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>>>>> However, you probably still don't want setters, as this implies the fields
>>>>>>>> are not related to each other and all cartesian products of all fields are
>>>>>>>> possible, which is rarely the case and such usages are still better covered
>>>>>>>> by records.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>>>>> mutable by spec?
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Oleksandr,
>>>>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>>>>> features that I think Java lacks for now.
>>>>>>>>>>>
>>>>>>>>>>> I think properties (seamless access to them to be precise) would
>>>>>>>>>>> be a great addition, but having my previous experience, I want to ask were
>>>>>>>>>>> there any discussions about that previously.
>>>>>>>>>>>
>>>>>>>>>>> Also, if there wasn't, or at least properties were not rejected,
>>>>>>>>>>> I have a few questions regarding implementation that I want to know
>>>>>>>>>>> community opinion about.
>>>>>>>>>>> Firstly, I think, having all the codebase populated with get and
>>>>>>>>>>> set accessors, the best way to add such thing would be to treat getX as a
>>>>>>>>>>> get accessor to property X and setX correspondingly.
>>>>>>>>>>> Secondly, unlike C# for example, I think that absence of
>>>>>>>>>>> property accessor should just imply direct access instead of forbidding it
>>>>>>>>>>> (in C#, int a {get;} implies a is effectively immutable)
>>>>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>>>>> be desugared in compile-time)
>>>>>>>>>>>
>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/4f6c5a2b/attachment-0001.htm>

From liangchenblue at gmail.com  Wed Apr 24 14:54:49 2024
From: liangchenblue at gmail.com (-)
Date: Wed, 24 Apr 2024 09:54:49 -0500
Subject: Properties
In-Reply-To: <CAP=Y=q_8V63Cp7BBqJ88Ds+qj2mgX6dd9GE9j+Ba74=QYz-g1w@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
 <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
 <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>
 <CAP=Y=q_8V63Cp7BBqJ88Ds+qj2mgX6dd9GE9j+Ba74=QYz-g1w@mail.gmail.com>
Message-ID: <CABe8uE2X3s7LQUQz9XhUeSYgvJSMHgKJ54emFhG-oEaTRv+auA@mail.gmail.com>

For init-only fields, Java has one upcoming JEP for that:
https://openjdk.org/jeps/8312611
This one exposes Java's existing @Stable annotation to users, so that these
init-only fields can be treated as constants by the JVM. It also has
multiple ways to set the field (via setter, lazy computation), all of which
guards against multiple sets as well.

For SDM vs RDM, I believe the core Java libraries mostly under the "RDM"
model, that its objects are not simply carriers but contain the actual
logic, like OOP is supposed to. The "SDM" is mainly used I believe for easy
conversion between data like JSON, which should be done with records for
cross-thread immutability.

After all, this thread is digressing and don't belong to the java
compilers. I hope we can move the discussion somewhere else. Also, most of
Java's feature expansion has little to do with compilers, such as Virtual
Threads or this Stable Values, which allows Java enhancements to actually
benefit all JVM programming languages instead of just Java itself.

On Wed, Apr 24, 2024 at 9:37?AM ??-24 ????????? ?????? <
rotan.olexandr at gmail.com> wrote:

> Firstly, about SDM. The only alternative to it is rich domain model. The
> key difference is while entities in RDM execute business logic (and
> sometimes database logic) on them itself, in SDM this is done with Services
> and Repositories. If you have ever seen such architecture - it is a SDM
> essentially. Currently, JPA promotes such approach with POJOS and
> persitencee specifications, persistence providers along with spring expose
> APIs like JpaRepositories and annotations like @Service. Modern Java
> frameworks are harnessed to suit SDM.
>
> About init-only fields. They usually are a compromise between legacy specs
> and immutability, but could also have other usages. They are pretty much
> like readonly fields but could be set from anywhere where setter is
> exposed, *only for once* (initialization i nconstructor also counts as
> intiialization of field). Then they become final. When it comes to
> persistence specifically, they help to make some fields of entities
> effectively immutable. Also the yare hepful if field cant be set by
> constructor for some reason right away, so accessor should be exposed (it
> is usually a bed design, but there are some exceptions like asyncronous
> tasks ran in the background that initialize field, while response arent
> dependent on it and has to be sent right away). Summarizing, its main
> application is in the entities, which could seem narrow, but in fact covers
> a significant part of commercial developers workflow.
>
> ??, 24 ???. 2024??. ? 17:25, - <liangchenblue at gmail.com>:
>
>> If a bad practice is common, it doesn't mean we should go along that path.
>>
>> > Nevertheless, the fact nowadays is that a simple domain model
>> conquered the world, and it requires accessors as it is essentially
>> procedural programming.
>>
>> I don't know how you've reached that conclusion, but almost no Java core
>> library code after Java 5 exhibits such patterns. There are getters to
>> immutable properties, which are fine, but most setters are replaced by
>> builders or factory methods instead. Setters are bad for JVM's JIT
>> compilations too.
>>
>> On Wed, Apr 24, 2024 at 9:21?AM ??-24 ????????? ?????? <
>> rotan.olexandr at gmail.com> wrote:
>>
>>> Also what I have to say on accessors is that getters and setters of any
>>> kind have been GRASP antipatterns since the first day of their existence.
>>> They breach encapsulation and information expert. Nevertheless, the fact
>>> nowadays is that a simple domain model conquered the world, and it requires
>>> accessors as it is essentially procedural programming. Fighting accessors
>>> is like fighting windmills: we could either accept and acknowledge their
>>> existence and adapt to actual environment or just try to pretend like some
>>> day ther will be a clear OOP in the world and in this
>>> fabulous world assessors will not be used at all
>>>
>>> ??, 24 ???. 2024??. ? 17:13, ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com>:
>>>
>>>> >  First, I don?t agree that properties have become an industry
>>>> standard. Not all languages, even those newer than Java have them. ....
>>>> The two languages with similar or higher popularity to Java?s have fewer
>>>> features than Java, not more.
>>>>
>>>> I have to agree with the point that JS, and Python (as I reckon that's
>>>> the ones you are referring to) have less features then Java. However, what
>>>> I would like to say is that, in my opinion, they are popular despite, not
>>>> due to it. Less features and simple syntax obviously make them easier for
>>>> learners, but that mostly comes from their interpreted nature, which comes
>>>> at the cost of dramatical performance differences. Still, what the market
>>>> currently indicates (I am not an analyst of any kind, this is just my
>>>> observations), is that most popular languages, especially for product
>>>> companies, are the ones that help *write* code faster at cost of support
>>>> terms. I agree with Java prioritizing second over first, but language
>>>> paradigms, as for me, should shift along with the market at least to some
>>>> extent. So to conclude, while most popular languages *do* have fewer
>>>> features, they still provide better developer experience due to their
>>>> interpreted nature, and their popularity is caused by better developer
>>>> experience, not by the amount of features in them.
>>>>
>>>> > While setters remain inevitable, if the need for them drops, the
>>>> problem of writing them more easily becomes smaller, and a smaller problem
>>>> doesn?t justify a language feature as much as a bigger problem. It makes
>>>> the cost in complexity of the feature higher with respect to its benefit.
>>>>
>>>> While it makes setters a lesser problem, does it make it that small for
>>>> pros to not outweigh cons? In modern applications, 99% of the time
>>>> concurrency is handled by controller pattern, while the
>>>> processing environment is single-threaded, and all possible problems are
>>>> covered by things like entity managers. Data mutations are non-concurrent
>>>> in the majority of situations, if we exclude race conditions at the
>>>> database level.
>>>>
>>>> > I don?t agree that properties have become an industry standard.
>>>>
>>>> I did some research on that. Let's consider only backend languages here
>>>> so we judge popularity across similar languages: I will use PYPL rankings
>>>> as it gives, as I think, the most accurate top 15. (Let's not refer to
>>>> TIOBE here for obvious reasons)
>>>>
>>>> Out of 15 most popular programming languages, there are 6 languages
>>>> that are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
>>>> Languages that have properties: TS, C#, Kotlin.
>>>> Languages that don't: Python, Go (and Java).
>>>>
>>>> Each of the languages that doesn't have properties has its reason to
>>>> it: python essentially doesn't have any encapsulation, Go just dont have
>>>> classes, only structs (same for Rust by the way). All languages that were
>>>> designed for OOP and server side (which essentially implies a simple domain
>>>> model), have properties. There aren't many languages to have comprehensive
>>>> statistics, but even now (especially if we weigh these languages with their
>>>> popularity), properties are much more popular then no properties. Also
>>>> judging by popularity now isn't the best way of doing measurements: best
>>>> languages now will be most popular in a decade at least. For example, I
>>>> have done more deep research for my country (Ukraine). With the start of
>>>> war, the market significantly shifted towards product companies from
>>>> outsource, and now, when it comes to building apps from scratch, C# is the
>>>> most popular choice. Concluding, while I might have really put too much
>>>> into saying it is an industry standard, this is clearly a popular choice.
>>>>
>>>> Also, what I always point out is that developer experience is tightly
>>>> linked to measurements like TTM and errors per line of code in languages,
>>>> and while dropping into users demand completely like python or js do is
>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>> closer to where C# currently is, not where Java is. (Although some features
>>>> of C# like arrays pattern matching are obviously redundant, so not that
>>>> close to C# :) )
>>>>
>>>> Appreciate Andrew`s comment, I haven't looked at it from this
>>>> perspective, but when it comes to syntaxic sugar and not root features, I
>>>> think that is not really applicable as it is transformed to recognizable
>>>> for JIT syntax during compilation.
>>>>
>>>> PS: I think I am not in a position to say what is right and wrong in
>>>> approach of many experienced developers that guide Java`s development, but
>>>> I think that when you are coming into discussion with mindset of trying to
>>>> find the reasoning why not to introduce something, it might be harder to
>>>> actually evaluate all pros and cons. As I understand, even if pros outweigh
>>>> cons, but not significantly enough, features are discarded. As for me,
>>>> that`s not the best way to go with requests that are popular in the
>>>> community.
>>>>
>>>> PPS: I would appreciate any feedback on this. And also about init-only
>>>> fields, is there some thoughts regarding them in the community? I feel like
>>>> it aligns pretty well with where jdk developers are heading currently
>>>>
>>>> ??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com>:
>>>>
>>>>> No, I am sorry, I had to write the last message from my phone and
>>>>> didn't notice the error. Thanks for letting me know
>>>>>
>>>>> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>>>>>
>>>>>> Is this intended to go to the mailing list or just to me?
>>>>>>
>>>>>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>
>>>>>>> Also, what I always point out is that developer experience is
>>>>>>> tightly linked to measurements like TTM and errors per line of code in
>>>>>>> languages, and while dropping into users demand completely like python or
>>>>>>> js do is obviously not the best choice, In my opinion, optimal point is
>>>>>>> somewhere closer to where C# currently is, not where Java is
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Well as a compromise between mutable and immutable objects there
>>>>>>>> could be init only fields. What is regarding to property mutations being
>>>>>>>> antipattern, it may have as many downsides as possible, but still is
>>>>>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>>>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>>>>>> can really do about that.
>>>>>>>>
>>>>>>>> I also appreciate Ron Pressler's clarifications, this makes
>>>>>>>> everything a lot more understandible for me.
>>>>>>>>
>>>>>>>> What I would like to say on this topic is that while immutability
>>>>>>>> is understandible trend nowadays, when we are talking about production, the
>>>>>>>> major part of the work is working with entities, which are inheritandably
>>>>>>>> mutable (and in many cases at least some of their properties should remain
>>>>>>>> that way).
>>>>>>>>
>>>>>>>> Current workarounds that exist to avoid undesired mutations is to
>>>>>>>> expose public constructor with required fields while making no-args
>>>>>>>> constructor protected, along with ommiting setters for such fields.
>>>>>>>>
>>>>>>>> Init only fields would probably be fix to problems of mutability, I
>>>>>>>> may also do some research on them, but what I would like to say is that
>>>>>>>> some properties are just mutable by their nature (like email fields, or
>>>>>>>> amount of attempts left), and this is still a very widely encountered case
>>>>>>>> and will surely remain so.
>>>>>>>>
>>>>>>>> Also, that's all discussion about set accessors. What about get
>>>>>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>>>>>> addition that could freshen up a language
>>>>>>>>
>>>>>>>> Edit: Ron, I saw your last message just now, so I will reply to
>>>>>>>> some of the points here.
>>>>>>>>
>>>>>>>> Firstly, I have already addressed that setters are effectively
>>>>>>>> inevitable, init only fields could do the trick you are trying to do by
>>>>>>>> disencouraging setters (which is a great by the way, I also think that even
>>>>>>>> for mutable objects immutability should be preserved where possible).
>>>>>>>>
>>>>>>>> About language complication, I get this point, concise syntax of
>>>>>>>> Java is why I fell in love with it in the first place. But as the time
>>>>>>>> moves, it becomes clear that some features just become industry standard:
>>>>>>>> properties, previously discarded extensions, object deconstruction etc.
>>>>>>>> While I agree that language should not just blindly accept every possible
>>>>>>>> feature, wide usage of some may indicate (and indicates) there is a demand
>>>>>>>> for those. I understand the desire to make language better by omitting the
>>>>>>>> road that once tricked languages like c++, but I think sometimes, when
>>>>>>>> demand is high enough, we should let users have what they want. At the end
>>>>>>>> of the day, trere isn't a problem in more flexible approaches, but some of
>>>>>>>> the most common problems, in my opinion, should be addressed specifically.
>>>>>>>> This way we could have a perfect balance between user experience and code
>>>>>>>> quality.
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> No, field modification is an antipattern and should be avoided at
>>>>>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>>>>>> antipatterns, as these can be made from other threads and cause
>>>>>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>>>>>> However, you probably still don't want setters, as this implies the fields
>>>>>>>>> are not related to each other and all cartesian products of all fields are
>>>>>>>>> possible, which is rarely the case and such usages are still better covered
>>>>>>>>> by records.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>>>>>> mutable by spec?
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Oleksandr,
>>>>>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>>>>>> features that I think Java lacks for now.
>>>>>>>>>>>>
>>>>>>>>>>>> I think properties (seamless access to them to be precise)
>>>>>>>>>>>> would be a great addition, but having my previous experience, I want to ask
>>>>>>>>>>>> were there any discussions about that previously.
>>>>>>>>>>>>
>>>>>>>>>>>> Also, if there wasn't, or at least properties were
>>>>>>>>>>>> not rejected, I have a few questions regarding implementation that I want
>>>>>>>>>>>> to know community opinion about.
>>>>>>>>>>>> Firstly, I think, having all the codebase populated with get
>>>>>>>>>>>> and set accessors, the best way to add such thing would be to treat getX as
>>>>>>>>>>>> a get accessor to property X and setX correspondingly.
>>>>>>>>>>>> Secondly, unlike C# for example, I think that absence of
>>>>>>>>>>>> property accessor should just imply direct access instead of forbidding it
>>>>>>>>>>>> (in C#, int a {get;} implies a is effectively immutable)
>>>>>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>>>>>> be desugared in compile-time)
>>>>>>>>>>>>
>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/c124b718/attachment-0001.htm>

From rotan.olexandr at gmail.com  Wed Apr 24 15:05:24 2024
From: rotan.olexandr at gmail.com (=?UTF-8?B?0IbQny0yNCDQntC70LXQutGB0LDQvdC00YAg0KDQvtGC0LDQvdGM?=)
Date: Wed, 24 Apr 2024 18:05:24 +0300
Subject: Properties
In-Reply-To: <CABe8uE2X3s7LQUQz9XhUeSYgvJSMHgKJ54emFhG-oEaTRv+auA@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
 <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
 <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>
 <CAP=Y=q_8V63Cp7BBqJ88Ds+qj2mgX6dd9GE9j+Ba74=QYz-g1w@mail.gmail.com>
 <CABe8uE2X3s7LQUQz9XhUeSYgvJSMHgKJ54emFhG-oEaTRv+auA@mail.gmail.com>
Message-ID: <CAP=Y=q9njuEYUDkwHvPr68RyNUBRS_YVZZyd=Qmuh3Fm-TtcCg@mail.gmail.com>

I agree, the initial topic has shifted significantly, so let's not pollute
this mail list. I wonder if there is a more suitable place for such
discussions in future.

Regarding stable values, I feel like it looks more like lazy getters to me,
init only property goal is to enforce effective immutability of mutable
objects in most of the cases, I don't see how it could be
accomplished using stable values.

??, 24 ???. 2024??. ? 17:55, - <liangchenblue at gmail.com>:

> For init-only fields, Java has one upcoming JEP for that:
> https://openjdk.org/jeps/8312611
> This one exposes Java's existing @Stable annotation to users, so that
> these init-only fields can be treated as constants by the JVM. It also has
> multiple ways to set the field (via setter, lazy computation), all of which
> guards against multiple sets as well.
>
> For SDM vs RDM, I believe the core Java libraries mostly under the "RDM"
> model, that its objects are not simply carriers but contain the actual
> logic, like OOP is supposed to. The "SDM" is mainly used I believe for easy
> conversion between data like JSON, which should be done with records for
> cross-thread immutability.
>
> After all, this thread is digressing and don't belong to the java
> compilers. I hope we can move the discussion somewhere else. Also, most of
> Java's feature expansion has little to do with compilers, such as Virtual
> Threads or this Stable Values, which allows Java enhancements to actually
> benefit all JVM programming languages instead of just Java itself.
>
> On Wed, Apr 24, 2024 at 9:37?AM ??-24 ????????? ?????? <
> rotan.olexandr at gmail.com> wrote:
>
>> Firstly, about SDM. The only alternative to it is rich domain model. The
>> key difference is while entities in RDM execute business logic (and
>> sometimes database logic) on them itself, in SDM this is done with Services
>> and Repositories. If you have ever seen such architecture - it is a SDM
>> essentially. Currently, JPA promotes such approach with POJOS and
>> persitencee specifications, persistence providers along with spring expose
>> APIs like JpaRepositories and annotations like @Service. Modern Java
>> frameworks are harnessed to suit SDM.
>>
>> About init-only fields. They usually are a compromise between legacy
>> specs and immutability, but could also have other usages. They are pretty
>> much like readonly fields but could be set from anywhere where setter is
>> exposed, *only for once* (initialization i nconstructor also counts as
>> intiialization of field). Then they become final. When it comes to
>> persistence specifically, they help to make some fields of entities
>> effectively immutable. Also the yare hepful if field cant be set by
>> constructor for some reason right away, so accessor should be exposed (it
>> is usually a bed design, but there are some exceptions like asyncronous
>> tasks ran in the background that initialize field, while response arent
>> dependent on it and has to be sent right away). Summarizing, its main
>> application is in the entities, which could seem narrow, but in fact covers
>> a significant part of commercial developers workflow.
>>
>> ??, 24 ???. 2024??. ? 17:25, - <liangchenblue at gmail.com>:
>>
>>> If a bad practice is common, it doesn't mean we should go along that
>>> path.
>>>
>>> > Nevertheless, the fact nowadays is that a simple domain model
>>> conquered the world, and it requires accessors as it is essentially
>>> procedural programming.
>>>
>>> I don't know how you've reached that conclusion, but almost no Java core
>>> library code after Java 5 exhibits such patterns. There are getters to
>>> immutable properties, which are fine, but most setters are replaced by
>>> builders or factory methods instead. Setters are bad for JVM's JIT
>>> compilations too.
>>>
>>> On Wed, Apr 24, 2024 at 9:21?AM ??-24 ????????? ?????? <
>>> rotan.olexandr at gmail.com> wrote:
>>>
>>>> Also what I have to say on accessors is that getters and setters of any
>>>> kind have been GRASP antipatterns since the first day of their existence.
>>>> They breach encapsulation and information expert. Nevertheless, the fact
>>>> nowadays is that a simple domain model conquered the world, and it requires
>>>> accessors as it is essentially procedural programming. Fighting accessors
>>>> is like fighting windmills: we could either accept and acknowledge their
>>>> existence and adapt to actual environment or just try to pretend like some
>>>> day ther will be a clear OOP in the world and in this
>>>> fabulous world assessors will not be used at all
>>>>
>>>> ??, 24 ???. 2024??. ? 17:13, ??-24 ????????? ?????? <
>>>> rotan.olexandr at gmail.com>:
>>>>
>>>>> >  First, I don?t agree that properties have become an industry
>>>>> standard. Not all languages, even those newer than Java have them. ....
>>>>> The two languages with similar or higher popularity to Java?s have fewer
>>>>> features than Java, not more.
>>>>>
>>>>> I have to agree with the point that JS, and Python (as I reckon that's
>>>>> the ones you are referring to) have less features then Java. However, what
>>>>> I would like to say is that, in my opinion, they are popular despite, not
>>>>> due to it. Less features and simple syntax obviously make them easier for
>>>>> learners, but that mostly comes from their interpreted nature, which comes
>>>>> at the cost of dramatical performance differences. Still, what the market
>>>>> currently indicates (I am not an analyst of any kind, this is just my
>>>>> observations), is that most popular languages, especially for product
>>>>> companies, are the ones that help *write* code faster at cost of support
>>>>> terms. I agree with Java prioritizing second over first, but language
>>>>> paradigms, as for me, should shift along with the market at least to some
>>>>> extent. So to conclude, while most popular languages *do* have fewer
>>>>> features, they still provide better developer experience due to their
>>>>> interpreted nature, and their popularity is caused by better developer
>>>>> experience, not by the amount of features in them.
>>>>>
>>>>> > While setters remain inevitable, if the need for them drops, the
>>>>> problem of writing them more easily becomes smaller, and a smaller problem
>>>>> doesn?t justify a language feature as much as a bigger problem. It makes
>>>>> the cost in complexity of the feature higher with respect to its benefit.
>>>>>
>>>>> While it makes setters a lesser problem, does it make it that small
>>>>> for pros to not outweigh cons? In modern applications, 99% of the time
>>>>> concurrency is handled by controller pattern, while the
>>>>> processing environment is single-threaded, and all possible problems are
>>>>> covered by things like entity managers. Data mutations are non-concurrent
>>>>> in the majority of situations, if we exclude race conditions at the
>>>>> database level.
>>>>>
>>>>> > I don?t agree that properties have become an industry standard.
>>>>>
>>>>> I did some research on that. Let's consider only backend languages
>>>>> here so we judge popularity across similar languages: I will use
>>>>> PYPL rankings as it gives, as I think, the most accurate top 15. (Let's not
>>>>> refer to TIOBE here for obvious reasons)
>>>>>
>>>>> Out of 15 most popular programming languages, there are 6 languages
>>>>> that are mostly used in backend: Python, Java, JS/TS, C#, Go and Kotlin.
>>>>> Languages that have properties: TS, C#, Kotlin.
>>>>> Languages that don't: Python, Go (and Java).
>>>>>
>>>>> Each of the languages that doesn't have properties has its reason to
>>>>> it: python essentially doesn't have any encapsulation, Go just dont have
>>>>> classes, only structs (same for Rust by the way). All languages that were
>>>>> designed for OOP and server side (which essentially implies a simple domain
>>>>> model), have properties. There aren't many languages to have comprehensive
>>>>> statistics, but even now (especially if we weigh these languages with their
>>>>> popularity), properties are much more popular then no properties. Also
>>>>> judging by popularity now isn't the best way of doing measurements: best
>>>>> languages now will be most popular in a decade at least. For example, I
>>>>> have done more deep research for my country (Ukraine). With the start of
>>>>> war, the market significantly shifted towards product companies from
>>>>> outsource, and now, when it comes to building apps from scratch, C# is the
>>>>> most popular choice. Concluding, while I might have really put too much
>>>>> into saying it is an industry standard, this is clearly a popular choice.
>>>>>
>>>>> Also, what I always point out is that developer experience is tightly
>>>>> linked to measurements like TTM and errors per line of code in languages,
>>>>> and while dropping into users demand completely like python or js do is
>>>>> obviously not the best choice, In my opinion, optimal point is somewhere
>>>>> closer to where C# currently is, not where Java is. (Although some features
>>>>> of C# like arrays pattern matching are obviously redundant, so not that
>>>>> close to C# :) )
>>>>>
>>>>> Appreciate Andrew`s comment, I haven't looked at it from this
>>>>> perspective, but when it comes to syntaxic sugar and not root features, I
>>>>> think that is not really applicable as it is transformed to recognizable
>>>>> for JIT syntax during compilation.
>>>>>
>>>>> PS: I think I am not in a position to say what is right and wrong in
>>>>> approach of many experienced developers that guide Java`s development, but
>>>>> I think that when you are coming into discussion with mindset of trying to
>>>>> find the reasoning why not to introduce something, it might be harder to
>>>>> actually evaluate all pros and cons. As I understand, even if pros outweigh
>>>>> cons, but not significantly enough, features are discarded. As for me,
>>>>> that`s not the best way to go with requests that are popular in the
>>>>> community.
>>>>>
>>>>> PPS: I would appreciate any feedback on this. And also about init-only
>>>>> fields, is there some thoughts regarding them in the community? I feel like
>>>>> it aligns pretty well with where jdk developers are heading currently
>>>>>
>>>>> ??, 24 ???. 2024??. ? 16:25, ??-24 ????????? ?????? <
>>>>> rotan.olexandr at gmail.com>:
>>>>>
>>>>>> No, I am sorry, I had to write the last message from my phone and
>>>>>> didn't notice the error. Thanks for letting me know
>>>>>>
>>>>>> ??, 24 ???. 2024??. ? 16:11, - <liangchenblue at gmail.com>:
>>>>>>
>>>>>>> Is this intended to go to the mailing list or just to me?
>>>>>>>
>>>>>>> On Wed, Apr 24, 2024 at 8:04?AM ??-24 ????????? ?????? <
>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>
>>>>>>>> Also, what I always point out is that developer experience is
>>>>>>>> tightly linked to measurements like TTM and errors per line of code in
>>>>>>>> languages, and while dropping into users demand completely like python or
>>>>>>>> js do is obviously not the best choice, In my opinion, optimal point is
>>>>>>>> somewhere closer to where C# currently is, not where Java is
>>>>>>>>
>>>>>>>> On Wed, Apr 24, 2024, 15:54 ??-24 ????????? ?????? <
>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Well as a compromise between mutable and immutable objects there
>>>>>>>>> could be init only fields. What is regarding to property mutations being
>>>>>>>>> antipattern, it may have as many downsides as possible, but still is
>>>>>>>>> inevitable in production, and, moreover, is one of the most popular tasks
>>>>>>>>> to perform. Entities are mutable by specification, and there is nothing we
>>>>>>>>> can really do about that.
>>>>>>>>>
>>>>>>>>> I also appreciate Ron Pressler's clarifications, this makes
>>>>>>>>> everything a lot more understandible for me.
>>>>>>>>>
>>>>>>>>> What I would like to say on this topic is that while immutability
>>>>>>>>> is understandible trend nowadays, when we are talking about production, the
>>>>>>>>> major part of the work is working with entities, which are inheritandably
>>>>>>>>> mutable (and in many cases at least some of their properties should remain
>>>>>>>>> that way).
>>>>>>>>>
>>>>>>>>> Current workarounds that exist to avoid undesired mutations is to
>>>>>>>>> expose public constructor with required fields while making no-args
>>>>>>>>> constructor protected, along with ommiting setters for such fields.
>>>>>>>>>
>>>>>>>>> Init only fields would probably be fix to problems of mutability,
>>>>>>>>> I may also do some research on them, but what I would like to say is that
>>>>>>>>> some properties are just mutable by their nature (like email fields, or
>>>>>>>>> amount of attempts left), and this is still a very widely encountered case
>>>>>>>>> and will surely remain so.
>>>>>>>>>
>>>>>>>>> Also, that's all discussion about set accessors. What about get
>>>>>>>>> accessors, I don't really see downsides of them, and it would be a neat
>>>>>>>>> addition that could freshen up a language
>>>>>>>>>
>>>>>>>>> Edit: Ron, I saw your last message just now, so I will reply to
>>>>>>>>> some of the points here.
>>>>>>>>>
>>>>>>>>> Firstly, I have already addressed that setters are effectively
>>>>>>>>> inevitable, init only fields could do the trick you are trying to do by
>>>>>>>>> disencouraging setters (which is a great by the way, I also think that even
>>>>>>>>> for mutable objects immutability should be preserved where possible).
>>>>>>>>>
>>>>>>>>> About language complication, I get this point, concise syntax of
>>>>>>>>> Java is why I fell in love with it in the first place. But as the time
>>>>>>>>> moves, it becomes clear that some features just become industry standard:
>>>>>>>>> properties, previously discarded extensions, object deconstruction etc.
>>>>>>>>> While I agree that language should not just blindly accept every possible
>>>>>>>>> feature, wide usage of some may indicate (and indicates) there is a demand
>>>>>>>>> for those. I understand the desire to make language better by omitting the
>>>>>>>>> road that once tricked languages like c++, but I think sometimes, when
>>>>>>>>> demand is high enough, we should let users have what they want. At the end
>>>>>>>>> of the day, trere isn't a problem in more flexible approaches, but some of
>>>>>>>>> the most common problems, in my opinion, should be addressed specifically.
>>>>>>>>> This way we could have a perfect balance between user experience and code
>>>>>>>>> quality.
>>>>>>>>>
>>>>>>>>> On Wed, Apr 24, 2024, 15:30 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> No, field modification is an antipattern and should be avoided at
>>>>>>>>>> best, so both of the direct setfield instruction or a setter call are
>>>>>>>>>> antipatterns, as these can be made from other threads and cause
>>>>>>>>>> unpredictable memory effects. For entity mutations, it's recommended that
>>>>>>>>>> they are only accessed single threaded to avoid incorrect programs.
>>>>>>>>>> However, you probably still don't want setters, as this implies the fields
>>>>>>>>>> are not related to each other and all cartesian products of all fields are
>>>>>>>>>> possible, which is rarely the case and such usages are still better covered
>>>>>>>>>> by records.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 24, 2024 at 7:22?AM ??-24 ????????? ?????? <
>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I am not fully getting it. So things like foo.prop = val is
>>>>>>>>>>> antipattern while foo.setProp(val) is not? What about objects like
>>>>>>>>>>> entities, where constant data mutations are inevitable and classes are
>>>>>>>>>>> mutable by spec?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Apr 24, 2024, 15:18 - <liangchenblue at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Oleksandr,
>>>>>>>>>>>> Such properties are an antipattern in Java nowadays. We should
>>>>>>>>>>>> prefer immutable objects and records/builders instead. Mutations should
>>>>>>>>>>>> happen on the stack as much as possible for thread safety. And record
>>>>>>>>>>>> components already accomplish the "property" feature in an immutable sense.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Apr 24, 2024 at 4:24?AM ??-24 ????????? ?????? <
>>>>>>>>>>>> rotan.olexandr at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> As I see extension methods haven't been accepted as gladly as
>>>>>>>>>>>>> expected, I decided to put them in stash for now and work on some other
>>>>>>>>>>>>> features that I think Java lacks for now.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think properties (seamless access to them to be precise)
>>>>>>>>>>>>> would be a great addition, but having my previous experience, I want to ask
>>>>>>>>>>>>> were there any discussions about that previously.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, if there wasn't, or at least properties were
>>>>>>>>>>>>> not rejected, I have a few questions regarding implementation that I want
>>>>>>>>>>>>> to know community opinion about.
>>>>>>>>>>>>> Firstly, I think, having all the codebase populated with get
>>>>>>>>>>>>> and set accessors, the best way to add such thing would be to treat getX as
>>>>>>>>>>>>> a get accessor to property X and setX correspondingly.
>>>>>>>>>>>>> Secondly, unlike C# for example, I think that absence of
>>>>>>>>>>>>> property accessor should just imply direct access instead of forbidding it
>>>>>>>>>>>>> (in C#, int a {get;} implies a is effectively immutable)
>>>>>>>>>>>>> Lastly, for the sake of backward compatibility, I guess if a
>>>>>>>>>>>>> variable is directly visible in scope, I think that it should be modified
>>>>>>>>>>>>> directly rather than through an assessor. While that severely damages data
>>>>>>>>>>>>> integrity, this will not introduce any source code incompatibilities
>>>>>>>>>>>>> (bytecode incompatibilities isn't a thing here if properties will
>>>>>>>>>>>>> be desugared in compile-time)
>>>>>>>>>>>>>
>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/f726aab3/attachment-0001.htm>

From cstein at openjdk.org  Wed Apr 24 16:57:48 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Apr 2024 16:57:48 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp
Message-ID: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>

Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.

This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.

The level of nesting is increased from 567 to 1000.

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

Commit messages:
 - 8331030: langtools/tools/javac/tree tests fail with SOE with fastdebug and -Xcomp

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

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

From ron.pressler at oracle.com  Wed Apr 24 17:55:32 2024
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 24 Apr 2024 17:55:32 +0000
Subject: Properties
In-Reply-To: <CAP=Y=q9njuEYUDkwHvPr68RyNUBRS_YVZZyd=Qmuh3Fm-TtcCg@mail.gmail.com>
References: <CAP=Y=q__AmH=OAF8Kq9jX-XwyL2+iLb6m=X_cp_F9qxMrRBO=w@mail.gmail.com>
 <CABe8uE2jKvLnRXMPXgxiTMwBJByerxFGnVw8Dy6LiWVAyFTxHQ@mail.gmail.com>
 <CAP=Y=q9uDnsbGa1iTpB1mbD=Ct1XUWvJ59tApnUgjLHd2_50Ug@mail.gmail.com>
 <CABe8uE3Va4Sh1KBXf6QPKy4u_BDUc3bKhg_oTrw3rjMFMnNBwg@mail.gmail.com>
 <CAP=Y=q8SYi29drtPbAjj94+VrHfdS0_MyhM67443Z46UQTbdvw@mail.gmail.com>
 <CAP=Y=q-K4kqf0=wxZ9uCHXEZe0Lk4fOOg97-L4+kvt0aRt5QBQ@mail.gmail.com>
 <CABe8uE0+cA4oKvoeyNjuibxa+9JTafYEPTbK2ppEWLznd=hWrA@mail.gmail.com>
 <CAP=Y=q9fPoo4PeKu5ywQucvH8r+eAFg=7+x5xcPUJAzk_1K0vg@mail.gmail.com>
 <CAP=Y=q8Tj7STppmHpjbcpN-G5StR_nT3L3LxeRhi0QBkTSBeuw@mail.gmail.com>
 <CAP=Y=q_Dp-xjq5j8AnHhBVj9h7FrHqNAYBTiTgQY4403bjW3Yg@mail.gmail.com>
 <CABe8uE2vAh58bRnD_9Bfwa9Lkf25DRB7BHzV9AGXRwFgAGkWaw@mail.gmail.com>
 <CAP=Y=q_8V63Cp7BBqJ88Ds+qj2mgX6dd9GE9j+Ba74=QYz-g1w@mail.gmail.com>
 <CABe8uE2X3s7LQUQz9XhUeSYgvJSMHgKJ54emFhG-oEaTRv+auA@mail.gmail.com>
 <CAP=Y=q9njuEYUDkwHvPr68RyNUBRS_YVZZyd=Qmuh3Fm-TtcCg@mail.gmail.com>
Message-ID: <A4A0D97D-2FC7-43C5-9639-051038E955A7@oracle.com>



> On 24 Apr 2024, at 16:05, ??-24 ????????? ?????? <rotan.olexandr at gmail.com> wrote:
> 
> I agree, the initial topic has shifted significantly, so let's not pollute this mail list. I wonder if there is a more suitable place for such discussions in future.

You may be disappointed by this answer, but discussions over which avenues to pursue take place in private among the project?s contributors, and they usually span a long time (rarely less than a year) before being proposed in public. However, while the experience reports from users may take a long time to translate into action, their impact is large.

? Ron

From jjg at openjdk.org  Wed Apr 24 18:30:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Apr 2024 18:30:30 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp
In-Reply-To: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
Message-ID: <UCoX2n5max-V_BefnPB9cqccHosjqXroPlPMpHO3Hl4=.f31a5121-4920-498c-be7d-5ea5d360dd91@github.com>

On Wed, 24 Apr 2024 16:52:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
> 
> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
> 
> The level of nesting is increased from 567 to 1000.

test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 42:

> 40:         lines.add("class Test {");
> 41:         lines.add("  static { ");
> 42:         for (int i = 0; i < 1000; i++) lines.add("    synchronized (Test.class) {");

Suggest using a  named constant  for the two values of 1000

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18939#discussion_r1578339343

From cstein at openjdk.org  Wed Apr 24 18:42:41 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Apr 2024 18:42:41 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
Message-ID: <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>

> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
> 
> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
> 
> The level of nesting is increased from 567 to 1000.

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

  Introduce constant for the depth of nesting levels

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18939/files
  - new: https://git.openjdk.org/jdk/pull/18939/files/91be173c..6d51348f

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

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

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

From jjg at openjdk.org  Wed Apr 24 18:42:41 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Apr 2024 18:42:41 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
Message-ID: <zaYFmmSwgw2NEaot89rhvW4uOf2R1fR9G_So8ttAYi8=.b38577fb-9ab4-4b89-bdd7-0c938526d2f4@github.com>

On Wed, 24 Apr 2024 18:40:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
>> 
>> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
>> 
>> The level of nesting is increased from 567 to 1000.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce constant for the depth of nesting levels

Approved, with a minor suggestion

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18939#pullrequestreview-2020650233

From cstein at openjdk.org  Wed Apr 24 18:42:42 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Apr 2024 18:42:42 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <UCoX2n5max-V_BefnPB9cqccHosjqXroPlPMpHO3Hl4=.f31a5121-4920-498c-be7d-5ea5d360dd91@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <UCoX2n5max-V_BefnPB9cqccHosjqXroPlPMpHO3Hl4=.f31a5121-4920-498c-be7d-5ea5d360dd91@github.com>
Message-ID: <Q0EIO20Fxpv7fm6PfiBJwopJNV9sOH-CXMB3nVRHJjI=.2ba6c007-3af0-4249-bc2b-6f30b8b3a351@github.com>

On Wed, 24 Apr 2024 18:27:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce constant for the depth of nesting levels
>
> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 42:
> 
>> 40:         lines.add("class Test {");
>> 41:         lines.add("  static { ");
>> 42:         for (int i = 0; i < 1000; i++) lines.add("    synchronized (Test.class) {");
> 
> Suggest using a  named constant  for the two instances of 1000

Done via https://github.com/openjdk/jdk/pull/18939/commits/6d51348f5edfa1586ae3255539bdb1a0f156d3ca

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18939#discussion_r1578352285

From jjg at openjdk.org  Wed Apr 24 19:06:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 24 Apr 2024 19:06:31 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
Message-ID: <yLmL3Pb2RcqqyundlpUXcoTu9znnFGCwtZxFfS9SXaQ=.ea74c72b-8177-4c10-8b8b-be5382c9b699@github.com>

On Wed, 24 Apr 2024 18:42:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
>> 
>> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
>> 
>> The level of nesting is increased from 567 to 1000.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce constant for the depth of nesting levels

Marked as reviewed by jjg (Reviewer).

test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 28:

> 26:  * @bug 8322992 8331030
> 27:  * @summary Javac fails with StackOverflowError when compiling deeply nested synchronized blocks
> 28:  * @compile SOEDeeplyNestedBlocksTest.java

This line is not necessary; the file will be compiled if needed by the `@run main`

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

PR Review: https://git.openjdk.org/jdk/pull/18939#pullrequestreview-2020698888
PR Review Comment: https://git.openjdk.org/jdk/pull/18939#discussion_r1578379692

From cstein at openjdk.org  Wed Apr 24 19:15:38 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Apr 2024 19:15:38 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v3]
In-Reply-To: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
Message-ID: <LPxUkaV1yKpMGlz0gyW4U7rk9ZyDLxGmQeJzzR4gPLs=.97d49a80-0857-4699-8542-2c2d65ba8872@github.com>

> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
> 
> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
> 
> The level of nesting is increased from 567 to 1000.

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

  Update test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18939/files
  - new: https://git.openjdk.org/jdk/pull/18939/files/6d51348f..4cec7636

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

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

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

From cstein at openjdk.org  Wed Apr 24 19:15:39 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 24 Apr 2024 19:15:39 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
Message-ID: <SIiY3ivOuXLdZjJwS_H-MeSK6nYTUQJUU_Ze9yNHJAo=.e3e38740-2bd4-4a2e-a3eb-7334f726510e@github.com>

On Wed, 24 Apr 2024 18:42:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
>> 
>> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
>> 
>> The level of nesting is increased from 567 to 1000.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce constant for the depth of nesting levels

test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 28:

> 26:  * @bug 8322992 8331030
> 27:  * @summary Javac fails with StackOverflowError when compiling deeply nested synchronized blocks
> 28:  * @compile SOEDeeplyNestedBlocksTest.java

Suggestion:



Auto-suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18939#discussion_r1578388968

From vromero at openjdk.org  Wed Apr 24 19:24:27 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 24 Apr 2024 19:24:27 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v3]
In-Reply-To: <LPxUkaV1yKpMGlz0gyW4U7rk9ZyDLxGmQeJzzR4gPLs=.97d49a80-0857-4699-8542-2c2d65ba8872@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <LPxUkaV1yKpMGlz0gyW4U7rk9ZyDLxGmQeJzzR4gPLs=.97d49a80-0857-4699-8542-2c2d65ba8872@github.com>
Message-ID: <wgD8BPaUw2A7AehHlNcidQHcvRrmUCGvxjCHmfXK6HM=.553ee550-9935-46e7-815e-73276a4e9c6d@github.com>

On Wed, 24 Apr 2024 19:15:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
>> 
>> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
>> 
>> The level of nesting is increased from 567 to 1000.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18939#pullrequestreview-2020735118

From cstein at openjdk.org  Thu Apr 25 06:52:36 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 Apr 2024 06:52:36 GMT
Subject: Integrated: 8331030: langtools/tools/javac/tree tests fail with SOE
 with fastdebug and -Xcomp
In-Reply-To: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
Message-ID: <-_QUjuBHp71F3RWOFSYJjVuzXJzEcz-2QOZOKpUw56A=.ea461ad7-7cda-4628-8dcb-7468d7986faa@github.com>

On Wed, 24 Apr 2024 16:52:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change that now uses a source generator and compiler task to verify no SOE is thrown.
> 
> This change replaces over 1000 lines of code that were being compiled by running this test as well as other tests crawling over test files. Some of those crawling tests failed to parse this formerly large file. The new size of this test file should be no problem for them.
> 
> The level of nesting is increased from 567 to 1000.

This pull request has now been integrated.

Changeset: d43654e5
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d43654e5733a4ad535e95d908de528ef29285e92
Stats:     1159 lines in 1 file changed: 4 ins; 1131 del; 24 mod

8331030: langtools/tools/javac/tree tests fail with SOE with fastdebug and -Xcomp

Reviewed-by: jjg, vromero

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

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

From cstein at openjdk.org  Thu Apr 25 06:52:36 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 25 Apr 2024 06:52:36 GMT
Subject: RFR: 8331030: langtools/tools/javac/tree tests fail with SOE with
 fastdebug and -Xcomp [v2]
In-Reply-To: <yLmL3Pb2RcqqyundlpUXcoTu9znnFGCwtZxFfS9SXaQ=.ea74c72b-8177-4c10-8b8b-be5382c9b699@github.com>
References: <hKQIQPBwUbUsZY1e1G--XFELPBuPVtMMim8JUIDQgdU=.1fe6579b-f017-4a50-a4f2-9571e90515c9@github.com>
 <2p-sJO2VbzJ9aV17uUjVhvJVfGtYuV76NPLvGnuaw74=.72a17b00-71e5-4239-a388-1d86dd1d0cbc@github.com>
 <yLmL3Pb2RcqqyundlpUXcoTu9znnFGCwtZxFfS9SXaQ=.ea74c72b-8177-4c10-8b8b-be5382c9b699@github.com>
Message-ID: <X6uhe0d5yf-oMNq8Ga6eYvOA0GhOY0b1_Cn9QCuq2c4=.6a4d889f-0cad-4a8c-b63b-80a5ed157814@github.com>

On Wed, 24 Apr 2024 19:03:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce constant for the depth of nesting levels
>
> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 28:
> 
>> 26:  * @bug 8322992 8331030
>> 27:  * @summary Javac fails with StackOverflowError when compiling deeply nested synchronized blocks
>> 28:  * @compile SOEDeeplyNestedBlocksTest.java
> 
> This line is not necessary; the file will be compiled if needed by the `@run main`

Line removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18939#discussion_r1578965329

From duke at openjdk.org  Thu Apr 25 13:16:58 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 25 Apr 2024 13:16:58 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v14]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <LwzO6nUOoNgMbKew4G1rhQV0hplhXg3AFAYygSH1pfY=.0cfb0df6-407a-496f-ba28-c3546cdd1711@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Empty commit to rerun checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/d2f358b3..59cbeb69

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

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

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

From duke at openjdk.org  Thu Apr 25 13:57:07 2024
From: duke at openjdk.org (Evemose)
Date: Thu, 25 Apr 2024 13:57:07 GMT
Subject: RFR: 8329760: Add indexOf(Predicate<? super E> filter) to
 java.util.List interface [v15]
In-Reply-To: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
References: <0GTABns5XjxppwlLCz4L7gG2Dod8QkrKIye6Jur_RYQ=.6c6848d0-8bb6-4a94-8667-83e8a42027e9@github.com>
Message-ID: <IBQeFmwGaZDKSCf58qcZqDw4RH4QLya705fJoWo03jU=.5023f535-6293-4ff6-bbd4-c01b2ef516b2@github.com>

> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to `java.util.List`
> 
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the `List` interface by providing a more flexible way to find the index of an element. Currently, the `indexOf` and `lastIndexOf` methods only accept an object as a parameter. This limits the flexibility of these methods as they can only find the index of exact object matches.
> 
> The proposed methods would accept a `Predicate` as a parameter, allowing users to define a condition that the desired element must meet. This would provide a more flexible and powerful way to find the index of an element in a list.
> 
> Here is a brief overview of the changes made in this pull request:
> 
> 1. Added the `indexOf(Predicate<? super E> filter)` method to the `List` interface.
> 2. Added the `lastIndexOf(Predicate<? super E> filter)` method to the `List` interface.
> 3. Implemented these methods in all non-abstract classes that implement the `List` interface.
> 
> The changes have been thoroughly tested to ensure they work as expected and do not introduce any regressions. The test cases cover a variety of scenarios to ensure the robustness of the implementation.
> 
> For example, consider the following test case:
> 
> List<String> list = new ArrayList<>();
> list.add("Object one");
> list.add("NotObject two");
> list.add("NotObject three");
> 
> int index1 = list.indexOf(s -> s.contains("ct t"));
> System.out.println(index1); // Expected output: 1
> int index2 = list.lastIndexOf(s -> s.startsWith("NotObject"));
> System.out.println(index2); // Expected output: 2
> 
> 
> Currently, to achieve the same result, we would have to use a more verbose approach:
> 
> int index1 = IntStream.range(0, list.size())
>                      .filter(i -> list.get(i).contains("ct t"))
>                      .findFirst()
>                      .orElse(-1);
> System.out.println(index1); // Output: 1
> int index2 = IntStream.range(0, list.size())
>                          .filter(i -> list.get(i).startsWith("NotObject"))
>                          .reduce((first, second) -> second)
>                          .orElse(-1);
> System.out.println(index2); // Output: 2
> 
> 
> I believe these additions would greatly enhance the functionality and flexibility of the `List` interface, making it more powerful and user-friendly. I look forward to your feedback and am open to making any necessary changes based on your suggestions.
> 
> Thank you for considering this proposal.
> 
> Best regards
> 
> PS: In ...

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

  Revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18639/files
  - new: https://git.openjdk.org/jdk/pull/18639/files/59cbeb69..9166be30

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

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

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

From jjg at openjdk.org  Thu Apr 25 22:53:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 22:53:04 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v8]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <l0Wf7Ng-zjDRAZwhsOY9wf2dytL6ctdsMmLCL3tkgdc=.670a964c-af86-4c75-9d5a-4f6e479ac598@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1c238d43...16a265a2

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 25 23:24:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 23:24:07 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  revert need to disable warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/16a265a2..39689a52

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

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

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

From vromero at openjdk.org  Fri Apr 26 00:23:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 00:23:33 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
Message-ID: <txquEDIJ7YBKTZ6-EggzWEHSYzFxMXIBbwTuexdYXro=.af5bb232-dbd4-4099-9fc7-3bc22aacdd07@github.com>

On Thu, 25 Apr 2024 23:24:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert need to disable warning

looks good

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

> 581:      *     dangling comments are also attached to the tree node
> 582:      *     by registering them using the {@link #deferredLintHandler}.
> 583:      *  5. (Later) Warnings may be genereated for the dangling

typo: generated

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2023792395
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1580263826

From jlahoda at openjdk.org  Fri Apr 26 08:25:34 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 26 Apr 2024 08:25:34 GMT
Subject: RFR: 8309881: Qualified name of a type element depends on its
 origin (source vs class) [v2]
In-Reply-To: <al0zXd5J7Q_YIrNN3P_RXtKbNNl1TZkjyLw9yMy6Rpo=.cd9f9c4a-0748-453c-a4c6-e238aae5a326@github.com>
References: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
 <al0zXd5J7Q_YIrNN3P_RXtKbNNl1TZkjyLw9yMy6Rpo=.cd9f9c4a-0748-453c-a4c6-e238aae5a326@github.com>
Message-ID: <uKERGCkd6fHFyr8lkfJekMzCby_ERMgzWxlH0V90qto=.a86b3939-5c46-4918-989c-7dd99399ae11@github.com>

On Wed, 24 Apr 2024 06:19:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> `javax.lang.model.type.TypeMirror::toString` says: "Any names embedded in the result are qualified if possible."
>> However in reality the form of the names depends on the source vs.class origin.
>> 
>> This patch enforces qualified name to be used.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggested test revealed the fix is not sufficient
>   
>   Co-authored-by: jlahoda

Looks good to me. Thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18917#pullrequestreview-2024417464

From asotona at openjdk.org  Fri Apr 26 08:29:47 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 Apr 2024 08:29:47 GMT
Subject: Integrated: 8309881: Qualified name of a type element depends on its
 origin (source vs class)
In-Reply-To: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
References: <0sSYl74p_hQ0I_CGcxA_IS2AopFB0St2oVq90niv5OA=.a1b8f5ec-945c-401c-9d97-3bba2081f266@github.com>
Message-ID: <7D1PuXr9_AXbIfnU07YGB9y2n3V_DoXv6t2BFI91yOU=.800584ec-e5ab-4b00-b7d8-8715bb48f87d@github.com>

On Tue, 23 Apr 2024 14:41:17 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> `javax.lang.model.type.TypeMirror::toString` says: "Any names embedded in the result are qualified if possible."
> However in reality the form of the names depends on the source vs.class origin.
> 
> This patch enforces qualified name to be used.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ffd850f1
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffd850f17efc88dddfeab629f829a03ad22dc49d
Stats:     75 lines in 2 files changed: 75 ins; 0 del; 0 mod

8309881: Qualified name of a type element depends on its origin (source vs class)

Reviewed-by: darcy, jlahoda

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

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

From jjg at openjdk.org  Fri Apr 26 16:04:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 16:04:09 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/39689a52..48e8b0a2

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

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

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

From prr at openjdk.org  Fri Apr 26 19:34:00 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:34:00 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
Message-ID: <SD0S716mdRSViTfaViQgFYEkmR7WmBalQQe3_FI7VQc=.b83407a8-0c84-4ed9-8b56-adf6db1a2e0c@github.com>

On Fri, 26 Apr 2024 16:04:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2025744069

From jjg at openjdk.org  Fri Apr 26 19:49:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 19:49:56 GMT
Subject: Integrated: 8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <jz5iSs8rS6B9ZP2l3HbT7UR9gdQiXvxyQFGqikRLN7U=.584799e9-55c0-4a22-b62f-e30406cfe8ea@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

This pull request has now been integrated.

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a920af233a11592af113f456f7608cb59dd1617e
Stats:     482 lines in 58 files changed: 385 ins; 3 del; 94 mod

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

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

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

From jjg at openjdk.org  Fri Apr 26 20:34:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 20:34:32 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v57]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <-gBUJIN77XgSqa6gYERcGf2AeCmTWxNzRDnwmzrpS2U=.bac755e7-ba7f-41b5-9d1b-2b6f56c02f3e@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits:

 - Merge with upstream/master
 - address review feedback for updates to Elements and friends
 - address review feedback for updates to Elements and friends
 - add support for JDK-8329296: Update Elements for '///' documentation comments
 - add support for `--disable-line-doc-comments`
 - Merge branch '8298405.doclet-markdown-v3' of https://github.com/jonathan-gibbons/jdk into 8298405.doclet-markdown-v3
 - Merge pull request #3 from lahodaj/fix-positions-replacement
   
   Fixing positions when transforming javadoc text with replacement characters.
 - Merge branch '8298405.doclet-markdown-v3' into fix-positions-replacement
 - Fixing positions when transforming javadoc text with replacement characters.
 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - ... and 71 more: https://git.openjdk.org/jdk/compare/a920af23...c4709cf5

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=56
  Stats: 24098 lines in 228 files changed: 23453 ins; 260 del; 385 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Fri Apr 26 21:26:19 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 21:26:19 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v58]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <MLs8RwacyqdpefVLbIw-eXbnxDrZ2wcyJfZfgag_toU=.7c176ef4-b269-4990-b491-7403ead4efbe@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  Suppress warnings building tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/c4709cf5..a884ae36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=56-57

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

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

From jlahoda at openjdk.org  Mon Apr 29 06:31:20 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 06:31:20 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v12]
In-Reply-To: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
Message-ID: <urTZyal7RpzvG7Y54dTff33e6vN7XzSuTUVgNmN3U-I=.50546221-7ed3-4b42-9bd1-b6f6268593fe@github.com>

> This is a patch for javac, that adds the Derived Record Creation expressions. The current draft specification for the feature is:
> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
> 
> The current CSR is here:
> https://bugs.openjdk.org/browse/JDK-8328637
> 
> The patch is mostly straightforward, with two notable changes:
>  - there is a new `ElementKind.COMPONENT_LOCAL_VARIABLE`, as the specification introduces this term, and it seems consistent with `ElementKind.BINDING_VARIABLE` that was introduced some time ago.
>  - there are a bit broader changes in `Flow`, to facilitate the introduction of variables without an explicit declaration for definite assignment and effectively final computation.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into wthexp
 - Post-merge fixes.
 - Merge branch 'master' into wthexp
 - Reflecting review feedback:
   - reverting unnecessary changes in TransPatterns
   - moving the patters/withers/Model test to a more appropriate place
 - Adding tests as suggested.
 - Reflecting review feedback:
   - pre-generating the JCVarDecls in Attr, to aid Flow
   - adding a note on how the desugared code looks like
 - JavaCompiler cleanup
 - Improving the javax.lang.model for component local variables, by darcy.
 - Reflecting review feedback.
 - Merge branch 'master' into wthexp
 - ... and 26 more: https://git.openjdk.org/jdk/compare/4e5c25ee...c97eb8e6

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

Changes: https://git.openjdk.org/jdk/pull/18509/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18509&range=11
  Stats: 2023 lines in 51 files changed: 1965 ins; 19 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/18509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18509/head:pull/18509

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

From jlahoda at openjdk.org  Mon Apr 29 11:56:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 Apr 2024 11:56:18 GMT
Subject: RFR: 8331212: Error recovery for broken switch expressions could be
 improved
Message-ID: <j2uB--Ev6_yNLs-B7cFooxRdd66SyKewjR9S8r25DWM=.70ca55a0-d081-46dd-967a-5f1431644351@github.com>

Consider code like:

class Test {
    public boolean test() {
        return switch (0) {
            case 0 -> true;
            default -> {}
        };
    }
}


when compiling this, javac reports and error, and then crashes with an exception:

$ javac -XDdev /tmp/Test.java
/tmp/Test.java:5: error: switch rule completes without providing a value
            default -> {}
                        ^
  (switch rules in switch expressions must either provide a value or throw)
1 error
An exception has occurred in the compiler (23-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "type" because "tree" is null
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2363)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitYield(Flow.java:2990)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCYield.accept(JCTree.java:1673)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scanSyntheticBreak(Flow.java:475)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.handleSwitch(Flow.java:2802)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitSwitchExpression(Flow.java:2777)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1395)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanExpr(Flow.java:2340)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitReturn(Flow.java:3023)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1724)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:58)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitBlock(Flow.java:2614)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1088)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:2517)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:2454)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:810)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:3251)
        at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.analyzeTree(Flow.java:3233)
        at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:231)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1418)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1392)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:977)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:66)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:52)
printing javac parameters to: .../javac.20240429_134610.args


This is because, at the end of a rule case (`case ->`), if the code in the case completes normally, `Flow` will visit a synthetic `yield` or `break`, to ensure `Flow` understands there is no fall through. But, for `yield`, there is no expression. This works in most cases, but not in a "condition" context (i.e. for type "boolean"), when the `null` is not silently ignored.

As this is error recovery, the proposed solution is to make sure the `yield` has an expression - an erroneous expression in this case.

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

Commit messages:
 - 8331212: Error recovery for broken switch expressions could be improved

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

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

From duke at openjdk.org  Mon Apr 29 13:26:08 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 29 Apr 2024 13:26:08 GMT
Subject: RFR: 8324651: Compiler Implementation for Derived Record Creation
 (Preview) [v5]
In-Reply-To: <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>
References: <TePn4tZSvh0EKVjNU1vnPFaeN72XFBExbN9bcrSCxEY=.bc6f52f2-2326-4b12-a1bc-11cbf4242b09@github.com>
 <peC776HZpjjZxwKkwoQ7_R-KtYhiNibGLwkf8VOXyEw=.e9d5f980-6fd8-4607-bdb6-2f3d0dbcf52e@github.com>
 <vudrAiU0bDuHOJxeXOhPTr6cGZzajM_xwkCqmmizFsU=.ad583459-b9c3-4162-a8e1-d1771dc446a9@github.com>
 <7-WZgG_hU3f6D54H_mjzaGKwyxs_R0a0zF_LVonbjOs=.6f2b3b1a-35bf-4151-80ae-d76c8b2925a4@github.com>
Message-ID: <1juNagMTuuP9Jbqcxo6ejfR_dF22NzVvx7udxBv-A54=.faff46d2-9d7a-4cf3-a004-e3416772633e@github.com>

On Wed, 3 Apr 2024 07:13:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 1415:
>> 
>>> 1413:                                                      canonicalConstructorTypes,
>>> 1414:                                                      List.nil());
>>> 1415:         createNew.constructor = init;
>> 
>> Maybe?instead of?hardcoding the?constructor that?is?canonical at?compile?time (in?case new?components get?added), it?might be?better to?go?through some?sort of?`indy`?callsite?like (at?least when?not in?the?same compilation?unit):
>> 
>> DynamicCallSiteDesc[java.lang.runtime.RecordSupport::derivedConstructor(modified component names...):(T extends Record, Class<?>... /*?modified component types?*/)T]
>> 
>> 
>> with?the `derivedConstructor` bootstrap?method:
>> 
>> public static MethodHandle derivedConstructor(MethodHandles.Lookup lookup, String unused, MethodType type, String... modifiedComponents) throws ReflectiveOperationException {
>> 	requireNonNull(lookup);
>> 	requireNonNull(type);
>> 	// implicit null-check:
>> 	List<String> modifiedComponentNames = List.of(modifiedComponents);
>> 
>> 	Class<?> rtype = type.returnType();
>> 	if (
>> 		!rtype.isRecord()
>> 		|| type.parameterCount() != modifiedComponents.length + 1
>> 		|| type.parameterType(0) != rtype
>> 	) {
>> 		throw new IllegalArgumentException("...");
>> 	}
>> 
>> 	Set<String> remainingComponentNames = new HashSet(modifiedComponentNames);
>> 	if (remainingComponentNames.size() != modifiedComponentNames.size()) {
>> 		throw new IllegalArgumentException("Duplicate component names in modifiedComponents");
>> 	}
>> 
>> 	RecordComponent[] recordComponents = rtype.getRecordComponents();
>> 
>> 	var componentTypes = new Class<?>[recordComponents.length];
>> 	var filters = new MethodHandle[recordComponents.length];
>> 	var reorder = new int[recordComponents.length];
>> 
>> 	for (int i = 0, j = 1; i < recordComponents.length; i++) {
>> 		var component = recordComponents[i];
>> 		componentTypes[i] = component.getType();
>> 
>> 		var getter = lookup.findVirtual(rtype, component.getName(), MethodType.methodType(component.getType()));
>> 		if (modifiedComponentNames.contains(component.getName())) {
>> 			remainingComponentNames.remove(component.getName());
>> 			filters[i] = null;
>> 			reorder[i] = j++;
>> 		} else {
>> 			filters[i] = getter;
>> 			reorder[i] = 0;
>> 		}
>> 	}
>> 
>> 	if (!remainingComponentNames.isEmpty()) {
>> 		throw new IllegalArgumentException("Components " + remainingComponentNames + " are not present in the record " + rtype);...
>
> While this is very smart, I would prefer not to do that. JLS 13.4.27 talks about binary compatibility for record, and warns that adding or removing components may break record usages. So I don't think we need to provide too much support for adding or removing record components.
> 
> Overall, I believe the current code adheres to what the JLS draft says. If the author of the record wants to add or remove components, they can make it so that the existing compiled code still works (by adding constructor overloads and keeping the accessors for removed component). It is better, IMO, to keep the behavior predictable, and leave adjustments after record component modifications up to the record author, than to introduce some magic.

This?was once?again asked?about on?amber?dev:
- https://mail.openjdk.org/pipermail/amber-dev/2024-April/008748.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18509#discussion_r1583084422

From asotona at openjdk.org  Mon Apr 29 14:43:04 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 Apr 2024 14:43:04 GMT
Subject: RFR: 8331212: Error recovery for broken switch expressions could
 be improved
In-Reply-To: <j2uB--Ev6_yNLs-B7cFooxRdd66SyKewjR9S8r25DWM=.70ca55a0-d081-46dd-967a-5f1431644351@github.com>
References: <j2uB--Ev6_yNLs-B7cFooxRdd66SyKewjR9S8r25DWM=.70ca55a0-d081-46dd-967a-5f1431644351@github.com>
Message-ID: <7C_YFEfhvt23k2TVJQ8sbllnI65A3U-B0uMC_PRINwY=.f4f7b295-fb82-45af-b313-a18896356e42@github.com>

On Mon, 29 Apr 2024 11:51:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> class Test {
>     public boolean test() {
>         return switch (0) {
>             case 0 -> true;
>             default -> {}
>         };
>     }
> }
> 
> 
> when compiling this, javac reports and error, and then crashes with an exception:
> 
> $ javac -XDdev /tmp/Test.java
> /tmp/Test.java:5: error: switch rule completes without providing a value
>             default -> {}
>                         ^
>   (switch rules in switch expressions must either provide a value or throw)
> 1 error
> An exception has occurred in the compiler (23-internal). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "type" because "tree" is null
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanCond(Flow.java:2363)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitYield(Flow.java:2990)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCYield.accept(JCTree.java:1673)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scanSyntheticBreak(Flow.java:475)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.handleSwitch(Flow.java:2802)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitSwitchExpression(Flow.java:2777)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCSwitchExpression.accept(JCTree.java:1395)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:463)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scan(Flow.java:2095)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.scanExpr(Flow.java:2340)
>         at jdk.compiler/com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitReturn(Flow.java:3023)
>         at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCReturn.accept(JCTree.java:1724)
>         at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:...

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18997#pullrequestreview-2028714350

From darcy at openjdk.org  Mon Apr 29 17:49:13 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 17:49:13 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v2]
In-Reply-To: <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <lu-9QcX3V9tbVbwCQCL722LR0b8DQkAzp49vupalU2w=.7164ca4c-37d1-4194-a93d-1717fdd3c784@github.com>
 <mLGfAs-KfJ9qKLhDM8IOspx2cKuTC6IzAFiIiUkfj6g=.5a6217f6-86e2-4eba-ac48-647b19052cda@github.com>
Message-ID: <i6esXfmg7Qx3-KZZgjmszE9ZFHd5-qmZeCZW-YAlef8=.fae9238b-100f-43ca-9cf2-9c1f9ea851a0@github.com>

On Tue, 23 Apr 2024 07:03:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are further updates to this test in the pipeline (new deprecated flags in 23) so you will need to keep updating to reflect that.

Thanks @dholmes-ora ; acknowledged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18787#discussion_r1583479535

From jjg at openjdk.org  Mon Apr 29 18:15:52 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 29 Apr 2024 18:15:52 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v59]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <n2SmbOhfixdaDsnqLOEF3ljuUmSARu3Q0yjxdTxmMjA=.8e2d0baf-1aa1-4bb5-a316-5d442c602cb0@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  Remove links to `jdk.javadoc` module from `java.compiler` module`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/a884ae36..fadc130b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=57-58

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

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

From darcy at openjdk.org  Mon Apr 29 22:50:26 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 29 Apr 2024 22:50:26 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v3]
In-Reply-To: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
Message-ID: <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>

> Get JDK 24 underway.

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

 - Update deprecated options test.
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Merge branch 'master' into JDK-8330188
 - Correct release date as observed in review feedback.
 - Improve javadoc of class file update.
 - JDK-8330182: Start of release updates for JDK 24
   JDK-8330183: Add SourceVersion.RELEASE_24
   JDK-8330184: Add source 24 and target 24 to javac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18787/files
  - new: https://git.openjdk.org/jdk/pull/18787/files/dc488f21..47100a28

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

  Stats: 69237 lines in 1984 files changed: 31363 ins; 31713 del; 6161 mod
  Patch: https://git.openjdk.org/jdk/pull/18787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18787/head:pull/18787

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

From acobbs at openjdk.org  Tue Apr 30 03:01:36 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 Apr 2024 03:01:36 GMT
Subject: RFR: 8325805: Compiler Implementation for Flexible Constructor
 Bodies (Second Preview) [v5]
In-Reply-To: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
References: <IogcGlrhYlfhliyts6HlHtikehK9MSagGkkIwIkdLkY=.b641d176-d0fa-4d56-b0d6-bbdb46693c7e@github.com>
Message-ID: <0CRDEAALnEaVegk3MZ_o38pnl3D7sNaQfIOuSMyRG60=.3917a4b9-1475-494b-97ea-7c752bb76205@github.com>

> This patch changes the compiler to allow constructors to make assignments to fields prior to the `super()` invocation, i.e., in the pre-construction context.  This is part of the work associated with [JDK-8325803 - Flexible Constructor Bodies (Second Preview)](https://bugs.openjdk.org/browse/JDK-8325803).
> 
> This patch is based the relevant bits from @vicente-romero-oracle's commit [1b99b5cf](https://github.com/openjdk/valhalla/commit/1b99b5cfd9a5d484b9e7bdfc284daad9ad6535bf) to the valhalla repo.

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

 - Allow declaring and instantiating local classes prior to super().
 - Merge branch 'master' into JDK-8325805
 - Merge branch 'master' into JDK-8325805
 - Disallow assignments to fields with initializers in constructor prologues.
 - Merge branch 'master' into JDK-8325805
 - Merge branch 'master' into JDK-8325805
 - Fix cut & paste of bug ID and summary.
 - Avoid possible unwanted side effects from method Symbol.flags().
 - Add a few more test cases.
 - Fix bug where early assignments in lambda's were being allowed.
 - ... and 10 more: https://git.openjdk.org/jdk/compare/9b423a85...7e6a6a0d

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

Changes: https://git.openjdk.org/jdk/pull/18088/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18088&range=04
  Stats: 478 lines in 13 files changed: 459 ins; 10 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/18088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18088/head:pull/18088

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

From iris at openjdk.org  Tue Apr 30 06:25:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 Apr 2024 06:25:08 GMT
Subject: RFR: 8330182: Start of release updates for JDK 24 [v3]
In-Reply-To: <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>
References: <YKsEQWuI-vNTEDjOBInuEjf8AEcTL4QZ_F4JYUqoxwk=.5ed43782-6dec-4383-948d-d9966a85b3bf@github.com>
 <VINxNLNLhQ2xaEHji5EqHYA1MxLKYpjqnaSzlp7Cklw=.a2b04dfa-65f2-4421-9852-cf7b5faf9cbb@github.com>
Message-ID: <xGZzLsZ7Je6HKGkeGvkIQBcF71OB4-oWlmAmF4DzpJI=.e1129607-d7da-4aea-a8de-b348ece53267@github.com>

On Mon, 29 Apr 2024 22:50:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Merge branch 'master' into JDK-8330188
>  - Correct release date as observed in review feedback.
>  - Improve javadoc of class file update.
>  - JDK-8330182: Start of release updates for JDK 24
>    JDK-8330183: Add SourceVersion.RELEASE_24
>    JDK-8330184: Add source 24 and target 24 to javac

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18787#pullrequestreview-2030298396

From vklang at openjdk.org  Tue Apr 30 09:18:20 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
Message-ID: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>

This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

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

Commit messages:
 - Updating PreviewFeature.STREAM_GATHERERS to 473 - Second Preview

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

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

From pminborg at openjdk.org  Tue Apr 30 09:18:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <rFwAA-MilLCBnSM2whLeZdAwyOj-hgMVfZoSvPoMUwQ=.1a643efe-a95c-49e8-a9dd-2afb72318ab3@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

LGTM

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030731354

From vklang at openjdk.org  Tue Apr 30 09:18:20 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

@AlanBateman Let me know if I should create a new JBS issue for this change, or if it is fine to target the JEP JBS issue. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/19003#issuecomment-2083196525

From alanb at openjdk.org  Tue Apr 30 09:18:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 09:18:20 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
 <_nPuZMQuVPI-E4ElYwUU2-VFmamgXDGtNl0t5_XB46w=.8883686e-4e38-48b5-840a-1ceb01d39d69@github.com>
Message-ID: <C0Lb3-7I3vjbzbb2865vXN5u7zSHJ6gayxiOWYmqrI8=.3e273759-70ee-480c-9790-a57b4e0a4c18@github.com>

On Mon, 29 Apr 2024 16:42:59 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> @AlanBateman Let me know if I should create a new JBS issue for this change, or if it is fine to target the JEP JBS issue. ?

The bot has spotted this already (see "Integration Blocker" in the updated description). You'll need to create a separate JBS issue for the implementation change and link it in JBS to the JEP.

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

PR Comment: https://git.openjdk.org/jdk/pull/19003#issuecomment-2083249877

From alanb at openjdk.org  Tue Apr 30 09:56:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 09:56:05 GMT
Subject: RFR: 8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <qc-YN1B0j6wZuR_SZz8afTrJf8wpQyvwcXHai8aocFU=.de7d4a76-b282-44c1-a61c-c7986ed4e314@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19003#pullrequestreview-2030820148

From asotona at openjdk.org  Tue Apr 30 11:56:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot of
 static initializations
Message-ID: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>

Hi,
During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.

I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
 
Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.

Thank you,
Adam

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

Commit messages:
 - added impl comment
 - removed list of predefined attributes
 - move mappers implementations to AbstractAttributeMapper
 - 8331291: java.lang.classfile.Attributes class performs a lot of static initializations

Changes: https://git.openjdk.org/jdk/pull/19006/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331291
  Stats: 2029 lines in 47 files changed: 904 ins; 619 del; 506 mod
  Patch: https://git.openjdk.org/jdk/pull/19006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19006/head:pull/19006

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

From liach at openjdk.org  Tue Apr 30 11:56:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>

On Mon, 29 Apr 2024 18:48:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Nice changes! Remarks
1. The `INSTANCE` fields should be declared `final`, still safe for lazy initialization.
2. Not from this patch, but the `AttributeStability stability()` overrides can be moved to `AbstractAttributeMapper`, stored in a field, to decrease source code size.
3. `AbstractAttributeMapper` might become sealed now that its implementations are no longer anonymous, might move it to be a private nested class of `Attributes` to omit the long list of permits.

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2083832111

From asotona at openjdk.org  Tue Apr 30 11:56:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 11:56:20 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <YUvFFllRTrJ-mTbS64o2QbfG2grk7mhTHmaHaqfsURE=.41d41022-1831-4354-8ad4-c7588146e211@github.com>
Message-ID: <9NS-fjr36lj9hA4htcRwnIEeN3qZHTXSOAWBeyBdAs4=.d2b88f96-f9f6-4f66-887c-1bfcd709e7d9@github.com>

On Mon, 29 Apr 2024 23:04:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Nice changes! Remarks
> 
> 1. The `INSTANCE` fields should be declared `final`, still safe for lazy initialization.
> 2. Not from this patch, but the `AttributeStability stability()` overrides can be moved to `AbstractAttributeMapper`, stored in a field, to decrease source code size.
> 3. `AbstractAttributeMapper` might become sealed now that its implementations are no longer anonymous, might move it to be a private nested class of `Attributes` to omit the long list of permits.

Yes, that is part of the plan for today :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2084446739

From liach at openjdk.org  Tue Apr 30 12:12:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:12:06 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>

On Mon, 29 Apr 2024 18:48:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

Also the `final` modifier addition should be included in the CSR, as it changes the access modifiers even if it has no real impact.

src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:

> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
> 995:         // critical bootstrap path, so no lambdas nor method handles here
> 996:         return switch (name.hashCode()) {

I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?

test/jdk/jdk/classfile/AttributesTest.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @summary Testing Attributes API.

Can add a line `@bug 8331291`

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085160221
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584686905
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584687500

From asotona at openjdk.org  Tue Apr 30 12:23:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:36 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

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

  added bug number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/b7b35c5d..27238368

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

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

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

From asotona at openjdk.org  Tue Apr 30 12:23:36 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:36 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations
In-Reply-To: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
Message-ID: <phaIEfkEGahvGXohPOJ98GEG7fGYWJ3XSQN5hLb1pL8=.c731ff13-d1ff-4729-a3ae-d55f7fe7b3cc@github.com>

On Tue, 30 Apr 2024 12:09:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also the `final` modifier addition should be included in the CSR, as it changes the access modifiers even if it has no real impact.

The class already had only private constructor, so there was no way to extend it.

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085173489

From asotona at openjdk.org  Tue Apr 30 12:23:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 12:23:37 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
Message-ID: <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>

On Tue, 30 Apr 2024 12:05:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added bug number
>
> src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:
> 
>> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>> 995:         // critical bootstrap path, so no lambdas nor method handles here
>> 996:         return switch (name.hashCode()) {
> 
> I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?

Freshly parsed Utf8Entries conversion to String is expensive and unnecessary. We should be very careful when to ask for the conversion as it significantly affects some benchmarks.

> test/jdk/jdk/classfile/AttributesTest.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @summary Testing Attributes API.
> 
> Can add a line `@bug 8331291`

Added, thank you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584696556
PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584707230

From liach at openjdk.org  Tue Apr 30 12:31:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:31:05 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <6tf20Z4MT9nZkowA_NZmPnCJSJBqAvv2oVx55QzlGA0=.3b8bc56a-1fd0-4fb8-a81d-97e505c242d8@github.com>
 <Mx9FkDxCrMsQ-zmdTCN1e6Vx615GyUYstAjNMBHdUOM=.35238e6f-fb15-4525-9ca1-b9c153fc60ce@github.com>
Message-ID: <qBd5LxYBcH_0mlhLjMYtXNGVePP4rW_6Z38YOpTi9kc=.ce79ce1d-ffcf-4338-b7b5-51f589ae13b1@github.com>

On Tue, 30 Apr 2024 12:13:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java line 996:
>> 
>>> 994:     public static AttributeMapper<?> standardAttribute(Utf8Entry name) {
>>> 995:         // critical bootstrap path, so no lambdas nor method handles here
>>> 996:         return switch (name.hashCode()) {
>> 
>> I think we can safely switch over strings, as they are compiled to hashCode switch like what you explicitly have right now. Isn't that the case?
>
> Freshly parsed Utf8Entries conversion to String is expensive and unnecessary. We should be very careful when to ask for the conversion as it significantly affects some benchmarks.

You are right, I forgot these are Utf8Entry instead of Strings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19006#discussion_r1584719802

From liach at openjdk.org  Tue Apr 30 12:41:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 30 Apr 2024 12:41:06 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v2]
In-Reply-To: <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
 <RozF-tbZQwbV2ffLbQZAlDJes7X0G0H9gw6GXpQq7e8=.e4e4ea57-3d5b-4acc-bbd4-a6ba80c78231@github.com>
Message-ID: <R5LZbb1mB39zC1ILcTk2HBRsPw_EMaB0AXya4c-uv6s=.40fde4a6-92df-41d3-8529-3eed90e41e53@github.com>

On Tue, 30 Apr 2024 12:23:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Hi,
>> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
>> 
>> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>>  
>> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added bug number

Yeah, it has no real usage impact but such changes do require CSRs, like https://bugs.openjdk.org/browse/JDK-8305158 for a `final` on `Arrays` class, so you should include the `final` modifier change in your CSR's specdiff.

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

PR Comment: https://git.openjdk.org/jdk/pull/19006#issuecomment-2085221255

From asotona at openjdk.org  Tue Apr 30 13:26:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 30 Apr 2024 13:26:19 GMT
Subject: RFR: 8331291: java.lang.classfile.Attributes class performs a lot
 of static initializations [v3]
In-Reply-To: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
References: <SHIvjbwCWBPERKxlytEsY_O_kEiJbSeEmSusuDwjTIw=.ae8dd21e-a822-476e-9760-dd489532dbf1@github.com>
Message-ID: <cQIT_b1jhjjlqszpj-IVZ4N1cSHsZ1yFmnSeivK5hxw=.e0063e4e-91ef-4edd-9f11-e7c4ae7b823f@github.com>

> Hi,
> During performance optimization work on Class-File API as JDK lambda generator we found some static initialization killers.
> One of them is `java.lang.classfile.Attributes` with tens of static fields initialized with individual attribute mappers, and common set of all mappers, and static map from attribute names to the mappers.
> 
> I propose to turn all the static fields into lazy-initialized static methods and remove `PREDEFINED_ATTRIBUTES` and `standardAttribute(Utf8Entry name)` static mapping method from the `Attributes` API class.
>  
> Please let me know your comments or objections and please review the [PR](https://github.com/openjdk/jdk/pull/19006) and [CSR](https://bugs.openjdk.org/browse/JDK-8331414), so we can make it into 23.
> 
> Thank you,
> Adam

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

  changed order in allowed modules attributes check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19006/files
  - new: https://git.openjdk.org/jdk/pull/19006/files/27238368..f0d9174e

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

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

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

From vklang at openjdk.org  Tue Apr 30 15:14:10 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 30 Apr 2024 15:14:10 GMT
Subject: Integrated: 8331346: Update PreviewFeature of STREAM_GATHERERS to
 JEP-473
In-Reply-To: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
References: <0KjuHh0as7UbWvsHTuthvJtCwqr9-I6b_4SiS1dndY0=.c6fa2d0c-84a2-4bd3-9cb5-b115bdc15a4c@github.com>
Message-ID: <O5weTFB1plrm852t0BaOtJvqs-MYXd9zS_pTcnL-cVU=.767cbc5e-2b21-46a4-b2fb-1d3ebc786bcb@github.com>

On Mon, 29 Apr 2024 16:42:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This PR finalizes JEP 473 by modifying the PreviewFeature JEP number and status for Stream Gatherers.

This pull request has now been integrated.

Changeset: 2cc8eccb
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2cc8eccb360848f3ddf3259f1d943552f86234b9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8331346: Update PreviewFeature of STREAM_GATHERERS to JEP-473

Reviewed-by: pminborg, alanb

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

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

From jjg at openjdk.org  Tue Apr 30 20:33:50 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Apr 2024 20:33:50 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v60]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <QhopqzGp9Z8FUSZrCkfBj0Ynk2XHrZPGZlpV6-Axim4=.68c55e6c-cc5f-4175-9997-95edfaf8790d@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  update commonmark-java from 0.21.0 to 0.22.0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/fadc130b..74c86f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=58-59

  Stats: 2382 lines in 53 files changed: 2020 ins; 258 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Tue Apr 30 20:56:21 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Apr 2024 20:56:21 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v61]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <WfeEp76yI2ydvziffv05JmzxWUGelLcMVJ13N_c9Zu8=.26b62a07-d07c-4211-b9cb-ba9bc403d9fc@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 85 commits:

 - Merge remote-tracking branch 'upstream/master' into 8298405.doclet-markdown-v3
 - update commonmark-java from 0.21.0 to 0.22.0
 - Remove links to `jdk.javadoc` module from `java.compiler` module`
 - Suppress warnings building tests
 - Merge with upstream/master
 - address review feedback for updates to Elements and friends
 - address review feedback for updates to Elements and friends
 - add support for JDK-8329296: Update Elements for '///' documentation comments
 - add support for `--disable-line-doc-comments`
 - Merge branch '8298405.doclet-markdown-v3' of https://github.com/jonathan-gibbons/jdk into 8298405.doclet-markdown-v3
 - ... and 75 more: https://git.openjdk.org/jdk/compare/b96b38c2...20a384b6

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

Changes: https://git.openjdk.org/jdk/pull/16388/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=60
  Stats: 26326 lines in 243 files changed: 25679 ins; 260 del; 387 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From jjg at openjdk.org  Tue Apr 30 21:32:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 30 Apr 2024 21:32:13 GMT
Subject: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments
 [v62]
In-Reply-To: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
References: <G_kdxk2HIXWT_S_THP0ZqOvYMNMmx-nmje2psbsVc38=.1af4b86f-02a0-4d5d-9435-a674af4701ee@github.com>
Message-ID: <wpVYrszNWaH_jfBZPg7NILh2k13qmWmIkJcMbq1_Utg=.52a4ce74-df34-4ae6-b307-0d07b2198608@github.com>

> Please review a patch to add support for Markdown syntax in documentation comments, as described in the associated JEP.
> 
> Notable features:
> 
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java` library
> * updates to `DocCommentParser` to treat `///` comments as Markdown
> * updates to the standard doclet to render Markdown comments in HTML

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

  update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16388/files
  - new: https://git.openjdk.org/jdk/pull/16388/files/20a384b6..6576d024

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=61
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=60-61

  Stats: 68 lines in 62 files changed: 0 ins; 7 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/16388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388

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

From muyuanjin at qq.com  Wed Apr 24 16:33:33 2024
From: muyuanjin at qq.com (=?ISO-8859-1?B?bXV5dWFuamlu?=)
Date: Wed, 24 Apr 2024 16:33:33 -0000
Subject: Bug Report: JavacTaskPool memory leak
Message-ID: <tencent_BC32D6DBC7A25F6CC52C5867025EA0995009@qq.com>

System / OS / Java Runtime InformationWindows 11 23H2
openjdk 22.0.1 2024-04-16
OpenJDK Runtime Environment (build 22.0.1+8-16)
OpenJDK 64-Bit Server VM (build 22.0.1+8-16, mixed mode, sharing)

Description
com.sun.tools.javac.code.Scope.ScopeListenerList#listeners&nbsp; is not cleaned up in time, which leads to the accumulation of List and WeakReference when reusing Context, leading to OOM.


Reproduce
Using JavacTaskPool to compile the same source code repeatedly, the memory usage rises steadily and cannot be recycled until OOM .


Expected Result
The heap memory size is stable and runs continuously.


Actual Result&nbsp;
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
&nbsp; &nbsp; &nbsp; &nbsp; at java.base/java.util.List.of(List.java:1030)
&nbsp; &nbsp; &nbsp; &nbsp; at ReproduceTest.main(ReproduceTest.java:35)


Source code for an executable test case
import com.sun.tools.javac.api.JavacTaskPool; import javax.tools.*; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.net.URI; import java.net.URISyntaxException; import java.util.*; public class ReproduceTest {     private static final String source = """             import java.util.function.BiFunction;             public class LambdaContainer {                 public static BiFunction<Integer, Integer, Integer&gt; getLambda() {                     return (x, y) -&gt; x + y;                 }             }             """;     public static void main(String[] args) throws URISyntaxException {         JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();         JavacTaskPool javacTaskPool = new JavacTaskPool(1);         DiagnosticCollector<JavaFileObject&gt; diagnostics = new DiagnosticCollector<&gt;();         StandardJavaFileManager fileManager = compiler.getStandardFileManager(diagnostics, null, null);         MemoryFileManager memoryFileManager = new MemoryFileManager(fileManager);         List<?&gt; list;         do {             System.gc();             list = javacTaskPool.getTask(null, memoryFileManager, diagnostics,                     List.of("-source", "22", "-target", "22", "-encoding", "UTF-8"), null                     , List.of(new MemoryInputJavaFileObject("LambdaContainer.java", source)), task -&gt; {                         if (task.call()) {                             try (memoryFileManager) {                                 return memoryFileManager.getOutputs();                             } catch (IOException e) {                                 throw new RuntimeException(e);                             }                         }                         return Collections.emptyList();                     });         } while (!list.isEmpty());     }     static class MemoryFileManager extends ForwardingJavaFileManager<JavaFileManager&gt; {         private final List<MemoryOutputJavaFileObject&gt; outputs = new ArrayList<&gt;();         // Simulate the cache implementation to speed up the run,         // repeated runs of the same class compilation will not cause the cache memory usage to keep growing         private final Map<String, String&gt; binaryNameCache = new HashMap<&gt;();         private final Map<String, Iterable<JavaFileObject&gt;&gt; fileListCache = new HashMap<&gt;();         protected MemoryFileManager(JavaFileManager fileManager) {             super(fileManager);         }         @Override         public String inferBinaryName(Location location, JavaFileObject file) {             if (file instanceof BinaryJavaFileObject b) {                 String binaryName = b.getBinaryName();                 if (binaryName != null) {                     return binaryName;                 }             }             return binaryNameCache.computeIfAbsent(location.getName() + file.toString(), k -&gt; super.inferBinaryName(location, file));         }         @Override         public JavaFileObject getJavaFileForOutput(Location location, String className, JavaFileObject.Kind kind, FileObject sibling) throws IOException {             if (kind == JavaFileObject.Kind.CLASS) {                 var fileObject = new MemoryOutputJavaFileObject(className);                 outputs.add(fileObject);                 return fileObject;             }             return super.getJavaFileForOutput(location, className, kind, sibling);         }         @Override         public Iterable<JavaFileObject&gt; list(Location location, String packageName, Set<JavaFileObject.Kind&gt; kinds, boolean recurse) throws IOException {             String key = location.getName() + ":" + packageName + ":" + kinds + ":" + recurse;             return fileListCache.computeIfAbsent(key, k -&gt; {                 try {                     return super.list(location, packageName, kinds, recurse);                 } catch (IOException e) {                     return Collections.emptyList();                 }             });         }         public List<MemoryOutputJavaFileObject&gt; getOutputs() {             return new ArrayList<&gt;(outputs);         }         @Override         public void close() throws IOException {             super.close();             outputs.clear();         }     }     interface BinaryJavaFileObject extends JavaFileObject {         String getBinaryName();     }     static class MemoryInputJavaFileObject extends SimpleJavaFileObject {         private final String content;         public MemoryInputJavaFileObject(String uri, String content) throws URISyntaxException {             super(new URI("string:///" + uri), Kind.SOURCE);             this.content = content;         }         @Override         public CharSequence getCharContent(boolean ignoreEncodingErrors) {             return content;         }     }     static class MemoryOutputJavaFileObject extends SimpleJavaFileObject implements BinaryJavaFileObject {         private final ByteArrayOutputStream stream;         private final String binaryName;         public MemoryOutputJavaFileObject(String name) {             super(URI.create("string:///" + name.replace('.', '/') + Kind.CLASS.extension), Kind.CLASS);             this.binaryName = name;             this.stream = new ByteArrayOutputStream();         }         public byte[] toByteArray() {             return stream.toByteArray();         }         public String getBinaryName() {             return binaryName;         }         @Override         public InputStream openInputStream() {             return new ByteArrayInputStream(toByteArray());         }         @Override         public ByteArrayOutputStream openOutputStream() {             return this.stream;         }     } } 

Workaround1. Through reflection, after each call to task.call(), clean up context's Types.MembersClosureCache#nilScope And the Scope.ScopeListenerList#listeners of each ClassSymbol in com.sun.tools.javac.code.Symtab#classes.
2. Use agent (attachment MemoryLeakFixAgent.java) to change the Scope.ScopeListenerList to the following implementation:&nbsp; &nbsp; public static class ScopeListenerList {&nbsp; &nbsp; &nbsp; &nbsp; Set<ScopeListener&gt; listeners = Collections.newSetFromMap(new WeakHashMap<&gt;());&nbsp; &nbsp; &nbsp; &nbsp; void add(ScopeListener sl) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; listeners.add(sl);&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; void symbolAdded(Symbol sym, Scope scope) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; walkReferences(sym, scope, false);&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; void symbolRemoved(Symbol sym, Scope scope) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; walkReferences(sym, scope, true);&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; private void walkReferences(Symbol sym, Scope scope, boolean isRemove) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; for (ScopeListener sl : listeners) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (isRemove) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sl.symbolRemoved(sym, scope);&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } else {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sl.symbolAdded(sym, scope);&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/7d8c8597/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReproduceTest.java
Type: application/octet-stream
Size: 5759 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/7d8c8597/ReproduceTest.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MemoryLeakFixAgent.java
Type: application/octet-stream
Size: 17340 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240424/7d8c8597/MemoryLeakFixAgent.java>