From hufeng1987 at gmail.com  Mon Apr  1 06:00:23 2019
From: hufeng1987 at gmail.com (Netroby)
Date: Mon, 1 Apr 2019 14:00:23 +0800
Subject: Github mirror not sync for 11 days
Message-ID: <CAEZo+gfAuc_3A-3O9aC0jEc7+6d00Dd53NU0v9HNPra2ry=zUw@mail.gmail.com>

Any one know why github mirror not sync for 11 days?
https://github.com/openjdk/jdk
Appreciate your time.
----------------------------
Netroby

From erik.helin at oracle.com  Mon Apr  1 08:11:45 2019
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 1 Apr 2019 10:11:45 +0200
Subject: Github mirror not sync for 11 days
In-Reply-To: <CAEZo+gfAuc_3A-3O9aC0jEc7+6d00Dd53NU0v9HNPra2ry=zUw@mail.gmail.com>
References: <CAEZo+gfAuc_3A-3O9aC0jEc7+6d00Dd53NU0v9HNPra2ry=zUw@mail.gmail.com>
Message-ID: <790293E6-1455-4F74-BB06-98B7BAD4056C@oracle.com>

> On 1 Apr 2019, at 08:00, Netroby <hufeng1987 at gmail.com> wrote:
> 
> Any one know why github mirror not sync for 11 days?

Yes, we are currently applying some fixes to the conversion, we will soon re-enable the live mirroring. Unfortunately many of the hashes in the repository will change due to the fixes, so you will have to re-clone your local repositories. I will send some more information to skara-dev [0] once we re-enable the live mirroring.

Thanks,
Erik

[0]: http://mail.openjdk.java.net/mailman/listinfo/skara-dev

From doko at ubuntu.com  Mon Apr  1 09:38:22 2019
From: doko at ubuntu.com (Matthias Klose)
Date: Mon, 1 Apr 2019 11:38:22 +0200
Subject: build number for a jdk-*-ga tag?
Message-ID: <9e292abe-aaa0-69ba-6a52-683d588f9c32@ubuntu.com>

When preparing packages for Debian/Ubuntu for openjdk-12, I was using versions
derived from the jdk-12+<n> tags (e.g. 12~31, 12~32, ...). Using the tilde
meaning "less than/earlier than 12).  What build number should a build from the
jdk-12-ga get?   Asking because my packaging choose to set the build number to
an empty string, which is accepted by configure, but then later fails the build
because an empty macro is passed instead of an empty string.

For now I choose 12.0.0+0 (build number 0) to mark the final release and
resetting the build number to 0.  So I have 12~32-1 < 12.0.0+0-1 < 12.0.1+1-1.
Maybe not that important as this initial 12 release is usually very short lived.

Matthias


From erik.joelsson at oracle.com  Mon Apr  1 13:30:27 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 1 Apr 2019 06:30:27 -0700
Subject: build number for a jdk-*-ga tag?
In-Reply-To: <9e292abe-aaa0-69ba-6a52-683d588f9c32@ubuntu.com>
References: <9e292abe-aaa0-69ba-6a52-683d588f9c32@ubuntu.com>
Message-ID: <e3e1547c-0f7f-0390-fe0b-a089efd2bf16@oracle.com>

Hello Matthias,

Looking at the tags in the repo, jdk-12-ga points to the same change as 
jdk-12+33, so that would be the build number we released. If you 
download the binaries from http://jdk.java.net/12/, the version string 
reported from those builds also say 33:

$ bin/java -version
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)

/Erik

On 2019-04-01 02:38, Matthias Klose wrote:
> When preparing packages for Debian/Ubuntu for openjdk-12, I was using versions
> derived from the jdk-12+<n> tags (e.g. 12~31, 12~32, ...). Using the tilde
> meaning "less than/earlier than 12).  What build number should a build from the
> jdk-12-ga get?   Asking because my packaging choose to set the build number to
> an empty string, which is accepted by configure, but then later fails the build
> because an empty macro is passed instead of an empty string.
>
> For now I choose 12.0.0+0 (build number 0) to mark the final release and
> resetting the build number to 0.  So I have 12~32-1 < 12.0.0+0-1 < 12.0.1+1-1.
> Maybe not that important as this initial 12 release is usually very short lived.
>
> Matthias
>

From neugens at redhat.com  Mon Apr  1 17:21:59 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 1 Apr 2019 19:21:59 +0200
Subject: RFC: Urgent Rollback
Message-ID: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>

Hello all,

Due to a series of serious issues due to poor quality control and sloppy
development practices, I have an urgent rollback patch to apply, can
someone approve and push please?

https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b

The patch has been tested once on hardware available at the time of the
initial commit and is believed to be working!

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From thomas.stuefe at gmail.com  Mon Apr  1 17:56:38 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 1 Apr 2019 19:56:38 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
Message-ID: <CAA-vtUyRHwQk3V9T_QQ9-02jCnsG3UmFzJyW8GK_5SgyywRA=Q@mail.gmail.com>

Looks fine and trivial. Just push it yourself.

..Thomas

On Mon, Apr 1, 2019 at 7:24 PM Mario Torre <neugens at redhat.com> wrote:

> Hello all,
>
> Due to a series of serious issues due to poor quality control and sloppy
> development practices, I have an urgent rollback patch to apply, can
> someone approve and push please?
>
> https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b
>
> The patch has been tested once on hardware available at the time of the
> initial commit and is believed to be working!
>
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From dalibor.topic at oracle.com  Mon Apr  1 18:06:11 2019
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Mon, 1 Apr 2019 20:06:11 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
Message-ID: <4BBA7CB3-F2DE-482E-94B8-DF45A8476883@oracle.com>

I am afraid that all Reviewers are currently at the famous spaghetti harvest festival in Ticino, so I hope this patch can wait until tomorrow.

Cheers,
Dalibor Topic

?
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment

> On 1. Apr 2019, at 19:21, Mario Torre <neugens at redhat.com> wrote:
> 
> Hello all,
> 
> Due to a series of serious issues due to poor quality control and sloppy
> development practices, I have an urgent rollback patch to apply, can
> someone approve and push please?
> 
> https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b
> 
> The patch has been tested once on hardware available at the time of the
> initial commit and is believed to be working!
> 
> Cheers,
> Mario
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens.limasoftware at gmail.com  Mon Apr  1 18:16:59 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 1 Apr 2019 20:16:59 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <4BBA7CB3-F2DE-482E-94B8-DF45A8476883@oracle.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <4BBA7CB3-F2DE-482E-94B8-DF45A8476883@oracle.com>
Message-ID: <CAGUMyaT+r_Yv-t24kkgCQA5ZnuCkjUrLbUOJPA0ExfnnQLZVuA@mail.gmail.com>

Ah, the Graal Committer Workshop, indeed! :p

I?ll urgently wait then ;)

Cheers,
Mario

On Mon 1. Apr 2019 at 20:06, Dalibor Topic <dalibor.topic at oracle.com> wrote:

> I am afraid that all Reviewers are currently at the famous spaghetti
> harvest festival in Ticino, so I hope this patch can wait until tomorrow.
>
> Cheers,
> Dalibor Topic
>
> ?
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
>
> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg
> <https://maps.google.com/?q=K%C3%BChneh%C3%B6fe+5+%7C+D-22761+Hamburg&entry=gmail&source=g>
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992
> <https://maps.google.com/?q=Riesstr.+25,+D-80992&entry=gmail&source=g>
> M?nchen
> Registergericht: Amtsgericht M?nchen, HRA 95603
>
> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
>
> > On 1. Apr 2019, at 19:21, Mario Torre <neugens at redhat.com> wrote:
> >
> > Hello all,
> >
> > Due to a series of serious issues due to poor quality control and sloppy
> > development practices, I have an urgent rollback patch to apply, can
> > someone approve and push please?
> >
> > https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b
> >
> > The patch has been tested once on hardware available at the time of the
> > initial commit and is believed to be working!
> >
> > Cheers,
> > Mario
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From john.r.rose at oracle.com  Mon Apr  1 18:27:16 2019
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 1 Apr 2019 11:27:16 -0700
Subject: RFC: Urgent Rollback
In-Reply-To: <4BBA7CB3-F2DE-482E-94B8-DF45A8476883@oracle.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <4BBA7CB3-F2DE-482E-94B8-DF45A8476883@oracle.com>
Message-ID: <6705E01F-1F8F-4300-B8AB-190D7F2493C0@oracle.com>

Ah, for the subtle flavor of the first fruits of the spaghetti vines of Ticino!

> On Apr 1, 2019, at 11:06 AM, Dalibor Topic <dalibor.topic at oracle.com> wrote:
> 
> I am afraid that all Reviewers are currently at the famous spaghetti harvest festival in Ticino, so I hope this patch can wait until tomorrow.
> 
> Cheers,
> Dalibor Topic
> 
> ?
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
> <tel:+491737185961>
> 
> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
> Registergericht: Amtsgericht M?nchen, HRA 95603
> 
> Komplement?rin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher
> 
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment
> 
>> On 1. Apr 2019, at 19:21, Mario Torre <neugens at redhat.com> wrote:
>> 
>> Hello all,
>> 
>> Due to a series of serious issues due to poor quality control and sloppy
>> development practices, I have an urgent rollback patch to apply, can
>> someone approve and push please?
>> 
>> https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b
>> 
>> The patch has been tested once on hardware available at the time of the
>> initial commit and is believed to be working!
>> 
>> Cheers,
>> Mario
>> -- 
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From shade at redhat.com  Mon Apr  1 18:51:22 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Apr 2019 20:51:22 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
Message-ID: <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>

On 4/1/19 7:21 PM, Mario Torre wrote:
> The patch has been tested once on hardware available at the time of the
> initial commit and is believed to be working!

But that is irrelevant; please pass jdk-submit before pushing. That would unfortunately require some
simple rebasing to apply to jdk/jdk. On the plus side, it removes a lot of old code, which improves
maintainability. Here is the jdk/jdk changeset:
  http://cr.openjdk.java.net/~shade/20190401/20190401-changeset.xz

$ hg tip
20190401: Revert accidental commit
Summary: Roll back changes accrued since the first broken commit
Reviewed-by: never, gonna, give, you, up

Please request 12u, 11u, 8u and 7u backports immediately to let maintainers know they can stop doing
everything, as it would definitely result in duplicate work on their part.

-- 
Thanks,
-Aleksey


From igor.ignatyev at oracle.com  Mon Apr  1 19:01:05 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 1 Apr 2019 12:01:05 -0700
Subject: RFC: Urgent Rollback
In-Reply-To: <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
Message-ID: <ABF00AA2-C3C6-48A4-9BA2-B32257F3D925@oracle.com>

I'm afraid jdk-submit repo won't be able to test this rollback as the test system has been built on top of the flaws introduced by https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b <https://hg.openjdk.java.net/jdk6/jdk6/rev/d5ea358b429b>. please inform ops at openjdk.java.net <mailto:ops at openjdk.java.net> so the team fixes the test system and unblock you ASAP.

-- Igor

> On Apr 1, 2019, at 11:51 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 4/1/19 7:21 PM, Mario Torre wrote:
>> The patch has been tested once on hardware available at the time of the
>> initial commit and is believed to be working!
> 
> But that is irrelevant; please pass jdk-submit before pushing. That would unfortunately require some
> simple rebasing to apply to jdk/jdk.


From daniel.daugherty at oracle.com  Mon Apr  1 19:03:06 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 1 Apr 2019 15:03:06 -0400
Subject: RFC: Urgent Rollback
In-Reply-To: <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
Message-ID: <66a8d293-7adf-4d21-c57b-47114da2fedb@oracle.com>

On 4/1/19 2:51 PM, Aleksey Shipilev wrote:
> On 4/1/19 7:21 PM, Mario Torre wrote:
>> The patch has been tested once on hardware available at the time of the
>> initial commit and is believed to be working!
> But that is irrelevant; please pass jdk-submit before pushing. That would unfortunately require some
> simple rebasing to apply to jdk/jdk. On the plus side, it removes a lot of old code, which improves
> maintainability. Here is the jdk/jdk changeset:
>    http://cr.openjdk.java.net/~shade/20190401/20190401-changeset.xz
>
> $ hg tip
> 20190401: Revert accidental commit
> Summary: Roll back changes accrued since the first broken commit
> Reviewed-by: never, gonna, give, you, up

Tom R. (OpenJDK user 'never') says he didn't review this push!

Dan


>
> Please request 12u, 11u, 8u and 7u backports immediately to let maintainers know they can stop doing
> everything, as it would definitely result in duplicate work on their part.
>


From shade at redhat.com  Mon Apr  1 19:06:19 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Apr 2019 21:06:19 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <66a8d293-7adf-4d21-c57b-47114da2fedb@oracle.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
 <66a8d293-7adf-4d21-c57b-47114da2fedb@oracle.com>
Message-ID: <88db12ed-2c6f-4627-198b-32b76332ef5f@redhat.com>

On 4/1/19 9:03 PM, Daniel D. Daugherty wrote:
>> $ hg tip
>> 20190401: Revert accidental commit
>> Summary: Roll back changes accrued since the first broken commit
>> Reviewed-by: never, gonna, give, you, up
> 
> Tom R. (OpenJDK user 'never') says he didn't review this push!

But that's what it says: it was never reviewed by Tom.

-Aleksey

From neugens.limasoftware at gmail.com  Mon Apr  1 20:10:39 2019
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 1 Apr 2019 22:10:39 +0200
Subject: RFC: Urgent Rollback
In-Reply-To: <88db12ed-2c6f-4627-198b-32b76332ef5f@redhat.com>
References: <CAJwKKmazJxKn1_159RVCL1oQNcMRm6ScYL1T5CLAMFVTQS=OwQ@mail.gmail.com>
 <88fef205-ac2a-0508-26e5-47c3c44626a8@redhat.com>
 <66a8d293-7adf-4d21-c57b-47114da2fedb@oracle.com>
 <88db12ed-2c6f-4627-198b-32b76332ef5f@redhat.com>
Message-ID: <CAGUMyaRLm+-kWqC3Rk4whooQN73==UnbSCd_=ycWQ8cQttvXkA@mail.gmail.com>

Never reviewed the patch, exactly, what?s the problem? :p

Cheers,
Mario

On Mon 1. Apr 2019 at 21:06, Aleksey Shipilev <shade at redhat.com> wrote:

> On 4/1/19 9:03 PM, Daniel D. Daugherty wrote:
> >> $ hg tip
> >> 20190401: Revert accidental commit
> >> Summary: Roll back changes accrued since the first broken commit
> >> Reviewed-by: never, gonna, give, you, up
> >
> > Tom R. (OpenJDK user 'never') says he didn't review this push!
>
> But that's what it says: it was never reviewed by Tom.
>
> -Aleksey
>
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From nhoward at twitter.com  Tue Apr  2 22:35:26 2019
From: nhoward at twitter.com (Nora Howard)
Date: Tue, 2 Apr 2019 16:35:26 -0600
Subject: JDK-8170910: Avoid 5 second localhost lookup behavior on OSX
Message-ID: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>

On OSX 10.12 or later, when no mDNS services are registered, getaddrinfo
fails on looking up localhost addresses[1]. The jdk?s current
implementation falls back to getifaddrs after getaddrinfo fails[2]. When
getaddrinfo fails in this way, it takes 5 seconds to fail [3]. This means
that calls to InetAddress.getLocalHost() may take up to 5 seconds to run.

I?d like to change the jdk?s behavior in this instance so that instead of
falling back to calling getifaddrs after getaddrinfo fails, it instead
calls getifaddrs first if we?re on OSX and the hostname is localhost?s.

Doing this will eliminate the 5 second delay looking up localhost on
machines with this network setup. When looking up non-localhost addresses,
it?ll add a call to os:gethostname and a comparison.

I?d like to get some feedback about whether this approach sounds
reasonable, and some guidance about next steps. I?ve read the ?how to
contribute? page[4], and the ?code review? guide[5].

