From brian.goetz at oracle.com  Wed Jun  4 22:28:27 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 4 Jun 2025 18:28:27 -0400
Subject: Fwd: Regarding JEP 512
In-Reply-To: <CAPGaaEgp+pOrJ+vKYFg3xbnbP_b8=J+bqeKSuj2UyhOG0AFdKw@mail.gmail.com>
References: <CAPGaaEgp+pOrJ+vKYFg3xbnbP_b8=J+bqeKSuj2UyhOG0AFdKw@mail.gmail.com>
Message-ID: <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>

This was received on amber-spec-comments.


-------- Forwarded Message --------
Subject: 	Regarding JEP 512
Date: 	Wed, 4 Jun 2025 18:43:32 +0200
From: 	Rufus Riefenstahl <rufusriefenstahl at gmail.com>
To: 	amber-spec-comments at openjdk.org



Hello there, project Amber EG team.
 ?I would like to share my honest thoughts regarding JEP 512: "Compact 
Source Files and Instance Main Methods".
First off, let me introduce myself. My name is Rufus Riefenstahl.
I have been programming Java for about 20 years, 13 of them professionally.
My work includes major contributions to desktop software at film 
production firms and 3 years so far, backend development using Spring 
Boot. Lately I am preparing to apply for a mentorship position at my 
company, teaching novices how to do Java better.
Now my thoughts about the JEP...
When I first saw it, I thought to myself: "Well, great! Newcomers can 
get started with Java quicker!"
Yes, the "public static void main(String[] args)..." is definitely a lot 
to a new coder, especially if not proficient enough in object 
orientation, and seemingly very difficult for a person whose first 
programming language is Java! (I remember it myself...)
As the JEP depicts, a beginner may tell to himself that the language is 
just too "complex" to carry out a simple println(). Also, it says that 
the current, long way of doing it, is intended for large scale programs. 
And that's where my first doubt about this arrives - what really is a 
"large scale program"? Onto that later. The JEP proposes an interesting 
way of simplifying things. Instead beginners, or "simple command line 
scripts/utilities" (!!!, I will get to this later too) will use the void 
main(){} with IO.[whatever]. Now here is the second problem as I see it: 
By introducing an "IO" class, the "conventional" ways of getting 
something to the standard input/output increases to 2. The original is 
System.out.println(), which is the standard, Java-iconic way to do it. 
Now, IO is not limited to this "compact notation" as I will call it, but 
freely available in "large-scale programs", too. This may eventually 
result to some people using IO for printing & reading in non-small 
source. But I still presume most codebases will continue to use 
System.[whatever].[whatever] or the BufferedReader to get input - most 
Java is written in enterprise anyway. (yes, getting input, especially in 
Java, is pretty complex for a beginner, for sure.). Also tutorials 
regarding Java have always used the "standard" ways and it would take 
time to adopt this simplification and would maybe contribute to some 
confusion on why don't people introduce Java "that way". Another thing 
is that most "production-grade" Java isn't on the newest version, which 
is unfortunate, but this JEP being integrated to 25, an LTS, would make 
a difference. Back to my criticism. This creates a duality. Why may this 
be this be a problem? Let me explain. The core values of Java.
Most of the Java community, or at least the contributors/developers 
working on it, value stability, backwards compatibility, and overall 
maybe a slower pace of features, but making sure that those features 
actually commit to making Java better. To make Java last very long as a 
language. A language you can always come back to and not get overwhelmed 
with a bunch of "optional" syntax candy. I stand behind this too. Trust 
me, I have programmed in languages like C#, and their pace of change is 
too quick for me - while reading other projects' code I need to have a 
documentation tab open - showing the new syntax, at least most of the 
time. Java strives to be different. Recent additions like Virtual 
Threads prove that Java is exceptional: amazing "async/await" behaviour 
without the "burden" of function coloring (I recommend reading the post 
"What color is your function?" online). Making Java great, maintainable, 
good to write for the future, while being familiar to any programmers 
that may return to Java. Can't of course forget the new people, too. 
Sure, Java onboarding is not the easiest, especially when compared to 
languages like Python, but it makes sense in the long run.
This gets to the core of this message: The feature that's being proposed 
isn't inherently "bad", but the philosophy change that may occur. For 
example, specifically dividing "small learning programs/utilities" and 
"large scale programs" is just completely foreign to me in the Java 
space. Java was always built on solid conventions, style guides, and the 
ease of writing (not immediately perhaps, but after understanding major 
OO concepts), and most importantly - reading, yes, reading. When I open 
a java project of any codebase, I can understand it almost always. Don't 
forget: most time looking at the editor buffer is spent reading and 
debugging code, not writing new code. Yes, the programming landscape is 
changing with Python at the top of the food chain currently. Java must 
adapt to necessary industry changes, but should not adopt the "shiny new 
thing" immediately, as it hasn't done in the past and I feel like that's 
a good thing. Again, I don't feel like this compact writing is bad, but 
I feel that it's not absolutely necessary and contributes to a code 
style divide, more so because it's not only geared towards beginners but 
also "small scale programs". Java has gotten lots of "hate" from a lot 
of people who criticized things I praise. Java isn't perfect, but it's a 
stable, statically typed high-level programming language. A language you 
can always get back to.
I'm sorry if this "rant" was too long, but these are my thoughts. 
Perhaps I can't do much now as the feature is looking like to be 100% 
integrated in 25, but I at least so that this message to serves to 
everyone as a some sort of a "cautionary tale".
If you don't agree with my opinions, fine. But be aware.
If you'd like to discuss this matter further with me, I am 100% open.

Have a blessed day.
- Riefenstahl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250604/d456add1/attachment.htm>

From kfogel at dawsoncollege.qc.ca  Thu Jun  5 15:01:54 2025
From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel)
Date: Thu, 5 Jun 2025 15:01:54 +0000
Subject: Regarding JEP 512
In-Reply-To: <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
References: <CAPGaaEgp+pOrJ+vKYFg3xbnbP_b8=J+bqeKSuj2UyhOG0AFdKw@mail.gmail.com>
 <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
Message-ID: <QB1PPF5DAA3F5873B56E506A0EBABE6D0818D6FA@QB1PPF5DAA3F587.CANPRD01.PROD.OUTLOOK.COM>

That was an interesting perspective from Rufus. I was just about to write to this mailing list about how I was disappointed that it was now necessary to write IO.println rather than just println.

My perspective comes from teaching Java. I have always felt that learning a language involves evolution. Java has been reluctant to follow this model by requiring full on OOP on day one with all the myriad ?decorations?. I was excited to see ?void main()?. It made the entry point simple. Classless or simple source file was another enhancement that I also felt was going to make Java a language that could be taught, not just at University, at Primary and Secondary schools. It may be too late for this as Python has pretty much taken over the public-school space.

As for println or as it is now named IO.println, it is another significant advance in making Java easier to learn. I think we can agree that console I/O beyond learning language fundamentals is over, done, and nailed to its perch (Monty Python reference). Therefore, any simplification is significant. You want a desktop UI then use JavaFX. As I mentioned, I?m not crazy about needing the prefix IO but it is still better than System.out.println. I never taught System.in other than as a parameter for the Scanner class.

Enhancements to Java that, as Brian has called it as paving the on-ramp, must be applauded and encouraged. We may not agree (I still don?t like requiring IO) but it shows that the language can evolve not only to meet the needs of senior developers but also new developers and children.

Ken Fogel



From: amber-dev <amber-dev-retn at openjdk.org> On Behalf Of Brian Goetz
Sent: June 4, 2025 6:28 PM
To: amber-dev <amber-dev at openjdk.java.net>
Subject: Fwd: Regarding JEP 512

This was received on amber-spec-comments.


-------- Forwarded Message --------
Subject:
Regarding JEP 512
Date:
Wed, 4 Jun 2025 18:43:32 +0200
From:
Rufus Riefenstahl <rufusriefenstahl at gmail.com><mailto:rufusriefenstahl at gmail.com>
To:
amber-spec-comments at openjdk.org<mailto:amber-spec-comments at openjdk.org>

Hello there, project Amber EG team.
 I would like to share my honest thoughts regarding JEP 512: "Compact Source Files and Instance Main Methods".
