From goetz.lindenmaier at sap.com  Tue Dec  1 07:36:28 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 1 Dec 2020 07:36:28 +0000
Subject: Result: New JDK Reviewer: Richard Reingruber
Message-ID: <AM4PR0202MB296429EDB99C4B451D1E0D42ECF40@AM4PR0202MB2964.eurprd02.prod.outlook.com>

Hello,

   voting for Richard Reingruger (rrich) [1] is now closed.

Yes: 21
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Best regards,
  Goetz Lindenmaier

From jdowland at redhat.com  Tue Dec  1 09:55:09 2020
From: jdowland at redhat.com (Jonathan Dowland)
Date: Tue, 1 Dec 2020 09:55:09 +0000
Subject: Why is java -version implemented in Java?
In-Reply-To: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
Message-ID: <20201201095509.uspp6vpc7p53x4t2@qusp>

On Fri, Nov 20, 2020 at 05:22:15PM +0100, Thomas St?fe wrote:
> Or is using 'java -version' as a simple VM test just too convenient?

I've used it as a quick way to get a valid java invocation in order to
test other parameters (e.g. -XX:+UnlockDiagnosticVMOptions
-XX:+PrintContainerInfo) without having to have a valid Java program
(Jar, class, source file, etc.) around. I could use --dry-run, but I'd
either need to keep HelloWorld.class to hand or tolerate the invocation
error. On the other hand I can see the appeal of making bare "java
-version" operate more quickly.

-- 
???? Jonathan Dowland <jdowland at redhat.com>
Senior Software Engineer, OpenJDK, Red Hat


From thomas.stuefe at gmail.com  Tue Dec  1 12:51:44 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 1 Dec 2020 13:51:44 +0100
Subject: Why is java -version implemented in Java?
In-Reply-To: <20201201095509.uspp6vpc7p53x4t2@qusp>
References: <CAA-vtUx0hjpkxchw=w3G1Fsd7EDqsbqTcfyo+MacrnGXpysP+w@mail.gmail.com>
 <20201201095509.uspp6vpc7p53x4t2@qusp>
Message-ID: <CAA-vtUwft=V-tw7yBLnUpWw9NQQDZnqmOS=1jobz6tXdOc=+6g@mail.gmail.com>

Yes, from all the feedback I gathered it seems that -version, in its
current form, is here to stay.

Since there is "-Xinternalversion" which already does what I originally
wanted there is no pressing need to do anything. Unless one wants to change
the decidedly unsexy argument name, but that's a different issue :)

Cheers, Thomas

On Tue, Dec 1, 2020 at 10:57 AM Jonathan Dowland <jdowland at redhat.com>
wrote:

> On Fri, Nov 20, 2020 at 05:22:15PM +0100, Thomas St?fe wrote:
> > Or is using 'java -version' as a simple VM test just too convenient?
>
> I've used it as a quick way to get a valid java invocation in order to
> test other parameters (e.g. -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintContainerInfo) without having to have a valid Java program
> (Jar, class, source file, etc.) around. I could use --dry-run, but I'd
> either need to keep HelloWorld.class to hand or tolerate the invocation
> error. On the other hand I can see the appeal of making bare "java
> -version" operate more quickly.
>
> --
> ???? Jonathan Dowland <jdowland at redhat.com>
> Senior Software Engineer, OpenJDK, Red Hat
>
>

From mark.reinhold at oracle.com  Wed Dec  2 00:45:36 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 01 Dec 2020 16:45:36 -0800
Subject: JEP proposed to target JDK 16: 397: Sealed Classes (Second
 Preview)
In-Reply-To: <20201124230434.B5CA83CB481@eggemoggin.niobe.net>
References: <20201124230434.B5CA83CB481@eggemoggin.niobe.net>
Message-ID: <20201201164536.305830577@eggemoggin.niobe.net>

2020/11/24 15:04:34 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   397: Sealed Classes (Second Preview)
>        https://openjdk.java.net/jeps/397
> 
>   Summary: Enhance the Java programming language with sealed classes and
>   interfaces. Sealed classes and interfaces restrict which other classes
>   or interfaces may extend or implement them.
> 
> 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:59 UTC on Tuesday, 1 December, 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 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From fweimer at redhat.com  Wed Dec  2 09:32:38 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 02 Dec 2020 10:32:38 +0100
Subject: JEP proposed to target JDK 16: 390: Warnings for Value-Based
 Classes