I?ve put together a patch that I?ve tested locally by turning off mDNS
services on my local OSX machine and exercising the behavior. I?d like to
submit patches that target dev trunk as well as the jdk 8 and 11 branches.

References

1.

> On a Macintosh running 10.12 or later, if there are no apps that have a
> mDNS services registered (for instance, iTunes) and there are no services
> selected in the Sharing System Preferences, then the getaddrinfo will fail.
>
(https://bugs.openjdk.java.net/browse/JDK-8170910)

2.
http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet6AddressImpl.c#l252
http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet4AddressImpl.c#l132
(The lookupIfLocalhost function checks the passed hostname against
os::get_host_name, and if they match, looks up via getifaddrs.)

3. This comment describes how to reproduce the issue. I?ve reproduced it
locally on jdk 8, 11 and 13 ea.
https://bugs.openjdk.java.net/browse/JDK-8170910?focusedCommentId=14038262&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14038262

4. https://openjdk.java.net/contribute/

5. https://openjdk.java.net/guide/codeReview.html


Thanks,
--
Nora

From david.holmes at oracle.com  Tue Apr  2 22:48:06 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 3 Apr 2019 08:48:06 +1000
Subject: JDK-8170910: Avoid 5 second localhost lookup behavior on OSX
In-Reply-To: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>
References: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>
Message-ID: <eaff8324-8aca-951a-bf8a-06b597b0854a@oracle.com>

Hi Nora,

This sounds like something to be discussed on net-dev at openjdk.java.net.

Thanks,
David

On 3/04/2019 8:35 am, Nora Howard wrote:
> On OSX 10.12 or later, when no mDNS services are registered, getaddrinfo
> fails on looking up localhost addresses[1]. The jdk?s current
> implementation falls back to getifaddrs after getaddrinfo fails[2]. When
> getaddrinfo fails in this way, it takes 5 seconds to fail [3]. This means
> that calls to InetAddress.getLocalHost() may take up to 5 seconds to run.
> 
> I?d like to change the jdk?s behavior in this instance so that instead of
> falling back to calling getifaddrs after getaddrinfo fails, it instead
> calls getifaddrs first if we?re on OSX and the hostname is localhost?s.
> 
> Doing this will eliminate the 5 second delay looking up localhost on
> machines with this network setup. When looking up non-localhost addresses,
> it?ll add a call to os:gethostname and a comparison.
> 
> I?d like to get some feedback about whether this approach sounds
> reasonable, and some guidance about next steps. I?ve read the ?how to
> contribute? page[4], and the ?code review? guide[5].
> 
> I?ve put together a patch that I?ve tested locally by turning off mDNS
> services on my local OSX machine and exercising the behavior. I?d like to
> submit patches that target dev trunk as well as the jdk 8 and 11 branches.
> 
> References
> 
> 1.
> 
>> On a Macintosh running 10.12 or later, if there are no apps that have a
>> mDNS services registered (for instance, iTunes) and there are no services
>> selected in the Sharing System Preferences, then the getaddrinfo will fail.
>>
> (https://bugs.openjdk.java.net/browse/JDK-8170910)
> 
> 2.
> http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet6AddressImpl.c#l252
> http://hg.openjdk.java.net/jdk/jdk/file/cd3b7ad53265/src/java.base/unix/native/libnet/Inet4AddressImpl.c#l132
> (The lookupIfLocalhost function checks the passed hostname against
> os::get_host_name, and if they match, looks up via getifaddrs.)
> 
> 3. This comment describes how to reproduce the issue. I?ve reproduced it
> locally on jdk 8, 11 and 13 ea.
> https://bugs.openjdk.java.net/browse/JDK-8170910?focusedCommentId=14038262&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14038262
> 
> 4. https://openjdk.java.net/contribute/
> 
> 5. https://openjdk.java.net/guide/codeReview.html
> 
> 
> Thanks,
> --
> Nora
> 

From Alan.Bateman at oracle.com  Wed Apr  3 06:33:11 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Apr 2019 07:33:11 +0100
Subject: JDK-8170910: Avoid 5 second localhost lookup behavior on OSX
In-Reply-To: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>
References: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>
Message-ID: <2b5ebfb2-6441-ba0b-d8d7-4a45a4ce555d@oracle.com>

On 02/04/2019 23:35, Nora Howard wrote:
> On OSX 10.12 or later, when no mDNS services are registered, getaddrinfo
> fails on looking up localhost addresses[1]. The jdk?s current
> implementation falls back to getifaddrs after getaddrinfo fails[2]. When
> getaddrinfo fails in this way, it takes 5 seconds to fail [3]. This means
> that calls to InetAddress.getLocalHost() may take up to 5 seconds to run.
>
> I?d like to change the jdk?s behavior in this instance so that instead of
> falling back to calling getifaddrs after getaddrinfo fails, it instead
> calls getifaddrs first if we?re on OSX and the hostname is localhost?s.
>
Can you bring this to net-dev to discussion? You will probably need to 
provide a lot of information on the environment where this occurs and 
also be prepared to do testing on lots of different configurations to 
make sure that there aren't any regressions.

-Alan

From nhoward at twitter.com  Wed Apr  3 16:41:31 2019
From: nhoward at twitter.com (Nora Howard)
Date: Wed, 3 Apr 2019 10:41:31 -0600
Subject: JDK-8170910: Avoid 5 second localhost lookup behavior on OSX
In-Reply-To: <2b5ebfb2-6441-ba0b-d8d7-4a45a4ce555d@oracle.com>
References: <CAKrF-JyyQZyeV1XAA1e-DL3SuvqSrFfDCT4cjBssA67W-ckA5Q@mail.gmail.com>
 <2b5ebfb2-6441-ba0b-d8d7-4a45a4ce555d@oracle.com>
Message-ID: <CAKrF-Jw2=7tAOwhkgXE=EqsKvrbJLseK9FkDpRPmWnWUmQfRLw@mail.gmail.com>

David and Alan, thanks for directing me to move the discussion to net-dev.
I'll do that.

On Wed, Apr 3, 2019 at 12:39 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 02/04/2019 23:35, Nora Howard wrote:
> > On OSX 10.12 or later, when no mDNS services are registered, getaddrinfo
> > fails on looking up localhost addresses[1]. The jdk?s current
> > implementation falls back to getifaddrs after getaddrinfo fails[2]. When
> > getaddrinfo fails in this way, it takes 5 seconds to fail [3]. This means
> > that calls to InetAddress.getLocalHost() may take up to 5 seconds to run.
> >
> > I?d like to change the jdk?s behavior in this instance so that instead of
> > falling back to calling getifaddrs after getaddrinfo fails, it instead
> > calls getifaddrs first if we?re on OSX and the hostname is localhost?s.
> >
> Can you bring this to net-dev to discussion? You will probably need to
> provide a lot of information on the environment where this occurs and
> also be prepared to do testing on lots of different configurations to
> make sure that there aren't any regressions.
>
> -Alan
>


-- 
Nora

From patrick at os.amperecomputing.com  Fri Apr 12 07:24:14 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 12 Apr 2019 07:24:14 +0000
Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError
Message-ID: <BL0PR01MB5044BF173127697B05C6468E8F280@BL0PR01MB5044.prod.exchangelabs.com>

Hi,

Please review this patch.
The problem is that the launcher does a check on the input -Xss and ensure it >=64K for the initial thread, while vm has another function to determine whether the input stack size is big enough to future threads, such as cgc_thread, vm_thread, java_thead etc. However if -Xss0, the initial thread is created with stack size 64K, while others use hotspot/system default sizes, which would trigger StackOverflowError. We could either fine tune the threshold 64K to be a bigger one, or have the initial thread created with system defaults that may be what the user expects. This patch chooses the second solution, to avoid potential side-effect of the first.

This can be reproduced with 10, 11, 12 too, so I cc'ed jdk-updates-dev here.

More details please refer to the ticket.
JBS: https://bugs.openjdk.java.net/browse/JDK-8222334
Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/

Thanks for David's comments in Jira.

Regards
Patrick


From david.holmes at oracle.com  Fri Apr 12 07:42:42 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Apr 2019 17:42:42 +1000
Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError
In-Reply-To: <BL0PR01MB5044BF173127697B05C6468E8F280@BL0PR01MB5044.prod.exchangelabs.com>
References: <BL0PR01MB5044BF173127697B05C6468E8F280@BL0PR01MB5044.prod.exchangelabs.com>
Message-ID: <d912d753-53bd-06b3-b774-28977d524054@oracle.com>

Hi Patrick,

Please takes this to core-libs-dev for review.

Thanks,
David

On 12/04/2019 5:24 pm, Patrick Zhang OS wrote:
> Hi,
> 
> Please review this patch.
> 
> The problem is that the launcher does a check on the input -Xss and 
> ensure it >=64K for the initial thread, while vm has another function to 
> determine whether the input stack size is big enough to future threads, 
> such as cgc_thread, vm_thread, java_thead etc. However if -Xss0, the 
> initial thread is created with stack size 64K, while others use 
> hotspot/system default sizes, which would trigger StackOverflowError. We 
> could either fine tune the threshold 64K to be a bigger one, or have the 
> initial thread created with system defaults that may be what the user 
> expects. This patch chooses the second solution, to avoid potential 
> side-effect of the first.
> 
> This can be reproduced with 10, 11, 12 too, so I cc?ed jdk-updates-dev here.
> 
> More details please refer to the ticket.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8222334
> 
> Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/
> 
> Thanks for David?s comments in Jira.
> 
> Regards
> 
> Patrick
> 

From patrick at os.amperecomputing.com  Fri Apr 12 07:51:09 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 12 Apr 2019 07:51:09 +0000
Subject: RFR: 8222334: java -Xss0 triggers StackOverflowError
In-Reply-To: <d912d753-53bd-06b3-b774-28977d524054@oracle.com>
References: <BL0PR01MB5044BF173127697B05C6468E8F280@BL0PR01MB5044.prod.exchangelabs.com>
 <d912d753-53bd-06b3-b774-28977d524054@oracle.com>
Message-ID: <BL0PR01MB504422525229D36A04DE59258F280@BL0PR01MB5044.prod.exchangelabs.com>

Moved this to core-libs-dev for review, thanks.

Dropped and bcc'ed jdk-dev and jdk-updates-dev.

Regards
Patrick

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Friday, April 12, 2019 3:43 PM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; jdk-dev at openjdk.java.net
Cc: jdk-updates-dev at openjdk.java.net
Subject: Re: RFR: 8222334: java -Xss0 triggers StackOverflowError

Hi Patrick,

Please takes this to core-libs-dev for review.

Thanks,
David

On 12/04/2019 5:24 pm, Patrick Zhang OS wrote:
> Hi,
> 
> Please review this patch.
> 
> The problem is that the launcher does a check on the input -Xss and 
> ensure it >=64K for the initial thread, while vm has another function 
> to determine whether the input stack size is big enough to future 
> threads, such as cgc_thread, vm_thread, java_thead etc. However if 
> -Xss0, the initial thread is created with stack size 64K, while others 
> use hotspot/system default sizes, which would trigger 
> StackOverflowError. We could either fine tune the threshold 64K to be 
> a bigger one, or have the initial thread created with system defaults 
> that may be what the user expects. This patch chooses the second 
> solution, to avoid potential side-effect of the first.
> 
> This can be reproduced with 10, 11, 12 too, so I cc'ed jdk-updates-dev here.
> 
> More details please refer to the ticket.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8222334
> 
> Webrev: http://cr.openjdk.java.net/~qpzhang/8222334/webrev.01/
> 
> Thanks for David's comments in Jira.
> 
> Regards
> 
> Patrick
> 

From michael at michaelpollmeier.com  Tue Apr 16 02:14:46 2019
From: michael at michaelpollmeier.com (Michael Pollmeier)
Date: Tue, 16 Apr 2019 14:14:46 +1200
Subject: SoftReference incorrect javadoc?
Message-ID: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>

Quoting
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html


> All soft references to softly-reachable objects are guaranteed to have
been cleared before the virtual machine throws an OutOfMemoryError

That statement was true when soft references were first introduced in
java 1.2, but from java 1.3.1 the jvm property
`-XX:SoftRefLRUPolicyMSPerMB` was introduced.
It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
available heap, the garbage collector will free references that have
been used more than 10s ago. I.e. everything else (including young
softly reachable objects) will *not* be freed, leading to an
OutOfMemoryError, contradicting the above quoted 'guarantee'.

That's also the behaviour I observed on various JREs. Would you agree,
i.e. should I propose an updated doc?

Cheers
Michael


From david.holmes at oracle.com  Tue Apr 16 02:19:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Apr 2019 12:19:41 +1000
Subject: SoftReference incorrect javadoc?
In-Reply-To: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
Message-ID: <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>

Hi Michael,

Re-directing to core-libs-dev and hotspot-gc-dev.

Thanks,
David

On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
> Quoting
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
> 
> 
>> All soft references to softly-reachable objects are guaranteed to have
> been cleared before the virtual machine throws an OutOfMemoryError
> 
> That statement was true when soft references were first introduced in
> java 1.2, but from java 1.3.1 the jvm property
> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
> available heap, the garbage collector will free references that have
> been used more than 10s ago. I.e. everything else (including young
> softly reachable objects) will *not* be freed, leading to an
> OutOfMemoryError, contradicting the above quoted 'guarantee'.
> 
> That's also the behaviour I observed on various JREs. Would you agree,
> i.e. should I propose an updated doc?
> 
> Cheers
> Michael
> 

From per.liden at oracle.com  Tue Apr 16 06:27:15 2019
From: per.liden at oracle.com (Per Liden)
Date: Tue, 16 Apr 2019 08:27:15 +0200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
Message-ID: <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>

Hi Michael,

On 4/16/19 4:19 AM, David Holmes wrote:
> Hi Michael,
> 
> Re-directing to core-libs-dev and hotspot-gc-dev.
> 
> Thanks,
> David
> 
> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>> Quoting
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html 
>>
>>
>>
>>> All soft references to softly-reachable objects are guaranteed to have
>> been cleared before the virtual machine throws an OutOfMemoryError
>>
>> That statement was true when soft references were first introduced in
>> java 1.2, but from java 1.3.1 the jvm property
>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.

That statement is still true. When the GC gets into a situation where it 
is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB 
will be ignored and all soft references will be cleared, before the GC 
gives up and throws an OOME.

>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>> available heap, the garbage collector will free references that have
>> been used more than 10s ago. I.e. everything else (including young
>> softly reachable objects) will *not* be freed, leading to an
>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>
>> That's also the behaviour I observed on various JREs. Would you agree,
>> i.e. should I propose an updated doc?

Could you elaborate on what kind of test you did to come to this 
conclusion? Preferably provide a re-producer. In OOME situations, if a 
SoftReference isn't cleared, it is typically because you have 
unknowingly made it strongly reachable.

cheers,
Per

From shade at redhat.com  Tue Apr 16 11:58:20 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Apr 2019 13:58:20 +0200
Subject: JDK-8184205 -- accidentally confidential?
Message-ID: <d03a60ed-e5be-2863-a978-da8b6314b25f@redhat.com>

This bug is confidential:
  https://bugs.openjdk.java.net/browse/JDK-8184205

Yet the changeset does not imply any problem?
  http://hg.openjdk.java.net/jdk/jdk/rev/1a395165c09b

Can anyone from Oracle take a look, and hopefully make the bug public?

-- 
Thanks,
-Aleksey



From dalibor.topic at oracle.com  Tue Apr 16 12:00:45 2019
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 16 Apr 2019 14:00:45 +0200
Subject: Release notes for each version of Java 11?
In-Reply-To: <ff1700ef-9338-433a-4b18-59d7afbb7bf2@gmail.com>
References: <ff1700ef-9338-433a-4b18-59d7afbb7bf2@gmail.com>
Message-ID: <3420df7d-68b3-ca5e-948d-957d7cfe1237@oracle.com>

Hi,

a forthcoming Code Tools subproject should be able to let you provide 
your own variants of release notes easily. See 
https://mail.openjdk.java.net/pipermail/code-tools-dev/2019-April/000527.html 
for details.

cheers,
dalibor topic

On 19.03.2019 10:44, Jaikiran Pai wrote:
> Right now the Java 11 release notes page[1] shows the release notes for
> the latest update release of Java 11. Is there a place where the release
> notes of previous releases of Java 11 can be found at? I looked at the
> archive page[2] but that just has links to binaries and checksums but
> not release notes. Maybe this archive page should include a link for
> release notes of each released version?
> 
> 
> [1] https://jdk.java.net/11/release-notes
> 
> [2] https://jdk.java.net/archive/
> 
> -Jaikiran
> 

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | D-22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment

From jonathan.gibbons at oracle.com  Tue Apr 16 20:55:43 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 16 Apr 2019 13:55:43 -0700
Subject: JDK-8184205 -- accidentally confidential?
In-Reply-To: <d03a60ed-e5be-2863-a978-da8b6314b25f@redhat.com>
References: <d03a60ed-e5be-2863-a978-da8b6314b25f@redhat.com>
Message-ID: <683d40ce-7049-1687-1630-bedc3fc5859c@oracle.com>

Aleksey,

This situation can sometimes arise when some parts of the JBS entry 
contain Oracle-internal information.

-- Jon

On 4/16/19 4:58 AM, Aleksey Shipilev wrote:
> This bug is confidential:
>    https://bugs.openjdk.java.net/browse/JDK-8184205
>
> Yet the changeset does not imply any problem?
>    http://hg.openjdk.java.net/jdk/jdk/rev/1a395165c09b
>
> Can anyone from Oracle take a look, and hopefully make the bug public?
>

From michael at michaelpollmeier.com  Wed Apr 17 01:59:09 2019
From: michael at michaelpollmeier.com (Michael Pollmeier)
Date: Wed, 17 Apr 2019 13:59:09 +1200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
Message-ID: <b0236bcc-310b-496e-dc73-8fab0a25ffac@michaelpollmeier.com>

Hi Per,

While testing different JVMs I realized that it's fixed in openjdk 11,
e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
That's great to know, but is it worth updating the javadocs of older
versions?

To reproduce it I attached a simple SoftRefTest.java to easily reproduce
it. It allocates (only) softly referenced objects that occupy some heap,
occasionally printing counts (instantiated, finalized, free heap).

Usage:
javac SoftRefTest.java
java -Xms256m -Xmx256m SoftRefTest

Output:
100000 instances created; free=212M
200000 instances created; free=181M
300000 instances created; free=152M
400000 instances created; free=121M
500000 instances created; free=93M
600000 instances created; free=61M
700000 instances created; free=33M
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at Instance.<init>(SoftRefTest.java:27)
        at SoftRefTest.main(SoftRefTest.java:12)

Interpretation:
It doesn't free any of the only softly referenced objects, resulting in
an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.

Workaround: if you additionally configure
`-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
of memory.

Tested with:
openjdk version "1.8.0_212"
java version "1.8.0_144" (oracle)
openjdk version "9.0.4.1" (zulu build)
openjdk version "10.0.2" 2018-07-17  (zulu build)

Cheers
Michael


On 16/04/19 6:27 pm, Per Liden wrote:
> Hi Michael,
> 
> On 4/16/19 4:19 AM, David Holmes wrote:
>> Hi Michael,
>>
>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>
>> Thanks,
>> David
>>
>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>> Quoting
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>>
>>>
>>>
>>>> All soft references to softly-reachable objects are guaranteed to have
>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>
>>> That statement was true when soft references were first introduced in
>>> java 1.2, but from java 1.3.1 the jvm property
>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
> 
> That statement is still true. When the GC gets into a situation where it
> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
> will be ignored and all soft references will be cleared, before the GC
> gives up and throws an OOME.
> 
>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>> available heap, the garbage collector will free references that have
>>> been used more than 10s ago. I.e. everything else (including young
>>> softly reachable objects) will *not* be freed, leading to an
>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>
>>> That's also the behaviour I observed on various JREs. Would you agree,
>>> i.e. should I propose an updated doc?
> 
> Could you elaborate on what kind of test you did to come to this
> conclusion? Preferably provide a re-producer. In OOME situations, if a
> SoftReference isn't cleared, it is typically because you have
> unknowingly made it strongly reachable.
> 
> cheers,
> Per
> 

From alex.buckley at oracle.com  Wed Apr 17 02:00:16 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 16 Apr 2019 19:00:16 -0700
Subject: Call for feedback -- switch expressions in JDK 12
Message-ID: <5CB688B0.7030502@oracle.com>

An easy way to help move Java forward is to try out new features on real 
code and share your experiences. We're asking for feedback on how you 
use switch expressions, the new language feature in JDK 12:

   int numLetters = switch (day) {
       case MONDAY, FRIDAY, SUNDAY -> 6;
       case TUESDAY                -> 7;
       case THURSDAY, SATURDAY     -> 8;
       case WEDNESDAY              -> 9;
   };

   // Multiple labels per case (also allowed in switch statements)
   // No fallthrough with the -> form (also allowed in switch statements)

Do you find switch expressions useful? Is anything surprising? Did you 
turn any switch statements into switch expressions? Please let us know 
on this list, even if the answer is "Tried it. Works fine."

To enable switch expressions in your environment:
- IntelliJ IDEA 2019.1 
https://blog.jetbrains.com/idea/2019/02/java-12-and-intellij-idea/
- Eclipse 4.11  https://www.eclipse.org/eclipse/news/4.11/jdt.php#Java12
- Apache NetBeans 11.0 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091452
- jshell in JDK 12  run with `--enable-preview`
- javac in JDK 12  run with `--release 12 --enable-preview`

Alex

From hufeng1987 at gmail.com  Wed Apr 17 03:24:49 2019
From: hufeng1987 at gmail.com (Netroby)
Date: Wed, 17 Apr 2019 11:24:49 +0800
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <5CB688B0.7030502@oracle.com>
References: <5CB688B0.7030502@oracle.com>
Message-ID: <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>

   int numLetters = switch (day) {
       case MONDAY, FRIDAY, SUNDAY -> 6,
       case TUESDAY                -> 7,
       case THURSDAY, SATURDAY     -> 8,
       case WEDNESDAY              -> 9,
       _ -> 0,
   };

Should we using  comma , instead of ;

comma , means these cases the same switch.

Another point, should we have an default match pattern ? using _ or default


idea from rust match
```rust
fn main() {
    let number = 13;
    // TODO ^ Try different values for `number`

    println!("Tell me about {}", number);
    match number {
        // Match a single value
        1 => println!("One!"),
        // Match several values
        2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
        // Match an inclusive range
        13...19 => println!("A teen"),
        // Handle the rest of cases
        _ => println!("Ain't special"),
    }

    let boolean = true;
    // Match is an expression too
    let binary = match boolean {
        // The arms of a match must cover all the possible values
        false => 0,
        true => 1,
        // TODO ^ Try commenting out one of these arms
    };

    println!("{} -> {}", boolean, binary);
}

```

Appreciate your time.
----------------------------
Netroby

Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00???
>
> An easy way to help move Java forward is to try out new features on real
> code and share your experiences. We're asking for feedback on how you
> use switch expressions, the new language feature in JDK 12:
>
>    int numLetters = switch (day) {
>        case MONDAY, FRIDAY, SUNDAY -> 6;
>        case TUESDAY                -> 7;
>        case THURSDAY, SATURDAY     -> 8;
>        case WEDNESDAY              -> 9;
>    };
>
>    // Multiple labels per case (also allowed in switch statements)
>    // No fallthrough with the -> form (also allowed in switch statements)
>
> Do you find switch expressions useful? Is anything surprising? Did you
> turn any switch statements into switch expressions? Please let us know
> on this list, even if the answer is "Tried it. Works fine."
>
> To enable switch expressions in your environment:
> - IntelliJ IDEA 2019.1
> https://blog.jetbrains.com/idea/2019/02/java-12-and-intellij-idea/
> - Eclipse 4.11  https://www.eclipse.org/eclipse/news/4.11/jdt.php#Java12
> - Apache NetBeans 11.0
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091452
> - jshell in JDK 12  run with `--enable-preview`
> - javac in JDK 12  run with `--release 12 --enable-preview`
>
> Alex

From michael at michaelpollmeier.com  Wed Apr 17 03:54:43 2019
From: michael at michaelpollmeier.com (Michael Pollmeier)
Date: Wed, 17 Apr 2019 15:54:43 +1200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <E1hGZsY-00047x-R6@mailfront10.runbox.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <E1hGZsY-00047x-R6@mailfront10.runbox.com>
Message-ID: <2e3a0b1b-d051-28fe-4d09-f4e5a0d2a637@michaelpollmeier.com>

Looks like the mailing list removed the attachment. It's short enough to
be in the email body.

SoftRefTest.java:
```
import java.lang.ref.SoftReference;
import java.util.ArrayList;

public class SoftRefTest {
  static final int count = 2000000;

  public static void main(String[] args) throws Exception {
    ArrayList<SoftReference<Instance>> instances = new ArrayList<>();
    long start = System.currentTimeMillis();

    for (int i = 0; i<count; i++) {
      instances.add(new SoftReference<>(new Instance()));

      if (i % 100000 == 0 && i > 0) {
        Thread.sleep(100); // give GC time to breathe
        System.out.println(i + " instances created; free=" +
Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
      }
    }

    System.out.println("time taken: " + (System.currentTimeMillis() -
start));
  }

}

class Instance {
  static int finalizedCount = 0;
  String[] occupySomeHeap = new String[50];

  @Override
  protected void finalize() throws Throwable {
    super.finalize();
    finalizedCount++;
    if (finalizedCount % 100000 == 0) {
      System.out.println(finalizedCount + " instances finalized");
    }
  }
}
```

On 17/04/19 1:59 pm, Michael Pollmeier wrote:
> Hi Per,
> 
> While testing different JVMs I realized that it's fixed in openjdk 11,
> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
> That's great to know, but is it worth updating the javadocs of older
> versions?
> 
> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
> it. It allocates (only) softly referenced objects that occupy some heap,
> occasionally printing counts (instantiated, finalized, free heap).
> 
> Usage:
> javac SoftRefTest.java
> java -Xms256m -Xmx256m SoftRefTest
> 
> Output:
> 100000 instances created; free=212M
> 200000 instances created; free=181M
> 300000 instances created; free=152M
> 400000 instances created; free=121M
> 500000 instances created; free=93M
> 600000 instances created; free=61M
> 700000 instances created; free=33M
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>         at Instance.<init>(SoftRefTest.java:27)
>         at SoftRefTest.main(SoftRefTest.java:12)
> 
> Interpretation:
> It doesn't free any of the only softly referenced objects, resulting in
> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
> 
> Workaround: if you additionally configure
> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
> of memory.
> 
> Tested with:
> openjdk version "1.8.0_212"
> java version "1.8.0_144" (oracle)
> openjdk version "9.0.4.1" (zulu build)
> openjdk version "10.0.2" 2018-07-17  (zulu build)
> 
> Cheers
> Michael
> 
> 
> On 16/04/19 6:27 pm, Per Liden wrote:
>> Hi Michael,
>>
>> On 4/16/19 4:19 AM, David Holmes wrote:
>>> Hi Michael,
>>>
>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>
>>> Thanks,
>>> David
>>>
>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>> Quoting
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>>>
>>>>
>>>>
>>>>> All soft references to softly-reachable objects are guaranteed to have
>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>
>>>> That statement was true when soft references were first introduced in
>>>> java 1.2, but from java 1.3.1 the jvm property
>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>
>> That statement is still true. When the GC gets into a situation where it
>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>> will be ignored and all soft references will be cleared, before the GC
>> gives up and throws an OOME.
>>
>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>> available heap, the garbage collector will free references that have
>>>> been used more than 10s ago. I.e. everything else (including young
>>>> softly reachable objects) will *not* be freed, leading to an
>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>
>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>> i.e. should I propose an updated doc?
>>
>> Could you elaborate on what kind of test you did to come to this
>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>> SoftReference isn't cleared, it is typically because you have
>> unknowingly made it strongly reachable.
>>
>> cheers,
>> Per
>>
> 


From michael at michaelpollmeier.com  Wed Apr 17 04:38:19 2019
From: michael at michaelpollmeier.com (Michael Pollmeier)
Date: Wed, 17 Apr 2019 16:38:19 +1200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <DB7PR08MB3307CC61C5E8DC70410A17E7FF250@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <E1hGZsY-00047x-R6@mailfront10.runbox.com>
 <2e3a0b1b-d051-28fe-4d09-f4e5a0d2a637@michaelpollmeier.com>
 <DB7PR08MB3307CC61C5E8DC70410A17E7FF250@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <82c31a07-670a-9085-5413-1b3ce06808b5@michaelpollmeier.com>

You're right, without overriding `finalized` it does free softly
referenced objects. That's still a bug IMO in JRE <11, but more nuanced
than what I first assumed.

So we probably don't need to worry about it any further. Good to know
and have it documented here.

Many thanks
Michael

On 17/04/19 4:01 pm, Bernd Eckenfels wrote:
> Your test code does not fail because of the SoftRef but because of the
> Finalizer I think. But it?s good to know that 11 handles this better.
> 
> -- 
> https://Bernd.eckenfels.net
> ?
> ------------------------------------------------------------------------
> *Von:* Michael Pollmeier <michael at michaelpollmeier.com>
> *Gesendet:* Mittwoch, April 17, 2019 5:54 AM
> *An:* jdk-dev at openjdk.java.net
> *Cc:* ecki at zusammenkunft.net
> *Betreff:* Re: SoftReference incorrect javadoc?
> ?
> Looks like the mailing list removed the attachment. It's short enough to
> be in the email body.
> 
> SoftRefTest.java:
> ```
> import java.lang.ref.SoftReference;
> import java.util.ArrayList;
> 
> public class SoftRefTest {
> static final int count = 2000000;
> 
> public static void main(String[] args) throws Exception {
> ArrayList<SoftReference<Instance>> instances = new ArrayList<>();
> long start = System.currentTimeMillis();
> 
> for (int i = 0; i<count; i++) {
> instances.add(new SoftReference<>(new Instance()));
> 
> if (i % 100000 == 0 && i > 0) {
> Thread.sleep(100); // give GC time to breathe
> System.out.println(i + " instances created; free=" +
> Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
> }
> }
> 
> System.out.println("time taken: " + (System.currentTimeMillis() -
> start));
> }
> 
> }
> 
> class Instance {
> static int finalizedCount = 0;
> String[] occupySomeHeap = new String[50];
> 
> @Override
> protected void finalize() throws Throwable {
> super.finalize();
> finalizedCount++;
> if (finalizedCount % 100000 == 0) {
> System.out.println(finalizedCount + " instances finalized");
> }
> }
> }
> ```
> 
> On 17/04/19 1:59 pm, Michael Pollmeier wrote:
>> Hi Per,
>>
>> While testing different JVMs I realized that it's fixed in openjdk 11,
>> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
>> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
>> That's great to know, but is it worth updating the javadocs of older
>> versions?
>>
>> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
>> it. It allocates (only) softly referenced objects that occupy some heap,
>> occasionally printing counts (instantiated, finalized, free heap).
>>
>> Usage:
>> javac SoftRefTest.java
>> java -Xms256m -Xmx256m SoftRefTest
>>
>> Output:
>> 100000 instances created; free=212M
>> 200000 instances created; free=181M
>> 300000 instances created; free=152M
>> 400000 instances created; free=121M
>> 500000 instances created; free=93M
>> 600000 instances created; free=61M
>> 700000 instances created; free=33M
>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>> at Instance.<init>(SoftRefTest.java:27)
>> at SoftRefTest.main(SoftRefTest.java:12)
>>
>> Interpretation:
>> It doesn't free any of the only softly referenced objects, resulting in
>> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
>>
>> Workaround: if you additionally configure
>> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
>> of memory.
>>
>> Tested with:
>> openjdk version "1.8.0_212"
>> java version "1.8.0_144" (oracle)
>> openjdk version "9.0.4.1" (zulu build)
>> openjdk version "10.0.2" 2018-07-17 (zulu build)
>>
>> Cheers
>> Michael
>>
>>
>> On 16/04/19 6:27 pm, Per Liden wrote:
>>> Hi Michael,
>>>
>>> On 4/16/19 4:19 AM, David Holmes wrote:
>>>> Hi Michael,
>>>>
>>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>>> Quoting
>>>>>
> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
> 
>>>>>
>>>>>
>>>>>
>>>>>> All soft references to softly-reachable objects are guaranteed to
> have
>>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>>
>>>>> That statement was true when soft references were first introduced in
>>>>> java 1.2, but from java 1.3.1 the jvm property
>>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>>
>>> That statement is still true. When the GC gets into a situation where it
>>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>>> will be ignored and all soft references will be cleared, before the GC
>>> gives up and throws an OOME.
>>>
>>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>>> available heap, the garbage collector will free references that have
>>>>> been used more than 10s ago. I.e. everything else (including young
>>>>> softly reachable objects) will *not* be freed, leading to an
>>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>>
>>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>>> i.e. should I propose an updated doc?
>>>
>>> Could you elaborate on what kind of test you did to come to this
>>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>>> SoftReference isn't cleared, it is typically because you have
>>> unknowingly made it strongly reachable.
>>>
>>> cheers,
>>> Per
>>>
>>
> 


From per.liden at oracle.com  Wed Apr 17 10:22:53 2019
From: per.liden at oracle.com (Per Liden)
Date: Wed, 17 Apr 2019 12:22:53 +0200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <b0236bcc-310b-496e-dc73-8fab0a25ffac@michaelpollmeier.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <b0236bcc-310b-496e-dc73-8fab0a25ffac@michaelpollmeier.com>
Message-ID: <dc402238-bb30-4412-e196-2e72409f1b97@oracle.com>

Hi Michael,

On 04/17/2019 03:59 AM, Michael Pollmeier wrote:
> Hi Per,
> 
> While testing different JVMs I realized that it's fixed in openjdk 11,
> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5

That bug only affected ZGC (which was introduced in 11), so it didn't 
change the behavior of any other GC.

> That's great to know, but is it worth updating the javadocs of older
> versions?
> 
> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
> it. It allocates (only) softly referenced objects that occupy some heap,
> occasionally printing counts (instantiated, finalized, free heap).

Thanks for the test. The problem with the test is that you have a 
finalize() function on Instance. This means the object will be kept 
around until it has been finalized. So even if the SoftReference 
referring to it is cleared, the memory will not be freed until the 
object also has been finalized. In your test, you're simply creating too 
many objects, and the Finalizer thread is simply unable to keep up 
finalizing them at the same pace as they are created, so the heap fills up.

I adjusted your test a bit, and removed the use of finalize(). You can 
run this test forever without running into OOMEs. By having the same 
thread that creates the objects also poll the reference queue, the test 
will automatically be throttled. If SoftReferences weren't cleared as 
they should, this test would OOME pretty fast.

import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
import java.util.HashMap;

public class SoftRefTest2 {
   public static void main(String[] args) throws Exception {
     final ReferenceQueue<Instance> queue = new ReferenceQueue<>();
     final HashMap<Object, SoftReference<Instance>> instances = new 
HashMap<>();
     long createdCount = 0;
     long clearedCount = 0;

     for (;;) {
       SoftReference<Instance> softref = new SoftReference<Instance>(new 
Instance(), queue);
       instances.put(softref, softref);
       if (++createdCount % 100000 == 0) {
         System.out.println(createdCount + " instances created; free=" + 
Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
       }

       // Drain queue
       Reference<?> ref;
       while ((ref = queue.poll()) != null) {
           instances.remove(ref);
           if (++clearedCount % 100000 == 0) {
               System.out.println(clearedCount + " instances cleared");
           }
       }
     }
   }

   static class Instance {
     static int finalizedCount = 0;
     String[] occupySomeHeap = new String[50];
   }
}


cheers,
Per

> 
> Usage:
> javac SoftRefTest.java
> java -Xms256m -Xmx256m SoftRefTest
> 
> Output:
> 100000 instances created; free=212M
> 200000 instances created; free=181M
> 300000 instances created; free=152M
> 400000 instances created; free=121M
> 500000 instances created; free=93M
> 600000 instances created; free=61M
> 700000 instances created; free=33M
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>          at Instance.<init>(SoftRefTest.java:27)
>          at SoftRefTest.main(SoftRefTest.java:12)
> 
> Interpretation:
> It doesn't free any of the only softly referenced objects, resulting in
> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
> 
> Workaround: if you additionally configure
> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
> of memory.
> 
> Tested with:
> openjdk version "1.8.0_212"
> java version "1.8.0_144" (oracle)
> openjdk version "9.0.4.1" (zulu build)
> openjdk version "10.0.2" 2018-07-17  (zulu build)
> 
> Cheers
> Michael
> 
> 
> On 16/04/19 6:27 pm, Per Liden wrote:
>> Hi Michael,
>>
>> On 4/16/19 4:19 AM, David Holmes wrote:
>>> Hi Michael,
>>>
>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>
>>> Thanks,
>>> David
>>>
>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>> Quoting
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>>>
>>>>
>>>>
>>>>> All soft references to softly-reachable objects are guaranteed to have
>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>
>>>> That statement was true when soft references were first introduced in
>>>> java 1.2, but from java 1.3.1 the jvm property
>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>
>> That statement is still true. When the GC gets into a situation where it
>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>> will be ignored and all soft references will be cleared, before the GC
>> gives up and throws an OOME.
>>
>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>> available heap, the garbage collector will free references that have
>>>> been used more than 10s ago. I.e. everything else (including young
>>>> softly reachable objects) will *not* be freed, leading to an
>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>
>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>> i.e. should I propose an updated doc?
>>
>> Could you elaborate on what kind of test you did to come to this
>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>> SoftReference isn't cleared, it is typically because you have
>> unknowingly made it strongly reachable.
>>
>> cheers,
>> Per
>>

From ecki at zusammenkunft.net  Wed Apr 17 04:01:33 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 17 Apr 2019 04:01:33 +0000
Subject: SoftReference incorrect javadoc?
In-Reply-To: <2e3a0b1b-d051-28fe-4d09-f4e5a0d2a637@michaelpollmeier.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <E1hGZsY-00047x-R6@mailfront10.runbox.com>,
 <2e3a0b1b-d051-28fe-4d09-f4e5a0d2a637@michaelpollmeier.com>
Message-ID: <DB7PR08MB3307CC61C5E8DC70410A17E7FF250@DB7PR08MB3307.eurprd08.prod.outlook.com>

Your test code does not fail because of the SoftRef but because of the Finalizer I think. But it?s good to know that 11 handles this better.

--
https://Bernd.eckenfels.net

________________________________
Von: Michael Pollmeier <michael at michaelpollmeier.com>
Gesendet: Mittwoch, April 17, 2019 5:54 AM
An: jdk-dev at openjdk.java.net
Cc: ecki at zusammenkunft.net
Betreff: Re: SoftReference incorrect javadoc?

Looks like the mailing list removed the attachment. It's short enough to
be in the email body.

SoftRefTest.java:
```
import java.lang.ref.SoftReference;
import java.util.ArrayList;

public class SoftRefTest {
static final int count = 2000000;

public static void main(String[] args) throws Exception {
ArrayList<SoftReference<Instance>> instances = new ArrayList<>();
long start = System.currentTimeMillis();

for (int i = 0; i<count; i++) {
instances.add(new SoftReference<>(new Instance()));

if (i % 100000 == 0 && i > 0) {
Thread.sleep(100); // give GC time to breathe
System.out.println(i + " instances created; free=" +
Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
}
}

System.out.println("time taken: " + (System.currentTimeMillis() -
start));
}

}

class Instance {
static int finalizedCount = 0;
String[] occupySomeHeap = new String[50];

@Override
protected void finalize() throws Throwable {
super.finalize();
finalizedCount++;
if (finalizedCount % 100000 == 0) {
System.out.println(finalizedCount + " instances finalized");
}
}
}
```

On 17/04/19 1:59 pm, Michael Pollmeier wrote:
> Hi Per,
>
> While testing different JVMs I realized that it's fixed in openjdk 11,
> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
> That's great to know, but is it worth updating the javadocs of older
> versions?
>
> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
> it. It allocates (only) softly referenced objects that occupy some heap,
> occasionally printing counts (instantiated, finalized, free heap).
>
> Usage:
> javac SoftRefTest.java
> java -Xms256m -Xmx256m SoftRefTest
>
> Output:
> 100000 instances created; free=212M
> 200000 instances created; free=181M
> 300000 instances created; free=152M
> 400000 instances created; free=121M
> 500000 instances created; free=93M
> 600000 instances created; free=61M
> 700000 instances created; free=33M
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at Instance.<init>(SoftRefTest.java:27)
> at SoftRefTest.main(SoftRefTest.java:12)
>
> Interpretation:
> It doesn't free any of the only softly referenced objects, resulting in
> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
>
> Workaround: if you additionally configure
> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
> of memory.
>
> Tested with:
> openjdk version "1.8.0_212"
> java version "1.8.0_144" (oracle)
> openjdk version "9.0.4.1" (zulu build)
> openjdk version "10.0.2" 2018-07-17 (zulu build)
>
> Cheers
> Michael
>
>
> On 16/04/19 6:27 pm, Per Liden wrote:
>> Hi Michael,
>>
>> On 4/16/19 4:19 AM, David Holmes wrote:
>>> Hi Michael,
>>>
>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>
>>> Thanks,
>>> David
>>>
>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>> Quoting
>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>>>
>>>>
>>>>
>>>>> All soft references to softly-reachable objects are guaranteed to have
>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>
>>>> That statement was true when soft references were first introduced in
>>>> java 1.2, but from java 1.3.1 the jvm property
>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>
>> That statement is still true. When the GC gets into a situation where it
>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>> will be ignored and all soft references will be cleared, before the GC
>> gives up and throws an OOME.
>>
>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>> available heap, the garbage collector will free references that have
>>>> been used more than 10s ago. I.e. everything else (including young
>>>> softly reachable objects) will *not* be freed, leading to an
>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>
>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>> i.e. should I propose an updated doc?
>>
>> Could you elaborate on what kind of test you did to come to this
>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>> SoftReference isn't cleared, it is typically because you have
>> unknowingly made it strongly reachable.
>>
>> cheers,
>> Per
>>
>


From alex.buckley at oracle.com  Wed Apr 17 17:52:29 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 17 Apr 2019 10:52:29 -0700
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
Message-ID: <5CB767DD.3050503@oracle.com>

The feedback we're looking for is "I tried switch expressions in my code 
and observed ...". For example:

https://mail.openjdk.java.net/pipermail/amber-dev/2019-March/004199.html

If anyone is blogging about their experience with switch expressions, 
feel free to share the URL here. For example, here's a great writeup of 
using switch expressions in lambdas:

http://minborgsjavapot.blogspot.com/2019/03/java-12-mapping-with-switch-expressions.html

Alex

On 4/16/2019 8:24 PM, Netroby wrote:
>     int numLetters = switch (day) {
>         case MONDAY, FRIDAY, SUNDAY -> 6,
>         case TUESDAY                -> 7,
>         case THURSDAY, SATURDAY     -> 8,
>         case WEDNESDAY              -> 9,
>         _ -> 0,
>     };
>
> Should we using  comma , instead of ;
>
> comma , means these cases the same switch.
>
> Another point, should we have an default match pattern ? using _ or default
>
>
> idea from rust match
> ```rust
> fn main() {
>      let number = 13;
>      // TODO ^ Try different values for `number`
>
>      println!("Tell me about {}", number);
>      match number {
>          // Match a single value
>          1 => println!("One!"),
>          // Match several values
>          2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
>          // Match an inclusive range
>          13...19 => println!("A teen"),
>          // Handle the rest of cases
>          _ => println!("Ain't special"),
>      }
>
>      let boolean = true;
>      // Match is an expression too
>      let binary = match boolean {
>          // The arms of a match must cover all the possible values
>          false => 0,
>          true => 1,
>          // TODO ^ Try commenting out one of these arms
>      };
>
>      println!("{} -> {}", boolean, binary);
> }
>
> ```
>
> Appreciate your time.
> ----------------------------
> Netroby
>
> Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00???
>>
>> An easy way to help move Java forward is to try out new features on real
>> code and share your experiences. We're asking for feedback on how you
>> use switch expressions, the new language feature in JDK 12:
>>
>>     int numLetters = switch (day) {
>>         case MONDAY, FRIDAY, SUNDAY -> 6;
>>         case TUESDAY                -> 7;
>>         case THURSDAY, SATURDAY     -> 8;
>>         case WEDNESDAY              -> 9;
>>     };
>>
>>     // Multiple labels per case (also allowed in switch statements)
>>     // No fallthrough with the -> form (also allowed in switch statements)
>>
>> Do you find switch expressions useful? Is anything surprising? Did you
>> turn any switch statements into switch expressions? Please let us know
>> on this list, even if the answer is "Tried it. Works fine."
>>
>> To enable switch expressions in your environment:
>> - IntelliJ IDEA 2019.1
>> https://blog.jetbrains.com/idea/2019/02/java-12-and-intellij-idea/
>> - Eclipse 4.11  https://www.eclipse.org/eclipse/news/4.11/jdt.php#Java12
>> - Apache NetBeans 11.0
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103091452
>> - jshell in JDK 12  run with `--enable-preview`
>> - javac in JDK 12  run with `--release 12 --enable-preview`
>>
>> Alex

From per.liden at oracle.com  Wed Apr 17 18:12:41 2019
From: per.liden at oracle.com (Per Liden)
Date: Wed, 17 Apr 2019 20:12:41 +0200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <82c31a07-670a-9085-5413-1b3ce06808b5@michaelpollmeier.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <E1hGZsY-00047x-R6@mailfront10.runbox.com>
 <2e3a0b1b-d051-28fe-4d09-f4e5a0d2a637@michaelpollmeier.com>
 <DB7PR08MB3307CC61C5E8DC70410A17E7FF250@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <82c31a07-670a-9085-5413-1b3ce06808b5@michaelpollmeier.com>
Message-ID: <ad6848b2-ebc4-3992-9359-00ba39c3b43c@oracle.com>

On 04/17/2019 06:38 AM, Michael Pollmeier wrote:
> You're right, without overriding `finalized` it does free softly
> referenced objects. That's still a bug IMO in JRE <11, but more nuanced
> than what I first assumed.

Whether the VM clears a SoftReference or not is unrelated to whether the 
referent has a finalize method. However, a finalize method affects when 
the memory can be reclaimed.

This behavior is the same across all JDK versions, there's nothing 
special about 11 here.

cheers,
Per

> 
> So we probably don't need to worry about it any further. Good to know
> and have it documented here.
> 
> Many thanks
> Michael
> 
> On 17/04/19 4:01 pm, Bernd Eckenfels wrote:
>> Your test code does not fail because of the SoftRef but because of the
>> Finalizer I think. But it?s good to know that 11 handles this better.
>>
>> -- 
>> https://Bernd.eckenfels.net
>>   
>> ------------------------------------------------------------------------
>> *Von:* Michael Pollmeier <michael at michaelpollmeier.com>
>> *Gesendet:* Mittwoch, April 17, 2019 5:54 AM
>> *An:* jdk-dev at openjdk.java.net
>> *Cc:* ecki at zusammenkunft.net
>> *Betreff:* Re: SoftReference incorrect javadoc?
>>   
>> Looks like the mailing list removed the attachment. It's short enough to
>> be in the email body.
>>
>> SoftRefTest.java:
>> ```
>> import java.lang.ref.SoftReference;
>> import java.util.ArrayList;
>>
>> public class SoftRefTest {
>> static final int count = 2000000;
>>
>> public static void main(String[] args) throws Exception {
>> ArrayList<SoftReference<Instance>> instances = new ArrayList<>();
>> long start = System.currentTimeMillis();
>>
>> for (int i = 0; i<count; i++) {
>> instances.add(new SoftReference<>(new Instance()));
>>
>> if (i % 100000 == 0 && i > 0) {
>> Thread.sleep(100); // give GC time to breathe
>> System.out.println(i + " instances created; free=" +
>> Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
>> }
>> }
>>
>> System.out.println("time taken: " + (System.currentTimeMillis() -
>> start));
>> }
>>
>> }
>>
>> class Instance {
>> static int finalizedCount = 0;
>> String[] occupySomeHeap = new String[50];
>>
>> @Override
>> protected void finalize() throws Throwable {
>> super.finalize();
>> finalizedCount++;
>> if (finalizedCount % 100000 == 0) {
>> System.out.println(finalizedCount + " instances finalized");
>> }
>> }
>> }
>> ```
>>
>> On 17/04/19 1:59 pm, Michael Pollmeier wrote:
>>> Hi Per,
>>>
>>> While testing different JVMs I realized that it's fixed in openjdk 11,
>>> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
>>> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
>>> That's great to know, but is it worth updating the javadocs of older
>>> versions?
>>>
>>> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
>>> it. It allocates (only) softly referenced objects that occupy some heap,
>>> occasionally printing counts (instantiated, finalized, free heap).
>>>
>>> Usage:
>>> javac SoftRefTest.java
>>> java -Xms256m -Xmx256m SoftRefTest
>>>
>>> Output:
>>> 100000 instances created; free=212M
>>> 200000 instances created; free=181M
>>> 300000 instances created; free=152M
>>> 400000 instances created; free=121M
>>> 500000 instances created; free=93M
>>> 600000 instances created; free=61M
>>> 700000 instances created; free=33M
>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>> at Instance.<init>(SoftRefTest.java:27)
>>> at SoftRefTest.main(SoftRefTest.java:12)
>>>
>>> Interpretation:
>>> It doesn't free any of the only softly referenced objects, resulting in
>>> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
>>>
>>> Workaround: if you additionally configure
>>> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
>>> of memory.
>>>
>>> Tested with:
>>> openjdk version "1.8.0_212"
>>> java version "1.8.0_144" (oracle)
>>> openjdk version "9.0.4.1" (zulu build)
>>> openjdk version "10.0.2" 2018-07-17 (zulu build)
>>>
>>> Cheers
>>> Michael
>>>
>>>
>>> On 16/04/19 6:27 pm, Per Liden wrote:
>>>> Hi Michael,
>>>>
>>>> On 4/16/19 4:19 AM, David Holmes wrote:
>>>>> Hi Michael,
>>>>>
>>>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>>>> Quoting
>>>>>>
>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> All soft references to softly-reachable objects are guaranteed to
>> have
>>>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>>>
>>>>>> That statement was true when soft references were first introduced in
>>>>>> java 1.2, but from java 1.3.1 the jvm property
>>>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>>>
>>>> That statement is still true. When the GC gets into a situation where it
>>>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>>>> will be ignored and all soft references will be cleared, before the GC
>>>> gives up and throws an OOME.
>>>>
>>>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>>>> available heap, the garbage collector will free references that have
>>>>>> been used more than 10s ago. I.e. everything else (including young
>>>>>> softly reachable objects) will *not* be freed, leading to an
>>>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>>>
>>>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>>>> i.e. should I propose an updated doc?
>>>>
>>>> Could you elaborate on what kind of test you did to come to this
>>>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>>>> SoftReference isn't cleared, it is typically because you have
>>>> unknowingly made it strongly reachable.
>>>>
>>>> cheers,
>>>> Per
>>>>
>>>
>>
> 

From michael at michaelpollmeier.com  Wed Apr 17 21:19:34 2019
From: michael at michaelpollmeier.com (Michael Pollmeier)
Date: Thu, 18 Apr 2019 09:19:34 +1200
Subject: SoftReference incorrect javadoc?
In-Reply-To: <dc402238-bb30-4412-e196-2e72409f1b97@oracle.com>
References: <ece6c3a2-7a9f-8296-118f-4a4c7e3b65a2@michaelpollmeier.com>
 <3f29d05c-ee18-ed77-6bda-7f6a76fec587@oracle.com>
 <99718e43-ad0b-ee70-bdfd-fdea85218288@oracle.com>
 <b0236bcc-310b-496e-dc73-8fab0a25ffac@michaelpollmeier.com>
 <dc402238-bb30-4412-e196-2e72409f1b97@oracle.com>
Message-ID: <d914daba-298f-0cda-cd0b-76c8c7a678bd@michaelpollmeier.com>

Thanks Per, your detailed insights make sense.

On 17/04/19 10:22 pm, Per Liden wrote:
> Hi Michael,
> 
> On 04/17/2019 03:59 AM, Michael Pollmeier wrote:
>> Hi Per,
>>
>> While testing different JVMs I realized that it's fixed in openjdk 11,
>> e.g. openjdk version "11.0.1" 2018-10-16 LTS (zulu build), maybe by this
>> commit: https://hg.openjdk.java.net/jdk/jdk/rev/6464882498b5
> 
> That bug only affected ZGC (which was introduced in 11), so it didn't
> change the behavior of any other GC.
> 
>> That's great to know, but is it worth updating the javadocs of older
>> versions?
>>
>> To reproduce it I attached a simple SoftRefTest.java to easily reproduce
>> it. It allocates (only) softly referenced objects that occupy some heap,
>> occasionally printing counts (instantiated, finalized, free heap).
> 
> Thanks for the test. The problem with the test is that you have a
> finalize() function on Instance. This means the object will be kept
> around until it has been finalized. So even if the SoftReference
> referring to it is cleared, the memory will not be freed until the
> object also has been finalized. In your test, you're simply creating too
> many objects, and the Finalizer thread is simply unable to keep up
> finalizing them at the same pace as they are created, so the heap fills up.
> 
> I adjusted your test a bit, and removed the use of finalize(). You can
> run this test forever without running into OOMEs. By having the same
> thread that creates the objects also poll the reference queue, the test
> will automatically be throttled. If SoftReferences weren't cleared as
> they should, this test would OOME pretty fast.
> 
> import java.lang.ref.Reference;
> import java.lang.ref.ReferenceQueue;
> import java.lang.ref.SoftReference;
> import java.util.HashMap;
> 
> public class SoftRefTest2 {
> ? public static void main(String[] args) throws Exception {
> ??? final ReferenceQueue<Instance> queue = new ReferenceQueue<>();
> ??? final HashMap<Object, SoftReference<Instance>> instances = new
> HashMap<>();
> ??? long createdCount = 0;
> ??? long clearedCount = 0;
> 
> ??? for (;;) {
> ????? SoftReference<Instance> softref = new SoftReference<Instance>(new
> Instance(), queue);
> ????? instances.put(softref, softref);
> ????? if (++createdCount % 100000 == 0) {
> ??????? System.out.println(createdCount + " instances created; free=" +
> Runtime.getRuntime().freeMemory() / 1024 / 1024 + "M");
> ????? }
> 
> ????? // Drain queue
> ????? Reference<?> ref;
> ????? while ((ref = queue.poll()) != null) {
> ????????? instances.remove(ref);
> ????????? if (++clearedCount % 100000 == 0) {
> ????????????? System.out.println(clearedCount + " instances cleared");
> ????????? }
> ????? }
> ??? }
> ? }
> 
> ? static class Instance {
> ??? static int finalizedCount = 0;
> ??? String[] occupySomeHeap = new String[50];
> ? }
> }
> 
> 
> cheers,
> Per
> 
>>
>> Usage:
>> javac SoftRefTest.java
>> java -Xms256m -Xmx256m SoftRefTest
>>
>> Output:
>> 100000 instances created; free=212M
>> 200000 instances created; free=181M
>> 300000 instances created; free=152M
>> 400000 instances created; free=121M
>> 500000 instances created; free=93M
>> 600000 instances created; free=61M
>> 700000 instances created; free=33M
>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>> ???????? at Instance.<init>(SoftRefTest.java:27)
>> ???????? at SoftRefTest.main(SoftRefTest.java:12)
>>
>> Interpretation:
>> It doesn't free any of the only softly referenced objects, resulting in
>> an OutOfMemoryError, contradicting the 'guarantee' in the javadoc.
>>
>> Workaround: if you additionally configure
>> `-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
>> of memory.
>>
>> Tested with:
>> openjdk version "1.8.0_212"
>> java version "1.8.0_144" (oracle)
>> openjdk version "9.0.4.1" (zulu build)
>> openjdk version "10.0.2" 2018-07-17? (zulu build)
>>
>> Cheers
>> Michael
>>
>>
>> On 16/04/19 6:27 pm, Per Liden wrote:
>>> Hi Michael,
>>>
>>> On 4/16/19 4:19 AM, David Holmes wrote:
>>>> Hi Michael,
>>>>
>>>> Re-directing to core-libs-dev and hotspot-gc-dev.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
>>>>> Quoting
>>>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> All soft references to softly-reachable objects are guaranteed to
>>>>>> have
>>>>> been cleared before the virtual machine throws an OutOfMemoryError
>>>>>
>>>>> That statement was true when soft references were first introduced in
>>>>> java 1.2, but from java 1.3.1 the jvm property
>>>>> `-XX:SoftRefLRUPolicyMSPerMB` was introduced.
>>>
>>> That statement is still true. When the GC gets into a situation where it
>>> is having trouble satisfying an allocation, then SoftRefLRUPolicyMSPerMB
>>> will be ignored and all soft references will be cleared, before the GC
>>> gives up and throws an OOME.
>>>
>>>>> It defaults to 1000 (milliseconds), meaning that if there?s only 10MB
>>>>> available heap, the garbage collector will free references that have
>>>>> been used more than 10s ago. I.e. everything else (including young
>>>>> softly reachable objects) will *not* be freed, leading to an
>>>>> OutOfMemoryError, contradicting the above quoted 'guarantee'.
>>>>>
>>>>> That's also the behaviour I observed on various JREs. Would you agree,
>>>>> i.e. should I propose an updated doc?
>>>
>>> Could you elaborate on what kind of test you did to come to this
>>> conclusion? Preferably provide a re-producer. In OOME situations, if a
>>> SoftReference isn't cleared, it is typically because you have
>>> unknowingly made it strongly reachable.
>>>
>>> cheers,
>>> Per
>>>
> 


From manoj.palat at in.ibm.com  Wed Apr 17 23:50:34 2019
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Thu, 18 Apr 2019 05:20:34 +0530
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <5CB767DD.3050503@oracle.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
Message-ID: <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>


Hi Alex,
Please find our feedback from Eclipse Java Dev.

   1)	For the break expression part we would be happy to have the
      ?overloading? of break replaced by something else ? since this is
      already in the cards, no additional comment on this part.

   2)	Thanks to Remi Forax raising a bug in ecj [
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=545716] and the
      following discussions, we believe that there could be a bug [in spec,
      javac as well as ecj] ? see this comment from Stephan Herrmann
      https://bugs.eclipse.org/bugs/show_bug.cgi?id=545716#c16 specifically
      for the findings. [@Alex: I am taking the liberty of pointing to the
      bug link rather than summarizing here since you have mentioned that a
      blog pointer should also be fine]

   Regards,

   Manoj

   Eclipse Java Dev, IBM




From:	Alex Buckley <alex.buckley at oracle.com>
To:	jdk-dev at openjdk.java.net
Date:	04/17/2019 11:23 PM
Subject:	Re: Call for feedback -- switch expressions in JDK 12
Sent by:	"jdk-dev" <jdk-dev-bounces at openjdk.java.net>



The feedback we're looking for is "I tried switch expressions in my code
and observed ...". For example:

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_amber-2Ddev_2019-2DMarch_004199.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=9at0fZB0bQpeEPI5L2IWbMSlUqcdgEsfF5944Rfjaxo&e=


If anyone is blogging about their experience with switch expressions,
feel free to share the URL here. For example, here's a great writeup of
using switch expressions in lambdas:

https://urldefense.proofpoint.com/v2/url?u=http-3A__minborgsjavapot.blogspot.com_2019_03_java-2D12-2Dmapping-2Dwith-2Dswitch-2Dexpressions.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=JE0ESlf3gLQJ5-QzuOU1uR_xMLngiysxuz0o948ZlW4&e=


Alex

On 4/16/2019 8:24 PM, Netroby wrote:
>     int numLetters = switch (day) {
>         case MONDAY, FRIDAY, SUNDAY -> 6,
>         case TUESDAY                -> 7,
>         case THURSDAY, SATURDAY     -> 8,
>         case WEDNESDAY              -> 9,
>         _ -> 0,
>     };
>
> Should we using  comma , instead of ;
>
> comma , means these cases the same switch.
>
> Another point, should we have an default match pattern ? using _ or
default
>
>
> idea from rust match
> ```rust
> fn main() {
>      let number = 13;
>      // TODO ^ Try different values for `number`
>
>      println!("Tell me about {}", number);
>      match number {
>          // Match a single value
>          1 => println!("One!"),
>          // Match several values
>          2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
>          // Match an inclusive range
>          13...19 => println!("A teen"),
>          // Handle the rest of cases
>          _ => println!("Ain't special"),
>      }
>
>      let boolean = true;
>      // Match is an expression too
>      let binary = match boolean {
>          // The arms of a match must cover all the possible values
>          false => 0,
>          true => 1,
>          // TODO ^ Try commenting out one of these arms
>      };
>
>      println!("{} -> {}", boolean, binary);
> }
>
> ```
>
> Appreciate your time.
> ----------------------------
> Netroby
>
> Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00?
??
>>
>> An easy way to help move Java forward is to try out new features on real
>> code and share your experiences. We're asking for feedback on how you
>> use switch expressions, the new language feature in JDK 12:
>>
>>     int numLetters = switch (day) {
>>         case MONDAY, FRIDAY, SUNDAY -> 6;
>>         case TUESDAY                -> 7;
>>         case THURSDAY, SATURDAY     -> 8;
>>         case WEDNESDAY              -> 9;
>>     };
>>
>>     // Multiple labels per case (also allowed in switch statements)
>>     // No fallthrough with the -> form (also allowed in switch
statements)
>>
>> Do you find switch expressions useful? Is anything surprising? Did you
>> turn any switch statements into switch expressions? Please let us know
>> on this list, even if the answer is "Tried it. Works fine."
>>
>> To enable switch expressions in your environment:
>> - IntelliJ IDEA 2019.1
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.jetbrains.com_idea_2019_02_java-2D12-2Dand-2Dintellij-2Didea_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=-WsqDARpX60gLIBem_6IqycbQFRWL5bzkTNGVV322aU&e=

>> - Eclipse 4.11
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_eclipse_news_4.11_jdt.php-23Java12&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=zClnCpCg04gt1vZS1Zz8j64uam6ZkpnGMVe4M5kCYd0&e=

>> - Apache NetBeans 11.0
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D103091452&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=5RLv6qs5qiU3r9dJ8KjnT4aPKRyz8hxXvNN0w5Z6x94&e=

>> - jshell in JDK 12  run with `--enable-preview`
>> - javac in JDK 12  run with `--release 12 --enable-preview`
>>
>> Alex




From stanislav.smirnov at oracle.com  Tue Apr 23 17:15:42 2019
From: stanislav.smirnov at oracle.com (Stanislav Smirnov)
Date: Tue, 23 Apr 2019 13:15:42 -0400
Subject: jdk-submit maintenance April 26 - 28, 2019
Message-ID: <E29779F8-F8D9-4785-B272-F589915C8AD1@oracle.com>

Hello,

A planned maintenance will happen this weekend, April 26 - 28.
jdk-submit builds will not be available starting 10 am PDT Friday April 26.

The system should be back online by 10 am PDT Monday April 29.

Best regards,
Stanislav Smirnov

From jbvernee at xs4all.nl  Wed Apr 24 17:07:45 2019
From: jbvernee at xs4all.nl (Jorn Vernee)
Date: Wed, 24 Apr 2019 19:07:45 +0200
Subject: Building hsdis on Windows & porting to Capstone
Message-ID: <60f8ac1380087daaf9e9973a8e135f4d@xs4all.nl>

Hi,

I have been keeping an eye on the following hsdis related issues:

port "hsdis" plugin to Capstone library 
(https://bugs.openjdk.java.net/browse/JDK-8188073)
Include hsdis in the JDK 
(https://bugs.openjdk.java.net/browse/JDK-8209784)
hsdis should build OOTB on Windows 
(https://bugs.openjdk.java.net/browse/JDK-8208495)

Being on Windows, I've previously always used a binary distribution of 
hsdis, but lately have been trying to figure out how to build it myself.

The current problem with the makefile included with the hsdis sources, 
is that it uses gcc as a compiler on Windows, and this is required to 
build binutils which is part of the build process, but then tries to 
pass MSVC flags to gcc, which doesn't work obviously. After translating 
the flags to gcc compatible ones, and adding zlib as a dependency as 
well, I can build hsdis on Windows using cygwin's gcc, but then we have 
a dependency on the cygwin runtime, which can't be linked statically 
(bleh). Compiling with mingw gcc doesn't work either, since some part of 
binutils depends on fcntl.h, which is not available with mingw gcc.

Another interesting idea is to have the OpenJDK build system build 
hsdis, as per JDK-8209784, but the problem is that binutils requires gcc 
as a compiler, which is not supported by the OpenJDK build system on all 
platforms (e.g. Windows). So building hsdis based on binutils using the 
OpenJDK build system doesn't seem like a good option.

That seems to be where JDK-8188073 comes in. By dropping the binutils 
dependency, and switching to Capstone, which is a much smaller/simpler 
library, we can support building on Windows as well. Capstone can very 
easily be built using cmake and supports MSVC as well. I don't know how 
much discussion there has been on this topic already, but porting to 
Capstone seems to provide a nice answer to the other 2 problems.

I have a prototype of that working on Windows: 
http://cr.openjdk.java.net/~jvernee/capstone2/webrev.02/

I'd like to contribute this if possible. But, there's probably still a 
few things that need to happen before that. I have some questions;

- What should the licensing of the new sources be? hsdis is under UPL 
currently, so that's what I've copied for the prototype as well, but not 
sure it's correct.
- Should the building of capstone itself be included in the OpenJDK 
build system as well (i.e. clone the repo + run cmake), or is it better 
to have users do that separately?

Thanks,
Jorn

From mark.reinhold at oracle.com  Thu Apr 25 21:26:13 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Apr 2019 14:26:13 -0700 (PDT)
Subject: JEP proposed to target JDK 13: 350: Dynamic CDS Archives
Message-ID: <20190425212613.B336F28837B@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 13:

  350: Dynamic CDS Archives
       https://openjdk.java.net/jeps/350

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:00 UTC on Thursday, 2 May, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 13.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From mark.reinhold at oracle.com  Thu Apr 25 21:26:24 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 25 Apr 2019 14:26:24 -0700 (PDT)
Subject: JEP proposed to target JDK 13: 351: ZGC: Uncommit Unused Memory
Message-ID: <20190425212624.9B25F28837D@eggemoggin.niobe.net>

The following JEP is proposed to target JDK 13:

  351: ZGC: Uncommit Unused Memory
       https://openjdk.java.net/jeps/351

Feedback on this proposal from JDK Project Committers and Reviewers [1]
is more than welcome, as are reasoned objections.  If no such objections
are raised by 23:00 UTC on Thursday, 2 May, or if they?re raised and
then satisfactorily answered, then per the JEP 2.0 process proposal [2]
I?ll target this JEP to JDK 13.

- Mark


[1] https://openjdk.java.net/census#jdk
[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

From manoj.palat at in.ibm.com  Fri Apr 26 04:28:22 2019
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Fri, 26 Apr 2019 09:58:22 +0530
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
Message-ID: <OF48BF43BD.DF94DB46-ON652583E8.00181AD0-652583E8.001891FE@notes.na.collabserv.com>


Hi,
 One more item in the feedback list:

We understand that the "->" in switch expressions lends itself to future
pattern matching constructs, but is there a real need for "->" to be there
in switch statements as well other than the convenience factor of avoiding
break ( or rather making the break implicit)  in switch statements?

Regards,
Manoj



From:	"Manoj Palat" <manoj.palat at in.ibm.com>
To:	"Alex Buckley" <alex.buckley at oracle.com>
Cc:	Stephan Herrmann <stephan.herrmann at berlin.de>,
            jdk-dev at openjdk.java.net
Date:	04/19/2019 03:28 AM
Subject:	Re: Call for feedback -- switch expressions in JDK 12
Sent by:	"jdk-dev" <jdk-dev-bounces at openjdk.java.net>




Hi Alex,
Please find our feedback from Eclipse Java Dev.

   1)		 For the break expression part we would be happy to have the
      ?overloading? of break replaced by something else ? since this is
      already in the cards, no additional comment on this part.

   2)		 Thanks to Remi Forax raising a bug in ecj [

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=bTz3kPNJIWSaFf9MBqxF1ZKUwUHxpH0AJkS2Noth9O0&e=
] and the
      following discussions, we believe that there could be a bug [in spec,
      javac as well as ecj] ? see this comment from Stephan Herrmann

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716-23c16&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=lp0V33xF-hHx6PbOuSpmziGYZGad42PPROmWzFvu8xQ&e=
 specifically
      for the findings. [@Alex: I am taking the liberty of pointing to the
      bug link rather than summarizing here since you have mentioned that a
      blog pointer should also be fine]

   Regards,

   Manoj

   Eclipse Java Dev, IBM




From:		 Alex Buckley <alex.buckley at oracle.com>
To:		 jdk-dev at openjdk.java.net
Date:		 04/17/2019 11:23 PM
Subject:		 Re: Call for feedback -- switch expressions in JDK 12
Sent by:		 "jdk-dev" <jdk-dev-bounces at openjdk.java.net>



The feedback we're looking for is "I tried switch expressions in my code
and observed ...". For example:

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_amber-2Ddev_2019-2DMarch_004199.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=9at0fZB0bQpeEPI5L2IWbMSlUqcdgEsfF5944Rfjaxo&e=



If anyone is blogging about their experience with switch expressions,
feel free to share the URL here. For example, here's a great writeup of
using switch expressions in lambdas:

https://urldefense.proofpoint.com/v2/url?u=http-3A__minborgsjavapot.blogspot.com_2019_03_java-2D12-2Dmapping-2Dwith-2Dswitch-2Dexpressions.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=JE0ESlf3gLQJ5-QzuOU1uR_xMLngiysxuz0o948ZlW4&e=



Alex

On 4/16/2019 8:24 PM, Netroby wrote:
>     int numLetters = switch (day) {
>         case MONDAY, FRIDAY, SUNDAY -> 6,
>         case TUESDAY                -> 7,
>         case THURSDAY, SATURDAY     -> 8,
>         case WEDNESDAY              -> 9,
>         _ -> 0,
>     };
>
> Should we using  comma , instead of ;
>
> comma , means these cases the same switch.
>
> Another point, should we have an default match pattern ? using _ or
default
>
>
> idea from rust match
> ```rust
> fn main() {
>      let number = 13;
>      // TODO ^ Try different values for `number`
>
>      println!("Tell me about {}", number);
>      match number {
>          // Match a single value
>          1 => println!("One!"),
>          // Match several values
>          2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
>          // Match an inclusive range
>          13...19 => println!("A teen"),
>          // Handle the rest of cases
>          _ => println!("Ain't special"),
>      }
>
>      let boolean = true;
>      // Match is an expression too
>      let binary = match boolean {
>          // The arms of a match must cover all the possible values
>          false => 0,
>          true => 1,
>          // TODO ^ Try commenting out one of these arms
>      };
>
>      println!("{} -> {}", boolean, binary);
> }
>
> ```
>
> Appreciate your time.
> ----------------------------
> Netroby
>
> Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00?
??
>>
>> An easy way to help move Java forward is to try out new features on real
>> code and share your experiences. We're asking for feedback on how you
>> use switch expressions, the new language feature in JDK 12:
>>
>>     int numLetters = switch (day) {
>>         case MONDAY, FRIDAY, SUNDAY -> 6;
>>         case TUESDAY                -> 7;
>>         case THURSDAY, SATURDAY     -> 8;
>>         case WEDNESDAY              -> 9;
>>     };
>>
>>     // Multiple labels per case (also allowed in switch statements)
>>     // No fallthrough with the -> form (also allowed in switch
statements)
>>
>> Do you find switch expressions useful? Is anything surprising? Did you
>> turn any switch statements into switch expressions? Please let us know
>> on this list, even if the answer is "Tried it. Works fine."
>>
>> To enable switch expressions in your environment:
>> - IntelliJ IDEA 2019.1
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.jetbrains.com_idea_2019_02_java-2D12-2Dand-2Dintellij-2Didea_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=-WsqDARpX60gLIBem_6IqycbQFRWL5bzkTNGVV322aU&e=


>> - Eclipse 4.11
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_eclipse_news_4.11_jdt.php-23Java12&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=zClnCpCg04gt1vZS1Zz8j64uam6ZkpnGMVe4M5kCYd0&e=


>> - Apache NetBeans 11.0
>>
https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D103091452&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=5RLv6qs5qiU3r9dJ8KjnT4aPKRyz8hxXvNN0w5Z6x94&e=


>> - jshell in JDK 12  run with `--enable-preview`
>> - javac in JDK 12  run with `--release 12 --enable-preview`
>>
>> Alex







From brian.goetz at oracle.com  Sat Apr 27 22:56:06 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 27 Apr 2019 18:56:06 -0400
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <OF48BF43BD.DF94DB46-ON652583E8.00181AD0-652583E8.001891FE@notes.na.collabserv.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
 <OF48BF43BD.DF94DB46-ON652583E8.00181AD0-652583E8.001891FE@notes.na.collabserv.com>
Message-ID: <9472AED5-6D2A-4817-BE27-3D73FA9E6EA2@oracle.com>

I?m not sure whether you?re asking about the specific overloading of -> (some people find it disturbing that both switch and lambda use the same punctuation; others see a switch as a sort of ?function by parts? and the arrow makes sense to them), or about why there was a need to have a shorthand form at all.  

We surely could have done this:

     case A: break-with 1;
     case B: break-with 2; 
    ?

And that might have been a reasonable idea, though people seem to have such an allergy to ?break? in switch that the convenience factor was significant.


> One more item in the feedback list:
> 
> We understand that the "->" in switch expressions lends itself to future
> pattern matching constructs, but is there a real need for "->" to be there
> in switch statements as well other than the convenience factor of avoiding
> break ( or rather making the break implicit)  in switch statements?
> 
> Regards,
> Manoj
> 
> 
> 
> From:	"Manoj Palat" <manoj.palat at in.ibm.com>
> To:	"Alex Buckley" <alex.buckley at oracle.com>
> Cc:	Stephan Herrmann <stephan.herrmann at berlin.de>,
>            jdk-dev at openjdk.java.net
> Date:	04/19/2019 03:28 AM
> Subject:	Re: Call for feedback -- switch expressions in JDK 12
> Sent by:	"jdk-dev" <jdk-dev-bounces at openjdk.java.net>
> 
> 
> 
> 
> Hi Alex,
> Please find our feedback from Eclipse Java Dev.
> 
>   1)		 For the break expression part we would be happy to have the
>      ?overloading? of break replaced by something else ? since this is
>      already in the cards, no additional comment on this part.
> 
>   2)		 Thanks to Remi Forax raising a bug in ecj [
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=bTz3kPNJIWSaFf9MBqxF1ZKUwUHxpH0AJkS2Noth9O0&e=
> ] and the
>      following discussions, we believe that there could be a bug [in spec,
>      javac as well as ecj] ? see this comment from Stephan Herrmann
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716-23c16&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=lp0V33xF-hHx6PbOuSpmziGYZGad42PPROmWzFvu8xQ&e=
> specifically
>      for the findings. [@Alex: I am taking the liberty of pointing to the
>      bug link rather than summarizing here since you have mentioned that a
>      blog pointer should also be fine]
> 
>   Regards,
> 
>   Manoj
> 
>   Eclipse Java Dev, IBM
> 
> 
> 
> 
> From:		 Alex Buckley <alex.buckley at oracle.com>
> To:		 jdk-dev at openjdk.java.net
> Date:		 04/17/2019 11:23 PM
> Subject:		 Re: Call for feedback -- switch expressions in JDK 12
> Sent by:		 "jdk-dev" <jdk-dev-bounces at openjdk.java.net>
> 
> 
> 
> The feedback we're looking for is "I tried switch expressions in my code
> and observed ...". For example:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_amber-2Ddev_2019-2DMarch_004199.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=9at0fZB0bQpeEPI5L2IWbMSlUqcdgEsfF5944Rfjaxo&e=
> 
> 
> 
> If anyone is blogging about their experience with switch expressions,
> feel free to share the URL here. For example, here's a great writeup of
> using switch expressions in lambdas:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__minborgsjavapot.blogspot.com_2019_03_java-2D12-2Dmapping-2Dwith-2Dswitch-2Dexpressions.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=JE0ESlf3gLQJ5-QzuOU1uR_xMLngiysxuz0o948ZlW4&e=
> 
> 
> 
> Alex
> 
> On 4/16/2019 8:24 PM, Netroby wrote:
>>    int numLetters = switch (day) {
>>        case MONDAY, FRIDAY, SUNDAY -> 6,
>>        case TUESDAY                -> 7,
>>        case THURSDAY, SATURDAY     -> 8,
>>        case WEDNESDAY              -> 9,
>>        _ -> 0,
>>    };
>> 
>> Should we using  comma , instead of ;
>> 
>> comma , means these cases the same switch.
>> 
>> Another point, should we have an default match pattern ? using _ or
> default
>> 
>> 
>> idea from rust match
>> ```rust
>> fn main() {
>>     let number = 13;
>>     // TODO ^ Try different values for `number`
>> 
>>     println!("Tell me about {}", number);
>>     match number {
>>         // Match a single value
>>         1 => println!("One!"),
>>         // Match several values
>>         2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
>>         // Match an inclusive range
>>         13...19 => println!("A teen"),
>>         // Handle the rest of cases
>>         _ => println!("Ain't special"),
>>     }
>> 
>>     let boolean = true;
>>     // Match is an expression too
>>     let binary = match boolean {
>>         // The arms of a match must cover all the possible values
>>         false => 0,
>>         true => 1,
>>         // TODO ^ Try commenting out one of these arms
>>     };
>> 
>>     println!("{} -> {}", boolean, binary);
>> }
>> 
>> ```
>> 
>> Appreciate your time.
>> ----------------------------
>> Netroby
>> 
>> Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00?
> ??
>>> 
>>> An easy way to help move Java forward is to try out new features on real
>>> code and share your experiences. We're asking for feedback on how you
>>> use switch expressions, the new language feature in JDK 12:
>>> 
>>>    int numLetters = switch (day) {
>>>        case MONDAY, FRIDAY, SUNDAY -> 6;
>>>        case TUESDAY                -> 7;
>>>        case THURSDAY, SATURDAY     -> 8;
>>>        case WEDNESDAY              -> 9;
>>>    };
>>> 
>>>    // Multiple labels per case (also allowed in switch statements)
>>>    // No fallthrough with the -> form (also allowed in switch
> statements)
>>> 
>>> Do you find switch expressions useful? Is anything surprising? Did you
>>> turn any switch statements into switch expressions? Please let us know
>>> on this list, even if the answer is "Tried it. Works fine."
>>> 
>>> To enable switch expressions in your environment:
>>> - IntelliJ IDEA 2019.1
>>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.jetbrains.com_idea_2019_02_java-2D12-2Dand-2Dintellij-2Didea_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=-WsqDARpX60gLIBem_6IqycbQFRWL5bzkTNGVV322aU&e=
> 
> 
>>> - Eclipse 4.11
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_eclipse_news_4.11_jdt.php-23Java12&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=zClnCpCg04gt1vZS1Zz8j64uam6ZkpnGMVe4M5kCYd0&e=
> 
> 
>>> - Apache NetBeans 11.0
>>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D103091452&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=5RLv6qs5qiU3r9dJ8KjnT4aPKRyz8hxXvNN0w5Z6x94&e=
> 
> 
>>> - jshell in JDK 12  run with `--enable-preview`
>>> - javac in JDK 12  run with `--release 12 --enable-preview`
>>> 
>>> Alex
> 
> 
> 
> 
> 
> 


From stephan.herrmann at berlin.de  Sun Apr 28 11:37:27 2019
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Sun, 28 Apr 2019 13:37:27 +0200
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <9472AED5-6D2A-4817-BE27-3D73FA9E6EA2@oracle.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
 <OF48BF43BD.DF94DB46-ON652583E8.00181AD0-652583E8.001891FE@notes.na.collabserv.com>
 <9472AED5-6D2A-4817-BE27-3D73FA9E6EA2@oracle.com>
Message-ID: <fd9b6371-a685-5a3c-5013-efc078b78ccd@berlin.de>

Brian,

let me try to help
(I'm not on jdk-dev, so this may not make it to the list, feel free to forward).

I had discussions about this with Manoj, and the focus was on "->" inside a 
switch *statement*. No question about switch expressions, here.


In the recent past we stumbled on several issues with this combination, and we 
started to wonder, whether this particular combination carries its own weight:

(1) Spec is complex (buggy), where it defines different rules of definite 
assignments for switch statements/expressions with ":" / "->".

(2) We have issues naming this thing, e.g., in compiler messages. Even JEP 325 & 
JEP 354 don't have a name for it but put the horse (syntax) before the cart 
(concept) by speaking of the "case L ->" switch label. The grammar term 
SwitchLabeledRule doesn't seem to be suitable for user-facing messages and 
explanations, either.

(3) The recent proposal of admitting break-with in more contexts would create 
new confusion if the following were admitted:

//---
int result = switch (in1) {
     case 0 -> {
             switch (in2) {
                   case 0 -> break-with 13; // line 4
                   default -> System.out.println("default");
             }
             break-with 14;
         }
     default -> 42;
};
//---

Just from looking at line 4 users would surely, but incorrectly assume that we 
are breaking from the inner switch. IOW, "case 0 -> break-with 13;" within a 
switch statement looks particularly hazardous to me.

Other related concepts that don't exactly align with switch statement with ->:
- lambdas can be void compatible and/or value compatible.
   This concept *could* be applied to switch also, but isn't.
- we already have the concept of ExpressionStatement/StatementExpression,
   for things that swing both ways, but switch does not participate in this, either.

IMHO, these are several bad smells, all caused by the same combination of 
constructs, so we were asking what benefits would possibly outweigh those bad 
smells.

Yet another way of asking: to what degree are switch statement and switch 
expression (intended to be) the same animal, or disjoint concepts?

best,
Stephan

On 28.04.19 00:56, Brian Goetz wrote:
> I?m not sure whether you?re asking about the specific overloading of -> (some people find it disturbing that both switch and lambda use the same punctuation; others see a switch as a sort of ?function by parts? and the arrow makes sense to them), or about why there was a need to have a shorthand form at all.
> 
> We surely could have done this:
> 
>       case A: break-with 1;
>       case B: break-with 2;
>      ?
> 
> And that might have been a reasonable idea, though people seem to have such an allergy to ?break? in switch that the convenience factor was significant.
> 
> 
>> One more item in the feedback list:
>>
>> We understand that the "->" in switch expressions lends itself to future
>> pattern matching constructs, but is there a real need for "->" to be there
>> in switch statements as well other than the convenience factor of avoiding
>> break ( or rather making the break implicit)  in switch statements?
>>
>> Regards,
>> Manoj
>>
>>
>>
>> From:	"Manoj Palat" <manoj.palat at in.ibm.com>
>> To:	"Alex Buckley" <alex.buckley at oracle.com>
>> Cc:	Stephan Herrmann <stephan.herrmann at berlin.de>,
>>             jdk-dev at openjdk.java.net
>> Date:	04/19/2019 03:28 AM
>> Subject:	Re: Call for feedback -- switch expressions in JDK 12
>> Sent by:	"jdk-dev" <jdk-dev-bounces at openjdk.java.net>
>>
>>
>>
>>
>> Hi Alex,
>> Please find our feedback from Eclipse Java Dev.
>>
>>    1)		 For the break expression part we would be happy to have the
>>       ?overloading? of break replaced by something else ? since this is
>>       already in the cards, no additional comment on this part.
>>
>>    2)		 Thanks to Remi Forax raising a bug in ecj [
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=bTz3kPNJIWSaFf9MBqxF1ZKUwUHxpH0AJkS2Noth9O0&e=
>> ] and the
>>       following discussions, we believe that there could be a bug [in spec,
>>       javac as well as ecj] ? see this comment from Stephan Herrmann
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716-23c16&d=DwIFJg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=kii1fGYS4Td8yanneEhpKyvY68-2ZuWy6UGnDArvEtU&s=lp0V33xF-hHx6PbOuSpmziGYZGad42PPROmWzFvu8xQ&e=
>> specifically
>>       for the findings. [@Alex: I am taking the liberty of pointing to the
>>       bug link rather than summarizing here since you have mentioned that a
>>       blog pointer should also be fine]
>>
>>    Regards,
>>
>>    Manoj
>>
>>    Eclipse Java Dev, IBM
>>
>>
>>
>>
>> From:		 Alex Buckley <alex.buckley at oracle.com>
>> To:		 jdk-dev at openjdk.java.net
>> Date:		 04/17/2019 11:23 PM
>> Subject:		 Re: Call for feedback -- switch expressions in JDK 12
>> Sent by:		 "jdk-dev" <jdk-dev-bounces at openjdk.java.net>
>>
>>
>>
>> The feedback we're looking for is "I tried switch expressions in my code
>> and observed ...". For example:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_amber-2Ddev_2019-2DMarch_004199.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=9at0fZB0bQpeEPI5L2IWbMSlUqcdgEsfF5944Rfjaxo&e=
>>
>>
>>
>> If anyone is blogging about their experience with switch expressions,
>> feel free to share the URL here. For example, here's a great writeup of
>> using switch expressions in lambdas:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__minborgsjavapot.blogspot.com_2019_03_java-2D12-2Dmapping-2Dwith-2Dswitch-2Dexpressions.html&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=JE0ESlf3gLQJ5-QzuOU1uR_xMLngiysxuz0o948ZlW4&e=
>>
>>
>>
>> Alex
>>
>> On 4/16/2019 8:24 PM, Netroby wrote:
>>>     int numLetters = switch (day) {
>>>         case MONDAY, FRIDAY, SUNDAY -> 6,
>>>         case TUESDAY                -> 7,
>>>         case THURSDAY, SATURDAY     -> 8,
>>>         case WEDNESDAY              -> 9,
>>>         _ -> 0,
>>>     };
>>>
>>> Should we using  comma , instead of ;
>>>
>>> comma , means these cases the same switch.
>>>
>>> Another point, should we have an default match pattern ? using _ or
>> default
>>>
>>>
>>> idea from rust match
>>> ```rust
>>> fn main() {
>>>      let number = 13;
>>>      // TODO ^ Try different values for `number`
>>>
>>>      println!("Tell me about {}", number);
>>>      match number {
>>>          // Match a single value
>>>          1 => println!("One!"),
>>>          // Match several values
>>>          2 | 3 | 5 | 7 | 11 => println!("This is a prime"),
>>>          // Match an inclusive range
>>>          13...19 => println!("A teen"),
>>>          // Handle the rest of cases
>>>          _ => println!("Ain't special"),
>>>      }
>>>
>>>      let boolean = true;
>>>      // Match is an expression too
>>>      let binary = match boolean {
>>>          // The arms of a match must cover all the possible values
>>>          false => 0,
>>>          true => 1,
>>>          // TODO ^ Try commenting out one of these arms
>>>      };
>>>
>>>      println!("{} -> {}", boolean, binary);
>>> }
>>>
>>> ```
>>>
>>> Appreciate your time.
>>> ----------------------------
>>> Netroby
>>>
>>> Alex Buckley <alex.buckley at oracle.com> ?2019?4?17??? ??10:00?
>> ??
>>>>
>>>> An easy way to help move Java forward is to try out new features on real
>>>> code and share your experiences. We're asking for feedback on how you
>>>> use switch expressions, the new language feature in JDK 12:
>>>>
>>>>     int numLetters = switch (day) {
>>>>         case MONDAY, FRIDAY, SUNDAY -> 6;
>>>>         case TUESDAY                -> 7;
>>>>         case THURSDAY, SATURDAY     -> 8;
>>>>         case WEDNESDAY              -> 9;
>>>>     };
>>>>
>>>>     // Multiple labels per case (also allowed in switch statements)
>>>>     // No fallthrough with the -> form (also allowed in switch
>> statements)
>>>>
>>>> Do you find switch expressions useful? Is anything surprising? Did you
>>>> turn any switch statements into switch expressions? Please let us know
>>>> on this list, even if the answer is "Tried it. Works fine."
>>>>
>>>> To enable switch expressions in your environment:
>>>> - IntelliJ IDEA 2019.1
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.jetbrains.com_idea_2019_02_java-2D12-2Dand-2Dintellij-2Didea_&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=-WsqDARpX60gLIBem_6IqycbQFRWL5bzkTNGVV322aU&e=
>>
>>
>>>> - Eclipse 4.11
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eclipse.org_eclipse_news_4.11_jdt.php-23Java12&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=zClnCpCg04gt1vZS1Zz8j64uam6ZkpnGMVe4M5kCYd0&e=
>>
>>
>>>> - Apache NetBeans 11.0
>>>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_pages_viewpage.action-3FpageId-3D103091452&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=yINx0-noxNSSsm-dLx2P9YD7dvF6187FW7CStT07mp4&s=5RLv6qs5qiU3r9dJ8KjnT4aPKRyz8hxXvNN0w5Z6x94&e=
>>
>>
>>>> - jshell in JDK 12  run with `--enable-preview`
>>>> - javac in JDK 12  run with `--release 12 --enable-preview`
>>>>
>>>> Alex
>>
>>
>>
>>
>>
>>
> 


