From magnus.ihse.bursie at oracle.com  Fri Apr  1 05:51:44 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 1 Apr 2022 07:51:44 +0200
Subject: Call for Discussion: Project proposal: Greenfields
Message-ID: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>

With Project Loom[1] getting closer to delivery, we will soon have a 
world where even simple Java programs might use millions of threads. 
This will, in effect, mean a world-wide multiplication on the number of 
threads in Java programs by several magnitudes! This might seem like a 
fantastic win for the Java eco-system, but we are forgetting the effects 
on the real eco-system.

As you might or might not be aware of, the textile industry is one of 
the heaviest polluter in the world[2]. Adding billions upon billions of 
new threads to this world seem like environmental arrogance.

I therefore propose we start Project Greenfield, which will research the 
reintroduction of Green Threads, and study how much pesticide and 
fertilizer use will rise due to Project Loom. Project Greenfields will 
also develop prototypes to lower pesticide, fertilizer, and water use 
for Java programs that need to create millions of threads.

Project Greenfields will deliver its first prototype in exactly one 
years time, April 1, 2023. If this is successful, we can retarget the 
project for the upcoming year, to look at the CO2 cost associated with 
Java bean production.

/Magnus

[1] https://openjdk.java.net/projects/loom
[2] 
https://www.europarl.europa.eu/news/en/headlines/society/20201208STO93327/the-impact-of-textile-production-and-waste-on-the-environment-infographic 


From forax at univ-mlv.fr  Fri Apr  1 06:13:01 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 1 Apr 2022 08:13:01 +0200 (CEST)
Subject: Call for Discussion: Project proposal: Greenfields
In-Reply-To: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
Message-ID: <1770691058.5309328.1648793581927.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Magnus Ihse Bursie" <magnus.ihse.bursie at oracle.com>
> To: "discuss" <discuss at openjdk.java.net>
> Sent: Friday, April 1, 2022 7:51:44 AM
> Subject: Call for Discussion: Project proposal: Greenfields

> With Project Loom[1] getting closer to delivery, we will soon have a
> world where even simple Java programs might use millions of threads.
> This will, in effect, mean a world-wide multiplication on the number of
> threads in Java programs by several magnitudes! This might seem like a
> fantastic win for the Java eco-system, but we are forgetting the effects
> on the real eco-system.
> 
> As you might or might not be aware of, the textile industry is one of
> the heaviest polluter in the world[2]. Adding billions upon billions of
> new threads to this world seem like environmental arrogance.
> 
> I therefore propose we start Project Greenfield, which will research the
> reintroduction of Green Threads, and study how much pesticide and
> fertilizer use will rise due to Project Loom. Project Greenfields will
> also develop prototypes to lower pesticide, fertilizer, and water use
> for Java programs that need to create millions of threads.
> 
> Project Greenfields will deliver its first prototype in exactly one
> years time, April 1, 2023. If this is successful, we can retarget the
> project for the upcoming year, to look at the CO2 cost associated with
> Java bean production.

Thanks Magnus, that's very moving for me.

I would like to add that i feel responsible here, in Java 7 we introduce the try-with-resources and i think it's now time to be bolder and introduce the try-without-resources that will help to make the planet greener.

The try-without-resources, with the syntax
  try() {  // notice here, no resources used !
    ...
  }

is a responsible choice to everybody that crave to signal that he/she/their want to make an effort for the planet.

Even if this Project is not yet voted, i think we can already allow everybody on Twitter to re-tweet Java codes with one or more trw-without-resources.
It's all this little steps on Twitter that makes an impact for our blue planet.

> 
> /Magnus

R?mi

> 
> [1] https://openjdk.java.net/projects/loom
> [2]
> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO93327/the-impact-of-textile-production-and-waste-on-the-environment-infographic

From peter.lawrey at gmail.com  Fri Apr  1 06:45:44 2022
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Fri, 1 Apr 2022 07:45:44 +0100
Subject: Call for Discussion: Project proposal: Greenfields
In-Reply-To: <1770691058.5309328.1648793581927.JavaMail.zimbra@u-pem.fr>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
 <1770691058.5309328.1648793581927.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAOgwmTiV9LU6B+PFQg=OoJQFzFOVGMn3sniMu5aKhqo8Odv4-Q@mail.gmail.com>

A timely point, just yesterday I wrote

try (Closeable close = null) {
}

As a work around I suggest

/* try */ {
}

On Fri, 1 Apr 2022, 07:14 Remi Forax, <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Magnus Ihse Bursie" <magnus.ihse.bursie at oracle.com>
> > To: "discuss" <discuss at openjdk.java.net>
> > Sent: Friday, April 1, 2022 7:51:44 AM
> > Subject: Call for Discussion: Project proposal: Greenfields
>
> > With Project Loom[1] getting closer to delivery, we will soon have a
> > world where even simple Java programs might use millions of threads.
> > This will, in effect, mean a world-wide multiplication on the number of
> > threads in Java programs by several magnitudes! This might seem like a
> > fantastic win for the Java eco-system, but we are forgetting the effects
> > on the real eco-system.
> >
> > As you might or might not be aware of, the textile industry is one of
> > the heaviest polluter in the world[2]. Adding billions upon billions of
> > new threads to this world seem like environmental arrogance.
> >
> > I therefore propose we start Project Greenfield, which will research the
> > reintroduction of Green Threads, and study how much pesticide and
> > fertilizer use will rise due to Project Loom. Project Greenfields will
> > also develop prototypes to lower pesticide, fertilizer, and water use
> > for Java programs that need to create millions of threads.
> >
> > Project Greenfields will deliver its first prototype in exactly one
> > years time, April 1, 2023. If this is successful, we can retarget the
> > project for the upcoming year, to look at the CO2 cost associated with
> > Java bean production.
>
> Thanks Magnus, that's very moving for me.
>
> I would like to add that i feel responsible here, in Java 7 we introduce
> the try-with-resources and i think it's now time to be bolder and introduce
> the try-without-resources that will help to make the planet greener.
>
> The try-without-resources, with the syntax
>   try() {  // notice here, no resources used !
>     ...
>   }
>
> is a responsible choice to everybody that crave to signal that
> he/she/their want to make an effort for the planet.
>
> Even if this Project is not yet voted, i think we can already allow
> everybody on Twitter to re-tweet Java codes with one or more
> trw-without-resources.
> It's all this little steps on Twitter that makes an impact for our blue
> planet.
>
> >
> > /Magnus
>
> R?mi
>
> >
> > [1] https://openjdk.java.net/projects/loom
> > [2]
> >
> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO93327/the-impact-of-textile-production-and-waste-on-the-environment-infographic
>

From erik.osterlund at oracle.com  Fri Apr  1 07:33:05 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 1 Apr 2022 07:33:05 +0000
Subject: Call for Discussion: Project proposal: Greenfields
In-Reply-To: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
Message-ID: <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>

This is a great idea Magnus.

It is so crucial for the environment that we recycle as much as possible. The great thing
with green threads, is that unlike normal threads, they can be recycled by the GC, which
is ever so important for the environment. However, I think that as part of this project,
we should make recycling of green threads even more aggressive. I propose a probabilistic
approach that lets the GC find not just provably garbage green threads, but also
"probably garbage" green threads. I'm sure the user can just create a new thread
in the unlikely scenario that my algorithm is occasionally inaccurate, because everyone
is running stateless apps nowadays anyway. Right?

The algorithm will traverse green thread roots and their transitive closure, looking for
strings that can be associated with probably garbage work that is likely to be just discarded, 
such as "BTC", "ETH", etc. ZGC will then use a new "probably garbage" color in its pointers,
to paint the transitive closure of green threads as "probably garbage". Then the entire
object graph of such green threads can be immediately recycled. In the unlikely event
that such a pointer is loaded by another thread, the load will raise a PrematureRecyclingException.

I think this idea could greatly benefit the environment, and promote recycling to a new level.

/Erik

> -----Original Message-----
> From: discuss <discuss-retn at openjdk.java.net> On Behalf Of Magnus Ihse
> Bursie
> Sent: Friday, 1 April 2022 07:52
> To: discuss at openjdk.java.net
> Subject: Call for Discussion: Project proposal: Greenfields
> 
> With Project Loom[1] getting closer to delivery, we will soon have a world
> where even simple Java programs might use millions of threads.
> This will, in effect, mean a world-wide multiplication on the number of
> threads in Java programs by several magnitudes! This might seem like a
> fantastic win for the Java eco-system, but we are forgetting the effects on
> the real eco-system.
> 
> As you might or might not be aware of, the textile industry is one of the
> heaviest polluter in the world[2]. Adding billions upon billions of new threads
> to this world seem like environmental arrogance.
> 
> I therefore propose we start Project Greenfield, which will research the
> reintroduction of Green Threads, and study how much pesticide and fertilizer
> use will rise due to Project Loom. Project Greenfields will also develop
> prototypes to lower pesticide, fertilizer, and water use for Java programs
> that need to create millions of threads.
> 
> Project Greenfields will deliver its first prototype in exactly one years time,
> April 1, 2023. If this is successful, we can retarget the project for the
> upcoming year, to look at the CO2 cost associated with Java bean production.
> 
> /Magnus
> 
> [1] https://openjdk.java.net/projects/loom
> [2]
> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO
> 93327/the-impact-of-textile-production-and-waste-on-the-environment-
> infographic


From jesper.wilhelmsson at oracle.com  Fri Apr  1 08:37:13 2022
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Fri, 1 Apr 2022 08:37:13 +0000
Subject: Call for Discussion: Project proposal: Greenfields
In-Reply-To: <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
 <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>
Message-ID: <9E9C2DB6-18D9-41F4-B7A9-CF0F41A6A81E@oracle.com>

This is an awesome suggestion. And if I'm not mistaken you already did reserve the green pointer color for the future in the ZGC code, so this is essentially already done, right?
/Jesper

> On 1 Apr 2022, at 09:33, Erik Osterlund <erik.osterlund at oracle.com> wrote:
> 
> This is a great idea Magnus.
> 
> It is so crucial for the environment that we recycle as much as possible. The great thing
> with green threads, is that unlike normal threads, they can be recycled by the GC, which
> is ever so important for the environment. However, I think that as part of this project,
> we should make recycling of green threads even more aggressive. I propose a probabilistic
> approach that lets the GC find not just provably garbage green threads, but also
> "probably garbage" green threads. I'm sure the user can just create a new thread
> in the unlikely scenario that my algorithm is occasionally inaccurate, because everyone
> is running stateless apps nowadays anyway. Right?
> 
> The algorithm will traverse green thread roots and their transitive closure, looking for
> strings that can be associated with probably garbage work that is likely to be just discarded,
> such as "BTC", "ETH", etc. ZGC will then use a new "probably garbage" color in its pointers,
> to paint the transitive closure of green threads as "probably garbage". Then the entire
> object graph of such green threads can be immediately recycled. In the unlikely event
> that such a pointer is loaded by another thread, the load will raise a PrematureRecyclingException.
> 
> I think this idea could greatly benefit the environment, and promote recycling to a new level.
> 
> /Erik
> 
>> -----Original Message-----
>> From: discuss <discuss-retn at openjdk.java.net> On Behalf Of Magnus Ihse
>> Bursie
>> Sent: Friday, 1 April 2022 07:52
>> To: discuss at openjdk.java.net
>> Subject: Call for Discussion: Project proposal: Greenfields
>> 
>> With Project Loom[1] getting closer to delivery, we will soon have a world
>> where even simple Java programs might use millions of threads.
>> This will, in effect, mean a world-wide multiplication on the number of
>> threads in Java programs by several magnitudes! This might seem like a
>> fantastic win for the Java eco-system, but we are forgetting the effects on
>> the real eco-system.
>> 
>> As you might or might not be aware of, the textile industry is one of the
>> heaviest polluter in the world[2]. Adding billions upon billions of new threads
>> to this world seem like environmental arrogance.
>> 
>> I therefore propose we start Project Greenfield, which will research the
>> reintroduction of Green Threads, and study how much pesticide and fertilizer
>> use will rise due to Project Loom. Project Greenfields will also develop
>> prototypes to lower pesticide, fertilizer, and water use for Java programs
>> that need to create millions of threads.
>> 
>> Project Greenfields will deliver its first prototype in exactly one years time,
>> April 1, 2023. If this is successful, we can retarget the project for the
>> upcoming year, to look at the CO2 cost associated with Java bean production.
>> 
>> /Magnus
>> 
>> [1] https://openjdk.java.net/projects/loom
>> [2]
>> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO
>> 93327/the-impact-of-textile-production-and-waste-on-the-environment-
>> infographic
> 


From shade at redhat.com  Fri Apr  1 08:57:27 2022
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 1 Apr 2022 10:57:27 +0200
Subject: Call for Discussion: Project proposal: Greenfields
In-Reply-To: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
Message-ID: <64912da4-28ed-0a60-9d75-ec91951b2e9a@redhat.com>

On 4/1/22 07:51, Magnus Ihse Bursie wrote:
> I therefore propose we start Project Greenfield, which will research the
> reintroduction of Green Threads, and study how much pesticide and
> fertilizer use will rise due to Project Loom. Project Greenfields will
> also develop prototypes to lower pesticide, fertilizer, and water use
> for Java programs that need to create millions of threads.

While the project suggestion looks interesting, there is, unfortunately, a nearly fatal flaw in it.

The flaw is right in the name: Greenfield is the registered brand name for tea, which clashes with 
Java coffee branding that generates billions in coffee companies partnership revenues. There are 
also minor ripple effects, for example, Java Class Format magic numbers, which should then be 
changed to 0xTEAABABE, yielding the plainly illegal hexadecimal value.

Switching the ecosystem-wide preference for beverages should be discussed at and unanimously voted 
by JCP (Java Coffee Professionals). The implications for LTS (ooLong Tea Sommeliers) projects would 
have to be investigated as well.

-- 
Thanks,
-Aleksey


From eric.vergnaud at wanadoo.fr  Fri Apr  1 09:25:25 2022
From: eric.vergnaud at wanadoo.fr (Eric Vergnaud)
Date: Fri, 1 Apr 2022 11:25:25 +0200
Subject: Project proposal: ROI
In-Reply-To: <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
 <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>
Message-ID: <85E7C063-FDA3-4D30-A87C-666384140ED4@wanadoo.fr>

In a similar responsible inspiration, I would like to introduce the ROI project, and submit it for approval by the OpenJDK community.

ROI stands for Recycle Obsolete Instances, and introduces the following interface:

public interface Recyclable<T extends Recyclable> {
	
	default T recycle(T obsolete) { return obsolete; }
}

Unlike regular instances, Recyclable instances eligible for GC are not immediately disposed.
Instead, they are moved to a new memory zone called SLS, standing for Second Life Space.

Thanks to the default method above, implementing the Recyclable interface may be as simple as the following:

class ValuableStuff implements Recyclable< ValuableStuff > {
}

This in turn enables a completely new syntax for instantiating objects:

ValuableStuff vs = recycle ValuableStuff();

Please note the introduction of the new ?recycle? keyword.