First off, let me introduce myself. My name is Rufus Riefenstahl.
I have been programming Java for about 20 years, 13 of them professionally.
My work includes major contributions to desktop software at film production firms and 3 years so far, backend development using Spring Boot. Lately I am preparing to apply for a mentorship position at my company, teaching novices how to do Java better.
Now my thoughts about the JEP...
When I first saw it, I thought to myself: "Well, great! Newcomers can get started with Java quicker!"
Yes, the "public static void main(String[] args)..." is definitely a lot to a new coder, especially if not proficient enough in object orientation, and seemingly very difficult for a person whose first programming language is Java! (I remember it myself...)
As the JEP depicts, a beginner may tell to himself that the language is just too "complex" to carry out a simple println(). Also, it says that the current, long way of doing it, is intended for large scale programs. And that's where my first doubt about this arrives - what really is a "large scale program"? Onto that later. The JEP proposes an interesting way of simplifying things. Instead beginners, or "simple command line scripts/utilities" (!!!, I will get to this later too) will use the void main(){} with IO.[whatever]. Now here is the second problem as I see it: By introducing an "IO" class, the "conventional" ways of getting something to the standard input/output increases to 2. The original is System.out.println(), which is the standard, Java-iconic way to do it. Now, IO is not limited to this "compact notation" as I will call it, but freely available in "large-scale programs", too. This may eventually result to some people using IO for printing & reading in non-small source. But I still presume most codebases will continue to use System.[whatever].[whatever] or the BufferedReader to get input - most Java is written in enterprise anyway. (yes, getting input, especially in Java, is pretty complex for a beginner, for sure.). Also tutorials regarding Java have always used the "standard" ways and it would take time to adopt this simplification and would maybe contribute to some confusion on why don't people introduce Java "that way". Another thing is that most "production-grade" Java isn't on the newest version, which is unfortunate, but this JEP being integrated to 25, an LTS, would make a difference. Back to my criticism. This creates a duality. Why may this be this be a problem? Let me explain. The core values of Java.
Most of the Java community, or at least the contributors/developers working on it, value stability, backwards compatibility, and overall maybe a slower pace of features, but making sure that those features actually commit to making Java better. To make Java last very long as a language. A language you can always come back to and not get overwhelmed with a bunch of "optional" syntax candy. I stand behind this too. Trust me, I have programmed in languages like C#, and their pace of change is too quick for me - while reading other projects' code I need to have a documentation tab open - showing the new syntax, at least most of the time. Java strives to be different. Recent additions like Virtual Threads prove that Java is exceptional: amazing "async/await" behaviour without the "burden" of function coloring (I recommend reading the post "What color is your function?" online). Making Java great, maintainable, good to write for the future, while being familiar to any programmers that may return to Java. Can't of course forget the new people, too. Sure, Java onboarding is not the easiest, especially when compared to languages like Python, but it makes sense in the long run.
This gets to the core of this message: The feature that's being proposed isn't inherently "bad", but the philosophy change that may occur. For example, specifically dividing "small learning programs/utilities" and "large scale programs" is just completely foreign to me in the Java space. Java was always built on solid conventions, style guides, and the ease of writing (not immediately perhaps, but after understanding major OO concepts), and most importantly - reading, yes, reading. When I open a java project of any codebase, I can understand it almost always. Don't forget: most time looking at the editor buffer is spent reading and debugging code, not writing new code. Yes, the programming landscape is changing with Python at the top of the food chain currently. Java must adapt to necessary industry changes, but should not adopt the "shiny new thing" immediately, as it hasn't done in the past and I feel like that's a good thing. Again, I don't feel like this compact writing is bad, but I feel that it's not absolutely necessary and contributes to a code style divide, more so because it's not only geared towards beginners but also "small scale programs". Java has gotten lots of "hate" from a lot of people who criticized things I praise. Java isn't perfect, but it's a stable, statically typed high-level programming language. A language you can always get back to.
I'm sorry if this "rant" was too long, but these are my thoughts. Perhaps I can't do much now as the feature is looking like to be 100% integrated in 25, but I at least so that this message to serves to everyone as a some sort of a "cautionary tale".
If you don't agree with my opinions, fine. But be aware.
If you'd like to discuss this matter further with me, I am 100% open.

Have a blessed day.
- Riefenstahl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250605/05ecdecf/attachment-0001.htm>

From david.1993grajales at gmail.com  Thu Jun  5 16:10:30 2025
From: david.1993grajales at gmail.com (david Grajales)
Date: Thu, 5 Jun 2025 11:10:30 -0500
Subject: Regarding JEP 512
In-Reply-To: <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
References: <CAPGaaEgp+pOrJ+vKYFg3xbnbP_b8=J+bqeKSuj2UyhOG0AFdKw@mail.gmail.com>
 <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
Message-ID: <CADFQZ76KuVBKS=+rRwbOobUEgsPt_t1H=Zhhg9e=ZzrEDwUsOg@mail.gmail.com>

I think any software related technology (frameworks, languages and even
applications) that goes around long enough will eventually have
duplications in how the user interacts with it. Java is not the exception,
it happened already very early in the history of the language ,r emember
how HashTables and vectors were replaced by the Collection API for example,
Date and LocalDateTime are another example, both are, objectively speaking,
dualities that are more important and even disruptive in both surface and
application in real production systems than the new IO class.

This happens naturally and gradually since languages and frameworks are not
isolated islands but exist within a competitive market environment which
demands and requirements evolve with time, so they must. Java is a tool for
solving problems not a symbol of tradition and OOP sacredness.

The best solution to resolve this duality issues is good documentation and
a collaborative community that embraces and teach the new ways, that most
of the time are more convenient.

Best regards.

El mi?, 4 de jun de 2025, 5:29?p. m., Brian Goetz <brian.goetz at oracle.com>
escribi?:

> This was received on amber-spec-comments.
>
>
> -------- Forwarded Message --------
> Subject: Regarding JEP 512
> Date: Wed, 4 Jun 2025 18:43:32 +0200
> From: Rufus Riefenstahl <rufusriefenstahl at gmail.com>
> <rufusriefenstahl at gmail.com>
> To: amber-spec-comments at openjdk.org
>
> Hello there, project Amber EG team.
>  I would like to share my honest thoughts regarding JEP 512: "Compact
> Source Files and Instance Main Methods".
> First off, let me introduce myself. My name is Rufus Riefenstahl.
> I have been programming Java for about 20 years, 13 of them professionally.
> My work includes major contributions to desktop software at film
> production firms and 3 years so far, backend development using Spring Boot.
> Lately I am preparing to apply for a mentorship position at my company,
> teaching novices how to do Java better.
> Now my thoughts about the JEP...
> When I first saw it, I thought to myself: "Well, great! Newcomers can get
> started with Java quicker!"
> Yes, the "public static void main(String[] args)..." is definitely a lot
> to a new coder, especially if not proficient enough in object orientation,
> and seemingly very difficult for a person whose first programming language
> is Java! (I remember it myself...)
> As the JEP depicts, a beginner may tell to himself that the language is
> just too "complex" to carry out a simple println(). Also, it says that the
> current, long way of doing it, is intended for large scale programs. And
> that's where my first doubt about this arrives - what really is a "large
> scale program"? Onto that later. The JEP proposes an interesting way of
> simplifying things. Instead beginners, or "simple command line
> scripts/utilities" (!!!, I will get to this later too) will use the void
> main(){} with IO.[whatever]. Now here is the second problem as I see it: By
> introducing an "IO" class, the "conventional" ways of getting something to
> the standard input/output increases to 2. The original is
> System.out.println(), which is the standard, Java-iconic way to do it. Now,
> IO is not limited to this "compact notation" as I will call it, but freely
> available in "large-scale programs", too. This may eventually result to
> some people using IO for printing & reading in non-small source. But I
> still presume most codebases will continue to use
> System.[whatever].[whatever] or the BufferedReader to get input - most Java
> is written in enterprise anyway. (yes, getting input, especially in Java,
> is pretty complex for a beginner, for sure.). Also tutorials regarding Java
> have always used the "standard" ways and it would take time to adopt this
> simplification and would maybe contribute to some confusion on why don't
> people introduce Java "that way". Another thing is that most
> "production-grade" Java isn't on the newest version, which is unfortunate,
> but this JEP being integrated to 25, an LTS, would make a difference. Back
> to my criticism. This creates a duality. Why may this be this be a problem?
> Let me explain. The core values of Java.
> Most of the Java community, or at least the contributors/developers
> working on it, value stability, backwards compatibility, and overall maybe
> a slower pace of features, but making sure that those features actually
> commit to making Java better. To make Java last very long as a language. A
> language you can always come back to and not get overwhelmed with a bunch
> of "optional" syntax candy. I stand behind this too. Trust me, I have
> programmed in languages like C#, and their pace of change is too quick for
> me - while reading other projects' code I need to have a documentation tab
> open - showing the new syntax, at least most of the time. Java strives to
> be different. Recent additions like Virtual Threads prove that Java is
> exceptional: amazing "async/await" behaviour without the "burden" of
> function coloring (I recommend reading the post "What color is your
> function?" online). Making Java great, maintainable, good to write for the
> future, while being familiar to any programmers that may return to Java.
> Can't of course forget the new people, too. Sure, Java onboarding is not
> the easiest, especially when compared to languages like Python, but it
> makes sense in the long run.
> This gets to the core of this message: The feature that's being proposed
> isn't inherently "bad", but the philosophy change that may occur. For
> example, specifically dividing "small learning programs/utilities" and
> "large scale programs" is just completely foreign to me in the Java space.
> Java was always built on solid conventions, style guides, and the ease of
> writing (not immediately perhaps, but after understanding major OO
> concepts), and most importantly - reading, yes, reading. When I open a java
> project of any codebase, I can understand it almost always. Don't forget:
> most time looking at the editor buffer is spent reading and debugging code,
> not writing new code. Yes, the programming landscape is changing with
> Python at the top of the food chain currently. Java must adapt to necessary
> industry changes, but should not adopt the "shiny new thing" immediately,
> as it hasn't done in the past and I feel like that's a good thing. Again, I
> don't feel like this compact writing is bad, but I feel that it's not
> absolutely necessary and contributes to a code style divide, more so
> because it's not only geared towards beginners but also "small scale
> programs". Java has gotten lots of "hate" from a lot of people who
> criticized things I praise. Java isn't perfect, but it's a stable,
> statically typed high-level programming language. A language you can always
> get back to.
> I'm sorry if this "rant" was too long, but these are my thoughts. Perhaps
> I can't do much now as the feature is looking like to be 100% integrated in
> 25, but I at least so that this message to serves to everyone as a some
> sort of a "cautionary tale".
> If you don't agree with my opinions, fine. But be aware.
> If you'd like to discuss this matter further with me, I am 100% open.
>
> Have a blessed day.
> - Riefenstahl
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250605/9491c52d/attachment.htm>

From jean-noel.rouvignac at pingidentity.com  Sat Jun  7 07:13:31 2025
From: jean-noel.rouvignac at pingidentity.com (=?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac?=)
Date: Sat, 7 Jun 2025 09:13:31 +0200
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
Message-ID: <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>

Hello folks,

JDK 25 rampdown phase 1 is now behind us, congrats and thanks for all the
work done to get there!

I am reviving this use case to see if anyone agrees that this may be a bug?

Thank you,
Jean-Noel


On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Hello amber-dev folks!
>
> While using pattern matching for instanceof I noticed a small incoherent
> oddity.
>
> Take this code:
> ```
> static void ensureCapacity(List l) {
>   if (l instanceof LinkedList) {
>     throw new IllegalArgumentException("Use an efficient list
> implementation");
>   } else if (!(l instanceof ArrayList al)) {
>     return;
>   }
>   al.ensureCapacity(10);
>   System.out.println("done");
> }
>
> ensureCapacity(new ArrayList());
> ```
>
> The compiler rejects this code with: `Cannot resolve symbol 'al'`.
> (I have tested that code with JDK 24 in the playground (
> https://dev.java/playground) but also in my IDE with JDK 21)
>
> However #1, removing the `else` keyword makes the code successfully
> compile:
> ```
>   }
>   if (!(l instanceof ArrayList al)) {
>     return;
>   }
> ```
>
> However #2, adding an additional `else` keyword makes the code
> successfully compile:
> ```
>         } else if (!(l instanceof ArrayList al)) {
>             return;
>         } else {
>             al.ensureCapacity(10);
>             System.out.println("done");
>         }
> ```
>
> While option #1 and #2 are acceptable workarounds, it looks to me like
> there could be a bug in javac? Therefore I am bringing this to your
> attention so you can decide if it is a bug or not.
>
> I searched the JDK's bug tracker for this specific case, but could not
> find anything related.
>
> Thanks!
> Jean-No?l
>


-- 
<https://www.pingidentity.com/> <https://www.pingidentity.com/>[image: Ping
Identity] <https://www.pingidentity.com/>
Jean-Noel Rouvignac
Senior Principal Software Engineer
jean-noel.rouvignac at pingidentity.com

<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/events/youniverse.html>
<https://www.pingidentity.com/en/gartner-magic-quadrant-access-management.html?utm_medium=email>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
<https://www.pingidentity.com/en/events/youniverse.html>
Connect with us: [image: Glassdoor logo]
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
LinkedIn logo] <https://www.linkedin.com/company/21870>[image: Twitter logo]
<https://twitter.com/pingidentity>[image: YouTube logo]
<https://www.youtube.com/user/PingIdentityTV>[image: Blog logo]
<https://www.pingidentity.com/en/blog.html>
To view our privacy policy, click here
<https://www.pingidentity.com/en/legal/privacy.html>
To stop receiving these emails, click here
<https://4.pingidentity.com/PreferenceCenter.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.? If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250607/93b32a14/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Jun  7 14:55:10 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 7 Jun 2025 10:55:10 -0400
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
 <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
Message-ID: <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>

This definitely looks like a bug. Maybe some of the amber folks are busy
with Valhalla or something, but I can't see this NOT being a bug.

@Angelos Bimpoudis <angelos.bimpoudis at oracle.com> poke poke poke

On Sat, Jun 7, 2025, 3:14?AM Jean-No?l Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Hello folks,
>
> JDK 25 rampdown phase 1 is now behind us, congrats and thanks for all the
> work done to get there!
>
> I am reviving this use case to see if anyone agrees that this may be a bug?
>
> Thank you,
> Jean-Noel
>
>
> On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac <
> jean-noel.rouvignac at pingidentity.com> wrote:
>
>> Hello amber-dev folks!
>>
>> While using pattern matching for instanceof I noticed a small incoherent
>> oddity.
>>
>> Take this code:
>> ```
>> static void ensureCapacity(List l) {
>>   if (l instanceof LinkedList) {
>>     throw new IllegalArgumentException("Use an efficient list
>> implementation");
>>   } else if (!(l instanceof ArrayList al)) {
>>     return;
>>   }
>>   al.ensureCapacity(10);
>>   System.out.println("done");
>> }
>>
>> ensureCapacity(new ArrayList());
>> ```
>>
>> The compiler rejects this code with: `Cannot resolve symbol 'al'`.
>> (I have tested that code with JDK 24 in the playground (
>> https://dev.java/playground) but also in my IDE with JDK 21)
>>
>> However #1, removing the `else` keyword makes the code successfully
>> compile:
>> ```
>>   }
>>   if (!(l instanceof ArrayList al)) {
>>     return;
>>   }
>> ```
>>
>> However #2, adding an additional `else` keyword makes the code
>> successfully compile:
>> ```
>>         } else if (!(l instanceof ArrayList al)) {
>>             return;
>>         } else {
>>             al.ensureCapacity(10);
>>             System.out.println("done");
>>         }
>> ```
>>
>> While option #1 and #2 are acceptable workarounds, it looks to me like
>> there could be a bug in javac? Therefore I am bringing this to your
>> attention so you can decide if it is a bug or not.
>>
>> I searched the JDK's bug tracker for this specific case, but could not
>> find anything related.
>>
>> Thanks!
>> Jean-No?l
>>
>
>
> --
> <https://www.pingidentity.com/> <https://www.pingidentity.com/>[image:
> Ping Identity] <https://www.pingidentity.com/>
> Jean-Noel Rouvignac
> Senior Principal Software Engineer
> jean-noel.rouvignac at pingidentity.com
>
> <https://www.pingidentity.com/en/events/youniverse.html>
> <https://www.pingidentity.com/en/events/youniverse.html>
> <https://www.pingidentity.com/en/events/youniverse.html>
> <https://www.pingidentity.com/en/gartner-magic-quadrant-access-management.html?utm_medium=email>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>
> <https://www.pingidentity.com/en/events/youniverse.html>
> Connect with us: [image: Glassdoor logo]
> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
> LinkedIn logo] <https://www.linkedin.com/company/21870>[image: Twitter
> logo] <https://twitter.com/pingidentity>[image: YouTube logo]
> <https://www.youtube.com/user/PingIdentityTV>[image: Blog logo]
> <https://www.pingidentity.com/en/blog.html>
> To view our privacy policy, click here
> <https://www.pingidentity.com/en/legal/privacy.html>
> To stop receiving these emails, click here
> <https://4.pingidentity.com/PreferenceCenter.html>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250607/57009e54/attachment.htm>

From chen.l.liang at oracle.com  Sun Jun  8 00:47:22 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 8 Jun 2025 00:47:22 +0000
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
 <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
 <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
Message-ID: <SJ2PR10MB7669379BA7EEC145F4A5343CA269A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi all,

First, note the original example is equivalent to below:
  if (l instanceof LinkedList) {
    throw new IllegalArgumentException("Use an efficient list implementation");
  } else {
    if (!(l instanceof ArrayList al)) {
      return;
    }
  }
Which should be more clarifying about why the language has this behavior. Variables defined in a block is not available outside of that block.

From the specification perspective, currently, JLS 6.3.2.2 "if Statements" says:
A pattern variable is introduced by if (e) S else T iff either: ... It is introduced by e when false, and S cannot complete normally, and T can complete normally.

This means that a pattern variable introduced by statement T (here the nested if statement after else) is not introduced by the (main) if statement, and this is working as intended per JLS.

I personally think the status quo is fine - allowing variables to leak beyond blocks is risky and may introduce source incompatibility; even if we commit to such a change, we have too many statements to update (for, if, do, while, etc...) and is also error-prone.