From brian.goetz at oracle.com  Mon Apr 29 15:42:56 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Apr 2019 11:42:56 -0400
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <fd9b6371-a685-5a3c-5013-efc078b78ccd@berlin.de>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
 <OF48BF43BD.DF94DB46-ON652583E8.00181AD0-652583E8.001891FE@notes.na.collabserv.com>
 <9472AED5-6D2A-4817-BE27-3D73FA9E6EA2@oracle.com>
 <fd9b6371-a685-5a3c-5013-efc078b78ccd@berlin.de>
Message-ID: <8C495CC2-E8A9-48DF-981E-AD15F5D3CCFF@oracle.com>

> I had discussions about this with Manoj, and the focus was on "->" inside a switch *statement*. No question about switch expressions, here.

Thanks for the clarifications.

> In the recent past we stumbled on several issues with this combination, and we started to wonder, whether this particular combination carries its own weight:

Indeed, there are trade-offs here.

The ?arrow? labels surely synergize better with expression switches than with statement switches, so it was a reasonable question to ask whether a wider split made sense.  The current feature could be described as 2x2, which is that switches can be expression or statement, and, orthogonally, use either ?old? or ?new? style labels.  All four quadrants are viable, though clearly we expect the (expression, new labels) quadrant to be the most popular.  