When utilized, the ?recycle? keyword forces the JVM to look for an existing instance in the SLS.
If one is available, its recycle method is invoked, it is removed from the SLS, and the result is returned to the caller.
If none is available, the JVM falls back to the historical allocation mechanism.

Please note that ROI usually stands for Return On Investment, which seems particularly appropriate here: once you?ve heavily invested in constructing an object, you want to maximize the return on that investment.

I hope the OpenJDK community will be supportive.

Thanks,

Eric


> Le 1 avr. 2022 ? 09:33, Erik Osterlund <erik.osterlund at oracle.com> a ?crit :
> 
> This is a great idea Magnus.
> 
> It is so crucial for the environment that we recycle as much as possible. The great thing
> with green threads, is that unlike normal threads, they can be recycled by the GC, which
> is ever so important for the environment. However, I think that as part of this project,
> we should make recycling of green threads even more aggressive. I propose a probabilistic
> approach that lets the GC find not just provably garbage green threads, but also
> "probably garbage" green threads. I'm sure the user can just create a new thread
> in the unlikely scenario that my algorithm is occasionally inaccurate, because everyone
> is running stateless apps nowadays anyway. Right?
> 
> The algorithm will traverse green thread roots and their transitive closure, looking for
> strings that can be associated with probably garbage work that is likely to be just discarded, 
> such as "BTC", "ETH", etc. ZGC will then use a new "probably garbage" color in its pointers,
> to paint the transitive closure of green threads as "probably garbage". Then the entire
> object graph of such green threads can be immediately recycled. In the unlikely event
> that such a pointer is loaded by another thread, the load will raise a PrematureRecyclingException.
> 
> I think this idea could greatly benefit the environment, and promote recycling to a new level.
> 
> /Erik
> 
>> -----Original Message-----
>> From: discuss <discuss-retn at openjdk.java.net> On Behalf Of Magnus Ihse
>> Bursie
>> Sent: Friday, 1 April 2022 07:52
>> To: discuss at openjdk.java.net
>> Subject: Call for Discussion: Project proposal: Greenfields
>> 
>> With Project Loom[1] getting closer to delivery, we will soon have a world
>> where even simple Java programs might use millions of threads.
>> This will, in effect, mean a world-wide multiplication on the number of
>> threads in Java programs by several magnitudes! This might seem like a
>> fantastic win for the Java eco-system, but we are forgetting the effects on
>> the real eco-system.
>> 
>> As you might or might not be aware of, the textile industry is one of the
>> heaviest polluter in the world[2]. Adding billions upon billions of new threads
>> to this world seem like environmental arrogance.
>> 
>> I therefore propose we start Project Greenfield, which will research the
>> reintroduction of Green Threads, and study how much pesticide and fertilizer
>> use will rise due to Project Loom. Project Greenfields will also develop
>> prototypes to lower pesticide, fertilizer, and water use for Java programs
>> that need to create millions of threads.
>> 
>> Project Greenfields will deliver its first prototype in exactly one years time,
>> April 1, 2023. If this is successful, we can retarget the project for the
>> upcoming year, to look at the CO2 cost associated with Java bean production.
>> 
>> /Magnus
>> 
>> [1] https://openjdk.java.net/projects/loom
>> [2]
>> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO
>> 93327/the-impact-of-textile-production-and-waste-on-the-environment-
>> infographic
> 


From tanksherman27 at gmail.com  Fri Apr  1 13:36:45 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 1 Apr 2022 21:36:45 +0800
Subject: Call for Discussion: Project proposal: Greenfields
Message-ID: <CAP2b4GMv=7jzO9eFWwCoYdPLEeP-ZqixUTSHVS4LvMW3SAm1FQ@mail.gmail.com>

> Switching the ecosystem-wide preference for beverages should be discussed
at > and unanimously voted by JCP (Java Coffee Professionals). The
implications for > LTS (ooLong Tea Sommeliers) projects would have to be
investigated as well.

Haha, that's the best thing I've read in a while :P

-Julian

From peter.lawrey at gmail.com  Fri Apr  8 09:53:36 2022
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Fri, 8 Apr 2022 10:53:36 +0100
Subject: Project proposal: ROI
In-Reply-To: <85E7C063-FDA3-4D30-A87C-666384140ED4@wanadoo.fr>
References: <032e3bfa-1631-4ab3-9f27-42354700ab73@oracle.com>
 <BLAPR10MB516935550040C87D07416AEFF4E09@BLAPR10MB5169.namprd10.prod.outlook.com>
 <85E7C063-FDA3-4D30-A87C-666384140ED4@wanadoo.fr>
Message-ID: <CAOgwmTjXQjWAZV5=deFfa6N4=92UbE7_3O5cvmOGmZ5KWCDLpA@mail.gmail.com>

Hi,
   I highly recommend creating a prototype as a library showing the
functionality first and adding syntactic sugar later.
It should be possible to do this with static factory methods and a
WeakHashMap/WeakReferences initially and then make it more
efficient/cleaner/builtin later.
This would make back porting to older versions easier as well.

ValuableStuff vs = ROI.recycle(ValuableStuff::new);

You might like to think about objects created with non default
constructors. Like

final class ROI {
   static <T, A> T recycle(Function<A, T> creator, A arg);
}

class ValuableStuff {
    public ValuableStuff(Config config) {
}

ValuableStuff vs = ROI.recycle(ValuableStuff::new, config);


Regards,
   Peter.

On Fri, 1 Apr 2022 at 10:26, Eric Vergnaud <eric.vergnaud at wanadoo.fr> wrote:

> In a similar responsible inspiration, I would like to introduce the ROI
> project, and submit it for approval by the OpenJDK community.
>
> ROI stands for Recycle Obsolete Instances, and introduces the following
> interface:
>
> public interface Recyclable<T extends Recyclable> {
>
>         default T recycle(T obsolete) { return obsolete; }
> }
>
> Unlike regular instances, Recyclable instances eligible for GC are not
> immediately disposed.
> Instead, they are moved to a new memory zone called SLS, standing for
> Second Life Space.
>
> Thanks to the default method above, implementing the Recyclable interface
> may be as simple as the following:
>
> class ValuableStuff implements Recyclable< ValuableStuff > {
> }
>
> This in turn enables a completely new syntax for instantiating objects:
>
> ValuableStuff vs = recycle ValuableStuff();
>
> Please note the introduction of the new ?recycle? keyword.
>
> When utilized, the ?recycle? keyword forces the JVM to look for an
> existing instance in the SLS.
> If one is available, its recycle method is invoked, it is removed from the
> SLS, and the result is returned to the caller.
> If none is available, the JVM falls back to the historical allocation
> mechanism.
>
> Please note that ROI usually stands for Return On Investment, which seems
> particularly appropriate here: once you?ve heavily invested in constructing
> an object, you want to maximize the return on that investment.
>
> I hope the OpenJDK community will be supportive.
>
> Thanks,
>
> Eric
>
>
> > Le 1 avr. 2022 ? 09:33, Erik Osterlund <erik.osterlund at oracle.com> a
> ?crit :
> >
> > This is a great idea Magnus.
> >
> > It is so crucial for the environment that we recycle as much as
> possible. The great thing
> > with green threads, is that unlike normal threads, they can be recycled
> by the GC, which
> > is ever so important for the environment. However, I think that as part
> of this project,
> > we should make recycling of green threads even more aggressive. I
> propose a probabilistic
> > approach that lets the GC find not just provably garbage green threads,
> but also
> > "probably garbage" green threads. I'm sure the user can just create a
> new thread
> > in the unlikely scenario that my algorithm is occasionally inaccurate,
> because everyone
> > is running stateless apps nowadays anyway. Right?
> >
> > The algorithm will traverse green thread roots and their transitive
> closure, looking for
> > strings that can be associated with probably garbage work that is likely
> to be just discarded,
> > such as "BTC", "ETH", etc. ZGC will then use a new "probably garbage"
> color in its pointers,
> > to paint the transitive closure of green threads as "probably garbage".
> Then the entire
> > object graph of such green threads can be immediately recycled. In the
> unlikely event
> > that such a pointer is loaded by another thread, the load will raise a
> PrematureRecyclingException.
> >
> > I think this idea could greatly benefit the environment, and promote
> recycling to a new level.
> >
> > /Erik
> >
> >> -----Original Message-----
> >> From: discuss <discuss-retn at openjdk.java.net> On Behalf Of Magnus Ihse
> >> Bursie
> >> Sent: Friday, 1 April 2022 07:52
> >> To: discuss at openjdk.java.net
> >> Subject: Call for Discussion: Project proposal: Greenfields
> >>
> >> With Project Loom[1] getting closer to delivery, we will soon have a
> world
> >> where even simple Java programs might use millions of threads.
> >> This will, in effect, mean a world-wide multiplication on the number of
> >> threads in Java programs by several magnitudes! This might seem like a
> >> fantastic win for the Java eco-system, but we are forgetting the
> effects on
> >> the real eco-system.
> >>
> >> As you might or might not be aware of, the textile industry is one of
> the
> >> heaviest polluter in the world[2]. Adding billions upon billions of new
> threads
> >> to this world seem like environmental arrogance.
> >>
> >> I therefore propose we start Project Greenfield, which will research the
> >> reintroduction of Green Threads, and study how much pesticide and
> fertilizer
> >> use will rise due to Project Loom. Project Greenfields will also develop
> >> prototypes to lower pesticide, fertilizer, and water use for Java
> programs
> >> that need to create millions of threads.
> >>
> >> Project Greenfields will deliver its first prototype in exactly one
> years time,
> >> April 1, 2023. If this is successful, we can retarget the project for
> the
> >> upcoming year, to look at the CO2 cost associated with Java bean
> production.
> >>
> >> /Magnus
> >>
> >> [1] https://openjdk.java.net/projects/loom
> >> [2]
> >> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO
> >> 93327/the-impact-of-textile-production-and-waste-on-the-environment-
> >> infographic
> >
>
>

From tobias.gierke at code-sourcery.de  Fri Apr  8 14:03:29 2022
From: tobias.gierke at code-sourcery.de (Tobias Gierke)
Date: Fri, 8 Apr 2022 16:03:29 +0200
Subject: multi-catch vs. multiple type patterns in a single case label
Message-ID: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>

Hello,

Having read through JEP-420, I wonder why

 ??? try {
 ? ?? ?? .... do stuff ....
 ??? } catch( IOException | IllegalStateException e) {
 ? ?? ?? System.out.println("Something went wrong: "+e);
 ??? }

is valid but

 ??? Exception x = ....
 ??? switch(x) {
 ? ?? ??? case IOException | TimeoutException e -> 
System.out.println("Something went wrong: "+e);
 ??? }

is not. I get that something like

 ??? Exception x = ....
 ??? switch(x) {
 ? ?? ??? case IOException a, IllegalStateException b ->? .....
 ??? }

would leave one of the variables undefined but why can't I bind multiple 
type patterns to the same variable, have the compiler infer a common 
super-type and use that to check the switch branch ?

Regards,
Tobias


From ethan at mccue.dev  Fri Apr  8 16:19:00 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 8 Apr 2022 12:19:00 -0400
Subject: multi-catch vs. multiple type patterns in a single case label
In-Reply-To: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>
References: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>
Message-ID: <CA+NR86iw7B6Psenyqez9Rs5YC9CHbBDiiROm-ut4BLXSFnOOCg@mail.gmail.com>

The answer is that a switch does not yet support an "or" pattern. It could
in the future, but the exact shape of switch patterns is in flux.

On Fri, Apr 8, 2022, 10:05 AM Tobias Gierke <tobias.gierke at code-sourcery.de>
wrote:

> Hello,
>
> Having read through JEP-420, I wonder why
>
>      try {
>          .... do stuff ....
>      } catch( IOException | IllegalStateException e) {
>          System.out.println("Something went wrong: "+e);
>      }
>
> is valid but
>
>      Exception x = ....
>      switch(x) {
>           case IOException | TimeoutException e ->
> System.out.println("Something went wrong: "+e);
>      }
>
> is not. I get that something like
>
>      Exception x = ....
>      switch(x) {
>           case IOException a, IllegalStateException b ->  .....
>      }
>
> would leave one of the variables undefined but why can't I bind multiple
> type patterns to the same variable, have the compiler infer a common
> super-type and use that to check the switch branch ?
>
> Regards,
> Tobias
>
>

From andru at cs.cornell.edu  Fri Apr  8 16:24:29 2022
From: andru at cs.cornell.edu (Andrew Myers)
Date: Fri, 8 Apr 2022 12:24:29 -0400
Subject: multi-catch vs. multiple type patterns in a single case label
In-Reply-To: <CA+NR86iw7B6Psenyqez9Rs5YC9CHbBDiiROm-ut4BLXSFnOOCg@mail.gmail.com>
References: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>
 <CA+NR86iw7B6Psenyqez9Rs5YC9CHbBDiiROm-ut4BLXSFnOOCg@mail.gmail.com>
Message-ID: <ccb752de-528a-63ee-76ee-4b273233d5d7@cs.cornell.edu>

If you want to see what switch patterns on steroids could look like, 
check out JMatch:

https://www.cs.cornell.edu/projects/jmatch/

--Andrew

Ethan McCue wrote on 4/8/22 12:19 PM:
> The answer is that a switch does not yet support an "or" pattern. It could
> in the future, but the exact shape of switch patterns is in flux.
>
> On Fri, Apr 8, 2022, 10:05 AM Tobias Gierke <tobias.gierke at code-sourcery.de>
> wrote:
>
>> Hello,
>>
>> Having read through JEP-420, I wonder why
>>
>>       try {
>>           .... do stuff ....
>>       } catch( IOException | IllegalStateException e) {
>>           System.out.println("Something went wrong: "+e);
>>       }
>>
>> is valid but
>>
>>       Exception x = ....
>>       switch(x) {
>>            case IOException | TimeoutException e ->
>> System.out.println("Something went wrong: "+e);
>>       }
>>
>> is not. I get that something like
>>
>>       Exception x = ....
>>       switch(x) {
>>            case IOException a, IllegalStateException b ->  .....
>>       }
>>
>> would leave one of the variables undefined but why can't I bind multiple
>> type patterns to the same variable, have the compiler infer a common
>> super-type and use that to check the switch branch ?
>>
>> Regards,
>> Tobias
>>
>>


From brian.goetz at oracle.com  Fri Apr  8 21:25:42 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 8 Apr 2022 17:25:42 -0400
Subject: multi-catch vs. multiple type patterns in a single case label
In-Reply-To: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>
References: <a62d54c1-8131-7bdb-e526-c19f470ed32f@code-sourcery.de>
Message-ID: <72b9fb4a-6f62-1a10-188f-ec8fe86baf10@oracle.com>

There's really three questions fused together here; one about union 
types, one about the feasibility of pattern fusion, all wrapped up in 
one about syntax.

Multi-catch was added to Java in Java 7, as part of "Project Coin"; the 
mission of Coin was highly constrained.? When extrapolating from the 
syntax of multi-catch to an imagined syntax of OR patterns, there is a 
subtle difference between:

 ??? case (IOException | TimeoutException) e:???? // parens added for effect

(Before continuing, what is the type of e?)

and