In-Reply-To: <20201130224227.399613CBEA5@eggemoggin.niobe.net> (mark
 reinhold's message of "Mon, 30 Nov 2020 14:42:27 -0800 (PST)")
References: <20201130224227.399613CBEA5@eggemoggin.niobe.net>
Message-ID: <87sg8ozh6x.fsf@oldenburg2.str.redhat.com>

* mark reinhold:

> The following JEP is proposed to target JDK 16:
>
>   390: Warnings for Value-Based Classes
>        https://openjdk.java.net/jeps/390
>
>   Summary: Designate the primitive wrapper classes as value-based and
>   deprecate their constructors for removal, prompting new deprecation
>   warnings.  Provide warnings about improper attempts to synchronize on
>   instances of any value-based classes in the Java Platform.
>
> 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:59 UTC on Monday, 7 December, 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 16.

The proposal does not discuss the concurrency impact of a switch to
primitive types.  I expect that lot of code has data races on fields
whose type is a value-based class, and these races are largely
recognized as benign today.  I think the default choice for primitive
types will be that data races can observe invalid states, and it would
be nice to tell developers if that's going to happen for e.g. immutable
maps.

(Sorry if I brought this up before; I think I did but I can't recall a
discussion.)

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


From daniel.smith at oracle.com  Wed Dec  2 15:43:16 2020
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 2 Dec 2020 08:43:16 -0700
Subject: JEP proposed to target JDK 16: 390: Warnings for Value-Based
 Classes
In-Reply-To: <87sg8ozh6x.fsf@oldenburg2.str.redhat.com>
References: <20201130224227.399613CBEA5@eggemoggin.niobe.net>
 <87sg8ozh6x.fsf@oldenburg2.str.redhat.com>
Message-ID: <6D25C510-4711-454A-BBBA-0087FCC20DD8@oracle.com>

> On Dec 2, 2020, at 2:32 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> The proposal does not discuss the concurrency impact of a switch to
> primitive types.  I expect that lot of code has data races on fields
> whose type is a value-based class, and these races are largely
> recognized as benign today.  I think the default choice for primitive
> types will be that data races can observe invalid states, and it would
> be nice to tell developers if that's going to happen for e.g. immutable
> maps.

Details of how Valhalla will cope with data races and atomicity are still to be worked out. But it should not be a problem for migration.

Briefly, the model is that each primitive class has two types: a value type and a reference type. Reference types hold pointers, so reads/writes of variables of that type are atomic. For migrated primitive classes, the class name ('LocalDate') refers to the reference type. Thus, all legacy code will continue to operate safely on references. Data races only become a problem when the programmer opts in to flattened storage by using the value type (via something like 'LocalDate.val').


From mark.reinhold at oracle.com  Thu Dec  3 17:30:59 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu,  3 Dec 2020 09:30:59 -0800 (PST)
Subject: JDK 16 enters Rampdown Phase One next week
Message-ID: <20201203173059.791D93CC782@eggemoggin.niobe.net>

JDK 16 enters Rampdown Phase One next week, on Thursday, 10 December.
Changes intended for JDK 16 should be in the main-line repository
(https://github.com/openjdk/jdk) by 16:00 UTC on that day [1].

At that time we?ll fork the main line to the JDK 16 stabilization
repository, jdk16, and promote next week?s build and all remaining
JDK 16 builds from there.

We?ll semi-automatically merge changes pushed to jdk16 into the
main-line repository, as we have in previous feature-release
transitions.  This means that:

  - If you make a change in JDK 16 then you needn't do any extra
    work to get it into the main line, though if a merge conflict
    arises then you might be asked to help resolve it.

  - If you need to make a change in both JDK 16 and the main line
    then just push it to JDK 16, and wait for the automatic merge
    to complete.

Changes pushed to the main line after 16:00 UTC next Thursday will
be bound for JDK 17 only, unless they're subsequently back-ported
to JDK 16.

The Rampdown Phase One process is defined in JEP 3 [2].

- Mark


[1] https://time.is/1600_10_December_2020_in_UTC?JDK_16_Rampdown_Phase_One
[2] https://openjdk.java.net/jeps/3

From shade at redhat.com  Thu Dec  3 17:37:59 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 3 Dec 2020 18:37:59 +0100
Subject: JDK 16 enters Rampdown Phase One next week
In-Reply-To: <20201203173059.791D93CC782@eggemoggin.niobe.net>
References: <20201203173059.791D93CC782@eggemoggin.niobe.net>
Message-ID: <43878e4e-403b-c708-2361-ad3d35b1d9d3@redhat.com>

On 12/3/20 6:30 PM, mark.reinhold at oracle.com wrote:
>    - If you need to make a change in both JDK 16 and the main line
>      then just push it to JDK 16, and wait for the automatic merge
>      to complete.

With Skara, this must mean "base your PR on JDK 16 stabilization repository"? Coincidentally, was 
that tested to work? I assume it would be no different from other non-mainline Skara-based repositories.

-- 
Thanks,
-Aleksey


From mark.reinhold at oracle.com  Thu Dec  3 18:22:18 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 03 Dec 2020 10:22:18 -0800
Subject: JDK 16 enters Rampdown Phase One next week
In-Reply-To: <43878e4e-403b-c708-2361-ad3d35b1d9d3@redhat.com>
References: <20201203173059.791D93CC782@eggemoggin.niobe.net>
 <43878e4e-403b-c708-2361-ad3d35b1d9d3@redhat.com>
Message-ID: <20201203102218.488032251@eggemoggin.niobe.net>

2020/12/3 9:37:59 -0800, Aleksey Shipilev <shade at redhat.com>:
> On 12/3/20 6:30 PM, mark.reinhold at oracle.com wrote:
>>   - If you need to make a change in both JDK 16 and the main line
>>     then just push it to JDK 16, and wait for the automatic merge
>>     to complete.
> 
> With Skara, this must mean "base your PR on JDK 16 stabilization
> repository"?

Yes.

- Mark

From Alan.Bateman at oracle.com  Mon Dec  7 10:29:37 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 7 Dec 2020 10:29:37 +0000
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
Message-ID: <ed8b928b-0791-b0aa-e22d-f39da6401d51@oracle.com>

On 24/11/2020 13:18, Severin Gehwolf wrote:
> Hi,
>
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
>
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream to
> OpenJDK.
>
> Andrew has 12 contributions: [0] and has also been involved in aiding 7
> backports for jdk8u/11u: [3] [4]
The rough guideline is that a Contributor should have at least 8 
significant contributions before being nominated. There's a lot of 
interpretation and wriggle room in that guidelines but I wonder if there 
are sufficient significant contributions in this case to support the 
nomination at this time.

-Alan

From sgehwolf at redhat.com  Mon Dec  7 15:08:01 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 07 Dec 2020 16:08:01 +0100
Subject: CFV: New JDK Committer: Andrew Leonard
In-Reply-To: <ed8b928b-0791-b0aa-e22d-f39da6401d51@oracle.com>
References: <d8a0a3849ade660202674533a2b629bed9fa28ad.camel@redhat.com>
 <ed8b928b-0791-b0aa-e22d-f39da6401d51@oracle.com>
Message-ID: <70b339691ed499df7aeda61e5685e28e085db946.camel@redhat.com>

Hi Alan,

On Mon, 2020-12-07 at 10:29 +0000, Alan Bateman wrote:
On 24/11/2020 13:18, Severin Gehwolf wrote:
> Hi,
> 
> I hereby nominate Andrew Leonard (aleonard) to JDK Project Committer.
> 
> Andrew has been working primarily on the core-libs and build
> components, on a range of fixes mainly discovered by his involvement
> with Eclipse OpenJ9 and AdoptOpenJDK, and contributing them upstream
> to
> OpenJDK.
> 
> Andrew has 12 contributions: [0] and has also been involved in aiding
> 7
> backports for jdk8u/11u: [3] [4]
The rough guideline is that a Contributor should have at least 8 
significant contributions before being nominated. There's a lot of 
interpretation and wriggle room in that guidelines but I wonder if
there 
are sufficient significant contributions in this case to support the 
nomination at this time.

To me, "rough guideline" is the keyword.

>From looking at other recent proposals[1][2][3], the nomination seemed
reasonable to me at this point. Do you have specific concerns, or
should we just wait a little longer for some more contributions of
Andrew to get in?

Thanks,
Severin

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-October/004840.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004897.html
[3] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004704.html


From mark.reinhold at oracle.com  Tue Dec  8 19:34:23 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 08 Dec 2020 11:34:23 -0800
Subject: JEP proposed to target JDK 16: 390: Warnings for Value-Based
 Classes
In-Reply-To: <20201130224227.399613CBEA5@eggemoggin.niobe.net>
References: <20201130224227.399613CBEA5@eggemoggin.niobe.net>
Message-ID: <20201208113423.739358065@eggemoggin.niobe.net>

2020/11/30 14:42:27 -0800, mark.reinhold at oracle.com:
> The following JEP is proposed to target JDK 16:
> 
>   390: Warnings for Value-Based Classes
>        https://openjdk.java.net/jeps/390
> 
>   Summary: Designate the primitive wrapper classes as value-based and
>   deprecate their constructors for removal, prompting new deprecation
>   warnings.  Provide warnings about improper attempts to synchronize on
>   instances of any value-based classes in the Java Platform.
> 
> 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:59 UTC on Monday, 7 December, 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 16.

Hearing no objections, I?ve targeted this JEP to JDK 16.

- Mark

From mark.reinhold at oracle.com  Thu Dec 10 16:44:41 2020
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 10 Dec 2020 08:44:41 -0800 (PST)
Subject: JDK 16 is now in Rampdown Phase One
Message-ID: <20201210164442.021FE3CE3DB@eggemoggin.niobe.net>

Per the JDK 16 schedule [1], we are now in Rampdown Phase One.

The overall feature set is frozen.  No further JEPs will be targeted to
this release.

We?ve forked the main-line source repository to the jdk16 stabilization
repository (https://github.com/openjdk/jdk16).  Any changes pushed to
the main line are now bound for JDK 17, as noted previously [2].

The stabilization repository is open for select bug fixes and, with
approval, late enhancements per JEP 3, the JDK Release Process [3].
If you?re responsible for any of the bugs on the RDP 1 candidate-bug
list [4] then please see JEP 3 for guidance on how to handle them.

- Mark


[1] https://openjdk.java.net/projects/jdk/16/#Schedule
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-December/004985.html
[3] https://openjdk.java.net/jeps/3
[4] https://j.mp/jdk-rdp-1

From hufeng1987 at gmail.com  Fri Dec 11 22:39:47 2020
From: hufeng1987 at gmail.com (Netroby)
Date: Sat, 12 Dec 2020 06:39:47 +0800
Subject: Question: Why Java not have an union type
Message-ID: <CAEZo+gfMpXP_yeqDu9jy2VMVCeX_K7PY2bzNZAwNrpUaNr9Vzg@mail.gmail.com>

For short, let's see the RFC document from the PHP community.

https://wiki.php.net/rfc/union_types_v2

for a small piece of code

```

class Number {
    private int|float $number;

    public function setNumber(int|float $number): void {
        $this->number = $number;
    }

    public function getNumber(): int|float {
        return $this->number;
    }
}

```
The union type seems to have it's benefits.

Do less code, get more flexibility.

We limit two Type: Int or float.
Our function only accepts these two type inputs. and returns the same type .

As for now, we can use generics. but it's too heavy .
generics normally come with Class level, but union type can be Function level .






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

From sgehwolf at redhat.com  Mon Dec 14 15:55:18 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 14 Dec 2020 16:55:18 +0100
Subject: Result: New JDK Committer: Andrew Leonard
Message-ID: <b281293303872e1c62f09a998b7c26503a7b1369.camel@redhat.com>

Voting for Andrew Leonard[1] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus[2], this is sufficient 
to approve the nomination.

Thanks,
Severin

[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004967.html
[2] https://openjdk.java.net/bylaws#lazy-consensus



From bsrbnd at gmail.com  Sun Dec 20 14:31:41 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Sun, 20 Dec 2020 15:31:41 +0100
Subject: Question: Why Java not have an union type
In-Reply-To: <CAEZo+gfMpXP_yeqDu9jy2VMVCeX_K7PY2bzNZAwNrpUaNr9Vzg@mail.gmail.com>
References: <CAEZo+gfMpXP_yeqDu9jy2VMVCeX_K7PY2bzNZAwNrpUaNr9Vzg@mail.gmail.com>
Message-ID: <CAEgw74AO-vByBsYq4vEBg-7F_9saLRqdjfoojdFQvM30pMxPNA@mail.gmail.com>

Hi,

On Fri, 11 Dec 2020 at 23:40, Netroby <hufeng1987 at gmail.com> wrote:
>
> For short, let's see the RFC document from the PHP community.
>
> https://wiki.php.net/rfc/union_types_v2

Union types are internally approximated with the least upper bound
(JLS15 ?4.10.4) but the language exposes them in 'catch' clauses
though, see JLS15 ?14.20:
"The declared type of an exception parameter that denotes its type as
a union with alternatives D 1 | D 2 | ... | D n is lub( D 1 , D 2 ,
..., D n )."

However, is someone else aware of any plan to use this syntax more
broadly in Java?

Regards,
Bernard

From github.com+27751938+amcap1712 at openjdk.java.net  Sat Dec 26 23:34:55 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sat, 26 Dec 2020 23:34:55 GMT
Subject: Withdrawn: 8248122: java.base should not handle JavaFX application in
 a specific way
In-Reply-To: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
Message-ID: <6mRhvDiX2SWJfPzkauuPG7BFpkj8nN7yvABguWxgGuA=.b3dbc87e-abab-428f-a2f3-79a143e9aa8d@github.com>

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
> 
> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
> I think we should remove this code as well and the related tests for it.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/978