There were a few considerations that drove us to the 2x2 interpretation rather than the more ad-hoc ?expression switches with new labels, or statement switches with old labels? design.  

 - There are statement switches that operate by side-effects, but which still are generally ?one action per label?.  Bringing these into the fold with new-style labels makes these more straightforward and less error-prone.  

 - That the default for control flow is to fall through, rather than to break out, was an unfortunate early choice, and this is a matter of huge angst for users.  This seemed to be something that should be solved for switches in general, not just for expression switches.

 - It seemed more desirable to tease the desired benefits (expression-ness, better control flow and scoping) into orthogonal features, so that switch expression and statement could share more in common.  The more that switch expression and statement diverge (aside from the obvious), the more complex we make the language, and the more sharp edges there are for users to cut themselves on.  

All that said, we realize switch statements with -> labels are a little weird, especially if the statement on the RHS is not lexically short.  

> (1) Spec is complex (buggy), where it defines different rules of definite assignments for switch statements/expressions with ":" / "->?.

Please report bugs and propose improvements!

> (2) We have issues naming this thing, e.g., in compiler messages. Even JEP 325 & JEP 354 don't have a name for it but put the horse (syntax) before the cart (concept) by speaking of the "case L ->" switch label. The grammar term SwitchLabeledRule doesn't seem to be suitable for user-facing messages and explanations, either.