 ??? case (IOExcetion e) | (TimeoutException e):? // parens added for effect

which is more of an OR of patterns.

Multi-catch did not add general purpose union types to the language; it 
focused them on one little corner.? (We can argue over whether this was 
a clever pragmatic compromise, or whether we merely created a lot of 
incremental language complexity for minor gain.)? It is possible it 
might make sense to add it in another corner too, but we're wary of such 
moves, because such types invariably escape into inference and produce 
weird, non-denotable types elsewhere.? (See the travails over how to 
sanitize capture types with `var`.)? So just copying what multi-catch 
does is not an obvious slam-dunk.

OR patterns are a more powerful mechanism, and one we'd like to 
consider, but they are complicated too.? In the second example, `e` has 
*two* declaration sites, and we still probably end up inferring a union 
type for it, or maybe we infer the least-upper-bound (which is often 
Object).? So this is also not an obvious slam dunk either.

So the short answer is that just because there is a way to express 
something somewhere, doesn't mean that carries over to other similar 
things elsewhere.? Even if the syntax would be obvious.





On 4/8/2022 10:03 AM, Tobias Gierke wrote:
> Hello,
>
> Having read through JEP-420, I wonder why
>
> ??? try {
> ? ?? ?? .... do stuff ....
> ??? } catch( IOException | IllegalStateException e) {
> ? ?? ?? System.out.println("Something went wrong: "+e);
> ??? }
>
> is valid but
>
> ??? Exception x = ....
> ??? switch(x) {
> ? ?? ??? case IOException | TimeoutException e -> 
> System.out.println("Something went wrong: "+e);
> ??? }
>
> is not. I get that something like
>
> ??? Exception x = ....
> ??? switch(x) {
> ? ?? ??? case IOException a, IllegalStateException b ->? .....
> ??? }
>
> would leave one of the variables undefined but why can't I bind 
> multiple type patterns to the same variable, have the compiler infer a 
> common super-type and use that to check the switch branch ?
>
> Regards,
> Tobias
>

From anton.haubner at outlook.de  Wed Apr 13 09:12:00 2022
From: anton.haubner at outlook.de (Anton W. Haubner)
Date: Wed, 13 Apr 2022 11:12:00 +0200
Subject: JVM does not match JVMS regarding array component types?
Message-ID: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>

Hi!

I am not sure if this is the right place to ask these questions. At 
first glance, the "jls-jvms-spec-comments" mailing list looks more 
appropriate but its description says that that list "is solely a drop 
box for reports".
Therefore, if I am out-of-place here, please direct me to the 
appropriate mailing list.

My question is about the behaviour of the JVM which seemingly does not 
match the JVMS specification when it comes to lazy-linking and empty arrays.

I noticed that regarding lazy-linking strategies and resolution, the 
JVMS states that if an array type is resolved whose element type is a 
reference type, then

"a symbolic reference to the class or interface representing the element type is resolved [...] recursively." [1]

More specifically, the `anewarray` instruction requires the resolution 
of the component type when executed [2].

However, while inspecting programs with the JDI, I observed that when 
creating an empty array, the component type of the array is actually not 
loaded.
You can observe this as follows:

1. Compile the following program with `javac -g`:

```
class Test { }

public class ArrayTest {
 ? public static void main(String[] args) {
 ??? var x = new Test[] {};
 ? }
}

```

2. Executing `javap -v ArrayTest` will confirm that when stopping the 
program on line 6, `anewarray` must have been executed.

3. Run the following commands in `jdb`:

stop at ArrayTest:6
run ArrayTest
class Test

4. It will say "Test is not a valid id or class name.", i.e. the class 
"Test" has not been loaded, even though it should have been because it 
is the component type of Test[] for which an instance has been created.

5. If you change line 5 to "var x = new Test[] {new Test()};" jdb will 
actually return information about "Test", that is, the class is loaded.