Regards,
Chen Liang
________________________________
From: amber-dev <amber-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Saturday, June 7, 2025 9:55 AM
To: Jean-No?l Rouvignac <jean-noel.rouvignac at pingidentity.com>; Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Cc: amber-dev <amber-dev at openjdk.org>
Subject: Re: "Cannot resolve symbol al" after `else if (! (l instanceof ArrayList al))`


This definitely looks like a bug. Maybe some of the amber folks are busy with Valhalla or something, but I can't see this NOT being a bug.

@Angelos Bimpoudis<mailto:angelos.bimpoudis at oracle.com> poke poke poke

On Sat, Jun 7, 2025, 3:14?AM Jean-No?l Rouvignac <jean-noel.rouvignac at pingidentity.com<mailto:jean-noel.rouvignac at pingidentity.com>> wrote:
Hello folks,

JDK 25 rampdown phase 1 is now behind us, congrats and thanks for all the work done to get there!

I am reviving this use case to see if anyone agrees that this may be a bug?

Thank you,
Jean-Noel


On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac <jean-noel.rouvignac at pingidentity.com<mailto:jean-noel.rouvignac at pingidentity.com>> wrote:
Hello amber-dev folks!

While using pattern matching for instanceof I noticed a small incoherent oddity.

Take this code:
```
static void ensureCapacity(List l) {
  if (l instanceof LinkedList) {
    throw new IllegalArgumentException("Use an efficient list implementation");
  } else if (!(l instanceof ArrayList al)) {
    return;
  }
  al.ensureCapacity(10);
  System.out.println("done");
}

ensureCapacity(new ArrayList());
```