Please help suggest a better name!  

> (3) The recent proposal of admitting break-with in more contexts would create new confusion if the following were admitted:
> 
> //---
> int result = switch (in1) {
>    case 0 -> {
>            switch (in2) {
>                  case 0 -> break-with 13; // line 4
>                  default -> System.out.println("default");
>            }
>            break-with 14;
>        }
>    default -> 42;
> };
> //?

This is a difficult tradeoff.  On the one hand, allowing break-with to ?tunnel through? a switch statement (just as break tunnels through an if statement) is perfectly unambiguous, and potentially useful. (I suspect it would be used more from for loops, rather than from nested switches.)  On the other hand, it is possible to write complex code using nonlocal control flow that is confusing.  

> Other related concepts that don't exactly align with switch statement with ->:
> - lambdas can be void compatible and/or value compatible.
>  This concept *could* be applied to switch also, but isn?t.

Good point!  

> - we already have the concept of ExpressionStatement/StatementExpression,
>  for things that swing both ways, but switch does not participate in this, either.
> 
> IMHO, these are several bad smells, all caused by the same combination of constructs, so we were asking what benefits would possibly outweigh those bad smells.
> 
> Yet another way of asking: to what degree are switch statement and switch expression (intended to be) the same animal, or disjoint concepts?

This I can answer clearly: we are surely better off maximizing their commonality. Gratuitous divergence is just pure accidental complexity.  Their differences should be related to their essential differences, rather than just the style of code we think we want to encourage in 2019.  