 From these observations I conclude, that the component type of an array 
type is not loaded, if only empty instances of the array type are created.
I wonder, why this does not violate the specification of the JVMS at [1] 
and [2]

(I am working with Java 11, so so far I tested this only for OpenJDK 11)

[1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11: 
https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1
[2] 
https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray




From volker.simonis at gmail.com  Wed Apr 13 13:02:28 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 Apr 2022 15:02:28 +0200
Subject: JVM does not match JVMS regarding array component types?
In-Reply-To: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>

Just to make sure this is not an issue with jdb, could you please run your
example program with "-Xlog:class+load" and check the output?

Anton W. Haubner <anton.haubner at outlook.de> schrieb am Mi., 13. Apr. 2022,
11:12:

> Hi!
>
> I am not sure if this is the right place to ask these questions. At
> first glance, the "jls-jvms-spec-comments" mailing list looks more
> appropriate but its description says that that list "is solely a drop
> box for reports".
> Therefore, if I am out-of-place here, please direct me to the
> appropriate mailing list.
>
> My question is about the behaviour of the JVM which seemingly does not
> match the JVMS specification when it comes to lazy-linking and empty
> arrays.
>
> I noticed that regarding lazy-linking strategies and resolution, the
> JVMS states that if an array type is resolved whose element type is a
> reference type, then
>
> "a symbolic reference to the class or interface representing the element
> type is resolved [...] recursively." [1]
>
> More specifically, the `anewarray` instruction requires the resolution
> of the component type when executed [2].
>
> However, while inspecting programs with the JDI, I observed that when
> creating an empty array, the component type of the array is actually not
> loaded.
> You can observe this as follows:
>
> 1. Compile the following program with `javac -g`:
>
> ```
> class Test { }
>
> public class ArrayTest {
>    public static void main(String[] args) {
>      var x = new Test[] {};
>    }
> }
>
> ```
>
> 2. Executing `javap -v ArrayTest` will confirm that when stopping the
> program on line 6, `anewarray` must have been executed.
>
> 3. Run the following commands in `jdb`:
>
> stop at ArrayTest:6
> run ArrayTest
> class Test
>
> 4. It will say "Test is not a valid id or class name.", i.e. the class
> "Test" has not been loaded, even though it should have been because it
> is the component type of Test[] for which an instance has been created.
>
> 5. If you change line 5 to "var x = new Test[] {new Test()};" jdb will
> actually return information about "Test", that is, the class is loaded.
>
>  From these observations I conclude, that the component type of an array
> type is not loaded, if only empty instances of the array type are created.
> I wonder, why this does not violate the specification of the JVMS at [1]
> and [2]
>
> (I am working with Java 11, so so far I tested this only for OpenJDK 11)
>
> [1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11:
>
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1
> [2]
>
> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray
>
>
>
>

From anton.haubner at outlook.de  Wed Apr 13 14:14:12 2022
From: anton.haubner at outlook.de (Anton W. Haubner)
Date: Wed, 13 Apr 2022 16:14:12 +0200
Subject: JVM does not match JVMS regarding array component types?
In-Reply-To: <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>
References: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>
Message-ID: <AM0PR10MB310621FEB62B53A59AE21AD98FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>

Hi!

Thank you for this hint.

The output of `java -Xlog:class+load ArrayTest` contains

```
...
[0.242s][info][class,load] java.lang.Void source: jrt:/java.base
[0.242s][info][class,load] Test source: file:/home/anton/<...>
[0.242s][info][class,load] jdk.internal.misc.TerminatingThreadLocal$1 
source: jrt:/java.base
...

```

This is the only place where the component type "Test" is mentioned.

If I understand this output correctly, then the "Test" class has 
actually been created.
Now I wonder, under which conditions a created type becomes visible 
through the JDI.

Best regards,

Anton Haubner

On 4/13/22 15:02, Volker Simonis wrote:
> Just to make sure this is not an issue with jdb, could you please run 
> your example program with "-Xlog:class+load" and check the output?
>
> Anton W. Haubner <anton.haubner at outlook.de> schrieb am Mi., 13. Apr. 
> 2022, 11:12:
>
>     Hi!
>
>     I am not sure if this is the right place to ask these questions. At
>     first glance, the "jls-jvms-spec-comments" mailing list looks more
>     appropriate but its description says that that list "is solely a drop
>     box for reports".
>     Therefore, if I am out-of-place here, please direct me to the
>     appropriate mailing list.
>
>     My question is about the behaviour of the JVM which seemingly does
>     not
>     match the JVMS specification when it comes to lazy-linking and
>     empty arrays.
>
>     I noticed that regarding lazy-linking strategies and resolution, the
>     JVMS states that if an array type is resolved whose element type is a
>     reference type, then
>
>     "a symbolic reference to the class or interface representing the
>     element type is resolved [...] recursively." [1]
>
>     More specifically, the `anewarray` instruction requires the
>     resolution
>     of the component type when executed [2].
>
>     However, while inspecting programs with the JDI, I observed that when
>     creating an empty array, the component type of the array is
>     actually not
>     loaded.
>     You can observe this as follows:
>
>     1. Compile the following program with `javac -g`:
>
>     ```
>     class Test { }
>
>     public class ArrayTest {
>     ?? public static void main(String[] args) {
>     ???? var x = new Test[] {};
>     ?? }
>     }
>
>     ```
>
>     2. Executing `javap -v ArrayTest` will confirm that when stopping the
>     program on line 6, `anewarray` must have been executed.
>
>     3. Run the following commands in `jdb`:
>
>     stop at ArrayTest:6
>     run ArrayTest
>     class Test
>
>     4. It will say "Test is not a valid id or class name.", i.e. the
>     class
>     "Test" has not been loaded, even though it should have been
>     because it
>     is the component type of Test[] for which an instance has been
>     created.
>
>     5. If you change line 5 to "var x = new Test[] {new Test()};" jdb
>     will
>     actually return information about "Test", that is, the class is
>     loaded.
>
>     ?From these observations I conclude, that the component type of an
>     array
>     type is not loaded, if only empty instances of the array type are
>     created.
>     I wonder, why this does not violate the specification of the JVMS
>     at [1]
>     and [2]
>
>     (I am working with Java 11, so so far I tested this only for
>     OpenJDK 11)
>
>     [1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11:
>     https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1
>     [2]
>     https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray
>
>
>

From anton.haubner at outlook.de  Wed Apr 13 14:17:00 2022
From: anton.haubner at outlook.de (Anton W. Haubner)
Date: Wed, 13 Apr 2022 16:17:00 +0200
Subject: JVM does not match JVMS regarding array component types?
In-Reply-To: <AM0PR10MB310621FEB62B53A59AE21AD98FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>
 <AM0PR10MB310621FEB62B53A59AE21AD98FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <AM0PR10MB31065F30D64A0ACD50266C828FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>

Follow up on the conditions under which types should become visible 
during debugging:

JDB uses the JDI methods VirtualMachine.allClasses() and 
VirtualMachine.classesByName() to look up types
(See com.sun.tools.example.debug.tty.Env.getReferenceTypeFromToken()).

Looking at the JDI documentation and the specification of the underlying 
JDWP, one normally should be able to look up all loaded types:

https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#allClasses()
https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_AllClasses

https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#classesByName(java.lang.String)
https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_ClassesBySignature

So maybe the JPDA backend agent of OpenJDK does not respect this 
specification?


On 4/13/22 16:14, Anton W. Haubner wrote:
> Hi!
>
> Thank you for this hint.
>
> The output of `java -Xlog:class+load ArrayTest` contains
>
> ```
> ...
> [0.242s][info][class,load] java.lang.Void source: jrt:/java.base
> [0.242s][info][class,load] Test source: file:/home/anton/<...>
> [0.242s][info][class,load] jdk.internal.misc.TerminatingThreadLocal$1 
> source: jrt:/java.base
> ...
>
> ```
>
> This is the only place where the component type "Test" is mentioned.
>
> If I understand this output correctly, then the "Test" class has 
> actually been created.
> Now I wonder, under which conditions a created type becomes visible 
> through the JDI.
>
> Best regards,
>
> Anton Haubner
>
> On 4/13/22 15:02, Volker Simonis wrote:
>> Just to make sure this is not an issue with jdb, could you please run 
>> your example program with "-Xlog:class+load" and check the output?
>>
>> Anton W. Haubner <anton.haubner at outlook.de> schrieb am Mi., 13. Apr. 
>> 2022, 11:12:
>>
>> ??? Hi!
>>
>> ??? I am not sure if this is the right place to ask these questions. At
>> ??? first glance, the "jls-jvms-spec-comments" mailing list looks more
>> ??? appropriate but its description says that that list "is solely a 
>> drop
>> ??? box for reports".
>> ??? Therefore, if I am out-of-place here, please direct me to the
>> ??? appropriate mailing list.
>>
>> ??? My question is about the behaviour of the JVM which seemingly does
>> ??? not
>> ??? match the JVMS specification when it comes to lazy-linking and
>> ??? empty arrays.
>>
>> ??? I noticed that regarding lazy-linking strategies and resolution, the
>> ??? JVMS states that if an array type is resolved whose element type 
>> is a
>> ??? reference type, then
>>
>> ??? "a symbolic reference to the class or interface representing the
>> ??? element type is resolved [...] recursively." [1]
>>
>> ??? More specifically, the `anewarray` instruction requires the
>> ??? resolution
>> ??? of the component type when executed [2].
>>
>> ??? However, while inspecting programs with the JDI, I observed that 
>> when
>> ??? creating an empty array, the component type of the array is
>> ??? actually not
>> ??? loaded.
>> ??? You can observe this as follows:
>>
>> ??? 1. Compile the following program with `javac -g`:
>>
>> ??? ```
>> ??? class Test { }
>>
>> ??? public class ArrayTest {
>> ??? ?? public static void main(String[] args) {
>> ??? ???? var x = new Test[] {};
>> ??? ?? }
>> ??? }
>>
>> ??? ```
>>
>> ??? 2. Executing `javap -v ArrayTest` will confirm that when stopping 
>> the
>> ??? program on line 6, `anewarray` must have been executed.
>>
>> ??? 3. Run the following commands in `jdb`:
>>
>> ??? stop at ArrayTest:6
>> ??? run ArrayTest
>> ??? class Test
>>
>> ??? 4. It will say "Test is not a valid id or class name.", i.e. the
>> ??? class
>> ??? "Test" has not been loaded, even though it should have been
>> ??? because it
>> ??? is the component type of Test[] for which an instance has been
>> ??? created.
>>
>> ??? 5. If you change line 5 to "var x = new Test[] {new Test()};" jdb
>> ??? will
>> ??? actually return information about "Test", that is, the class is
>> ??? loaded.
>>
>> ??? ?From these observations I conclude, that the component type of an
>> ??? array
>> ??? type is not loaded, if only empty instances of the array type are
>> ??? created.
>> ??? I wonder, why this does not violate the specification of the JVMS
>> ??? at [1]
>> ??? and [2]
>>
>> ??? (I am working with Java 11, so so far I tested this only for
>> ??? OpenJDK 11)
>>
>> ??? [1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11:
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1
>> ??? [2]
>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray
>>
>>
>>

From david.holmes at oracle.com  Thu Apr 14 07:51:04 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 14 Apr 2022 17:51:04 +1000
Subject: JVM does not match JVMS regarding array component types?
In-Reply-To: <AM0PR10MB31065F30D64A0ACD50266C828FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>
 <AM0PR10MB310621FEB62B53A59AE21AD98FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB31065F30D64A0ACD50266C828FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <f18fff50-cc91-65e2-9c10-d08dda305ecb@oracle.com>

Hi Anton,

On 14/04/2022 12:17 am, Anton W. Haubner wrote:
> Follow up on the conditions under which types should become visible 
> during debugging:
> 
> JDB uses the JDI methods VirtualMachine.allClasses() and 
> VirtualMachine.classesByName() to look up types
> (See com.sun.tools.example.debug.tty.Env.getReferenceTypeFromToken()).
> 
> Looking at the JDI documentation and the specification of the underlying 
> JDWP, one normally should be able to look up all loaded types:
> 
> https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#allClasses() 
> 
> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_AllClasses 
> 
> 
> https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#classesByName(java.lang.String) 
> 
> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_ClassesBySignature 
> 
> 
> So maybe the JPDA backend agent of OpenJDK does not respect this 
> specification?

See https://bugs.openjdk.java.net/browse/JDK-8181144

Cheers,
David

> 
> On 4/13/22 16:14, Anton W. Haubner wrote:
>> Hi!
>>
>> Thank you for this hint.
>>
>> The output of `java -Xlog:class+load ArrayTest` contains
>>
>> ```
>> ...
>> [0.242s][info][class,load] java.lang.Void source: jrt:/java.base
>> [0.242s][info][class,load] Test source: file:/home/anton/<...>
>> [0.242s][info][class,load] jdk.internal.misc.TerminatingThreadLocal$1 
>> source: jrt:/java.base
>> ...
>>
>> ```
>>
>> This is the only place where the component type "Test" is mentioned.
>>
>> If I understand this output correctly, then the "Test" class has 
>> actually been created.
>> Now I wonder, under which conditions a created type becomes visible 
>> through the JDI.
>>
>> Best regards,
>>
>> Anton Haubner
>>
>> On 4/13/22 15:02, Volker Simonis wrote:
>>> Just to make sure this is not an issue with jdb, could you please run 
>>> your example program with "-Xlog:class+load" and check the output?
>>>
>>> Anton W. Haubner <anton.haubner at outlook.de> schrieb am Mi., 13. Apr. 
>>> 2022, 11:12:
>>>
>>> ??? Hi!
>>>
>>> ??? I am not sure if this is the right place to ask these questions. At
>>> ??? first glance, the "jls-jvms-spec-comments" mailing list looks more
>>> ??? appropriate but its description says that that list "is solely a 
>>> drop
>>> ??? box for reports".
>>> ??? Therefore, if I am out-of-place here, please direct me to the
>>> ??? appropriate mailing list.
>>>
>>> ??? My question is about the behaviour of the JVM which seemingly does
>>> ??? not
>>> ??? match the JVMS specification when it comes to lazy-linking and
>>> ??? empty arrays.
>>>
>>> ??? I noticed that regarding lazy-linking strategies and resolution, the
>>> ??? JVMS states that if an array type is resolved whose element type 
>>> is a
>>> ??? reference type, then
>>>
>>> ??? "a symbolic reference to the class or interface representing the
>>> ??? element type is resolved [...] recursively." [1]
>>>
>>> ??? More specifically, the `anewarray` instruction requires the
>>> ??? resolution
>>> ??? of the component type when executed [2].
>>>
>>> ??? However, while inspecting programs with the JDI, I observed that 
>>> when
>>> ??? creating an empty array, the component type of the array is
>>> ??? actually not
>>> ??? loaded.
>>> ??? You can observe this as follows:
>>>
>>> ??? 1. Compile the following program with `javac -g`:
>>>
>>> ??? ```
>>> ??? class Test { }
>>>
>>> ??? public class ArrayTest {
>>> ??? ?? public static void main(String[] args) {
>>> ??? ???? var x = new Test[] {};
>>> ??? ?? }
>>> ??? }
>>>
>>> ??? ```
>>>
>>> ??? 2. Executing `javap -v ArrayTest` will confirm that when stopping 
>>> the
>>> ??? program on line 6, `anewarray` must have been executed.
>>>
>>> ??? 3. Run the following commands in `jdb`:
>>>
>>> ??? stop at ArrayTest:6
>>> ??? run ArrayTest
>>> ??? class Test
>>>
>>> ??? 4. It will say "Test is not a valid id or class name.", i.e. the
>>> ??? class
>>> ??? "Test" has not been loaded, even though it should have been
>>> ??? because it
>>> ??? is the component type of Test[] for which an instance has been
>>> ??? created.
>>>
>>> ??? 5. If you change line 5 to "var x = new Test[] {new Test()};" jdb
>>> ??? will
>>> ??? actually return information about "Test", that is, the class is
>>> ??? loaded.
>>>
>>> ??? ?From these observations I conclude, that the component type of an
>>> ??? array
>>> ??? type is not loaded, if only empty instances of the array type are
>>> ??? created.
>>> ??? I wonder, why this does not violate the specification of the JVMS
>>> ??? at [1]
>>> ??? and [2]
>>>
>>> ??? (I am working with Java 11, so so far I tested this only for
>>> ??? OpenJDK 11)
>>>
>>> ??? [1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11:
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1 
>>>
>>> ??? [2]
>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray 
>>>
>>>
>>>
>>>

From mark at talios.com  Thu Apr 14 08:44:57 2022
From: mark at talios.com (Mark Derricutt)
Date: Thu, 14 Apr 2022 01:44:57 -0700
Subject: Possible casing issue with DateTimeFormatter in JDK 15 on
Message-ID: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>

Hey all,

I?ve just been working on finally migrating some of our code to at least,
build UNDER a JDK greater than 8 - and ran into a test case in my code base
that failed relating to (possibly) undocumented changes in the the
DateTimeFormatter.

In this case, it?s triggered when using the AM/PM specifier - such as in
h:mma - under JDK8 and JDK11 this renders out as PM but, in 15/16/17/18
this renders as pm.

The docs on
https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/time/format/DateTimeFormatter.html
merely
show PM as an *example*, but doesn?t specifically call out casing.

I?ve thrown a simple JBang based class/test on
https://gist.github.com/talios/23cb742a7ac5fe6f984abd56c2d65352

JDK8:

$ jbang run DateFormatTest.java
Oct 2, 12:20PM (Z)


JDK18:

$ jbang run DateFormatTest.java
Oct 2, 12:20pm (Z)
Formatting failed


Is this a bug, an undocumented change, something I?m overthinking to much
over and I should just adjust my tests to ignore case?

Cheers
Mark


-- 
"Great artists are extremely selfish and arrogant things" ? Steven Wilson,
Porcupine Tree

From mark at talios.com  Thu Apr 14 09:24:04 2022
From: mark at talios.com (Mark Derricutt)
Date: Thu, 14 Apr 2022 02:24:04 -0700
Subject: Possible casing issue with DateTimeFormatter in JDK 15 on
In-Reply-To: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
References: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
Message-ID: <CALYGm1y_yHHy8ZAtcAj0earbh9XYsKSZOob_xnUiSSrLaeXYtg@mail.gmail.com>

On 14/04/2022 at 8:44:57 PM, Mark Derricutt <mark at talios.com> wrote:

In this case, it?s triggered when using the AM/PM specifier - such as in
> h:mma - under JDK8 and JDK11 this renders out as PM but, in 15/16/17/18
> this renders as pm.
>
>
Follow up - was pointed to https://bugs.openjdk.java.net/browse/JDK-8211985 on
twitter - and this does indeed seem to be the same locale related issue.

Changing my code to call:

withLocale(Locale.ENGLISH).format(instant)


and setting the locate explicitly yields the desired results - and runs the
same across 8/18 - which means I can alter the underly code separate to any
JDK rework I?m doing.

And now? for easter eggs.



> --
> "Great artists are extremely selfish and arrogant things" ? Steven Wilson,
> Porcupine Tree
>

From Alan.Bateman at oracle.com  Thu Apr 14 09:31:08 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 14 Apr 2022 10:31:08 +0100
Subject: Possible casing issue with DateTimeFormatter in JDK 15 on
In-Reply-To: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
References: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
Message-ID: <7c330175-226e-2913-3576-c286a358a135@oracle.com>

On 14/04/2022 09:44, Mark Derricutt wrote:
> Hey all,
>
> I?ve just been working on finally migrating some of our code to at least,
> build UNDER a JDK greater than 8 - and ran into a test case in my code base
> that failed relating to (possibly) undocumented changes in the the
> DateTimeFormatter.
>
This may be related to the switch to using the CLDR locale data by 
default in JDK 9, more on that in JEP 127 [1] and JEP 252 [2], including 
the system property that you can set to use the older JRE locale data if 
needed.

-Alan

[1] https://openjdk.java.net/jeps/127
[2] https://openjdk.java.net/jeps/252

From anton.haubner at outlook.de  Fri Apr 15 15:48:35 2022
From: anton.haubner at outlook.de (Anton W. Haubner)
Date: Fri, 15 Apr 2022 17:48:35 +0200
Subject: JVM does not match JVMS regarding array component types?
In-Reply-To: <f18fff50-cc91-65e2-9c10-d08dda305ecb@oracle.com>
References: <AM0PR10MB3106A947C99A7579CDB082588FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <CA+3eh13rmR+uXsXLHW9-sm__WLwAGjN7GEWvyjQnbV+xRExJLA@mail.gmail.com>
 <AM0PR10MB310621FEB62B53A59AE21AD98FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <AM0PR10MB31065F30D64A0ACD50266C828FEC9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>
 <f18fff50-cc91-65e2-9c10-d08dda305ecb@oracle.com>
Message-ID: <AM0PR10MB3106391DDC19E06CB210D7E98FEE9@AM0PR10MB3106.EURPRD10.PROD.OUTLOOK.COM>

Hi David,

thank you for the link to the bug report. Apparently I did not read the 
"fine-print" of the VirtualMachine.allClasses() method correctly.

I conclude:

The JVM does comply with the JVMS, the component type is created.

The JDI also complies with its specification.
The component type is not available during debugging, because the 
"VirtualMachine.allClasses()" and "VirtualMachine.classesByName" methods 
only return those loaded types which have also been prepared.
Section 5.4.3.1 of the JVMS which I was citing does only require 
creation of the component type, not preparation.

Hence, my question has been answered. Thanks to everyone involved.

Best regards,

Anton

On 4/14/22 09:51, David Holmes wrote:
> Hi Anton,
>
> On 14/04/2022 12:17 am, Anton W. Haubner wrote:
>> Follow up on the conditions under which types should become visible 
>> during debugging:
>>
>> JDB uses the JDI methods VirtualMachine.allClasses() and 
>> VirtualMachine.classesByName() to look up types
>> (See com.sun.tools.example.debug.tty.Env.getReferenceTypeFromToken()).
>>
>> Looking at the JDI documentation and the specification of the 
>> underlying JDWP, one normally should be able to look up all loaded 
>> types:
>>
>> https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#allClasses() 
>>
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_AllClasses 
>>
>>
>> https://docs.oracle.com/en/java/javase/11/docs/api/jdk.jdi/com/sun/jdi/VirtualMachine.html#classesByName(java.lang.String) 
>>
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_ClassesBySignature 
>>
>>
>> So maybe the JPDA backend agent of OpenJDK does not respect this 
>> specification?
>
> See https://bugs.openjdk.java.net/browse/JDK-8181144
>
> Cheers,
> David
>
>>
>> On 4/13/22 16:14, Anton W. Haubner wrote:
>>> Hi!
>>>
>>> Thank you for this hint.
>>>
>>> The output of `java -Xlog:class+load ArrayTest` contains
>>>
>>> ```
>>> ...
>>> [0.242s][info][class,load] java.lang.Void source: jrt:/java.base
>>> [0.242s][info][class,load] Test source: file:/home/anton/<...>
>>> [0.242s][info][class,load] 
>>> jdk.internal.misc.TerminatingThreadLocal$1 source: jrt:/java.base
>>> ...
>>>
>>> ```
>>>
>>> This is the only place where the component type "Test" is mentioned.
>>>
>>> If I understand this output correctly, then the "Test" class has 
>>> actually been created.
>>> Now I wonder, under which conditions a created type becomes visible 
>>> through the JDI.
>>>
>>> Best regards,
>>>
>>> Anton Haubner
>>>
>>> On 4/13/22 15:02, Volker Simonis wrote:
>>>> Just to make sure this is not an issue with jdb, could you please 
>>>> run your example program with "-Xlog:class+load" and check the output?
>>>>
>>>> Anton W. Haubner <anton.haubner at outlook.de> schrieb am Mi., 13. 
>>>> Apr. 2022, 11:12:
>>>>
>>>> ??? Hi!
>>>>
>>>> ??? I am not sure if this is the right place to ask these 
>>>> questions. At
>>>> ??? first glance, the "jls-jvms-spec-comments" mailing list looks more
>>>> ??? appropriate but its description says that that list "is solely 
>>>> a drop
>>>> ??? box for reports".
>>>> ??? Therefore, if I am out-of-place here, please direct me to the
>>>> ??? appropriate mailing list.
>>>>
>>>> ??? My question is about the behaviour of the JVM which seemingly does
>>>> ??? not
>>>> ??? match the JVMS specification when it comes to lazy-linking and
>>>> ??? empty arrays.
>>>>
>>>> ??? I noticed that regarding lazy-linking strategies and 
>>>> resolution, the
>>>> ??? JVMS states that if an array type is resolved whose element 
>>>> type is a
>>>> ??? reference type, then
>>>>
>>>> ??? "a symbolic reference to the class or interface representing the
>>>> ??? element type is resolved [...] recursively." [1]
>>>>
>>>> ??? More specifically, the `anewarray` instruction requires the
>>>> ??? resolution
>>>> ??? of the component type when executed [2].
>>>>
>>>> ??? However, while inspecting programs with the JDI, I observed 
>>>> that when
>>>> ??? creating an empty array, the component type of the array is
>>>> ??? actually not
>>>> ??? loaded.
>>>> ??? You can observe this as follows:
>>>>
>>>> ??? 1. Compile the following program with `javac -g`:
>>>>
>>>> ??? ```
>>>> ??? class Test { }
>>>>
>>>> ??? public class ArrayTest {
>>>> ??? ?? public static void main(String[] args) {
>>>> ??? ???? var x = new Test[] {};
>>>> ??? ?? }
>>>> ??? }
>>>>
>>>> ??? ```
>>>>
>>>> ??? 2. Executing `javap -v ArrayTest` will confirm that when 
>>>> stopping the
>>>> ??? program on line 6, `anewarray` must have been executed.
>>>>
>>>> ??? 3. Run the following commands in `jdb`:
>>>>
>>>> ??? stop at ArrayTest:6
>>>> ??? run ArrayTest
>>>> ??? class Test
>>>>
>>>> ??? 4. It will say "Test is not a valid id or class name.", i.e. the
>>>> ??? class
>>>> ??? "Test" has not been loaded, even though it should have been
>>>> ??? because it
>>>> ??? is the component type of Test[] for which an instance has been
>>>> ??? created.
>>>>
>>>> ??? 5. If you change line 5 to "var x = new Test[] {new Test()};" jdb
>>>> ??? will
>>>> ??? actually return information about "Test", that is, the class is
>>>> ??? loaded.
>>>>
>>>> ??? ?From these observations I conclude, that the component type of an
>>>> ??? array
>>>> ??? type is not loaded, if only empty instances of the array type are
>>>> ??? created.
>>>> ??? I wonder, why this does not violate the specification of the JVMS
>>>> ??? at [1]
>>>> ??? and [2]
>>>>
>>>> ??? (I am working with Java 11, so so far I tested this only for
>>>> ??? OpenJDK 11)
>>>>
>>>> ??? [1] Section 5.4.3.1, Java Virtual Machine Specification, Java 11:
>>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-5.html#jvms-5.4.3.1 
>>>>
>>>> ??? [2]
>>>> https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.anewarray 
>>>>
>>>>
>>>>
>>>>

From mark at talios.com  Sun Apr 17 08:13:37 2022
From: mark at talios.com (Mark Derricutt)
Date: Sun, 17 Apr 2022 01:13:37 -0700
Subject: Possible casing issue with DateTimeFormatter in JDK 15 on
In-Reply-To: <7c330175-226e-2913-3576-c286a358a135@oracle.com>
References: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
 <7c330175-226e-2913-3576-c286a358a135@oracle.com>
Message-ID: <CALYGm1yXmPH=pv_mPdosaR-HQ_aymyZrhOeaDjZm+jA9zRfxGg@mail.gmail.com>

 Looks like this is the case.  Setting the Locale specifically resolved my
casing issue. Interestingly tho, where my original test had returned
EST/ESD - under 11+ I ended up with EST/GMT-04:00 in an old day light
savings related test:

expected: "Feb 28, 7:00PM (EST) - Aug 7, 8:00PM 2014 (EDT)"
 but was: "Feb 28, 7:00PM (EST) - Aug 7, 8:00PM 2014 (GMT-04:00)"


[1] says there?s no such Timezone as EDT - yet it seems like it existed in
JDK8 - I assume that was removed at some point?


[1]
https://stackoverflow.com/questions/11129108/converting-edt-time-zone-to-gmt-not-working-fine-in-java

-- 
"Great artists are extremely selfish and arrogant things" ? Steven Wilson,
Porcupine Tree


On 14/04/2022 at 9:31:08 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 14/04/2022 09:44, Mark Derricutt wrote:
>
> Hey all,
>
>
> I?ve just been working on finally migrating some of our code to at least,
>
> build UNDER a JDK greater than 8 - and ran into a test case in my code base
>
> that failed relating to (possibly) undocumented changes in the the
>
> DateTimeFormatter.
>
>
> This may be related to the switch to using the CLDR locale data by
> default in JDK 9, more on that in JEP 127 [1] and JEP 252 [2], including
> the system property that you can set to use the older JRE locale data if
> needed.
>
> -Alan
>
> [1] https://openjdk.java.net/jeps/127
> [2] https://openjdk.java.net/jeps/252
>

From naoto.sato at oracle.com  Mon Apr 18 17:04:20 2022
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 18 Apr 2022 10:04:20 -0700
Subject: Possible casing issue with DateTimeFormatter in JDK 15 on
In-Reply-To: <CALYGm1yXmPH=pv_mPdosaR-HQ_aymyZrhOeaDjZm+jA9zRfxGg@mail.gmail.com>
References: <CALYGm1x6sqo6KK7jLUHCdQuJc3nZ8t=QQSwuPnFNn8auztMz4w@mail.gmail.com>
 <7c330175-226e-2913-3576-c286a358a135@oracle.com>
 <CALYGm1yXmPH=pv_mPdosaR-HQ_aymyZrhOeaDjZm+jA9zRfxGg@mail.gmail.com>
Message-ID: <fe1e0e54-ae70-966e-a8d6-aed83423c47d@oracle.com>

Hi Mark,

Please use core-libs-dev mailing list for the specific discussion.

As to your question, short display names of the time zone depend on the 
location, so you will need to be specific. If you need "EDT" for eg 
"America/New_York" time zone, you will have to specify Locale.US, 
otherwise it may end up "GMT-04:00", eg in Locale.UK.

Naoto

On 4/17/22 1:13 AM, Mark Derricutt wrote:
>   Looks like this is the case.  Setting the Locale specifically resolved my
> casing issue. Interestingly tho, where my original test had returned
> EST/ESD - under 11+ I ended up with EST/GMT-04:00 in an old day light
> savings related test:
> 
> expected: "Feb 28, 7:00PM (EST) - Aug 7, 8:00PM 2014 (EDT)"
>   but was: "Feb 28, 7:00PM (EST) - Aug 7, 8:00PM 2014 (GMT-04:00)"
> 
> 
> [1] says there?s no such Timezone as EDT - yet it seems like it existed in
> JDK8 - I assume that was removed at some point?
> 
> 
> [1]
> https://stackoverflow.com/questions/11129108/converting-edt-time-zone-to-gmt-not-working-fine-in-java
> 

From arjan.tijms at gmail.com  Mon Apr 18 18:53:52 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 18 Apr 2022 20:53:52 +0200
Subject: Method and Field Literals
In-Reply-To: <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
Message-ID: <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>

Hi,

It's again a couple of years later, is there already any desire to
pursue the method and field literals topic?

Kind regards,
Arjan Tijms

On Fri, Jul 27, 2018 at 7:00 PM Martijn Verburg <martijnverburg at gmail.com>
wrote:

> @HereBeDragons - I?m almost tempted to raise a JEP.
>
> On Fri, 27 Jul 2018 at 16:45, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> > > The non easy way is to make the method reference Serializable,
> serialize
> > it and extract the Serialization proxy which contains the class, the
> method
> > etc.
> >
> > In addition to non-easy, this is also non-safe, non-cost-free, etc.
> > Let's put this in the category of "dangerous workarounds" :)
> >
> >
> > --
> Cheers, Martijn (Sent from Gmail Mobile)
>

From peter.lawrey at gmail.com  Tue Apr 19 14:52:46 2022
From: peter.lawrey at gmail.com (Peter Lawrey)
Date: Tue, 19 Apr 2022 15:52:46 +0100
Subject: Method and Field Literals
In-Reply-To: <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
Message-ID: <CAOgwmThtTuVq+kT-Sg_SPNxnXPem9p=iUrd2trysJ59Kq5W7Gw@mail.gmail.com>

There is from me, but people seem comfortable with reflection instead.

Cheers,
   Peter.

On Mon, 18 Apr 2022 at 19:55, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> It's again a couple of years later, is there already any desire to
> pursue the method and field literals topic?
>
> Kind regards,
> Arjan Tijms
>
> On Fri, Jul 27, 2018 at 7:00 PM Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
> > @HereBeDragons - I?m almost tempted to raise a JEP.
> >
> > On Fri, 27 Jul 2018 at 16:45, Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >
> > > > The non easy way is to make the method reference Serializable,
> > serialize
> > > it and extract the Serialization proxy which contains the class, the
> > method
> > > etc.
> > >
> > > In addition to non-easy, this is also non-safe, non-cost-free, etc.
> > > Let's put this in the category of "dangerous workarounds" :)
> > >
> > >
> > > --
> > Cheers, Martijn (Sent from Gmail Mobile)
> >
>

From brian.goetz at oracle.com  Wed Apr 20 16:30:06 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Apr 2022 12:30:06 -0400
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
Message-ID: <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>


> It's again a couple of years later, is there already any desire to 
> pursue?the method and field literals topic?

The term "method and field literals" is somewhat overloaded, so let's be 
more specific: what do you expect the _type_ of a method literal is?? Is 
it just jlr.Method?? Or is MethodHandle / VarHandle also part of the 
story??? Is the goal simply to get earlier error checking that you 
specified a method that exists (errors at compile time vs run time)? Or 
to just have syntactic sugar for the reflective call?? Or somehow an 
expectation that the lookup can be more efficient, such as LDC 
MethodHandle + MH.unreflect?





From arjan.tijms at gmail.com  Wed Apr 20 23:17:23 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 21 Apr 2022 01:17:23 +0200
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
Message-ID: <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>

Hi,

One of the main use cases is for referring to methods in a typesafe way.

E.g. in Jakarta Persistence (previously JPA), one now has to either use a
string to reference a method, or generate a meta model that effectively
fakes method reference (technically JavaBean property references):

Root<Student> root = criteriaQuery.from(Student.class);
criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
2015));

This is not ideal. Generating the meta model is such a hassle that it's
often not done. Much nicer would be a method literal syntax of some kind,
so we can do:

Root<Student> root = criteriaQuery.from(Student.class);
criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
), 2015));

Another example that came up lately is in method handlers, for instance
here one for a dynamic proxy implementing multiple interfaces:

public static class LambdaHandler implements InvocationHandler {