The compiler rejects this code with: `Cannot resolve symbol 'al'`.
(I have tested that code with JDK 24 in the playground (https://dev.java/playground) but also in my IDE with JDK 21)

However #1, removing the `else` keyword makes the code successfully compile:
```
  }
  if (!(l instanceof ArrayList al)) {
    return;
  }
```

However #2, adding an additional `else` keyword makes the code successfully compile:
```
        } else if (!(l instanceof ArrayList al)) {
            return;
        } else {
            al.ensureCapacity(10);
            System.out.println("done");
        }
```

While option #1 and #2 are acceptable workarounds, it looks to me like there could be a bug in javac? Therefore I am bringing this to your attention so you can decide if it is a bug or not.

I searched the JDK's bug tracker for this specific case, but could not find anything related.

Thanks!
Jean-No?l


--
<https://www.pingidentity.com/><https://www.pingidentity.com/>[Ping Identity]<https://www.pingidentity.com/>
Jean-Noel Rouvignac
Senior Principal Software Engineer
jean-noel.rouvignac at pingidentity.com<mailto:jean-noel.rouvignac at pingidentity.com>

<https://www.pingidentity.com/en/events/youniverse.html><https://www.pingidentity.com/en/events/youniverse.html><https://www.pingidentity.com/en/events/youniverse.html><https://www.pingidentity.com/en/gartner-magic-quadrant-access-management.html?utm_medium=email><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent><https://www.pingidentity.com/en/events/virtualsummit.html?utm_source=sales&utm_medium=email&utm_campaign=VFE-GLOBAL-2025.03.18-19-PingVirtualEvent>[https://www.pingidentity.com/content/dam/picr/img/em/2025-YOUniverse-EmailSig.jpg]<https://www.pingidentity.com/en/events/youniverse.html>
Connect with us:        [Glassdoor logo] <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [LinkedIn logo] <https://www.linkedin.com/company/21870> [Twitter logo] <https://twitter.com/pingidentity> [YouTube logo] <https://www.youtube.com/user/PingIdentityTV> [Blog logo] <https://www.pingidentity.com/en/blog.html>
To view our privacy policy, click here<https://www.pingidentity.com/en/legal/privacy.html>
To stop receiving these emails, click here<https://4.pingidentity.com/PreferenceCenter.html>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250608/02c524f7/attachment-0001.htm>

From tzengshinfu at gmail.com  Sun Jun  8 14:01:24 2025
From: tzengshinfu at gmail.com (tzengshinfu)
Date: Sun, 8 Jun 2025 22:01:24 +0800
Subject: Regarding JEP 512
In-Reply-To: <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
References: <CAPGaaEgp+pOrJ+vKYFg3xbnbP_b8=J+bqeKSuj2UyhOG0AFdKw@mail.gmail.com>
 <adfbc395-1dd2-4f9d-9e42-cf3893de5884@oracle.com>
Message-ID: <CANj-iJeDaCq=m20P-efrotqUgcj60XoRoevDFmp+ADdGi62sBw@mail.gmail.com>

After mentoring new colleagues transitioning from other languages to Java,
I eventually moved away from the Java ecosystem due to a job rotation. Now,
I primarily use C# (for customer-facing system maintenance) and Python (for
RAG-related SDKs).

I also switched my main IDE from IntelliJ IDEA to VSCode. For small
features or proofs of concept, Python is usually the first thing that comes
to mind. It is usually my go-to?it lets me quickly write the first line of
code and jump straight in. This might also be because IntelliJ IDEA is a
bit heavy, and Java?s syntax and declarations are more complex.
(However, Python can be less reliable, especially with method suggestions.)

Both Python and C# support script-style execution, allowing me to start
coding with just a function definition and evolve into proper
object-oriented classes as needed. But when it comes to system performance
and reliability, I still firmly side with Java.

Although now I can take it easy for a while and no longer need to explain
to new colleagues why string comparisons should use ::equals instead of ==.


/* GET BETTER EVERY DAY */




On Thu, Jun 5, 2025 at 8:25?AM Brian Goetz <brian.goetz at oracle.com> wrote:

> This was received on amber-spec-comments.
>
>
> -------- Forwarded Message --------
> Subject: Regarding JEP 512
> Date: Wed, 4 Jun 2025 18:43:32 +0200
> From: Rufus Riefenstahl <rufusriefenstahl at gmail.com>
> <rufusriefenstahl at gmail.com>
> To: amber-spec-comments at openjdk.org
>
> Hello there, project Amber EG team.
>  I would like to share my honest thoughts regarding JEP 512: "Compact
> Source Files and Instance Main Methods".
> First off, let me introduce myself. My name is Rufus Riefenstahl.
> I have been programming Java for about 20 years, 13 of them professionally.
> My work includes major contributions to desktop software at film
> production firms and 3 years so far, backend development using Spring Boot.
> Lately I am preparing to apply for a mentorship position at my company,
> teaching novices how to do Java better.
> Now my thoughts about the JEP...
> When I first saw it, I thought to myself: "Well, great! Newcomers can get
> started with Java quicker!"
> Yes, the "public static void main(String[] args)..." is definitely a lot
> to a new coder, especially if not proficient enough in object orientation,
> and seemingly very difficult for a person whose first programming language
> is Java! (I remember it myself...)
> As the JEP depicts, a beginner may tell to himself that the language is
> just too "complex" to carry out a simple println(). Also, it says that the
> current, long way of doing it, is intended for large scale programs. And
> that's where my first doubt about this arrives - what really is a "large
> scale program"? Onto that later. The JEP proposes an interesting way of
> simplifying things. Instead beginners, or "simple command line
> scripts/utilities" (!!!, I will get to this later too) will use the void
> main(){} with IO.[whatever]. Now here is the second problem as I see it: By
> introducing an "IO" class, the "conventional" ways of getting something to
> the standard input/output increases to 2. The original is
> System.out.println(), which is the standard, Java-iconic way to do it. Now,
> IO is not limited to this "compact notation" as I will call it, but freely
> available in "large-scale programs", too. This may eventually result to
> some people using IO for printing & reading in non-small source. But I
> still presume most codebases will continue to use
> System.[whatever].[whatever] or the BufferedReader to get input - most Java
> is written in enterprise anyway. (yes, getting input, especially in Java,
> is pretty complex for a beginner, for sure.). Also tutorials regarding Java
> have always used the "standard" ways and it would take time to adopt this
> simplification and would maybe contribute to some confusion on why don't
> people introduce Java "that way". Another thing is that most
> "production-grade" Java isn't on the newest version, which is unfortunate,
> but this JEP being integrated to 25, an LTS, would make a difference. Back
> to my criticism. This creates a duality. Why may this be this be a problem?
> Let me explain. The core values of Java.
> Most of the Java community, or at least the contributors/developers
> working on it, value stability, backwards compatibility, and overall maybe
> a slower pace of features, but making sure that those features actually
> commit to making Java better. To make Java last very long as a language. A
> language you can always come back to and not get overwhelmed with a bunch
> of "optional" syntax candy. I stand behind this too. Trust me, I have
> programmed in languages like C#, and their pace of change is too quick for
> me - while reading other projects' code I need to have a documentation tab
> open - showing the new syntax, at least most of the time. Java strives to
> be different. Recent additions like Virtual Threads prove that Java is
> exceptional: amazing "async/await" behaviour without the "burden" of
> function coloring (I recommend reading the post "What color is your
> function?" online). Making Java great, maintainable, good to write for the
> future, while being familiar to any programmers that may return to Java.
> Can't of course forget the new people, too. Sure, Java onboarding is not
> the easiest, especially when compared to languages like Python, but it
> makes sense in the long run.
> This gets to the core of this message: The feature that's being proposed
> isn't inherently "bad", but the philosophy change that may occur. For
> example, specifically dividing "small learning programs/utilities" and
> "large scale programs" is just completely foreign to me in the Java space.
> Java was always built on solid conventions, style guides, and the ease of
> writing (not immediately perhaps, but after understanding major OO
> concepts), and most importantly - reading, yes, reading. When I open a java
> project of any codebase, I can understand it almost always. Don't forget:
> most time looking at the editor buffer is spent reading and debugging code,
> not writing new code. Yes, the programming landscape is changing with
> Python at the top of the food chain currently. Java must adapt to necessary
> industry changes, but should not adopt the "shiny new thing" immediately,
> as it hasn't done in the past and I feel like that's a good thing. Again, I
> don't feel like this compact writing is bad, but I feel that it's not
> absolutely necessary and contributes to a code style divide, more so
> because it's not only geared towards beginners but also "small scale
> programs". Java has gotten lots of "hate" from a lot of people who
> criticized things I praise. Java isn't perfect, but it's a stable,
> statically typed high-level programming language. A language you can always
> get back to.
> I'm sorry if this "rant" was too long, but these are my thoughts. Perhaps
> I can't do much now as the feature is looking like to be 100% integrated in
> 25, but I at least so that this message to serves to everyone as a some
> sort of a "cautionary tale".
> If you don't agree with my opinions, fine. But be aware.
> If you'd like to discuss this matter further with me, I am 100% open.
>
> Have a blessed day.
> - Riefenstahl
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250608/ea4990ef/attachment.htm>

From jan.lahoda at oracle.com  Mon Jun  9 06:12:26 2025
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 9 Jun 2025 08:12:26 +0200
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
 <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
 <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
Message-ID: <99e74791-4987-404b-8c17-b6d1142cb946@oracle.com>

Hi,


I believe this is what is specified.


Considering:

if (e) S

else T


JLS 6.3.2.2, says that (in some cases), the binding variable from 'e' 
can be introduced to the enclosing scope of the `if`. But I am not aware 
about anything that would say a variable from `T` should be introduced 
to the enclosing scope if the outer `if`.


In the example below, `if (l instanceof LinkedList)` does not introduce 
any binding variables, and hence no binding variable is not introduced 
to the enclosing scope of the `if`.


Please also see:

https://bugs.openjdk.org/browse/JDK-8335402


Jan


On 07. 06. 25 16:55, David Alayachew wrote:
>
> This definitely looks like a bug. Maybe some of the amber folks are 
> busy with Valhalla or something, but I can't see this NOT being a bug.
>
> @Angelos Bimpoudis <mailto:angelos.bimpoudis at oracle.com>?poke poke poke
>
>
> On Sat, Jun 7, 2025, 3:14?AM Jean-No?l Rouvignac 
> <jean-noel.rouvignac at pingidentity.com> wrote:
>
>     Hello folks,
>
>     JDK 25 rampdown?phase 1 is now behind us, congrats and thanks for
>     all the work done to get there!
>
>     I am reviving this use case to see if anyone agrees that this may
>     be a bug?
>
>     Thank you,
>     Jean-Noel
>
>
>     On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac
>     <jean-noel.rouvignac at pingidentity.com> wrote:
>
>         Hello amber-dev folks!
>
>         While using pattern matching for instanceof I noticed a small
>         incoherent oddity.
>
>         Take this code:
>         ```
>         static void ensureCapacity(List l) {
>         ? if (l instanceof LinkedList) {
>         ? ? throw new IllegalArgumentException("Use an efficient list
>         implementation");
>         ? } else if (!(l instanceof ArrayList al)) {
>         ? ? return;
>         ? }
>         ? al.ensureCapacity(10);
>         ? System.out.println("done");
>         }
>
>         ensureCapacity(new ArrayList());
>         ```
>
>         The compiler rejects this code with: `Cannot resolve symbol 'al'`.
>         (I have tested that code with JDK 24 in the playground
>         (https://dev.java/playground) but also in my IDE with JDK 21)
>
>         However #1, removing the `else` keyword makes the code
>         successfully compile:
>         ```
>         ? }
>         ? if (!(l instanceof ArrayList al)) {
>         ? ? return;
>         ? }
>         ```
>
>         However #2, adding an additional `else` keyword makes the code
>         successfully compile:
>         ```
>         ? ? ? ? } else if (!(l instanceof ArrayList al)) {
>         ? ? ? ? ? ? return;
>         ? ? ? ? } else {
>         ? ? ? ? ? ? al.ensureCapacity(10);
>         ? ? ? ? ? ? System.out.println("done");
>         ? ? ? ? }
>         ```
>
>         While option #1 and #2 are acceptable workarounds, it looks to
>         me like there could be a bug in javac? Therefore I am bringing
>         this to your attention so you can decide if it is a bug or not.
>
>         I searched the JDK's bug tracker for this specific case, but
>         could not find anything related.
>
>         Thanks!
>         Jean-No?l
>
>
>
>     -- 
>     Ping Identity <https://www.pingidentity.com/> 	
>     Jean-Noel Rouvignac
>     Senior Principal Software Engineer
>     jean-noel.rouvignac at pingidentity.com
>
>     <https://www.pingidentity.com/en/events/youniverse.html>
>     Connect with us: 	Glassdoor logo
>     <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>LinkedIn
>     logo <https://www.linkedin.com/company/21870>Twitter logo
>     <https://twitter.com/pingidentity>YouTube logo
>     <https://www.youtube.com/user/PingIdentityTV>Blog logo
>     <https://www.pingidentity.com/en/blog.html>
>
>     To view our privacy policy, click here
>     <https://www.pingidentity.com/en/legal/privacy.html>
>     To stop receiving these emails, click here
>     <https://4.pingidentity.com/PreferenceCenter.html>
>
>
>     /CONFIDENTIALITY NOTICE: This email may contain confidential and
>     privileged material for the sole use of the intended recipient(s).
>     Any review, use, distribution or disclosure by others is strictly
>     prohibited.? If you have received this communication in error,
>     please notify the sender immediately by e-mail and delete the
>     message and any file attachments from your computer. Thank you./
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250609/cd9a0a65/attachment-0001.htm>

From jean-noel.rouvignac at pingidentity.com  Mon Jun  9 08:34:25 2025
From: jean-noel.rouvignac at pingidentity.com (=?UTF-8?Q?Jean=2DNo=C3=ABl_Rouvignac?=)
Date: Mon, 9 Jun 2025 10:34:25 +0200
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <99e74791-4987-404b-8c17-b6d1142cb946@oracle.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
 <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
 <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
 <99e74791-4987-404b-8c17-b6d1142cb946@oracle.com>
Message-ID: <CABw-sUJ5vkPs5_MHh9ACn=x8GB50hzAx2Tdg3cGo95AiUc+3yw@mail.gmail.com>

Yes, I can now see how this matches the spec, and it makes sense.
Although this could perhaps be a bit surprising to the users, I believe the
workarounds make for better code anyway.

This reminds me of another case discussed some time ago: effectively final
assignment over try / catch. It is the same thing here: trying to go above
and beyond for edge cases can trigger more problems down the line, so we're
better off not doing it.

Thanks a lot to all of you for taking the time to answer.

Jean-No?l


Le lun. 9 juin 2025 ? 08:12, Jan Lahoda <jan.lahoda at oracle.com> a ?crit :

> Hi,
>
>
> I believe this is what is specified.
>
>
> Considering:
>
> if (e) S
>
> else T
>
>
> JLS 6.3.2.2, says that (in some cases), the binding variable from 'e' can
> be introduced to the enclosing scope of the `if`. But I am not aware about
> anything that would say a variable from `T` should be introduced to the
> enclosing scope if the outer `if`.
>
>
> In the example below, `if (l instanceof LinkedList)` does not introduce
> any binding variables, and hence no binding variable is not introduced to
> the enclosing scope of the `if`.
>
>
> Please also see:
>
> https://bugs.openjdk.org/browse/JDK-8335402
>
>
> Jan
>
>
> On 07. 06. 25 16:55, David Alayachew wrote:
>
> This definitely looks like a bug. Maybe some of the amber folks are busy
> with Valhalla or something, but I can't see this NOT being a bug.
>
> @Angelos Bimpoudis <angelos.bimpoudis at oracle.com> poke poke poke
>
> On Sat, Jun 7, 2025, 3:14?AM Jean-No?l Rouvignac <
> jean-noel.rouvignac at pingidentity.com> wrote:
>
>> Hello folks,
>>
>> JDK 25 rampdown phase 1 is now behind us, congrats and thanks for all the
>> work done to get there!
>>
>> I am reviving this use case to see if anyone agrees that this may be a
>> bug?
>>
>> Thank you,
>> Jean-Noel
>>
>>
>> On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac <
>> jean-noel.rouvignac at pingidentity.com> wrote:
>>
>>> Hello amber-dev folks!
>>>
>>> While using pattern matching for instanceof I noticed a small incoherent
>>> oddity.
>>>
>>> Take this code:
>>> ```
>>> static void ensureCapacity(List l) {
>>>   if (l instanceof LinkedList) {
>>>     throw new IllegalArgumentException("Use an efficient list
>>> implementation");
>>>   } else if (!(l instanceof ArrayList al)) {
>>>     return;
>>>   }
>>>   al.ensureCapacity(10);
>>>   System.out.println("done");
>>> }
>>>
>>> ensureCapacity(new ArrayList());
>>> ```
>>>
>>> The compiler rejects this code with: `Cannot resolve symbol 'al'`.
>>> (I have tested that code with JDK 24 in the playground (
>>> https://dev.java/playground) but also in my IDE with JDK 21)
>>>
>>> However #1, removing the `else` keyword makes the code successfully
>>> compile:
>>> ```
>>>   }
>>>   if (!(l instanceof ArrayList al)) {
>>>     return;
>>>   }
>>> ```
>>>
>>> However #2, adding an additional `else` keyword makes the code
>>> successfully compile:
>>> ```
>>>         } else if (!(l instanceof ArrayList al)) {
>>>             return;
>>>         } else {
>>>             al.ensureCapacity(10);
>>>             System.out.println("done");
>>>         }
>>> ```
>>>
>>> While option #1 and #2 are acceptable workarounds, it looks to me like
>>> there could be a bug in javac? Therefore I am bringing this to your
>>> attention so you can decide if it is a bug or not.
>>>
>>> I searched the JDK's bug tracker for this specific case, but could not
>>> find anything related.
>>>
>>> Thanks!
>>> Jean-No?l
>>>
>>
>>
>> --
>> [image: Ping Identity] <https://www.pingidentity.com/>
>> Jean-Noel Rouvignac
>> Senior Principal Software Engineer
>> jean-noel.rouvignac at pingidentity.com
>>
>> <https://www.pingidentity.com/en/events/youniverse.html>
>> Connect with us: [image: Glassdoor logo]
>> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
>> LinkedIn logo] <https://www.linkedin.com/company/21870>[image: Twitter
>> logo] <https://twitter.com/pingidentity>[image: YouTube logo]
>> <https://www.youtube.com/user/PingIdentityTV>[image: Blog logo]
>> <https://www.pingidentity.com/en/blog.html>
>> To view our privacy policy, click here
>> <https://www.pingidentity.com/en/legal/privacy.html>
>> To stop receiving these emails, click here
>> <https://4.pingidentity.com/PreferenceCenter.html>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.? If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250609/50a00cea/attachment-0001.htm>

From talden at gmail.com  Mon Jun  9 11:50:03 2025
From: talden at gmail.com (Aaron Scott-Boddendijk)
Date: Mon, 9 Jun 2025 23:50:03 +1200
Subject: "Cannot resolve symbol al" after `else if (! (l instanceof
 ArrayList al))`
In-Reply-To: <CABw-sUJ5vkPs5_MHh9ACn=x8GB50hzAx2Tdg3cGo95AiUc+3yw@mail.gmail.com>
References: <CABw-sUJnDr5KuUwJkFsmR4E1Lqs4_g2ugfNNVRSPWkA4wcGwQA@mail.gmail.com>
 <CABw-sUKcTerdwayfy0t4k95x=_eYch22wFPem1FKE=QDcOa=qQ@mail.gmail.com>
 <CAA9v-_NH824MPTnqzVYG4dMmhkAEw9abZ9MsfKkWPVir9Mwi_g@mail.gmail.com>
 <99e74791-4987-404b-8c17-b6d1142cb946@oracle.com>
 <CABw-sUJ5vkPs5_MHh9ACn=x8GB50hzAx2Tdg3cGo95AiUc+3yw@mail.gmail.com>
Message-ID: <CAE=ECuQkKnBDe1=rVH2O5B6W7dg9b5g3wF6N+YR4gi5tsXHr0A@mail.gmail.com>

I'd encourage them to flatten the if-else chain when true-bodies don't
complete normally (throwing or returning)

static void ensureCapacity(List l) {
  if (l instanceof LinkedList) {
    throw new IllegalArgumentException("Use an efficient list
implementation");
  }

  if (!(l instanceof ArrayList al)) {
    return;
  }
  al.ensureCapacity(10);
  System.out.println("done");
}

This is, IMO, simpler to read and reason about.  Simply some number of
'gates' to pass before reaching the work of the method.

And as you add new gates, you don't create churn on the lines for the other
gates (thinking about simpler diffs and clearer git-blame information).

--
Aaron Scott-Boddendijk


On Mon, 9 Jun 2025 at 20:34, Jean-No?l Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Yes, I can now see how this matches the spec, and it makes sense.
> Although this could perhaps be a bit surprising to the users, I believe
> the workarounds make for better code anyway.
>
> This reminds me of another case discussed some time ago: effectively final
> assignment over try / catch. It is the same thing here: trying to go above
> and beyond for edge cases can trigger more problems down the line, so we're
> better off not doing it.
>
> Thanks a lot to all of you for taking the time to answer.
>
> Jean-No?l
>
>
> Le lun. 9 juin 2025 ? 08:12, Jan Lahoda <jan.lahoda at oracle.com> a ?crit :
>
>> Hi,
>>
>>
>> I believe this is what is specified.
>>
>>
>> Considering:
>>
>> if (e) S
>>
>> else T
>>
>>
>> JLS 6.3.2.2, says that (in some cases), the binding variable from 'e' can
>> be introduced to the enclosing scope of the `if`. But I am not aware about
>> anything that would say a variable from `T` should be introduced to the
>> enclosing scope if the outer `if`.
>>
>>
>> In the example below, `if (l instanceof LinkedList)` does not introduce
>> any binding variables, and hence no binding variable is not introduced to
>> the enclosing scope of the `if`.
>>
>>
>> Please also see:
>>
>> https://bugs.openjdk.org/browse/JDK-8335402
>>
>>
>> Jan
>>
>>
>> On 07. 06. 25 16:55, David Alayachew wrote:
>>
>> This definitely looks like a bug. Maybe some of the amber folks are busy
>> with Valhalla or something, but I can't see this NOT being a bug.
>>
>> @Angelos Bimpoudis <angelos.bimpoudis at oracle.com> poke poke poke
>>
>> On Sat, Jun 7, 2025, 3:14?AM Jean-No?l Rouvignac <
>> jean-noel.rouvignac at pingidentity.com> wrote:
>>
>>> Hello folks,
>>>
>>> JDK 25 rampdown phase 1 is now behind us, congrats and thanks for all
>>> the work done to get there!
>>>
>>> I am reviving this use case to see if anyone agrees that this may be a
>>> bug?
>>>
>>> Thank you,
>>> Jean-Noel
>>>
>>>
>>> On Wed, Apr 16, 2025 at 11:37?AM Jean-No?l Rouvignac <
>>> jean-noel.rouvignac at pingidentity.com> wrote:
>>>
>>>> Hello amber-dev folks!
>>>>
>>>> While using pattern matching for instanceof I noticed a small
>>>> incoherent oddity.
>>>>
>>>> Take this code:
>>>> ```
>>>> static void ensureCapacity(List l) {
>>>>   if (l instanceof LinkedList) {
>>>>     throw new IllegalArgumentException("Use an efficient list
>>>> implementation");
>>>>   } else if (!(l instanceof ArrayList al)) {
>>>>     return;
>>>>   }
>>>>   al.ensureCapacity(10);
>>>>   System.out.println("done");
>>>> }
>>>>
>>>> ensureCapacity(new ArrayList());
>>>> ```
>>>>
>>>> The compiler rejects this code with: `Cannot resolve symbol 'al'`.
>>>> (I have tested that code with JDK 24 in the playground (
>>>> https://dev.java/playground) but also in my IDE with JDK 21)
>>>>
>>>> However #1, removing the `else` keyword makes the code successfully
>>>> compile:
>>>> ```
>>>>   }
>>>>   if (!(l instanceof ArrayList al)) {
>>>>     return;
>>>>   }
>>>> ```
>>>>
>>>> However #2, adding an additional `else` keyword makes the code
>>>> successfully compile:
>>>> ```
>>>>         } else if (!(l instanceof ArrayList al)) {
>>>>             return;
>>>>         } else {
>>>>             al.ensureCapacity(10);
>>>>             System.out.println("done");
>>>>         }
>>>> ```
>>>>
>>>> While option #1 and #2 are acceptable workarounds, it looks to me like
>>>> there could be a bug in javac? Therefore I am bringing this to your
>>>> attention so you can decide if it is a bug or not.
>>>>
>>>> I searched the JDK's bug tracker for this specific case, but could not
>>>> find anything related.
>>>>
>>>> Thanks!
>>>> Jean-No?l
>>>>
>>>
>>>
>>> --
>>> [image: Ping Identity] <https://www.pingidentity.com/>
>>> Jean-Noel Rouvignac
>>> Senior Principal Software Engineer
>>> jean-noel.rouvignac at pingidentity.com
>>>
>>> <https://www.pingidentity.com/en/events/youniverse.html>
>>> Connect with us: [image: Glassdoor logo]
>>> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
>>> LinkedIn logo] <https://www.linkedin.com/company/21870>[image: Twitter
>>> logo] <https://twitter.com/pingidentity>[image: YouTube logo]
>>> <https://www.youtube.com/user/PingIdentityTV>[image: Blog logo]
>>> <https://www.pingidentity.com/en/blog.html>
>>> To view our privacy policy, click here
>>> <https://www.pingidentity.com/en/legal/privacy.html>
>>> To stop receiving these emails, click here
>>> <https://4.pingidentity.com/PreferenceCenter.html>
>>>
>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s). Any
>>> review, use, distribution or disclosure by others is strictly prohibited.
>>> If you have received this communication in error, please notify the sender
>>> immediately by e-mail and delete the message and any file attachments from
>>> your computer. Thank you.*
>>
>>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250609/ec63bf94/attachment-0001.htm>

From go2432 at wayne.edu  Thu Jun 12 18:23:26 2025
From: go2432 at wayne.edu (Gregory Schwing)
Date: Thu, 12 Jun 2025 18:23:26 +0000
Subject: Native Amber Support for GPU Constant PH Implicit Solvent
Message-ID: <CO1PR11MB480333B067296FBCBA72C52FB474A@CO1PR11MB4803.namprd11.prod.outlook.com>

Dear AMBER developers:

I am interested in clarifying what exactly is happening when I follow the constant PH tutorial and use pmemd.cuda.  My two questions are following:


  1.
 What is the difference between the two manners of passing in parameters for running constant PH simulations?

There is method 1 (Constant PH tutorial approach https://ambermd.org/tutorials/advanced/tutorial18/)
TLEAP
"source leaprc.constph"
command line (e.g., AS4/GL4 dihedrals)
cpinutil.py -resnames HIP GL4 AS4 -p protein.prmtop -o protein.cpin
pmemd.cuda [...] -cpin cpin_file.in -cpout protein.prod.cpout -cprestrt protein.prod.cprestrt

Method 2 (GBNECK Patch Shen Lab Approach https://gitlab.com/shenlab-amber-cphmd<https://gitlab.com/shenlab-amber-cphmd>)
TLEAP
# Load the ff14SB force field
source leaprc.protein.ff14SB

# Set PBradii to mbondi3 (required for GBNeck2 in CpHMD)
set default PBradii mbondi3

# Load the CpHMD residue definitions (AS2 and GL2)
loadoff phmd.lib

# Load force field modifications for CpHMD (e.g., AS2/GL2 dihedrals)
loadamberparams frcmod.phmd

pmemd.cuda [...] -cpout protein.prod.cpout -cprestrt protein.prod.cprestrt \
-phmdparm gbneck2_input.parm -phmdin ph.mdin -phmdout protein.prod.lam -phmdrestrt protein.prod.phmdrst



  1.
How much of the calculation is on the GPU?  Are implicit solvent constant PH simulations accurate when using pmemd.cuda?

Continuous constant pH MD can be performed in three modes: implicit solvent (iphmd=1, only available in
CPU),[676?678] hybrid solvent (iphmd=2),[679] and all-atom (iphmd=3). [680?682] In the implicit-solvent mode,
both conformational and protonation state sampling is performed using a generalized Born (GB) model. [...] The implicit-solvent mode makes uses of the GBNeck2 model[28], and it is implemented for both CPUs[677] and GPUs[678], although the GPU version is currently only available through a downloadable patch (https://gitlab.com/shenlab-amber-cphmd/cphmd-patches). By contrast, the all-atom mode (iphmd=3) is implemented only for GPUs.[682]

Thank you in advance for your time,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250612/9ce8dd3e/attachment.htm>

From davidalayachew at gmail.com  Thu Jun 12 19:55:50 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 12 Jun 2025 15:55:50 -0400
Subject: Performance dropped significantly when switching from Nested Patterns
 to Flattened Patterns (was "Sharing my experience with Switch
 Expressions")
In-Reply-To: <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
References: <CAA9v-_NxT+x80yTpNugwXG6oC4JS6OVt_LTTvv2YZ0P-Yy4s3w@mail.gmail.com>
 <CAA9v-_PJ5MNW-UpLe2RY-TrK+ZJQQjOE1VpeiDeO7UorqyU6Mg@mail.gmail.com>
 <SJ2PR10MB766966B133C867ED109F9B58A294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PjaQK2Cunmqo4D3NfHme4rzixZ_kQbXCVWwPcJjOo7Tw@mail.gmail.com>
 <CAA9v-_MW7JbXSXPoZ7aQdA6bMYWjBMjbpoP+MDOceFTyk3VNww@mail.gmail.com>
 <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
Message-ID: <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>

Woah, something new came up.

On a whim, I tried to run the performance numbers, to see if there were any
performance differences between the nested pattern style and the flattened
pattern style, and there was!

The nested pattern style finished in under 30-60 seconds. But the flattened
pattern style took OVER AN HOUR.

I just wanted to bring this up, in case this is a bug, or maybe it's
expected behaviour. Please let me know!

On Fri, May 23, 2025 at 7:10?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Please let me know if there are any details missing, or if I could better
> explain the situation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250612/a4f68049/attachment-0001.htm>

From davidalayachew at gmail.com  Thu Jun 12 20:01:03 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 12 Jun 2025 16:01:03 -0400
Subject: Performance dropped significantly when switching from Nested
 Patterns to Flattened Patterns (was "Sharing my experience with Switch
 Expressions")
In-Reply-To: <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
References: <CAA9v-_NxT+x80yTpNugwXG6oC4JS6OVt_LTTvv2YZ0P-Yy4s3w@mail.gmail.com>
 <CAA9v-_PJ5MNW-UpLe2RY-TrK+ZJQQjOE1VpeiDeO7UorqyU6Mg@mail.gmail.com>
 <SJ2PR10MB766966B133C867ED109F9B58A294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PjaQK2Cunmqo4D3NfHme4rzixZ_kQbXCVWwPcJjOo7Tw@mail.gmail.com>
 <CAA9v-_MW7JbXSXPoZ7aQdA6bMYWjBMjbpoP+MDOceFTyk3VNww@mail.gmail.com>
 <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
 <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
Message-ID: <CAA9v-_MxsanAZ_eQ7hY45i8yexcWAQJo2J9dbe90KrYeNwdmPQ@mail.gmail.com>

Whoops, looks like the original thread did not get included during the
rename. Here is a link to the original thread --
https://mail.openjdk.org/pipermail/amber-dev/2025-May/009299.html

Alternatively, if you just want to jump to the code examples, I copied and
pasted them below.

Nested =
https://github.com/davidalayachew/HelltakerPathFinder/blob/12c57dab041924192b8613075ff6966b1b159e91/src/main/java/HelltakerPathFinderModule/HelltakerPathFinderPackage/Board.java#L511

Flattened =
https://github.com/davidalayachew/HelltakerPathFinder/blob/10b7a9d5fc4f6f563a68824de9a70735c7533226/src/main/java/HelltakerPathFinderModule/HelltakerPathFinderPackage/Board.java#L512

If you need me to provide a simplified example, I am happy to. Just let me
know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250612/7827e641/attachment.htm>

From brian.goetz at oracle.com  Thu Jun 12 20:10:43 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 12 Jun 2025 20:10:43 +0000
Subject: Performance dropped significantly when switching from Nested
 Patterns to Flattened Patterns (was "Sharing my experience with Switch
 Expressions")
In-Reply-To: <CAA9v-_MxsanAZ_eQ7hY45i8yexcWAQJo2J9dbe90KrYeNwdmPQ@mail.gmail.com>
References: <CAA9v-_NxT+x80yTpNugwXG6oC4JS6OVt_LTTvv2YZ0P-Yy4s3w@mail.gmail.com>
 <CAA9v-_PJ5MNW-UpLe2RY-TrK+ZJQQjOE1VpeiDeO7UorqyU6Mg@mail.gmail.com>
 <SJ2PR10MB766966B133C867ED109F9B58A294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PjaQK2Cunmqo4D3NfHme4rzixZ_kQbXCVWwPcJjOo7Tw@mail.gmail.com>
 <CAA9v-_MW7JbXSXPoZ7aQdA6bMYWjBMjbpoP+MDOceFTyk3VNww@mail.gmail.com>
 <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
 <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
 <CAA9v-_MxsanAZ_eQ7hY45i8yexcWAQJo2J9dbe90KrYeNwdmPQ@mail.gmail.com>
Message-ID: <3AC727A8-2D91-44EA-9021-12CAC241A3D3@oracle.com>

Some amount of this is to be expected, since the flattened style is going to redundantly do a lot of work in a kind of obvious way.  But that?s a pretty big difference, so there may be more going on there.

On Jun 12, 2025, at 4:01 PM, David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:

Whoops, looks like the original thread did not get included during the rename. Here is a link to the original thread -- https://mail.openjdk.org/pipermail/amber-dev/2025-May/009299.html

Alternatively, if you just want to jump to the code examples, I copied and pasted them below.

Nested = https://github.com/davidalayachew/HelltakerPathFinder/blob/12c57dab041924192b8613075ff6966b1b159e91/src/main/java/HelltakerPathFinderModule/HelltakerPathFinderPackage/Board.java#L511

Flattened = https://github.com/davidalayachew/HelltakerPathFinder/blob/10b7a9d5fc4f6f563a68824de9a70735c7533226/src/main/java/HelltakerPathFinderModule/HelltakerPathFinderPackage/Board.java#L512

If you need me to provide a simplified example, I am happy to. Just let me know.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250612/71234856/attachment.htm>

From angelos.bimpoudis at oracle.com  Thu Jun 12 20:11:00 2025
From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis)
Date: Thu, 12 Jun 2025 20:11:00 +0000
Subject: Performance dropped significantly when switching from Nested
 Patterns to Flattened Patterns (was "Sharing my experience with Switch
 Expressions")
In-Reply-To: <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
References: <CAA9v-_NxT+x80yTpNugwXG6oC4JS6OVt_LTTvv2YZ0P-Yy4s3w@mail.gmail.com>
 <CAA9v-_PJ5MNW-UpLe2RY-TrK+ZJQQjOE1VpeiDeO7UorqyU6Mg@mail.gmail.com>
 <SJ2PR10MB766966B133C867ED109F9B58A294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PjaQK2Cunmqo4D3NfHme4rzixZ_kQbXCVWwPcJjOo7Tw@mail.gmail.com>
 <CAA9v-_MW7JbXSXPoZ7aQdA6bMYWjBMjbpoP+MDOceFTyk3VNww@mail.gmail.com>
 <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
 <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
Message-ID: <DS0PR10MB6726B36E6823FCFC99A02C038274A@DS0PR10MB6726.namprd10.prod.outlook.com>

Hello David,

Many thanks for the experience/bug report.

It would help us tremendously if you could provide a single, self-contained and concise test file, demonstrating this behaviour.

A simple .java file that can be compiled via javac speeds up the process, but it is also an interesting exercise for the bug reporter.

(this is actually how most bug reports are stored in our test suite, minimized and self-contained so that jtreg can invoke them: https://github.com/openjdk/jdk/tree/master/test/langtools/tools/javac; for you, no need to use jtreg, something that compiles with just javac is fine)

Looking forward for the test minimization.

Angelos


________________________________
From: amber-dev <amber-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: 12 June 2025 21:55
To: Chen Liang <chen.l.liang at oracle.com>
Cc: amber-dev <amber-dev at openjdk.org>
Subject: Performance dropped significantly when switching from Nested Patterns to Flattened Patterns (was "Sharing my experience with Switch Expressions")

Woah, something new came up.

On a whim, I tried to run the performance numbers, to see if there were any performance differences between the nested pattern style and the flattened pattern style, and there was!

The nested pattern style finished in under 30-60 seconds. But the flattened pattern style took OVER AN HOUR.

I just wanted to bring this up, in case this is a bug, or maybe it's expected behaviour. Please let me know!

On Fri, May 23, 2025 at 7:10?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Please let me know if there are any details missing, or if I could better explain the situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250612/c7748719/attachment-0001.htm>

From davidalayachew at gmail.com  Mon Jun 16 00:43:09 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 15 Jun 2025 20:43:09 -0400
Subject: Performance dropped significantly when switching from Nested
 Patterns to Flattened Patterns (was "Sharing my experience with Switch
 Expressions")
In-Reply-To: <DS0PR10MB6726B36E6823FCFC99A02C038274A@DS0PR10MB6726.namprd10.prod.outlook.com>
References: <CAA9v-_NxT+x80yTpNugwXG6oC4JS6OVt_LTTvv2YZ0P-Yy4s3w@mail.gmail.com>
 <CAA9v-_PJ5MNW-UpLe2RY-TrK+ZJQQjOE1VpeiDeO7UorqyU6Mg@mail.gmail.com>
 <SJ2PR10MB766966B133C867ED109F9B58A294A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAA9v-_PjaQK2Cunmqo4D3NfHme4rzixZ_kQbXCVWwPcJjOo7Tw@mail.gmail.com>
 <CAA9v-_MW7JbXSXPoZ7aQdA6bMYWjBMjbpoP+MDOceFTyk3VNww@mail.gmail.com>
 <CAA9v-_McLFGwE=GgDXWiWiotEF_Sdwy=O687PC5hXqa1hX_BUQ@mail.gmail.com>
 <CAA9v-_N6kbh=m2wRzoSWB8KOqi9OO3pWDWh0-6Rcr9WnzfVC7A@mail.gmail.com>
 <DS0PR10MB6726B36E6823FCFC99A02C038274A@DS0PR10MB6726.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PTbJSfLQgkCSqfgVk7fbLkow9rieHNNV33WNdMhuzDkQ@mail.gmail.com>

Thanks for the response folks. I'll try and get this done as soon as I can.

On Thu, Jun 12, 2025 at 4:11?PM Angelos Bimpoudis <
angelos.bimpoudis at oracle.com> wrote:

> Hello David,
>
> Many thanks for the experience/bug report.
>
> It would help us tremendously if you could provide a single,
> self-contained and concise test file, demonstrating this behaviour.
>
> A simple .java file that can be compiled via javac speeds up the process,
> but it is also an interesting exercise for the bug reporter.
>
> (this is actually how most bug reports are stored in our test suite,
> minimized and self-contained so that jtreg can invoke them:
> https://github.com/openjdk/jdk/tree/master/test/langtools/tools/javac;
> for you, no need to use jtreg, something that compiles with just javac is
> fine)
>
> Looking forward for the test minimization.
>
> Angelos
>
>
> ------------------------------
> *From:* amber-dev <amber-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* 12 June 2025 21:55
> *To:* Chen Liang <chen.l.liang at oracle.com>
> *Cc:* amber-dev <amber-dev at openjdk.org>
> *Subject:* Performance dropped significantly when switching from Nested
> Patterns to Flattened Patterns (was "Sharing my experience with Switch
> Expressions")
>
> Woah, something new came up.
>
> On a whim, I tried to run the performance numbers, to see if there were
> any performance differences between the nested pattern style and the
> flattened pattern style, and there was!
>
> The nested pattern style finished in under 30-60 seconds. But the
> flattened pattern style took OVER AN HOUR.
>
> I just wanted to bring this up, in case this is a bug, or maybe it's
> expected behaviour. Please let me know!
>
> On Fri, May 23, 2025 at 7:10?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Please let me know if there are any details missing, or if I could better
> explain the situation.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250615/31419c2c/attachment.htm>

From duke at openjdk.org  Fri Jun 20 17:06:25 2025
From: duke at openjdk.org (duke)
Date: Fri, 20 Jun 2025 17:06:25 GMT
Subject: git: openjdk/amber-docs: Updating for JDK 25
Message-ID: <098d6c37-948b-4931-8b18-c211c64f7896@openjdk.org>

Changeset: ba5b39c9
Branch: master
Author:    Gavin Bierman <gavin.bierman at oracle.com>
Date:      2025-06-20 18:04:03 +0000
URL:       https://git.openjdk.org/amber-docs/commit/ba5b39c98c1baedbddc1d46e31dadaa34209eae8

Updating for JDK 25

! site/_index.md


From duke at openjdk.org  Fri Jun 20 17:20:38 2025
From: duke at openjdk.org (duke)
Date: Fri, 20 Jun 2025 17:20:38 GMT
Subject: git: openjdk/amber-docs: Minor nit
Message-ID: <b651152e-672a-4480-bdaa-27c2c67a950e@openjdk.org>

Changeset: adcf06e8
Branch: master
Author:    Gavin Bierman <gavin.bierman at oracle.com>
Date:      2025-06-20 18:19:41 +0000
URL:       https://git.openjdk.org/amber-docs/commit/adcf06e877d22b097c088be8b964f0ae924ca3ce

Minor nit

! site/_index.md


From duke at openjdk.org  Fri Jun 20 17:23:18 2025
From: duke at openjdk.org (duke)
Date: Fri, 20 Jun 2025 17:23:18 GMT
Subject: git: openjdk/amber-docs: Minor nit
Message-ID: <f00b0719-2861-4a06-9a35-af0f9d5e1fbd@openjdk.org>

Changeset: 11c2a618
Branch: master
Author:    Gavin Bierman <gavin.bierman at oracle.com>
Date:      2025-06-20 18:20:16 +0000
URL:       https://git.openjdk.org/amber-docs/commit/11c2a618cf24fd423261468717c7d88ef30356d1

Minor nit

! site/_index.md