SO given that, do you have suggestions as to how to improve the specification so as to gain the benefits of being as similar as is reasonable, while avoiding some of the pitfalls you raise?  Because most of the pitfalls seem largely accidental and fixable.





From alex.buckley at oracle.com  Mon Apr 29 20:46:41 2019
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 29 Apr 2019 13:46:41 -0700
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
Message-ID: <5CC762B1.9090308@oracle.com>

On 4/17/2019 4:50 PM, Manoj Palat wrote:
>     2) Thanks to Remi Forax raising a bug in ecj
>     [https://bugs.eclipse.org/bugs/show_bug.cgi?id=545716] and the
>     following discussions, we believe that there could be a bug [in
>     spec, javac as well as ecj] ? see this comment from Stephan Herrmann
>     _https://bugs.eclipse.org/bugs/show_bug.cgi?id=545716#c16_specifically
>     for the findings.

Thanks for raising this. There is a flaw in how the new JLS 16.2.9 
analyzes -> rules in a switch statement 
(http://cr.openjdk.java.net/~gbierman/switch-expressions.html#jep325-16.2.9). 
The flaw is due to the fact that -> rules were initially introduced in 
switch expressions, which are complete by construction. (Either there is 
an explicit default, or there is an implicit default to catch novel enum 
constants.)

We will publish a new spec for JEP 354 soon, but in the meantime here is 
the corrected part of 16.2.9:

-----
The following rules apply only if the switch block of the switch 
statement consists of switch labeled rules:

* V is assigned after a switch statement iff either of the following are 
true:

     V is assigned after the selector expression, or

     There is a default labeled rule and for every switch labeled rule 
one of the following is true:

         It is a switch labeled expression e and V is assigned after e.

         It is a switch labeled block b and both V is assigned after b 
and V is assigned before every break statement contained in b that may 
exit the switch statement.

         It is a switch labeled throw statement.

* V is unassigned after a switch statement iff both of the following 
rules are true:

     V is unassigned after the selector expression, and

     For every switch labeled rule one of the following is true:

         It is a switch labeled expression e and V is unassigned after e.

         It is a switch labeled block b and both V is unassigned after b 
and V is unassigned before every break statement contained in b that may 
exit the switch statement.

         It is a switch labeled throw statement.

* V is [un]assigned before any switch labeled expression, switch labeled 
block, or switch labeled throw statement iff V is [un]assigned after the 
selector expression.
-----

Alex

From luke.hutch at gmail.com  Tue Apr 30 08:25:37 2019
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Tue, 30 Apr 2019 02:25:37 -0600
Subject: StackWalker can crash the JVM
Message-ID: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>

I received a bug report that my library ClassGraph crashes the JVM:

https://github.com/classgraph/classgraph/issues/341

The top few stack frames are

V  [libjvm.dylib+0x65ca9b]  ResolvedMethodTable::add_method(Handle)+0x61
V  [libjvm.dylib+0x4eabf5]  CallInfo::set_resolved_method_name(Thread*)+0x5d
V  [libjvm.dylib+0x4eaaf7]  CallInfo::CallInfo(Method*, Klass*, Thread*)+0x1c5
V  [libjvm.dylib+0x3a95e5]
java_lang_StackFrameInfo::set_method_and_bci(Handle, methodHandle
const&, int, Thread*)+0x7f
V  [libjvm.dylib+0x68f6f0]  StackWalk::fill_in_frames(long,
BaseFrameStream&, int, int, objArrayHandle, int&, Thread*)+0x252
V  [libjvm.dylib+0x6907d3]  StackWalk::fetchNextBatch(Handle, long,
long, int, int, objArrayHandle, Thread*)+0xd9
V  [libjvm.dylib+0x417264]  JVM_MoreStackWalk+0x12f
j  java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(JJII[Ljava/lang/Object;)I+0
java.base at 11.0.3
j  java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(I)I+35
java.base at 11.0.3


Here is the class that calls into StackWalker, in method
getCallStackViaStackWalker() (it uses reflection to ensure the code is
backwards compatible with JDK 7/8):

https://github.com/classgraph/classgraph/blob/master/src/main/java/nonapi/io/github/classgraph/classpath/CallStackReader.java

This code works as intended most of the time, so I don't know what is
different about the reporting user's environment that triggers this crash.

It is possible that ClassGraph is somehow calling StackWalker wrongly in
some circumstances (if so, please let me know what I'm doing wrong) --
however, I am reporting the problem here, because I assume that non-native
code should never be able to crash the JVM.

Thank you,
Luke Hutchison

From aph at redhat.com  Tue Apr 30 08:35:31 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 30 Apr 2019 09:35:31 +0100
Subject: StackWalker can crash the JVM
In-Reply-To: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
Message-ID: <572ecf4d-b171-97ff-86b2-990b9bd0ef11@redhat.com>

On 4/30/19 9:25 AM, Luke Hutchison wrote:
> It is possible that ClassGraph is somehow calling StackWalker wrongly in
> some circumstances (if so, please let me know what I'm doing wrong) --
> however, I am reporting the problem here, because I assume that non-native
> code should never be able to crash the JVM.

That's true. Do I take it that you have never seen this error, and no of no
way to reproduce it?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From shade at redhat.com  Tue Apr 30 08:42:06 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Apr 2019 10:42:06 +0200
Subject: StackWalker can crash the JVM
In-Reply-To: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
Message-ID: <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>

On 4/30/19 10:25 AM, Luke Hutchison wrote:
> I received a bug report that my library ClassGraph crashes the JVM:
> 
> https://github.com/classgraph/classgraph/issues/341
> 
> The top few stack frames are
> 
> V  [libjvm.dylib+0x65ca9b]  ResolvedMethodTable::add_method(Handle)+0x61
> V  [libjvm.dylib+0x4eabf5]  CallInfo::set_resolved_method_name(Thread*)+0x5d
> V  [libjvm.dylib+0x4eaaf7]  CallInfo::CallInfo(Method*, Klass*, Thread*)+0x1c5
> V  [libjvm.dylib+0x3a95e5]

This looks suspiciously like:
  https://bugs.openjdk.java.net/browse/JDK-8210457

That fix is already backported to 11.0.4.

Further diagnostics can be helped with running with fastdebug build, and running on latest JDK too.
You can have the binaries here:
  https://builds.shipilev.net/openjdk-jdk11-dev/ (bleeding edge 11.0.4+)
  https://builds.shipilev.net/openjdk-jdk/       (bleeding edge 13+)

-Aleksey


From luke.hutch at gmail.com  Tue Apr 30 08:44:53 2019
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Tue, 30 Apr 2019 02:44:53 -0600
Subject: StackWalker can crash the JVM
In-Reply-To: <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
 <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>
Message-ID: <CAHLUFO=HpXPTc7a8urh777NDarS5OtY1ruZig-+EuzsZwOn52A@mail.gmail.com>

Yes, that looks like the very same bug. I will ask the reporter to test
with 11.0.4, if they are able.

Does this affect 11.0.0 through to 11.0.3 inclusive? I can blacklist those
JDK versions for stackwalking if so.




On Tue, Apr 30, 2019 at 2:42 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 4/30/19 10:25 AM, Luke Hutchison wrote:
> > I received a bug report that my library ClassGraph crashes the JVM:
> >
> > https://github.com/classgraph/classgraph/issues/341
> >
> > The top few stack frames are
> >
> > V  [libjvm.dylib+0x65ca9b]  ResolvedMethodTable::add_method(Handle)+0x61
> > V  [libjvm.dylib+0x4eabf5]
> CallInfo::set_resolved_method_name(Thread*)+0x5d
> > V  [libjvm.dylib+0x4eaaf7]  CallInfo::CallInfo(Method*, Klass*,
> Thread*)+0x1c5
> > V  [libjvm.dylib+0x3a95e5]
>
> This looks suspiciously like:
>   https://bugs.openjdk.java.net/browse/JDK-8210457
>
> That fix is already backported to 11.0.4.
>
> Further diagnostics can be helped with running with fastdebug build, and
> running on latest JDK too.
> You can have the binaries here:
>   https://builds.shipilev.net/openjdk-jdk11-dev/ (bleeding edge 11.0.4+)
>   https://builds.shipilev.net/openjdk-jdk/       (bleeding edge 13+)
>
> -Aleksey
>
>

From shade at redhat.com  Tue Apr 30 08:59:21 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 30 Apr 2019 10:59:21 +0200
Subject: StackWalker can crash the JVM
In-Reply-To: <CAHLUFO=HpXPTc7a8urh777NDarS5OtY1ruZig-+EuzsZwOn52A@mail.gmail.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
 <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>
 <CAHLUFO=HpXPTc7a8urh777NDarS5OtY1ruZig-+EuzsZwOn52A@mail.gmail.com>
Message-ID: <a88cb755-4eef-37d4-9173-cb0990fe44b1@redhat.com>

On 4/30/19 10:44 AM, Luke Hutchison wrote:
> Yes, that looks like the very same bug. I will ask the reporter to test with 11.0.4, if they are able.
> 
> Does this affect 11.0.0 through to 11.0.3 inclusive? I can blacklist those JDK versions for
> stackwalking if so.

Yes, it looks as affecting all versions up to 11.0.3 inclusive.

Would be nice to confirm this is the same bug, though. It looks very likely: the problem is with
class redifinition, and there are class redefinition events shortly before the crash reported by
your guy (see "Classes redefined" in hs_err) .

-Aleksey


From manoj.palat at in.ibm.com  Tue Apr 30 10:06:39 2019
From: manoj.palat at in.ibm.com (Manoj Palat)
Date: Tue, 30 Apr 2019 15:36:39 +0530
Subject: Call for feedback -- switch expressions in JDK 12
In-Reply-To: <5CC762B1.9090308@oracle.com>
References: <5CB688B0.7030502@oracle.com>
 <CAEZo+gcguq_Vuh7b7eDsho4rkG2NDkwpXZFnXLzU=Z4DLNDuFA@mail.gmail.com>
 <5CB767DD.3050503@oracle.com>
 <OF46F2C667.4DA040BF-ON652583DF.0082C89F-652583DF.0082F90E@notes.na.collabserv.com>
 <5CC762B1.9090308@oracle.com>
Message-ID: <OF524D29A0.4D8ED93F-ON652583EC.00376D10-652583EC.00378A5D@notes.na.collabserv.com>

Thanks Alex for the checking this issue and the heads up on spec changes!

Regards,
Manoj



From:	Alex Buckley <alex.buckley at oracle.com>
To:	jdk-dev at openjdk.java.net
Cc:	Stephan Herrmann <stephan.herrmann at berlin.de>
Date:	04/30/2019 02:17 AM
Subject:	Re: Call for feedback -- switch expressions in JDK 12
Sent by:	"jdk-dev" <jdk-dev-bounces at openjdk.java.net>



On 4/17/2019 4:50 PM, Manoj Palat wrote:
>     2) Thanks to Remi Forax raising a bug in ecj
>     [
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=GAhhBGxI89L4ZPYfJmojbo9hfTvw3qEcwI1DV9VnGVg&s=rcyhedLZFsxKexCqbSltcCqXiLrw9IbcN5sndzlNAho&e=
] and the
>     following discussions, we believe that there could be a bug [in
>     spec, javac as well as ecj] ? see this comment from Stephan Herrmann
>
_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.eclipse.org_bugs_show-5Fbug.cgi-3Fid-3D545716-23c16-5Fspecifically&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=GAhhBGxI89L4ZPYfJmojbo9hfTvw3qEcwI1DV9VnGVg&s=MT4WBGp2qntLBcd4TMM91AvS-iFa-LeRwrJqbl1-PzE&e=

>     for the findings.

Thanks for raising this. There is a flaw in how the new JLS 16.2.9
analyzes -> rules in a switch statement
(
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Egbierman_switch-2Dexpressions.html-23jep325-2D16.2.9&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=GAhhBGxI89L4ZPYfJmojbo9hfTvw3qEcwI1DV9VnGVg&s=bIajDf-jQmB-y2ER4sy41cLRN-b00CuaU_Muhcv9W9I&e=
).
The flaw is due to the fact that -> rules were initially introduced in
switch expressions, which are complete by construction. (Either there is
an explicit default, or there is an implicit default to catch novel enum
constants.)

We will publish a new spec for JEP 354 soon, but in the meantime here is
the corrected part of 16.2.9:

-----
The following rules apply only if the switch block of the switch
statement consists of switch labeled rules:

* V is assigned after a switch statement iff either of the following are
true:

     V is assigned after the selector expression, or

     There is a default labeled rule and for every switch labeled rule
one of the following is true:

         It is a switch labeled expression e and V is assigned after e.

         It is a switch labeled block b and both V is assigned after b
and V is assigned before every break statement contained in b that may
exit the switch statement.

         It is a switch labeled throw statement.

* V is unassigned after a switch statement iff both of the following
rules are true:

     V is unassigned after the selector expression, and

     For every switch labeled rule one of the following is true:

         It is a switch labeled expression e and V is unassigned after e.

         It is a switch labeled block b and both V is unassigned after b
and V is unassigned before every break statement contained in b that may
exit the switch statement.

         It is a switch labeled throw statement.

* V is [un]assigned before any switch labeled expression, switch labeled
block, or switch labeled throw statement iff V is [un]assigned after the
selector expression.
-----

Alex




From coleen.phillimore at oracle.com  Tue Apr 30 12:26:00 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 30 Apr 2019 08:26:00 -0400
Subject: StackWalker can crash the JVM
In-Reply-To: <a88cb755-4eef-37d4-9173-cb0990fe44b1@redhat.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
 <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>
 <CAHLUFO=HpXPTc7a8urh777NDarS5OtY1ruZig-+EuzsZwOn52A@mail.gmail.com>
 <a88cb755-4eef-37d4-9173-cb0990fe44b1@redhat.com>
Message-ID: <7d80331c-89cc-2c3d-30a8-c5bd9c846dbf@oracle.com>

Yes, if possible, can you please confirm that this is the same bug? We 
didn't have a reproducer for that bug so had to guess by the source code.
Thanks,
Coleen

On 4/30/19 4:59 AM, Aleksey Shipilev wrote:
> On 4/30/19 10:44 AM, Luke Hutchison wrote:
>> Yes, that looks like the very same bug. I will ask the reporter to test with 11.0.4, if they are able.
>>
>> Does this affect 11.0.0 through to 11.0.3 inclusive? I can blacklist those JDK versions for
>> stackwalking if so.
> Yes, it looks as affecting all versions up to 11.0.3 inclusive.
>
> Would be nice to confirm this is the same bug, though. It looks very likely: the problem is with
> class redifinition, and there are class redefinition events shortly before the crash reported by
> your guy (see "Classes redefined" in hs_err) .
>
> -Aleksey
>


From luke.hutch at gmail.com  Tue Apr 30 15:06:20 2019
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Tue, 30 Apr 2019 09:06:20 -0600
Subject: StackWalker can crash the JVM
In-Reply-To: <7d80331c-89cc-2c3d-30a8-c5bd9c846dbf@oracle.com>
References: <CAHLUFOnBqbkdaO8xtU9F690hcLif4hi6H8o2M2byDwM+2O-Wtg@mail.gmail.com>
 <f6433203-bc5d-5f9f-30fd-540f7038b40b@redhat.com>
 <CAHLUFO=HpXPTc7a8urh777NDarS5OtY1ruZig-+EuzsZwOn52A@mail.gmail.com>
 <a88cb755-4eef-37d4-9173-cb0990fe44b1@redhat.com>
 <7d80331c-89cc-2c3d-30a8-c5bd9c846dbf@oracle.com>
Message-ID: <CAHLUFOkfgUma3gB9gFa48=taCmrgGsB-4d0TDrkp+4dLqt+1dA@mail.gmail.com>

This is supposedly a reproducer project, though I haven't had a chance to
see if I can trigger it yet:

https://github.com/bertramn/classgraph-issue-341

If you want to discuss that test project, please jump into the ClassGraph
bug linked in my first email.





On Tue, Apr 30, 2019, 6:26 AM <coleen.phillimore at oracle.com> wrote:

> Yes, if possible, can you please confirm that this is the same bug? We
> didn't have a reproducer for that bug so had to guess by the source code.
> Thanks,
> Coleen
>
> On 4/30/19 4:59 AM, Aleksey Shipilev wrote:
> > On 4/30/19 10:44 AM, Luke Hutchison wrote:
> >> Yes, that looks like the very same bug. I will ask the reporter to test
> with 11.0.4, if they are able.
> >>
> >> Does this affect 11.0.0 through to 11.0.3 inclusive? I can blacklist
> those JDK versions for
> >> stackwalking if so.
> > Yes, it looks as affecting all versions up to 11.0.3 inclusive.
> >
> > Would be nice to confirm this is the same bug, though. It looks very
> likely: the problem is with
> > class redifinition, and there are class redefinition events shortly
> before the crash reported by
> > your guy (see "Classes redefined" in hs_err) .
> >
> > -Aleksey
> >
>
>