        private ELContext elContext;
        private LambdaExpression lambdaExpression;

        @Override
        public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
           if (method.getDeclaringClass().equals(BiConsumer.class) &&
               method.getName().equals("accept") {

           }
        }

The declaring class can be checked for in a type-safe way, but for the
method a String needs to be used.

Kind regards,
Arjan Tijms


On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> > It's again a couple of years later, is there already any desire to
> > pursue the method and field literals topic?
>
> The term "method and field literals" is somewhat overloaded, so let's be
> more specific: what do you expect the _type_ of a method literal is?  Is
> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
> story?   Is the goal simply to get earlier error checking that you
> specified a method that exists (errors at compile time vs run time)? Or
> to just have syntactic sugar for the reflective call?  Or somehow an
> expectation that the lookup can be more efficient, such as LDC
> MethodHandle + MH.unreflect?
>
>
>
>
>

From kedward777 at gmail.com  Thu Apr 21 15:55:46 2022
From: kedward777 at gmail.com (ken edward)
Date: Thu, 21 Apr 2022 11:55:46 -0400
Subject: When will fix be availkable for critical CVE-2022-21449 ?
Message-ID: <CAAqgmoOF4Z6fOkLKa1dQ9jGj86uuYx56RYh=xSHXqFx3EcV6pw@mail.gmail.com>

Hello,

I am a newbie, We are running openjdk 17.01. We see critical
vulnerabilities announced April 19th CVE-2022-21449. When will the fix be
available? Is this done through a GA release?

Ken

From kedward777 at gmail.com  Thu Apr 21 16:40:48 2022
From: kedward777 at gmail.com (ken edward)
Date: Thu, 21 Apr 2022 12:40:48 -0400
Subject: How are critical security updates implemented in openjdk vs oracle
 jdk?
Message-ID: <CAAqgmoPV9G91e_u4romPyC8p2jpYuNXQUZ8UULmJ89pd2HHP+A@mail.gmail.com>

Hello,

Can someone tell me how Critical security updates are implemented in open
jdk vs oracle?

For the recent CVE-2022-21449 I see oracle jdk 17.0.3 has been published to
address CVE, but open jdk is still on 17.0.2.  How long until open jdk
update typically?

Ken

From alexhd01m at gmail.com  Fri Apr 22 20:35:30 2022
From: alexhd01m at gmail.com (Alexander)
Date: Fri, 22 Apr 2022 23:35:30 +0300
Subject: How are critical security updates implemented in openjdk vs
 oracle jdk?
In-Reply-To: <CAAqgmoPV9G91e_u4romPyC8p2jpYuNXQUZ8UULmJ89pd2HHP+A@mail.gmail.com>
References: <CAAqgmoPV9G91e_u4romPyC8p2jpYuNXQUZ8UULmJ89pd2HHP+A@mail.gmail.com>
Message-ID: <CAMHkvOMBag+Vh2+YnmJu4JG6_0_fRLxLbujSvBXdb6pFWGjFzQ@mail.gmail.com>

Hi Ken,

 Looks like my original message didn't go through because of the HTML
format, so I'm repeating it in a plain text form:

You might want to take a look into the Timelines section of JDK 17u
page (https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u):

Timelines

OpenJDK 17.0.3

Friday, December 17 2021: jdk17u-dev repo open (no tag this time!)
Tuesday, February 8 2022: First merge from jdk17u-dev to jdk17u (tag:
17.0.3+1) (Delayed according to original plan to align with 11.0.15.)
Tuesday, March 1 30 2022: Rampdown; last merge from jdk17u-dev to jdk17u
Tuesday, March 29 2022: Last tag before code freeze
Tuesday, April 19 2022 GA; OpenJDK 17.0.3 released (tag: jdk-17.0.3-ga)

 OpenJDK 17.0.4

Wednesday, March 2 2022: jdk17u-dev repo open (tag: 17.0.4+0)
Tuesday, Mai 3 2022: First merge from jdk17u-dev to jdk17u (tag: 17.0.4+1)
Tuesday, Mai 31 2022: Rampdown; last merge from jdk17u-dev to jdk17u
Tuesday, June 28 2022: Last tag before code freeze
Tuesday, July 19 2022 GA; OpenJDK 17.0.4 released (tag: jdk-17.0.4-ga)

