MarkMail: net.java.openjdk

Re: CFV: New OpenJDK Members Group Member: Doug Simon

2023-07-31T08:59:30-07:00

From:	Philip Race (phil...@oracle.com)
List:	net.java.openjdk.members

Vote : yes

-phil.

Re: CFV: New OpenJDK Members Group Member: Doug Simon

2023-07-31T15:35:19+01:00

From:	Daniel Fuchs (dani...@oracle.com)
List:	net.java.openjdk.members

Vote: yes

best regards,

-- daniel

On 25/07/2023 09:07, Andrew Dinn wrote:

I hereby nominate Doug Simon [1] to membership in the OpenJDK Members Group.

[SECURITY] IcedTea 3.28.0 for OpenJDK 8 Released!

2023-07-29T02:03:32+01:00

From:	Andrew Hughes (gnu_...@member.fsf.org)
List:	net.java.openjdk.distro-pkg-dev

We are pleased to announce the release of IcedTea 3.28.0!

The IcedTea project provides a harness to build the source code from OpenJDK using Free Software build tools, along with additional features such as the ability to build against system libraries and support for alternative virtual machines and architectures beyond those supported by OpenJDK.

This release updates our OpenJDK 8 support with the July 2023 security fixes from OpenJDK 8u382.

If you find an issue with the release, please report it to our bug database (http://icedtea.classpath.org/bugzilla) under the appropriate component. Development discussion takes place on the distro-pkg-dev at openjdk.org mailing list and patches are always welcome.

Full details of the release can be found below.

What's New? =========== New in release 3.28.0 (2023-07-28):

* CVEs - CVE-2023-22045 - CVE-2023-22049 * Security fixes - JDK-8298676: Enhanced Look and Feel - JDK-8300596: Enhance Jar Signature validation - JDK-8304468: Better array usages - JDK-8305312: Enhanced path handling * Import of OpenJDK 8 u382 build 05 - JDK-8072678: Wrong exception messages in java.awt.color.ICC_ColorSpace - JDK-8151460: Metaspace counters can have inconsistent values - JDK-8152432: Implement setting jtreg @requires properties vm.flavor,
vm.bits, vm.compMode - JDK-8185736: missing default exception handler in calls to rethrow_Stub - JDK-8186801: Add regression test to test mapping based charsets (generated
at build time) - JDK-8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong
Pixel Color - JDK-8241311: Move some charset mapping tests from closed to open - JDK-8263059:
security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java
fails due to revoked cert - JDK-8268558: [TESTBUG] Case 2 in TestP11KeyFactoryGetRSAKeySpec is skipped - JDK-8271199: Mutual TLS handshake fails signing client certificate with
custom sensitive PKCS11 key - JDK-8276841: Add support for Visual Studio 2022 - JDK-8277881: Missing SessionID in TLS1.3 resumption in compatibility mode - JDK-8278851: Correct signer logic for jars signed with multiple digest
algorithms - JDK-8282345: handle latest VS2022 in abstract_vm_version - JDK-8282600: SSLSocketImpl should not use user_canceled workaround when not
necessary - JDK-8285515: (dc) DatagramChannel.disconnect fails with "Invalid argument"
on macOS 12.4 - JDK-8289301: P11Cipher should not throw out of bounds exception during
padding - JDK-8293232: Fix race condition in pkcs11 SessionManager - JDK-8293815: P11PSSSignature.engineUpdate should not print debug messages
during normal operation - JDK-8295530: Update Zlib Data Compression Library to Version 1.2.13 - JDK-8298108: Add a regression test for JDK-8297684 - JDK-8298271:
java/security/SignedJar/spi-calendar-provider/TestSPISigned.java failing on
Windows - JDK-8301119: Support for GB18030-2022 - JDK-8301400: Allow additional characters for GB18030-2022 support - JDK-8302791: Add specific ClassLoader object to Proxy
IllegalArgumentException message - JDK-8303028: Update system property for Java SE specification maintenance
version - JDK-8303462: Bump update version of OpenJDK: 8u382 - JDK-8304760: Add 2 Microsoft TLS roots - JDK-8305165: [8u] ServiceThread::nmethods_do is not called to keep nmethods
from being zombied while in the queue - JDK-8305681: Allow additional characters for GB18030-2022 (Level 2) support - JDK-8305975: Add TWCA Global Root CA - JDK-8307134: Add GTS root CAs - JDK-8307310: Backport the tests for JDK-8058969 and JDK-8039271 to the
OpenJDK8 - JDK-8307531: [aarch64] JDK8 single-step debugging is extremely slow - JDK-8310947: gb18030-2000 not selectable with LANG=zh_CN.GB18030 after
JDK-8301119

The tarballs can be downloaded from:

* http://icedtea.classpath.org/download/source/icedtea-3.28.0.tar.gz * http://icedtea.classpath.org/download/source/icedtea-3.28.0.tar.xz

We provide both gzip and xz tarballs, so that those who are able to make use of the smaller tarball produced by xz may do so.

The tarballs are accompanied by digital signatures available at:

* http://icedtea.classpath.org/download/source/icedtea-3.28.0.tar.gz.sig * http://icedtea.classpath.org/download/source/icedtea-3.28.0.tar.xz.sig

These are produced using my public key. See details below.

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew

GnuPG >= 2.1 is required to be able to handle this key.

SHA256 checksums:

f9396a18d1ef1c9f898034c2ba430de64a331c92a2a4bf21dd4b628643a1b21d
icedtea-3.28.0.tar.gz c23623652120973fb762977568cfe4b0866f63ca6132e18dc6124a81046f19b1
icedtea-3.28.0.tar.gz.sig 822697a4f0039ec312cc143df40916fc8b68fbfe49c2631186bbba83bd6c5c8d
icedtea-3.28.0.tar.xz f4c53bc28bff2162c41a26e27213902ab81336b682f6db566152a6e800b37d7a
icedtea-3.28.0.tar.xz.sig

The checksums can be downloaded from:

* http://icedtea.classpath.org/download/source/icedtea-3.28.0.sha256

The following people helped with this release:

* Andrew Hughes (all bug fixes and backports, release management)

We would also like to thank the bug reporters and testers!

To get started:

$ tar xzf icedtea-3.28.0.tar.gz

or:

$ tar x -I xz -f icedtea-3.28.0.tar.xz

then:

$ mkdir icedtea-build $ cd icedtea-build $ ../icedtea-3.28.0/configure $ make

Full build requirements and instructions are available in the INSTALL file.

Happy hacking!

-- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

Please contact via e-mail, not proprietary chat networks Available on Libera Chat & OFTC IRC networks as gnu_andrew

Re: JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up

2023-07-28T12:46:17Z

From:	David Delabassee (davi...@oracle.com)
List:	net.java.openjdk.quality-discuss

It is obviously JDK *21* that is in RDP2, not JDK 22!

--David

From: quality-discuss <qual...@openjdk.org> on behalf of David
Delabassee <davi...@oracle.com> Date: Friday, 28 July 2023 at 12:12 To: qual...@openjdk.org <qual...@openjdk.org> Subject: JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up Welcome to the OpenJDK Quality Outreach summer update.

JDK 21 is now in Rampdown Phase Two [1], its overall feature has been frozen a
few weeks ago. Per the JDK Release Process [2] we have now turned our focus to
P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are
still possible, with approval, but the bar is now extraordinarily high [4]. That
also means that the JDK 21 Initial Release Candidates are fast approaching,
i.e., August 10 [5]. So, and in addition to testing your projects with the
latest JDK 21 early-access builds, it is now also a good time to start testing
with the JDK 22 early-access builds.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-July/008034.html [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process [5] https://openjdk.org/projects/jdk/21/

## Heads-up - JDK 21 & JDK 22: Note if implicit annotation processing is being
used

Annotation processing by javac is enabled by default, including when no
annotation processing configuration options are present. We are considering
disabling implicit annotation processing by default in a future release,
possibly as early as JDK 22 [6]. To alert javac users of this possibility, as of
JDK 21 b29 and JDK 22 b04, javac prints a note if implicit annotation processing
is being used [7]. The reported note is:

Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable annotation processing unless at least one processor is specified by name (-processor), or a search path is specified (--processor-path, --processor-module-path), or annotation processing is enabled explicitly (-proc:only, -proc:full). Use -Xlint:-options to suppress this message. Use -proc:none to disable annotation processing.

Good build hygiene includes explicitly configuring annotation processing. To
ease the transition to a different default policy in the future, the
new-in-JDK-21 `-proc:full` javac option requests the current default behavior of
looking for annotation processors on the class path.

[6] https://bugs.openjdk.org/browse/JDK-8306819 [7] https://bugs.openjdk.org/browse/JDK-8310061

## Heads-up - JDK 22: JLine is now the Default Console Provider

In JDK 22, `System.console()` has been changed [8] to return a `Console` with
enhanced editing features that improve the experience of programs that use the
`Console` API. In addition, `System.console()` now returns a `Console` object
when the standard streams are redirected or connected to a virtual terminal.
Prior to JDK 22, `System.console()` instead returned `null` for these cases.
This change may impact code that checks the return from `System.console()` to
test if the JVM is connected to a terminal. If required, the
`-Djdk.console=java.base` flag will restore the old behavior where the console
is only returned when it is connected to a terminal. Starting JDK 22, one could
also use the new `Console.isTerminal()` method to test if the console is
connected to a terminal.

[8] https://bugs.openjdk.org/browse/JDK-8308591

## JDK 21 Early-Access Builds

The JDK 21 early-access builds 33 are available [9], and are provided under the
GNU General Public License v2, with the Classpath Exception. The Release Notes
are available here [10] and the Javadoc here [11].

[9] https://jdk.java.net/21/ [10] https://jdk.java.net/21/release-notes [11] https://download.java.net/java/early_access/jdk21/docs/api/

## JDK 22 Early-Access Builds

The JDK 22 early-access builds 8 are available [12], and are provided under the
GNU General Public License v2, with the Classpath Exception. The Release Notes
are available here [13].

[12] https://openjdk.org/projects/jdk/22 [13] https://jdk.java.net/22/release-notes

### Changes in recent JDK 22 builds (b2-b8) that may be of interest:

Note that this is only a curated list of changes, make sure to check [14] for
additional changes.

- JDK-8309882: LinkedHashMap adds an errant serializable field [Reported by
Eclipse Collections] - JDK-8312366: [arm32] Build crashes after JDK-8310233 [Reported by JaCoCo] - JDK-8167252: Some of Charset.availableCharsets() does not contain itself
[Reported by IntelliJ] - JDK-8310061: Note if implicit annotation processing is being used - JDK-8308591: JLine as the default Console provider - JDK-8312019: Simplify and modernize java.util.BitSet.equals - JDK-8308593: Add KEEPALIVE Extended Socket Options Support for Windows - JDK-8227229: Deprecate the launcher -Xdebug/-debug flags that have not done
anything since Java 6 - JDK-6983726: Reimplement MethodHandleProxies.asInterfaceInstance - JDK-8281658: Add a security category to the java -XshowSettings option - JDK-8310201: Reduce verbose locale output in -XshowSettings launcher option - JDK-8295894: Remove SECOM certificate that is expiring in September 2023 - JDK-8027711: Unify wildcarding syntax for CompileCommand and CompileOnly - JDK-8282797: CompileCommand parsing errors should exit VM - JDK-8305104: Remove the old core reflection implementation - JDK-8310460: Remove jdeps -profile option - JDK-8309032: jpackage does not work for module projects unless --module-path
is specified - JDK-8291065: Creating a VarHandle for a static field triggers class
initialization - JDK-8312072: Deprecate for removal the -Xnoagent option - JDK-8304885: Reuse stale data to improve DNS resolver resiliency= - JDK-8310047: Add UTF-32 based Charsets into StandardCharsets - JDK-8302483: Enhance ZIP performance - JDK-8300596: New System Property to Control the Maximum Size of Signature
Files - JDK-8294323: ASLR Support for CDS Archive - JDK-8311038: Incorrect exhaustivity computation - JDK-8312089: Simplify and modernize equals, hashCode, and compareTo in
java.nio… - JDK-8311188: Simplify and modernize equals and hashCode in java.text - JDK-8300285: Enhance TLS data handling - JDK-8302475: Enhance HTTP client file downloading

[14] https://github.com/openjdk/jdk/compare/jdk-22%2B1...jdk-22%2B8

## JavaFX Early-Access Builds

These are early access builds of the JavaFX 21 Runtime, built from openjdk/jfx
[15]. They enable JavaFX application developers to build and test their
applications with JavaFX 21 on JDK 21.

The latest JavaFX 21 early-access builds (build 27 - 2023/7/21) are now
available [16] with their related Javadoc [17]. Moreover, the initial JavaFX 22
early-access builds [18] are now also available. These early-access builds are
provided under the GNU General Public License, version 2, with the Classpath
Exception. Please send feedback to the openjfx-dev mailing list [19].

[15] https://github.com/openjdk/jfx [16] https://jdk.java.net/javafx21/ [17]
https://download.java.net/java/early_access/javafx21/docs/api/overview-summary.html [18] https://jdk.java.net/javafx22/ [19] http://mail.openjdk.org/mailman/listinfo/openjfx-dev

## Topics of Interest:

Foreign Function & Memory API Summer Update https://mail.openjdk.org/pipermail/panama-dev/2023-July/019510.html

What's Arriving for JFR in JDK 21 - Inside Java Newscast #53 https://inside.java/2023/07/20/java-21-jfr/

Java's Startup Booster: CDS - Stack Walker https://inside.java/2023/07/11/javas-startup-booster-cds/

## July 2023 Critical Patch Update Released

As part of the July 2023 CPU, Oracle released OpenJDK 20.0.2, JavaFX 20.0.2, JDK
20.0.2, JDK 17.0.8 LTS, JDK 11.0.20 LTS, JDK 8u381, as well as JDK 8u381-perf.

We still have a few days before JDK 21 enters into the Release Candidate phase
so please make sure to test your projects on the latest early-access builds and
report any issue.

PS: Make sure to enjoy the summer and recharge your batteries! 😎

--David

Re: CFV: New OpenJDK Members Group Member: Doug Simon

2023-07-28T07:54:47-04:00

From:	Frederic Parain (fred...@oracle.com)
List:	net.java.openjdk.members

Vote: yes

Fred

On 7/25/23 4:07 AM, Andrew Dinn wrote:

I hereby nominate Doug Simon [1] to membership in the OpenJDK Members Group.

Doug has led the Graal project [2] since its inception and was recently made project lead for the Galahad project [3], with numerous contributions to both projects. Doug is also an OpenJDK project Reviewer with an accompanying history of contributions to the OpenJDK development tree [4].

Votes are due by 23:00(CUT) Tuesday 8th August.

Only current members of the OpenJDK Members Group [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [6].

[1] https://openjdk.org/census#dnsimon [2] http://openjdk.org/projects/graal [3] http://openjdk.org/projects/galahad [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+is%3Aclosed+dougxc+author%3Adougxc [5] https://openjdk.org/census#members [6] https://openjdk.org/bylaws#lazy-consensus

Andrew Dinn

----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill

JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up

2023-07-28T10:11:53Z

From:	David Delabassee (davi...@oracle.com)
List:	net.java.openjdk.quality-discuss

Welcome to the OpenJDK Quality Outreach summer update.

## Heads-up - JDK 21 & JDK 22: Note if implicit annotation processing is being
used

[6] https://bugs.openjdk.org/browse/JDK-8306819 [7] https://bugs.openjdk.org/browse/JDK-8310061

## Heads-up - JDK 22: JLine is now the Default Console Provider

[8] https://bugs.openjdk.org/browse/JDK-8308591

## JDK 21 Early-Access Builds

[9] https://jdk.java.net/21/ [10] https://jdk.java.net/21/release-notes [11] https://download.java.net/java/early_access/jdk21/docs/api/

## JDK 22 Early-Access Builds

The JDK 22 early-access builds 8 are available [12], and are provided under the
GNU General Public License v2, with the Classpath Exception. The Release Notes
are available here [13].

[12] https://openjdk.org/projects/jdk/22 [13] https://jdk.java.net/22/release-notes

### Changes in recent JDK 22 builds (b2-b8) that may be of interest:

Note that this is only a curated list of changes, make sure to check [14] for
additional changes.

[14] https://github.com/openjdk/jdk/compare/jdk-22%2B1...jdk-22%2B8

## JavaFX Early-Access Builds

These are early access builds of the JavaFX 21 Runtime, built from openjdk/jfx
[15]. They enable JavaFX application developers to build and test their
applications with JavaFX 21 on JDK 21.

## Topics of Interest:

Foreign Function & Memory API Summer Update https://mail.openjdk.org/pipermail/panama-dev/2023-July/019510.html

What's Arriving for JFR in JDK 21 - Inside Java Newscast #53 https://inside.java/2023/07/20/java-21-jfr/

Java's Startup Booster: CDS - Stack Walker https://inside.java/2023/07/11/javas-startup-booster-cds/

## July 2023 Critical Patch Update Released

As part of the July 2023 CPU, Oracle released OpenJDK 20.0.2, JavaFX 20.0.2, JDK
20.0.2, JDK 17.0.8 LTS, JDK 11.0.20 LTS, JDK 8u381, as well as JDK 8u381-perf.

We still have a few days before JDK 21 enters into the Release Candidate phase
so please make sure to test your projects on the latest early-access builds and
report any issue.

PS: Make sure to enjoy the summer and recharge your batteries! 😎

--David

Re: RFR: 7903513: Update version to 7.4

2023-07-27T15:45:09Z

From:	Jonathan Gibbons (jj...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

On Thu, 27 Jul 2023 15:36:18 GMT, Christian Stein <cst...@openjdk.org> wrote:

Update jtreg's version to 7.4

Tough one; have to think long and hard about this ...

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

Marked as reviewed by jjg (Lead).

PR Review: https://git.openjdk.org/jtreg/pull/163#pullrequestreview-1550165261

Integrated: 7903513: Update version to 7.4

2023-07-27T15:45:09Z

From:	Christian Stein (cst...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

On Thu, 27 Jul 2023 15:36:18 GMT, Christian Stein <cst...@openjdk.org> wrote:

Update jtreg's version to 7.4

This pull request has now been integrated.

Changeset: b9c6dcd3 Author: Christian Stein <cst...@openjdk.org> URL:
https://git.openjdk.org/jtreg/commit/b9c6dcd3e87bfa9017ec6a485ca3917b0cfec997 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

7903513: Update version to 7.4

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jtreg/pull/163

jmx-dev Integrated: 8313174: Create fewer predictable port clashes in management tests

2023-07-27T15:43:05Z

From:	Kevin Walls (kev...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Wed, 26 Jul 2023 10:50:09 GMT, Kevin Walls <kev...@openjdk.org> wrote:

Specifically noticed on linux-aarch64, detection of port clashes by
LocateRegistry.createRegistry(port) appears "racy".

Predictable port clashes can be avoided, tests that are likely to run at the
same time should not choose the same port.

Why now? The RMI related parts are obviously fairly stable these days, as are
the tests themselves. Our OS version/host mix for testing may have changed. The problems I looked
into were on ol8-aarch64.

It doesn't seem necessary to add complexities to the tests, or change
LocateRegistry much at this point, when a simple change to the tests can avoid
asking for so many port clashes.

test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java:
int port = 5800; // 5801 to 5820 test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java:
int port = 5800; // 5821 to 5840 test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java:
int port = 5800; // 5841 to 5860 test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java:
int port = 5800; // 5861 to 5880 test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java:
int port = 5800; // 5881 to 5900 test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java:
int port = 5800; // 5901 to 5920

This pull request has now been integrated.

Changeset: 169b6e3c Author: Kevin Walls <kev...@openjdk.org> URL:
https://git.openjdk.org/jdk/commit/169b6e3cff8f9e0e09cdd5145c2dfe73a88519d1 Stats: 17 lines in 6 files changed: 0 ins; 0 del; 17 mod

8313174: Create fewer predictable port clashes in management tests

Reviewed-by: cjplummer, amenkov

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

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

Re: jmx-dev RFR: 8313174: Create fewer predictable port clashes in management tests [v2]

2023-07-27T15:43:03Z

From:	Kevin Walls (kev...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kev...@openjdk.org> wrote:

Specifically noticed on linux-aarch64, detection of port clashes by
LocateRegistry.createRegistry(port) appears "racy".

Predictable port clashes can be avoided, tests that are likely to run at the
same time should not choose the same port.

It doesn't seem necessary to add complexities to the tests, or change
LocateRegistry much at this point, when a simple change to the tests can avoid
asking for so many port clashes.

Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:

port range fix

Thanks Chris, thanks Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/15039#issuecomment-1653870034

RFR: 7903513: Update version to 7.4

2023-07-27T15:41:12Z

From:	Christian Stein (cst...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

Update jtreg's version to 7.4

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

Commit messages: - 7903513: Update version to 7.4

Changes: https://git.openjdk.org/jtreg/pull/163/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=163&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903513 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jtreg/pull/163.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/163/head:pull/163

PR: https://git.openjdk.org/jtreg/pull/163

Integrated: 7903512: Update changelog for jtreg 7.3

2023-07-27T15:15:09Z

From:	Christian Stein (cst...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

On Wed, 26 Jul 2023 15:27:23 GMT, Christian Stein <cst...@openjdk.org> wrote:

Please review this update to the changelog for jtreg 7.3.

This commit also tidies up the **display names** of the version headers: from
`7.1.1+1` to a more human-readable form of `7.1.1`. The underlying tag names are
kept as-is.

This pull request has now been integrated.

Changeset: e8a79680 Author: Christian Stein <cst...@openjdk.org> URL:
https://git.openjdk.org/jtreg/commit/e8a796803490f83da6893112af8f487489f4a349 Stats: 34 lines in 1 file changed: 16 ins; 8 del; 10 mod

7903512: Update changelog for jtreg 7.3

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jtreg/pull/162

Re: RFR: 7903512: Update changelog for jtreg 7.3

2023-07-27T14:28:05Z

From:	Jonathan Gibbons (jj...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

On Wed, 26 Jul 2023 15:27:23 GMT, Christian Stein <cst...@openjdk.org> wrote:

Please review this update to the changelog for jtreg 7.3.

This commit also tidies up the **display names** of the version headers: from
`7.1.1+1` to a more human-readable form of `7.1.1`. The underlying tag names are
kept as-is.

Marked as reviewed by jjg (Lead).

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

PR Review: https://git.openjdk.org/jtreg/pull/162#pullrequestreview-1549984900

Re: CFV: New OpenJDK Members Group Member: Doug Simon

2023-07-27T10:07:00-04:00

From:	Chris Phillips (Chri...@LGonQn.Org)
List:	net.java.openjdk.members

Vote: Yes

Cheers, Chris

On 2023-07-25 04:07, Andrew Dinn wrote:

I hereby nominate Doug Simon [1] to membership in the OpenJDK Members Group.

Votes are due by 23:00(CUT) Tuesday 8th August.

Only current members of the OpenJDK Members Group [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [6].

Andrew Dinn

----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill

RE: CFV: New OpenJDK Members Group Member: Doug Simon

2023-07-27T09:09:59Z

From:	Langer, Christoph (chri...@sap.com)
List:	net.java.openjdk.members

Vote: yes

/Christoph

-----Original Message----- From: members <memb...@openjdk.org> On Behalf Of Andrew Dinn Sent: Dienstag, 25. Juli 2023 10:08 To: members <memb...@openjdk.java.net> Subject: CFV: New OpenJDK Members Group Member: Doug Simon

I hereby nominate Doug Simon [1] to membership in the OpenJDK Members Group.

Votes are due by 23:00(CUT) Tuesday 8th August.

Only current members of the OpenJDK Members Group [5] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [6].

[1] https://openjdk.org/census#dnsimon [2] http://openjdk.org/projects/graal [3] http://openjdk.org/projects/galahad [4] https://github.com/openjdk/jdk/pulls?q=is%3Apr+is%3Aclosed+dougxc+aut hor%3Adougxc [5] https://openjdk.org/census#members [6] https://openjdk.org/bylaws#lazy-consensus

Andrew Dinn

----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill

RFR: 7903512: Update changelog for jtreg 7.3

2023-07-27T07:28:12Z

From:	Christian Stein (cst...@openjdk.org)
List:	net.java.openjdk.jtreg-dev

Please review this update to the changelog for jtreg 7.3.

This commit also tidies up the **display names** of the version headers. From
`7.1.1+1` to a more human-readable form of `7.1.1`. The underlying tag names are
kept as-is.

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

Commit messages: - 7903512: Update changelog for jtreg 7.3

Changes: https://git.openjdk.org/jtreg/pull/162/files Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=162&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903512 Stats: 34 lines in 1 file changed: 16 ins; 8 del; 10 mod Patch: https://git.openjdk.org/jtreg/pull/162.diff Fetch: git fetch https://git.openjdk.org/jtreg.git pull/162/head:pull/162

PR: https://git.openjdk.org/jtreg/pull/162

Re: jmx-dev RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

2023-07-27T07:14:56Z

From:	David Holmes (dhol...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee <ph...@openjdk.org> wrote:

MonitoringSupport_lock is initialized only when UseG1GC is true, but
[JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement
getTotalThreadAllocatedBytes, which is available for all garbage collectors.
While the current code sets UseG1GC regardless of which collector is specified,
see FLAG_SET_ERGO_IF_DEFAULT(UseG1GC, true) in gcConfig.cpp, if G1 isn't
included in the Hotspot build or Hotspot is not running on a server class
machine (unlikely these days), the lock will not be initialized. The lock's
initialization should be unconditional.

I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial
collectors.

Paul Hohensee has updated the pull request incrementally with one additional
commit since the last revision:

8313081: MonitoringSupport_lock should be unconditionally initialized after
8304074

src/hotspot/share/services/management.cpp line 2119:

2117: 2118: { 2119: assert(MonitoringSupport_lock != nullptr, "Must be");

This was unnecessary. If you have this here you would have one before every
single use of mutex that is expected to be non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15028#discussion_r1275828276

Re: jmx-dev RFR: 8313174: Create fewer predictable port clashes in management tests [v2]

2023-07-26T21:23:52Z

From:	Alex Menkov (amen...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kev...@openjdk.org> wrote:

Specifically noticed on linux-aarch64, detection of port clashes by
LocateRegistry.createRegistry(port) appears "racy".

Predictable port clashes can be avoided, tests that are likely to run at the
same time should not choose the same port.

It doesn't seem necessary to add complexities to the tests, or change
LocateRegistry much at this point, when a simple change to the tests can avoid
asking for so many port clashes.

Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:

port range fix

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548612980

jmx-dev Integrated: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

2023-07-26T19:33:49Z

From:	Paul Hohensee (ph...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee <ph...@openjdk.org> wrote:

I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial
collectors.

This pull request has now been integrated.

Changeset: a9d21c61 Author: Paul Hohensee <ph...@openjdk.org> URL:
https://git.openjdk.org/jdk/commit/a9d21c61fb12a11e18c6bb8aa903e5a8e42473f1 Stats: 17 lines in 3 files changed: 12 ins; 2 del; 3 mod

8313081: MonitoringSupport_lock should be unconditionally initialized after
8304074

Reviewed-by: dholmes, sspitsyn, shade

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

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

Re: jmx-dev RFR: 8313174: Create fewer predictable port clashes in management tests [v2]

2023-07-26T18:32:41Z

From:	Chris Plummer (cjpl...@openjdk.org)
List:	net.java.openjdk.jmx-dev

On Wed, 26 Jul 2023 18:06:56 GMT, Kevin Walls <kev...@openjdk.org> wrote:

Specifically noticed on linux-aarch64, detection of port clashes by
LocateRegistry.createRegistry(port) appears "racy".

Predictable port clashes can be avoided, tests that are likely to run at the
same time should not choose the same port.

It doesn't seem necessary to add complexities to the tests, or change
LocateRegistry much at this point, when a simple change to the tests can avoid
asking for so many port clashes.

Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:

port range fix

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548364525