 OpenJDK 17.0.5
Wednesday, June 1 2022: jdk17u-dev repo open (tag: 17.0.5+0)

17.0.3 binaries are already available
(https://adoptium.net/temurin/archive/) and, if I got this right
(https://github.com/openjdk/jdk17u/commit/2d4103a3d929e05edca98e7703e0869077966be7),
it does contain the fix you are looking for.

Regards,

Alexander Kiselyov.


??, 21 ???. 2022 ?. ? 19:41, ken edward <kedward777 at gmail.com>:
>
> Hello,
>
> Can someone tell me how Critical security updates are implemented in open
> jdk vs oracle?
>
> For the recent CVE-2022-21449 I see oracle jdk 17.0.3 has been published to
> address CVE, but open jdk is still on 17.0.2.  How long until open jdk
> update typically?
>
> Ken

From arjan.tijms at gmail.com  Sat Apr 23 15:06:23 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 23 Apr 2022 17:06:23 +0200
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
Message-ID: <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>

Hi,

Found one more example, in Jakarta Security/Soteria:

public final static Method validateRequestMethod = getMethod(
        HttpAuthenticationMechanism.class,
        "validateRequest",
        HttpServletRequest.class, HttpServletResponse.class,
HttpMessageContext.class);

The class and parameters are typesafe, but the method name is not. Would
also be useful if that could be made typesafe.

Kind regards,
Arjan Tijms


On Thu, Apr 21, 2022 at 1:17 AM arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> One of the main use cases is for referring to methods in a typesafe way.
>
> E.g. in Jakarta Persistence (previously JPA), one now has to either use a
> string to reference a method, or generate a meta model that effectively
> fakes method reference (technically JavaBean property references):
>
> Root<Student> root = criteriaQuery.from(Student.class);
> criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
> 2015));
>
> This is not ideal. Generating the meta model is such a hassle that it's
> often not done. Much nicer would be a method literal syntax of some kind,
> so we can do:
>
> Root<Student> root = criteriaQuery.from(Student.class);
> criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
> ), 2015));
>
> Another example that came up lately is in method handlers, for instance
> here one for a dynamic proxy implementing multiple interfaces:
>
> public static class LambdaHandler implements InvocationHandler {
>
>         private ELContext elContext;
>         private LambdaExpression lambdaExpression;
>
>         @Override
>         public Object invoke(Object proxy, Method method, Object[] args)
> throws Throwable {
>            if (method.getDeclaringClass().equals(BiConsumer.class) &&
>                method.getName().equals("accept") {
>
>            }
>         }
>
> The declaring class can be checked for in a type-safe way, but for the
> method a String needs to be used.
>
> Kind regards,
> Arjan Tijms
>
>
> On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>>
>> > It's again a couple of years later, is there already any desire to
>> > pursue the method and field literals topic?
>>
>> The term "method and field literals" is somewhat overloaded, so let's be
>> more specific: what do you expect the _type_ of a method literal is?  Is
>> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
>> story?   Is the goal simply to get earlier error checking that you
>> specified a method that exists (errors at compile time vs run time)? Or
>> to just have syntactic sugar for the reflective call?  Or somehow an
>> expectation that the lookup can be more efficient, such as LDC
>> MethodHandle + MH.unreflect?
>>
>>
>>
>>
>>

From ethan at mccue.dev  Sat Apr 23 16:11:08 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 23 Apr 2022 12:11:08 -0400
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
Message-ID: <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>

I think we should clearly define what you mean by type safety in this
context.

For the last example, even if the compiler were to statically infer that
the method does exist and that the parameter types are correct

public final static Method validateRequestMethod = getMethod(
        HttpAuthenticationMechanism.class,
        MAGIC[validateRequest],
        HttpServletRequest.class, HttpServletResponse.class,
        Integer.class); // This is wrong, compiler will tell you

In usage, invoke will still take an arbitrary array of objects and throw
some gnarly exceptions. So the "type safety" is clearly limited.

Even so, it sounds like "earlier error checking that you specified a method
that exists" is what you want.

On Sat, Apr 23, 2022 at 11:07 AM arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> Found one more example, in Jakarta Security/Soteria:
>
> public final static Method validateRequestMethod = getMethod(
>         HttpAuthenticationMechanism.class,
>         "validateRequest",
>         HttpServletRequest.class, HttpServletResponse.class,
> HttpMessageContext.class);
>
> The class and parameters are typesafe, but the method name is not. Would
> also be useful if that could be made typesafe.
>
> Kind regards,
> Arjan Tijms
>
>
> On Thu, Apr 21, 2022 at 1:17 AM arjan tijms <arjan.tijms at gmail.com> wrote:
>
> > Hi,
> >
> > One of the main use cases is for referring to methods in a typesafe way.
> >
> > E.g. in Jakarta Persistence (previously JPA), one now has to either use a
> > string to reference a method, or generate a meta model that effectively
> > fakes method reference (technically JavaBean property references):
> >
> > Root<Student> root = criteriaQuery.from(Student.class);
> > criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
> > 2015));
> >
> > This is not ideal. Generating the meta model is such a hassle that it's
> > often not done. Much nicer would be a method literal syntax of some kind,
> > so we can do:
> >
> > Root<Student> root = criteriaQuery.from(Student.class);
> >
> criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
> > ), 2015));
> >
> > Another example that came up lately is in method handlers, for instance
> > here one for a dynamic proxy implementing multiple interfaces:
> >
> > public static class LambdaHandler implements InvocationHandler {
> >
> >         private ELContext elContext;
> >         private LambdaExpression lambdaExpression;
> >
> >         @Override
> >         public Object invoke(Object proxy, Method method, Object[] args)
> > throws Throwable {
> >            if (method.getDeclaringClass().equals(BiConsumer.class) &&
> >                method.getName().equals("accept") {
> >
> >            }
> >         }
> >
> > The declaring class can be checked for in a type-safe way, but for the
> > method a String needs to be used.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com>
> > wrote:
> >
> >>
> >> > It's again a couple of years later, is there already any desire to
> >> > pursue the method and field literals topic?
> >>
> >> The term "method and field literals" is somewhat overloaded, so let's be
> >> more specific: what do you expect the _type_ of a method literal is?  Is
> >> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
> >> story?   Is the goal simply to get earlier error checking that you
> >> specified a method that exists (errors at compile time vs run time)? Or
> >> to just have syntactic sugar for the reflective call?  Or somehow an
> >> expectation that the lookup can be more efficient, such as LDC
> >> MethodHandle + MH.unreflect?
> >>
> >>
> >>
> >>
> >>
>

From arjan.tijms at gmail.com  Sat Apr 23 17:56:40 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 23 Apr 2022 19:56:40 +0200
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
Message-ID: <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>

Hi,

On Sat, Apr 23, 2022 at 6:11 PM Ethan McCue <ethan at mccue.dev> wrote:

> I think we should clearly define what you mean by type safety in this
> context.
>
> In usage, invoke will still take an arbitrary array of objects and throw
> some gnarly exceptions. So the "type safety" is clearly limited.
>
> Even so, it sounds like "earlier error checking that you specified a
> method that exists" is what you want.
>

And, of course, the ability to refactor using tools. If I'd rename the
"validateRequest" method to say "validate" the rename would also rename the
literal. It's not so different as with "HttpAuthenticationMechanism.class",
which we use throughout reflective code. If that syntax wouldn't have
value, we would have used Class.forName("HttpAuthenticationMechanism")
everywhere, but we don't.

Kind regards,
Arjan



>
> On Sat, Apr 23, 2022 at 11:07 AM arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> Found one more example, in Jakarta Security/Soteria:
>>
>> public final static Method validateRequestMethod = getMethod(
>>         HttpAuthenticationMechanism.class,
>>         "validateRequest",
>>         HttpServletRequest.class, HttpServletResponse.class,
>> HttpMessageContext.class);
>>
>> The class and parameters are typesafe, but the method name is not. Would
>> also be useful if that could be made typesafe.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>> On Thu, Apr 21, 2022 at 1:17 AM arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > One of the main use cases is for referring to methods in a typesafe way.
>> >
>> > E.g. in Jakarta Persistence (previously JPA), one now has to either use
>> a
>> > string to reference a method, or generate a meta model that effectively
>> > fakes method reference (technically JavaBean property references):
>> >
>> > Root<Student> root = criteriaQuery.from(Student.class);
>> > criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
>> > 2015));
>> >
>> > This is not ideal. Generating the meta model is such a hassle that it's
>> > often not done. Much nicer would be a method literal syntax of some
>> kind,
>> > so we can do:
>> >
>> > Root<Student> root = criteriaQuery.from(Student.class);
>> >
>> criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
>> > ), 2015));
>> >
>> > Another example that came up lately is in method handlers, for instance
>> > here one for a dynamic proxy implementing multiple interfaces:
>> >
>> > public static class LambdaHandler implements InvocationHandler {
>> >
>> >         private ELContext elContext;
>> >         private LambdaExpression lambdaExpression;
>> >
>> >         @Override
>> >         public Object invoke(Object proxy, Method method, Object[] args)
>> > throws Throwable {
>> >            if (method.getDeclaringClass().equals(BiConsumer.class) &&
>> >                method.getName().equals("accept") {
>> >
>> >            }
>> >         }
>> >
>> > The declaring class can be checked for in a type-safe way, but for the
>> > method a String needs to be used.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> > On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com>
>> > wrote:
>> >
>> >>
>> >> > It's again a couple of years later, is there already any desire to
>> >> > pursue the method and field literals topic?
>> >>
>> >> The term "method and field literals" is somewhat overloaded, so let's
>> be
>> >> more specific: what do you expect the _type_ of a method literal is?
>> Is
>> >> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
>> >> story?   Is the goal simply to get earlier error checking that you
>> >> specified a method that exists (errors at compile time vs run time)? Or
>> >> to just have syntactic sugar for the reflective call?  Or somehow an
>> >> expectation that the lookup can be more efficient, such as LDC
>> >> MethodHandle + MH.unreflect?
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>

From ethan at mccue.dev  Sat Apr 23 23:17:36 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Sat, 23 Apr 2022 19:17:36 -0400
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
Message-ID: <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>

Before moving on with the discussion, can you also address Brain Goetz's
questions directly?

1. what do you expect the _type_ of a method literal is?

2. Is it a goal to have
    a. earlier error checking that you specified a method that exists
    b. syntactic sugar for the reflective call
    c. the lookup can be more efficient

And then from me

3. What in your first example disqualifies a normal method reference lambda
(Class::method) from being appropriate?
4. This pattern of

    var thing = Lookup.find("externalUncheckedName", TypeA.class,
TypeB.class)
    var result = (TypeB) thing.invoke(new TypeA()); // Object... as arg
type and throws some exceptions

is also used in the API for Panama. If we are going to add new goo, is
there a way to address this sort of API as well?

On Sat, Apr 23, 2022 at 1:56 PM arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Sat, Apr 23, 2022 at 6:11 PM Ethan McCue <ethan at mccue.dev> wrote:
>
>> I think we should clearly define what you mean by type safety in this
>> context.
>>
>> In usage, invoke will still take an arbitrary array of objects and throw
>> some gnarly exceptions. So the "type safety" is clearly limited.
>>
>> Even so, it sounds like "earlier error checking that you specified a
>> method that exists" is what you want.
>>
>
> And, of course, the ability to refactor using tools. If I'd rename the
> "validateRequest" method to say "validate" the rename would also rename the
> literal. It's not so different as with "HttpAuthenticationMechanism.class",
> which we use throughout reflective code. If that syntax wouldn't have
> value, we would have used Class.forName("HttpAuthenticationMechanism")
> everywhere, but we don't.
>
> Kind regards,
> Arjan
>
>
>
>>
>> On Sat, Apr 23, 2022 at 11:07 AM arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Found one more example, in Jakarta Security/Soteria:
>>>
>>> public final static Method validateRequestMethod = getMethod(
>>>         HttpAuthenticationMechanism.class,
>>>         "validateRequest",
>>>         HttpServletRequest.class, HttpServletResponse.class,
>>> HttpMessageContext.class);
>>>
>>> The class and parameters are typesafe, but the method name is not. Would
>>> also be useful if that could be made typesafe.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>> On Thu, Apr 21, 2022 at 1:17 AM arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > One of the main use cases is for referring to methods in a typesafe
>>> way.
>>> >
>>> > E.g. in Jakarta Persistence (previously JPA), one now has to either
>>> use a
>>> > string to reference a method, or generate a meta model that effectively
>>> > fakes method reference (technically JavaBean property references):
>>> >
>>> > Root<Student> root = criteriaQuery.from(Student.class);
>>> > criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
>>> > 2015));
>>> >
>>> > This is not ideal. Generating the meta model is such a hassle that it's
>>> > often not done. Much nicer would be a method literal syntax of some
>>> kind,
>>> > so we can do:
>>> >
>>> > Root<Student> root = criteriaQuery.from(Student.class);
>>> >
>>> criteriaQuery.select(root).where(cb.equal(root.get(Student#gradYear.method
>>> > ), 2015));
>>> >
>>> > Another example that came up lately is in method handlers, for instance
>>> > here one for a dynamic proxy implementing multiple interfaces:
>>> >
>>> > public static class LambdaHandler implements InvocationHandler {
>>> >
>>> >         private ELContext elContext;
>>> >         private LambdaExpression lambdaExpression;
>>> >
>>> >         @Override
>>> >         public Object invoke(Object proxy, Method method, Object[]
>>> args)
>>> > throws Throwable {
>>> >            if (method.getDeclaringClass().equals(BiConsumer.class) &&
>>> >                method.getName().equals("accept") {
>>> >
>>> >            }
>>> >         }
>>> >
>>> > The declaring class can be checked for in a type-safe way, but for the
>>> > method a String needs to be used.
>>> >
>>> > Kind regards,
>>> > Arjan Tijms
>>> >
>>> >
>>> > On Wed, Apr 20, 2022 at 6:30 PM Brian Goetz <brian.goetz at oracle.com>
>>> > wrote:
>>> >
>>> >>
>>> >> > It's again a couple of years later, is there already any desire to
>>> >> > pursue the method and field literals topic?
>>> >>
>>> >> The term "method and field literals" is somewhat overloaded, so let's
>>> be
>>> >> more specific: what do you expect the _type_ of a method literal is?
>>> Is
>>> >> it just jlr.Method?  Or is MethodHandle / VarHandle also part of the
>>> >> story?   Is the goal simply to get earlier error checking that you
>>> >> specified a method that exists (errors at compile time vs run time)?
>>> Or
>>> >> to just have syntactic sugar for the reflective call?  Or somehow an
>>> >> expectation that the lookup can be more efficient, such as LDC
>>> >> MethodHandle + MH.unreflect?
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>>
>>

From arjan.tijms at gmail.com  Sun Apr 24 09:31:41 2022
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sun, 24 Apr 2022 11:31:41 +0200
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
 <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
Message-ID: <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>

Hi,

On Sun, Apr 24, 2022 at 1:17 AM Ethan McCue <ethan at mccue.dev> wrote:

> Before moving on with the discussion, can you also address Brain Goetz's
> questions directly?
>
> 1. what do you expect the _type_ of a method literal is?
>

java.lang.Method


2. Is it a goal to have
>     a. earlier error checking that you specified a method that exists
>     b. syntactic sugar for the reflective call
>     c. the lookup can be more efficient
>

a.


And then from me
>
> 3. What in your first example disqualifies a normal method reference
> lambda (Class::method) from being appropriate?
>

If you mean the Query example:

criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
2015));

Then it's not about the actual value of Student.gradYear at this point, but
about the identity of the property. It's used to (ultimately) generate SQL.
The property (field, method) needs to be identified, in order to
read annotations from it that specify the mapping.

If you mean the handler and interceptor examples, then it's checking that
an invoked (intercepted / handled) method is the intended method.



> 4. This pattern of
>
>     var thing = Lookup.find("externalUncheckedName", TypeA.class,
> TypeB.class)
>     var result = (TypeB) thing.invoke(new TypeA()); // Object... as arg
> type and throws some exceptions
>
> is also used in the API for Panama. If we are going to add new goo, is
> there a way to address this sort of API as well?
>

Is "externalUncheckedName" a method name there?

Kind regards,
Arjan Tijms

From brian.goetz at oracle.com  Sun Apr 24 15:31:39 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 24 Apr 2022 15:31:39 +0000
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
 <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
 <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>
Message-ID: <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>

So, a feature where field and method literals evaluated only to Method objects is a pretty weak one, and worse, fi the goal is merely to pull the reflection API into the language, is likely to result in requests to pull further.  Though I do enjoy the extra type checking that IntelliJ gives me for method and method handle lookup.)

The reality is that Method is not a very useful type; reflection is an escape hatch, which has more benefit for frameworks than for ordinary user code.  You might say ?but we have class literals?, but this is mostly a ?for consistency? argument*, and one that doesn?t even survive much scrutiny.

Class literals have two aspects that method literals would not: their role in inference (Foo.class has type Class<Foo>, meaning that it can be used as a source of constraints in type inference), and the Object::getClass method.  Method and field literals would have neither of these two touch points.  (If it were not for the type inference aspect, if we didn?t have class literals now, I might not be inclined to add them ? Class::forName works  too.)  So I would rate this a pretty weak feature.

The main reason method references are useful and these are less useful is that methods have behavior, and method refs allow you to access that behavior through the suitable abstraction level (e.g., Function, Supplier.)  Passing around Method or MethodHandle or VarHandle is not particularly desirable for ordinary application code.

There?s a version of method (and field) references that is more interesting, where we can use target typing to let Foo::bar evaluate to a SAM type, Method, MethodHandle, MethodDesc, or other description of a method.  (Note that you also have to pull in additional syntax and behavior to support overload selection, since we don?t have a SAM type to guide the overload selection.)  That?s more interesting, but a more complex feature.  Fields are even more complicated, because fields have TWO behaviors, and the obvious representations (Field, VarHandle) are also pretty low-level and unsuitable to application-level interaction.  (If the language had Properties, then turning a field into a Property would be a more appropriate API-level encoding.)


*If the best argument you can make for a feature is ?for consistency?, that?s usually a sign that the feature is weak.



On Apr 24, 2022, at 5:31 AM, arjan tijms <arjan.tijms at gmail.com<mailto:arjan.tijms at gmail.com>> wrote:

Hi,

On Sun, Apr 24, 2022 at 1:17 AM Ethan McCue <ethan at mccue.dev<mailto:ethan at mccue.dev>> wrote:
Before moving on with the discussion, can you also address Brain Goetz's questions directly?

1. what do you expect the _type_ of a method literal is?

java.lang.Method


2. Is it a goal to have
    a. earlier error checking that you specified a method that exists
    b. syntactic sugar for the reflective call
    c. the lookup can be more efficient

a.


And then from me

3. What in your first example disqualifies a normal method reference lambda (Class::method) from being appropriate?

If you mean the Query example:

criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear), 2015));

Then it's not about the actual value of Student.gradYear at this point, but about the identity of the property. It's used to (ultimately) generate SQL. The property (field, method) needs to be identified, in order to read annotations from it that specify the mapping.

If you mean the handler and interceptor examples, then it's checking that an invoked (intercepted / handled) method is the intended method.


4. This pattern of

    var thing = Lookup.find("externalUncheckedName", TypeA.class, TypeB.class)
    var result = (TypeB) thing.invoke(new TypeA()); // Object... as arg type and throws some exceptions

is also used in the API for Panama. If we are going to add new goo, is there a way to address this sort of API as well?

Is "externalUncheckedName" a method name there?

Kind regards,
Arjan Tijms


From ethan at mccue.dev  Sun Apr 24 15:55:45 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Sun, 24 Apr 2022 11:55:45 -0400
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
 <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
 <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>
 <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>
Message-ID: <CA+NR86hOnmdPx6-cgOF1hL7XfmBDuRvH_JBsUYE_GNHTxgoP1Q@mail.gmail.com>

> Is "externalUncheckedName" a method name there?

It would be the name of a symbol in a linked DLL/SO.

I think this pattern comes down to effectively "I have knowledge about how
this system outside of Java's compiler and type system should work, how do
I teach Java about it"

- For the Panama case, you have the C header files, you know what the Java
API needs to be.
- For the Method/Field reflection case, you have the methods and fields in
another corner of the type system
- For the SQL case, you have the available table and column names
hypothetically available from the sum of migrations or a dump of the state
of your DB

What makes it feel strange is that in a mostly closed world, like many
web applications, your methods are constant. What is available reflectively
at runtime is actually known at compile time. If you want to see this
assumption be thoroughly broken, you should see the code people write for
interacting with divergent minecraft versions.

https://github.com/CryptoMorin/XSeries/blob/master/src/main/java/com/cryptomorin/xseries/ReflectionUtils.java#L124

If you want a typed api for an externally defined resource, it seems the
route to go is either to write "unsafe" code yourself or generate it.

- For Panama, the jextract tool takes a C header and encodes its knowledge
of the C type system into Java.
- For Method/Field reflection, if you assume a closed world you can use
that knowledge to codegen ways for access to be checked
- For SQL, you can dump Java code which encodes some degree of your
knowledge about what will be safe to access in the database (column name
constants, full JOOQ, etc)



On Sun, Apr 24, 2022 at 11:31 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> So, a feature where field and method literals evaluated only to Method
> objects is a pretty weak one, and worse, fi the goal is merely to pull the
> reflection API into the language, is likely to result in requests to pull
> further.  Though I do enjoy the extra type checking that IntelliJ gives me
> for method and method handle lookup.)
>
> The reality is that Method is not a very useful type; reflection is an
> escape hatch, which has more benefit for frameworks than for ordinary user
> code.  You might say ?but we have class literals?, but this is mostly a
> ?for consistency? argument*, and one that doesn?t even survive much
> scrutiny.
>
> Class literals have two aspects that method literals would not: their role
> in inference (Foo.class has type Class<Foo>, meaning that it can be used as
> a source of constraints in type inference), and the Object::getClass
> method.  Method and field literals would have neither of these two touch
> points.  (If it were not for the type inference aspect, if we didn?t have
> class literals now, I might not be inclined to add them ? Class::forName
> works  too.)  So I would rate this a pretty weak feature.
>
> The main reason method references are useful and these are less useful is
> that methods have behavior, and method refs allow you to access that
> behavior through the suitable abstraction level (e.g., Function, Supplier.)
>  Passing around Method or MethodHandle or VarHandle is not particularly
> desirable for ordinary application code.
>
> There?s a version of method (and field) references that is more
> interesting, where we can use target typing to let Foo::bar evaluate to a
> SAM type, Method, MethodHandle, MethodDesc, or other description of a
> method.  (Note that you also have to pull in additional syntax and behavior
> to support overload selection, since we don?t have a SAM type to guide the
> overload selection.)  That?s more interesting, but a more complex feature.
> Fields are even more complicated, because fields have TWO behaviors, and
> the obvious representations (Field, VarHandle) are also pretty low-level
> and unsuitable to application-level interaction.  (If the language had
> Properties, then turning a field into a Property would be a more
> appropriate API-level encoding.)
>
>
> *If the best argument you can make for a feature is ?for consistency?,
> that?s usually a sign that the feature is weak.
>
>
>
> On Apr 24, 2022, at 5:31 AM, arjan tijms <arjan.tijms at gmail.com> wrote:
>
> Hi,
>
> On Sun, Apr 24, 2022 at 1:17 AM Ethan McCue <ethan at mccue.dev> wrote:
>
>> Before moving on with the discussion, can you also address Brain Goetz's
>> questions directly?
>>
>> 1. what do you expect the _type_ of a method literal is?
>>
>
> java.lang.Method
>
>
> 2. Is it a goal to have
>>     a. earlier error checking that you specified a method that exists
>>     b. syntactic sugar for the reflective call
>>     c. the lookup can be more efficient
>>
>
> a.
>
>
> And then from me
>>
>> 3. What in your first example disqualifies a normal method reference
>> lambda (Class::method) from being appropriate?
>>
>
> If you mean the Query example:
>
> criteriaQuery.select(root).where(cb.equal(root.get(Student_.gradYear),
> 2015));
>
> Then it's not about the actual value of Student.gradYear at this point,
> but about the identity of the property. It's used to (ultimately) generate
> SQL. The property (field, method) needs to be identified, in order to
> read annotations from it that specify the mapping.
>
> If you mean the handler and interceptor examples, then it's checking that
> an invoked (intercepted / handled) method is the intended method.
>
>
>
>> 4. This pattern of
>>
>>     var thing = Lookup.find("externalUncheckedName", TypeA.class,
>> TypeB.class)
>>     var result = (TypeB) thing.invoke(new TypeA()); // Object... as arg
>> type and throws some exceptions
>>
>> is also used in the API for Panama. If we are going to add new goo, is
>> there a way to address this sort of API as well?
>>
>
> Is "externalUncheckedName" a method name there?
>
> Kind regards,
> Arjan Tijms
>
>
>

From per.liden at oracle.com  Thu Apr 28 15:14:28 2022
From: per.liden at oracle.com (Per Liden)
Date: Thu, 28 Apr 2022 17:14:28 +0200
Subject: Resigning as ZGC Project Lead
Message-ID: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>

I hereby resign as ZGC Project Lead.

It has been a super exciting time for me to drive this project from a 
proof-of-concept to a state-of-the-art GC that today powers mission 
critical workloads around the world. However, I will be taking a step 
back from ZGC development to do other things, and so it feels natural to 
hand over the project lead role to someone else.

According to the OpenJDK Bylaws [1], a new Project Lead may be nominated 
by the Group Leads of a Project?s Sponsoring Groups. Such a nomination 
must be approved by a Three-Vote Consensus of these Group Leads. In this 
case, that means Vladimir Kozlov from the HotSpot Group appoints a new 
Project Lead. I would personally recommend Stefan Karlsson as new 
Project Lead. Stefan has played an invaluable role in this project since 
its inception and is a natural successor.

/Per Liden

[1] http://openjdk.java.net/bylaws#project-lead

From forax at univ-mlv.fr  Thu Apr 28 15:36:35 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 28 Apr 2022 17:36:35 +0200 (CEST)
Subject: Resigning as ZGC Project Lead
In-Reply-To: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>
References: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>
Message-ID: <268649458.18186052.1651160195008.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Per Liden" <per.liden at oracle.com>
> To: zgc-dev at openjdk.java.net, "discuss" <discuss at openjdk.java.net>
> Cc: "Vladimir Kozlov" <vladimir.kozlov at oracle.com>, "Stefan Karlsson" <stefan.karlsson at oracle.com>, per at malloc.se
> Sent: Thursday, April 28, 2022 5:14:28 PM
> Subject: Resigning as ZGC Project Lead

> I hereby resign as ZGC Project Lead.
> 
> It has been a super exciting time for me to drive this project from a
> proof-of-concept to a state-of-the-art GC that today powers mission
> critical workloads around the world. However, I will be taking a step
> back from ZGC development to do other things, and so it feels natural to
> hand over the project lead role to someone else.

Hi Per,
you will be missed.

Personally, i really liked your presentations on ZGC and the articles you have published.
I was waiting your explanation on generational ZGC, c'est la vie !

Thanks for all your work on ZGC and good luck for your future projects. 

> 
> According to the OpenJDK Bylaws [1], a new Project Lead may be nominated
> by the Group Leads of a Project?s Sponsoring Groups. Such a nomination
> must be approved by a Three-Vote Consensus of these Group Leads. In this
> case, that means Vladimir Kozlov from the HotSpot Group appoints a new
> Project Lead. I would personally recommend Stefan Karlsson as new
> Project Lead. Stefan has played an invaluable role in this project since
> its inception and is a natural successor.
> 
> /Per Liden
> 
> [1] http://openjdk.java.net/bylaws#project-lead

R?mi

From per.liden at oracle.com  Thu Apr 28 20:57:14 2022
From: per.liden at oracle.com (Per Liden)
Date: Thu, 28 Apr 2022 22:57:14 +0200
Subject: Resigning as ZGC Project Lead
In-Reply-To: <268649458.18186052.1651160195008.JavaMail.zimbra@u-pem.fr>
References: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>
 <268649458.18186052.1651160195008.JavaMail.zimbra@u-pem.fr>
Message-ID: <18f1d347-5c45-2a4f-0f97-eaadc026eb7b@oracle.com>

Thanks R?mi!

/Per

On 4/28/22 17:36, Remi Forax wrote:
> ----- Original Message -----
>> From: "Per Liden" <per.liden at oracle.com>
>> To: zgc-dev at openjdk.java.net, "discuss" <discuss at openjdk.java.net>
>> Cc: "Vladimir Kozlov" <vladimir.kozlov at oracle.com>, "Stefan Karlsson" <stefan.karlsson at oracle.com>, per at malloc.se
>> Sent: Thursday, April 28, 2022 5:14:28 PM
>> Subject: Resigning as ZGC Project Lead
> 
>> I hereby resign as ZGC Project Lead.
>>
>> It has been a super exciting time for me to drive this project from a
>> proof-of-concept to a state-of-the-art GC that today powers mission
>> critical workloads around the world. However, I will be taking a step
>> back from ZGC development to do other things, and so it feels natural to
>> hand over the project lead role to someone else.
> 
> Hi Per,
> you will be missed.
> 
> Personally, i really liked your presentations on ZGC and the articles you have published.
> I was waiting your explanation on generational ZGC, c'est la vie !
> 
> Thanks for all your work on ZGC and good luck for your future projects.
> 
>>
>> According to the OpenJDK Bylaws [1], a new Project Lead may be nominated
>> by the Group Leads of a Project?s Sponsoring Groups. Such a nomination
>> must be approved by a Three-Vote Consensus of these Group Leads. In this
>> case, that means Vladimir Kozlov from the HotSpot Group appoints a new
>> Project Lead. I would personally recommend Stefan Karlsson as new
>> Project Lead. Stefan has played an invaluable role in this project since
>> its inception and is a natural successor.
>>
>> /Per Liden
>>
>> [1] http://openjdk.java.net/bylaws#project-lead
> 
> R?mi
> 

From tobias.gierke at code-sourcery.de  Fri Apr 29 13:19:43 2022
From: tobias.gierke at code-sourcery.de (Tobias Gierke)
Date: Fri, 29 Apr 2022 15:19:43 +0200
Subject: What happened to JEP-302 (Lambda Leftovers) ?
Message-ID: <11a03085-1e11-a266-a97b-1f1c1d46f0f1@code-sourcery.de>

Hi,

I always feel like it's going to get included in the next JDK release 
... and yet it never happens :( Is there a specific reason for that, 
other than lack resources ?

Thanks,
Tobias


From maurizio.cimadamore at oracle.com  Fri Apr 29 17:30:15 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 29 Apr 2022 18:30:15 +0100
Subject: What happened to JEP-302 (Lambda Leftovers) ?
In-Reply-To: <11a03085-1e11-a266-a97b-1f1c1d46f0f1@code-sourcery.de>
References: <11a03085-1e11-a266-a97b-1f1c1d46f0f1@code-sourcery.de>
Message-ID: <7b14fd96-08e7-b6d5-b35b-fbbeba6adc25@oracle.com>

Hi Tobias,
your question is on point.

The JEP is consists of two main features:

* tweak the shadowing rules for lambda parameters, so that lambda 
parameter can shadow local variable from enclosing scopes
* use `_` as an unspecified lambda parameter name

While we have developed viable prototypes for both [1], we started to 
feel that the scope of JEP 302 was too narrow. That is, that JEP focuses 
mainly on enhancing usability of lambda expression, but some of the 
proposed solutions would be, in fact, be applicable in other contexts as 
well. For instance, using `_` as an unspecified name could be useful in 
exception parameter names, method parameter names, binding variables, 
etc. [2]. Similarly, while improving shadowing for lambda parameters can 
yield dividends (esp. in certain API such as Map::computeIfAbsent), 
other language features, such as pattern matching, suffer from similar 
problems (e.g. pattern variables can't shadow enclosing local variables).

For these reasons, we believe that this JEP no longer reflects the 
entirety of our thinking on these matters. As such, we propose that the 
JEP should be withdrawn. Of course that doesn't mean that some of the 
issues mentioned in the JEP will not be addressed. In due course they 
will, but with a more holistic perspective: after all, a lot has changed 
in the Java language since JEP 302 first appeared.

Cheers
Maurizio

[1] - 
http://mail.openjdk.java.net/pipermail/amber-dev/2017-March/000049.html
[2] - 
https://mail.openjdk.java.net/pipermail/amber-dev/2017-June/001370.html

On 29/04/2022 14:19, Tobias Gierke wrote:
> Hi,
>
> I always feel like it's going to get included in the next JDK release 
> ... and yet it never happens :( Is there a specific reason for that, 
> other than lack resources ?
>
> Thanks,
> Tobias
>

From john.r.rose at oracle.com  Fri Apr 29 20:01:06 2022
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 29 Apr 2022 13:01:06 -0700
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <fddfe208-e58a-6e06-b811-4575651ff919@oracle.com>
 <876194083.862388.1529433658434.JavaMail.zimbra@u-pem.fr>
 <38876efa-0dc7-3ff7-9ae7-04ff647e029a@oracle.com>
 <CAP7YuARru5tjXDpJyf=ybJavRyLQNH+w-Uch+WUogTmN1=BA2Q@mail.gmail.com>
 <CAE=-AhB14OavV+PfiJs0ma4itFyKMpDo59TBceH2dQ98m3dTfQ@mail.gmail.com>
 <41581c0d-871f-3322-ed32-637e376f1b2a@oracle.com>
 <CAE=-AhD+9Foa2gybkOop6+akXaO0AzO5StMZPaFGEKKqp_9kzg@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
 <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
 <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>
 <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>
Message-ID: <C6EFC5DA-7ABC-4496-AF9E-8EC0A7131B10@oracle.com>

On 24 Apr 2022, at 8:31, Brian Goetz wrote:

> So, a feature where field and method literals evaluated only to Method 
> objects is a pretty weak one, and worse, fi the goal is merely to pull 
> the reflection API into the language, is likely to result in requests 
> to pull further.  Though I do enjoy the extra type checking that 
> IntelliJ gives me for method and method handle lookup.)
>
> The reality is that Method is not a very useful type; reflection is an 
> escape hatch, which has more benefit for frameworks than for ordinary 
> user code.  You might say ?but we have class literals?, but this 
> is mostly a ?for consistency? argument*, and one that doesn?t 
> even survive much scrutiny.
>
> Class literals have two aspects that method literals would not: their 
> role in inference (Foo.class has type Class<Foo>, meaning that it can 
> be used as a source of constraints in type inference), and the 
> Object::getClass method.  Method and field literals would have neither 
> of these two touch points.  (If it were not for the type inference 
> aspect, if we didn?t have class literals now, I might not be 
> inclined to add them ? Class::forName works  too.)  So I would rate 
> this a pretty weak feature.
>
> The main reason method references are useful and these are less useful 
> is that methods have behavior, and method refs allow you to access 
> that behavior through the suitable abstraction level (e.g., Function, 
> Supplier.)  Passing around Method or MethodHandle or VarHandle is not 
> particularly desirable for ordinary application code.
>
> There?s a version of method (and field) references that is more 
> interesting, where we can use target typing to let Foo::bar evaluate 
> to a SAM type, Method, MethodHandle, MethodDesc, or other description 
> of a method.  (Note that you also have to pull in additional syntax 
> and behavior to support overload selection, since we don?t have a 
> SAM type to guide the overload selection.)  That?s more interesting, 
> but a more complex feature.  Fields are even more complicated, because 
> fields have TWO behaviors, and the obvious representations (Field, 
> VarHandle) are also pretty low-level and unsuitable to 
> application-level interaction.  (If the language had Properties, then 
> turning a field into a Property would be a more appropriate API-level 
> encoding.)
>
>
> *If the best argument you can make for a feature is ?for 
> consistency?, that?s usually a sign that the feature is weak.
>

This is a very good summary for the public record of the core design 
issues for method (and field) literals.  I think target typing is a 
promising tactic here but there are lots of fiddly details to work out.  
It?s definitely not one of those a ?why don?t you just?? 
suggestions.

I have two minor comments to add:

1. Brian mentions that target-typing to M/MH/MD fails to select 
overloads.  Some of that could be worked around (w/o syntax changes) by 
encouraging users to convert first to a FI object (which contains a 
method signature) and then to the desired M/MH/MD.  That would require 
fiddly rules to ensure that the right answer came out of the cascaded 
conversions, instead of an opaque FI object wrapper, so maybe an overt 
signature annotation syntax would be better on balance.  (The opaque 
wrapper is harmless for MHs but not jlr.Ms or MDs.)

2. Brian mentions that fields have two behaviors.  Actually they can 
have a bundle of many behaviors, including atomics, *when viewed through 
the VH lens*.  And that provides a way to think about those multiple 
behaviors:  Allow a field ref to be target-typed to a VH, and you get 
all the behaviors.  (Similar point for jlr.F and FD.)  I think it would 
be reasonable, for MHs and FIs, to simply return the read behavior and 
ignore the other behaviors.  After all, read is the most important 
operation on a field (and the only one, for a final field).

An aside:  If you really want to have static checking of name strings, 
you can do this today by building a private-static-final constant 
containing the string, as extracted (in the static initializer) from an 
appropriately bugged serializable method reference (maybe using a helper 
function).  Yeah, it?s harder than syntax sugar, but it can be done.

My take on the priority of better method and field literals:  I?m 
generally supportive of such a feature, for ease of use, for better 
type-checking, also for efficiency (ldc/condy), and with the end result 
of making practical more kinds of self-reflecting code (using 
MH/VH/MD/FD as well as good old jlr).  *That said,* it?s definitely an 
expert feature, so it doesn?t deserve a large footprint in the JLS.  
And, it has to be done right (for a range of target types), to justify 
any footprint in the JLS.  A full solution of those goals and 
constraints is yet to be designed, and will require a concerted effort 
at some point.  But, we are working on higher value JLS features these 
days, for everybody (not just framework experts).

I also suspect that a discussion of method and field literals will 
eventually be better informed by a deep consideration of other kinds of 
literals, starting with list/map/set and also validated strings and 
maybe quoted expressions.  (These would benefit all programmers not just 
experts.)  All user-defined literals would surely benefit from target 
typing, so maybe the considerations of TT for M/MH/etc. are just a 
special case of something more general.  So I will speculate that method 
and field literals could possibly end up as a feature that is derived, 
partially or wholly via library logic, from a more fundamental form of 
programmable literal.  (Static checking could be handled by compile-time 
intrinsic execution, for which there also are designs on the back 
burner.)  But, again, we are not ready to put such features at the top 
of the priority queue.

From forax at univ-mlv.fr  Fri Apr 29 20:26:21 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 29 Apr 2022 22:26:21 +0200 (CEST)
Subject: [External] : Re: Method and Field Literals
In-Reply-To: <C6EFC5DA-7ABC-4496-AF9E-8EC0A7131B10@oracle.com>
References: <CAE=-AhAMGcMiszYavG1c74xpc3iLKAYDcdK0TWqGaV+FE+AZKA@mail.gmail.com>
 <CAE=-AhCgMaVt5nqK5Phj9xh9HpGcaKbHep78K1w2rws0O=NMnQ@mail.gmail.com>
 <CA+NR86j7aFMOLH04ydQTLc0QQ-y=_HhrG_EECwNYViD0D+OL_A@mail.gmail.com>
 <CAE=-AhC=7OttjtBBzLOGxfqLfyNP50t7c6f5k-vm2C450FwKXg@mail.gmail.com>
 <CA+NR86haxBMtMaSsyvONAQOEAo5b7vaHctO-y0XmSgKTPJaYJw@mail.gmail.com>
 <CAE=-AhDMNW6KpDyZT4YUsUKmcPFdYMOC_Yrx==3gx1b+raJUoA@mail.gmail.com>
 <CD85934A-DBB6-4027-9AE2-229C65F740EF@oracle.com>
 <C6EFC5DA-7ABC-4496-AF9E-8EC0A7131B10@oracle.com>
Message-ID: <589438193.18710490.1651263981902.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "arjan tijms" <arjan.tijms at gmail.com>, "Ethan McCue" <ethan at mccue.dev>, "Martijn Verburg"
> <martijnverburg at gmail.com>, "discuss" <discuss at openjdk.java.net>
> Sent: Friday, April 29, 2022 10:01:06 PM
> Subject: Re: [External] : Re: Method and Field Literals

> On 24 Apr 2022, at 8:31, Brian Goetz wrote:
> 
>> So, a feature where field and method literals evaluated only to Method
>> objects is a pretty weak one, and worse, fi the goal is merely to pull
>> the reflection API into the language, is likely to result in requests
>> to pull further.  Though I do enjoy the extra type checking that
>> IntelliJ gives me for method and method handle lookup.)
>>
>> The reality is that Method is not a very useful type; reflection is an
>> escape hatch, which has more benefit for frameworks than for ordinary
>> user code.  You might say ?but we have class literals?, but this
>> is mostly a ?for consistency? argument*, and one that doesn?t
>> even survive much scrutiny.
>>
>> Class literals have two aspects that method literals would not: their
>> role in inference (Foo.class has type Class<Foo>, meaning that it can
>> be used as a source of constraints in type inference), and the
>> Object::getClass method.  Method and field literals would have neither
>> of these two touch points.  (If it were not for the type inference
>> aspect, if we didn?t have class literals now, I might not be
>> inclined to add them ? Class::forName works  too.)  So I would rate
>> this a pretty weak feature.
>>
>> The main reason method references are useful and these are less useful
>> is that methods have behavior, and method refs allow you to access
>> that behavior through the suitable abstraction level (e.g., Function,
>> Supplier.)  Passing around Method or MethodHandle or VarHandle is not
>> particularly desirable for ordinary application code.
>>
>> There?s a version of method (and field) references that is more
>> interesting, where we can use target typing to let Foo::bar evaluate
>> to a SAM type, Method, MethodHandle, MethodDesc, or other description
>> of a method.  (Note that you also have to pull in additional syntax
>> and behavior to support overload selection, since we don?t have a
>> SAM type to guide the overload selection.)  That?s more interesting,
>> but a more complex feature.  Fields are even more complicated, because
>> fields have TWO behaviors, and the obvious representations (Field,
>> VarHandle) are also pretty low-level and unsuitable to
>> application-level interaction.  (If the language had Properties, then
>> turning a field into a Property would be a more appropriate API-level
>> encoding.)
>>
>>
>> *If the best argument you can make for a feature is ?for
>> consistency?, that?s usually a sign that the feature is weak.
>>
> 
> This is a very good summary for the public record of the core design
> issues for method (and field) literals.  I think target typing is a
> promising tactic here but there are lots of fiddly details to work out.
> It?s definitely not one of those a ?why don?t you just??
> suggestions.
> 
> I have two minor comments to add:
> 
> 1. Brian mentions that target-typing to M/MH/MD fails to select
> overloads.  Some of that could be worked around (w/o syntax changes) by
> encouraging users to convert first to a FI object (which contains a
> method signature) and then to the desired M/MH/MD.  That would require
> fiddly rules to ensure that the right answer came out of the cascaded
> conversions, instead of an opaque FI object wrapper, so maybe an overt
> signature annotation syntax would be better on balance.  (The opaque
> wrapper is harmless for MHs but not jlr.Ms or MDs.)
> 
> 2. Brian mentions that fields have two behaviors.  Actually they can
> have a bundle of many behaviors, including atomics, *when viewed through
> the VH lens*.  And that provides a way to think about those multiple
> behaviors:  Allow a field ref to be target-typed to a VH, and you get
> all the behaviors.  (Similar point for jlr.F and FD.)  I think it would
> be reasonable, for MHs and FIs, to simply return the read behavior and
> ignore the other behaviors.  After all, read is the most important
> operation on a field (and the only one, for a final field).
> 
> An aside:  If you really want to have static checking of name strings,
> you can do this today by building a private-static-final constant
> containing the string, as extracted (in the static initializer) from an
> appropriately bugged serializable method reference (maybe using a helper
> function).  Yeah, it?s harder than syntax sugar, but it can be done.

see https://github.com/forax/macro/blob/master/src/main/java/com/github/forax/macro/Macro.java#L496
on how to convert a serializable method reference to a SerializedLambda object

and an example showing how to write a builder for any records (with 4 or less components)
using method references.
https://github.com/forax/macro/blob/master/src/main/examples/com/github.forax/macro/example/builder3.java#L156

R?mi

From Monica.Beckwith at microsoft.com  Sat Apr 30 18:21:29 2022
From: Monica.Beckwith at microsoft.com (Monica Beckwith)
Date: Sat, 30 Apr 2022 18:21:29 +0000
Subject: Resigning as ZGC Project Lead
In-Reply-To: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>
References: <d02b6a9a-37a0-8613-ff96-0c9737fbdf71@oracle.com>
Message-ID: <SN6PR2101MB16487C51FCF305A2A8D2591BE5FF9@SN6PR2101MB1648.namprd21.prod.outlook.com>

Thanks @Per Liden<mailto:per.liden at oracle.com> for your leadership in getting ZGC to where it's today.

I wish you the best in your future endeavors. I think ZGC will be in great hands with @Stefan Karlsson<mailto:stefan.karlsson at oracle.com> at the helm!

You have my full support. Thanks both for the great work.

Monica


Sent via a smartphone
Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: discuss <discuss-retn at openjdk.java.net> on behalf of Per Liden <per.liden at oracle.com>
Sent: Thursday, April 28, 2022, 10:15 AM
To: zgc-dev at openjdk.java.net <zgc-dev at openjdk.java.net>; discuss at openjdk.java.net <discuss at openjdk.java.net>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; stefan.karlsson at oracle.com <stefan.karlsson at oracle.com>; per at malloc.se <per at malloc.se>
Subject: Resigning as ZGC Project Lead

I hereby resign as ZGC Project Lead.

It has been a super exciting time for me to drive this project from a
proof-of-concept to a state-of-the-art GC that today powers mission
critical workloads around the world. However, I will be taking a step
back from ZGC development to do other things, and so it feels natural to
hand over the project lead role to someone else.

According to the OpenJDK Bylaws [1], a new Project Lead may be nominated
by the Group Leads of a Project?s Sponsoring Groups. Such a nomination
must be approved by a Three-Vote Consensus of these Group Leads. In this
case, that means Vladimir Kozlov from the HotSpot Group appoints a new
Project Lead. I would personally recommend Stefan Karlsson as new
Project Lead. Stefan has played an invaluable role in this project since
its inception and is a natural successor.

/Per Liden

[1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fbylaws%23project-lead&amp;data=05%7C01%7Cmonica.beckwith%40microsoft.com%7C34ea2fa614234be4a40f08da2929e4df%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637867557155401842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Wl1oJqoW9f24WvPM4zcdMMmVxUXtNcY841oGpoQdMZs%3D&amp;reserved=0