Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks, Kevin. When your fix turns up in a JDK release, I'll test drive
it. Then I may be able to back out the changes which I made to the Derby
tests and docs.
On 1/10/23 6:20 AM, Kevin Walls wrote:
Hi, that's great!
Maybe the remoteDeserializationEnabled() method is no longer needed? (
derbyTesting/functionTests/tests/management/CacheManagerMBeanTest.java )
Actually hold that thought while I tell you why I just logged a new JDK bug...
The JDK Core Libraries guide has more detail on Serialization Filters. There
is logging to show exactly what is rejected.
https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-6A048F49-052E-4591-9183-2775DC50831E
If I edit the jdk/conf/logging.properties file and uncomment the line:
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
and add:
java.io.serialization.level = FINE
..then I get a ~/java0.log in the home directory after the test. The failing
class is:
ObjectInputFilter REJECTED: class javax.management.Attribute, array
length: -1, nRefs: 1, depth: 1, bytes: 102, ex: n/a
Adding javax.management.Attribute to the list in management.properties works.
I'm thinking this should be in the list by default: the filter is intended to
need customisation for non-standard classes, but the basics should work
automatically.
The Derby test is calling: setAttribute(name, "CollectAccessCounts",
Boolean.TRUE);
...so not trying to transfer any of its own types across the connection, so
this probably is a bug in the filter value. If the parameters included
Derby-specific classes, you would expect to fail with the default filter and
need customisation.
Will follow this up in the JDK bug: https://bugs.openjdk.org/browse/JDK-8299891
Thanks!
Kevin
-Original Message-
From: Rick Hillegas
Sent: 09 January 2023 21:19
To: Kevin Walls ; derby-dev@db.apache.org
Cc: David Delabassee
Subject: Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds
Thanks for running that experiment, Kevin. I have reproduced your results,
re-enabled the skipped MBean tests, and documented this on
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7149__;!!ACWV5N9M2RV99hQ!JMEmA854HVODhgZXeDIVPYms8W096aLG-_TDeYhrp08mYMdNU38xKiOHS4f_Nl1SUz8x4UtmWOlqeW6LVkEpqR5Z$
.
While I have your attention, what should developers do when they see a
"java.io.InvalidClassException: filter status: REJECTED" error? Is there a way
to tease out which classes are failing deserialization so that the filter can be tailored
exactly? It would be nice to give users a workaround more subtle than turning off the
deserialization filter completely.
Thanks,
-Rick
On 1/6/23 3:59 PM, Kevin Walls wrote:
Hi Rick,
A little more on this MBean test situation. I think it was just that the
database itself was not running with the updated filter property setting.
I could reproduce the failure with:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBe
anTest
I could see that passing -D to the test app to relax the filter, does not pass
the -D to the spawned database process.
I can't see a way to do that with a setting, maybe there is a property
somewhere, but to test it I added a parameter in the method that sets up the
command line for MBean tests:
"../java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java"
124 protected static String[] getCommandLineProperties(boolean
authentication)
125 {
126 ArrayList list = new ArrayList();
127 list.add("com.sun.management.jmxremote.serial.filter.pattern=");
...etc...
...and rebuilding, I no longer see a failure.
Hopefully this, or something similar, can be used. There is no harm in
setting the filter pattern in earlier JDKs, where it defaults to being blank.
It would be great to update the recent edit about there being no way to set
this property, as that seems misleading. Apologies I didn't get here quick
enough to avoid that edit!
Thanks,
Kevin
From: Kevin Walls
Sent: 05 January 2023 13:54
To: rick.hille...@gmail.com
Cc: derby-dev@db.apache.org
Subject: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds
Hi Rick,
David pointed me at this thread about the ObjectInputFilter and Derby. I see
the notes on the use of -D to set a filter to run the test, but am unsure how
the database itself is started. That is in another process? (I think it's on
the same system, because you had success when changing the management
properties file.) How do we ensure that process is started with the same
arguments/filter pattern? (That is the process where we need the filter either
relaxed, or made more specific).
Thanks
Kevin
Re: FW: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for running that experiment, Kevin. I have reproduced your
results, re-enabled the skipped MBean tests, and documented this on
https://issues.apache.org/jira/browse/DERBY-7149.
While I have your attention, what should developers do when they see a
"java.io.InvalidClassException: filter status: REJECTED" error? Is there
a way to tease out which classes are failing deserialization so that the
filter can be tailored exactly? It would be nice to give users a
workaround more subtle than turning off the deserialization filter
completely.
Thanks,
-Rick
On 1/6/23 3:59 PM, Kevin Walls wrote:
Hi Rick,
A little more on this MBean test situation. I think it was just that the
database itself was not running with the updated filter property setting.
I could reproduce the failure with:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
I could see that passing -D to the test app to relax the filter, does not pass
the -D to the spawned database process.
I can't see a way to do that with a setting, maybe there is a property
somewhere, but to test it I added a parameter in the method that sets up the
command line for MBean tests:
"../java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/management/MBeanTest.java"
124 protected static String[] getCommandLineProperties(boolean
authentication)
125 {
126 ArrayList list = new ArrayList();
127 list.add("com.sun.management.jmxremote.serial.filter.pattern=");
...etc...
...and rebuilding, I no longer see a failure.
Hopefully this, or something similar, can be used. There is no harm in
setting the filter pattern in earlier JDKs, where it defaults to being blank.
It would be great to update the recent edit about there being no way to set
this property, as that seems misleading. Apologies I didn't get here quick
enough to avoid that edit!
Thanks,
Kevin
From: Kevin Walls
Sent: 05 January 2023 13:54
To: rick.hille...@gmail.com
Cc: derby-dev@db.apache.org
Subject: Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4
Early-Access builds
Hi Rick,
David pointed me at this thread about the ObjectInputFilter and Derby. I see
the notes on the use of -D to set a filter to run the test, but am unsure how
the database itself is started. That is in another process? (I think it's on
the same system, because you had success when changing the management
properties file.) How do we ensure that process is started with the same
arguments/filter pattern? (That is the process where we need the filter either
relaxed, or made more specific).
Thanks
Kevin
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi David, Derby now builds and tests cleanly after the changes introduced by Open JDK build 20-ea+27-2213. Our experience is described at https://issues.apache.org/jira/browse/DERBY-7149. Thanks, -Rick On 12/21/22 2:27 AM, David Delabassee wrote: Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154 Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for the quick response, David. I'm afraid I'm still confused.
Editing conf/management/management.properties to set
com.sun.management.jmxremote.serial.filter.pattern=*
causes
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
to run cleanly. However, if I add the following debug printout to the
test...
System.out.println("XXX
com.sun.management.jmxremote.serial.filter.pattern = " +
System.getProperty("com.sun.management.jmxremote.serial.filter.pattern"));
System.out.flush();
...then I get the following result:
XXX com.sun.management.jmxremote.serial.filter.pattern = null
If I revert management.properties to the JDK default and then set the
property on the boot command line,
java -Dcom.sun.management.jmxremote.serial.filter.pattern=*
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
...the test prints out
XXX com.sun.management.jmxremote.serial.filter.pattern = *
but the test fails. It appears that the property is not a system
property, but is managed somewhere else. Is there a way to override this
property other than by editing conf/management/management.properties? Do
developers have to hack the JDK in order to get MBeans to function?
Thanks,
-Rick
On 12/21/22 10:06 PM, David Delabassee wrote:
Hi Rick,
Just to confirm, the params passed below in your tests are passed to
the JVM that is throwing the exception, right ?
Can you try to comment the filter in
`JDK/conf/management/management.properties` ?
--David
On 21/12/2022 19:25, Rick Hillegas wrote:
Thanks for those pointers, David. I'm afraid that my naive attempts
have failed to circumvent this filtering. All of the following
commands fail with the same "java.io.InvalidClassException: filter
status: REJECTED" error:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
java -Djdk.serialFilter=* junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
java -Dcom.sun.management.jmxremote.serial.filter.pattern=*
junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest
Any advice you can give would be appreciated.
-Rick
On 12/21/22 2:27 AM, David Delabassee wrote:
Hi Rick,
There's now a default serialization filter for JMX since 20-EA build
22 (1), see release notes (2) and test (3). To confirm this is
indeed the issue, you can either relax the filter to allow your
target classes to be deserialized, or disable the filter.
(1) https://bugs.openjdk.org/browse/JDK-8283093
(2) https://bugs.openjdk.org/browse/JDK-8295938
(3)
https://urldefense.com/v3/__https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154__;!!ACWV5N9M2RV99hQ!NpoMjRUQIuayUbvdDVPAmCP3yMP2w6j3kcsIwQah_EzbUtfJpF6uv2K8AQXJznGfVIVn0pBm3umXdjiqGYyjzdgzGiCc$
Thanks,
--David
On 21/12/2022 02:36, Rick Hillegas wrote:
Hi David,
Open JDK build 20-ea+27-2213 introduces another problem. I see the
following error when unmarshalling an object on behalf of an MBean:
java.io.InvalidClassException: filter status: REJECTED
I do not see this problem under build 19+36-2238.
Can you point me at the experts who can advise me on how to address
this issue?
Thanks,
-Rick
On 12/12/22 2:07 AM, David Delabassee wrote:
Welcome to the final OpenJDK Quality Outreach update for 2022!
JDK 20, scheduled for General Availability on March 21 2023, is
now in Rampdown Phase One (RDP1) [1]. At this point, the overall
JDK 20 [2] feature set is frozen (see below the final list of JEPs
integrated into JDK 20) and only low-risk enhancements might still
be considered. The coming weeks should be used to identify and
resolve as many issues as possible, i.e. before JDK 20 enters the
Release Candidates phase in early February 2023.
## JDK 20 Early-Access builds
The latest Early-Access (builds 27) are available [2] with the
Release Notes here [3]. Those builds are provided under the GNU
GPL v2, with the Classpath Exception.
### JEPs integrated into JDK 20:
JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)
[1]
https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2]
https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$
[3]
https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$
### Changes in recent JDK 20 builds that may be of interest:
Build 27:
- JDK-8297794: Deprecate J
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi Rick, Just to confirm, the params passed below in your tests are passed to the JVM that is throwing the exception, right ? Can you try to comment the filter in `JDK/conf/management/management.properties` ? --David On 21/12/2022 19:25, Rick Hillegas wrote: Thanks for those pointers, David. I'm afraid that my naive attempts have failed to circumvent this filtering. All of the following commands fail with the same "java.io.InvalidClassException: filter status: REJECTED" error: java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Djdk.serialFilter=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Dcom.sun.management.jmxremote.serial.filter.pattern=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest Any advice you can give would be appreciated. -Rick On 12/21/22 2:27 AM, David Delabassee wrote: Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://urldefense.com/v3/__https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154__;!!ACWV5N9M2RV99hQ!NpoMjRUQIuayUbvdDVPAmCP3yMP2w6j3kcsIwQah_EzbUtfJpF6uv2K8AQXJznGfVIVn0pBm3umXdjiqGYyjzdgzGiCc$ Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilat
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Thanks for those pointers, David. I'm afraid that my naive attempts have failed to circumvent this filtering. All of the following commands fail with the same "java.io.InvalidClassException: filter status: REJECTED" error: java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Djdk.serialFilter=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest java -Dcom.sun.management.jmxremote.serial.filter.pattern=* junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.management.CacheManagerMBeanTest Any advice you can give would be appreciated. -Rick On 12/21/22 2:27 AM, David Delabassee wrote: Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154 Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes ##
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi Rick, There's now a default serialization filter for JMX since 20-EA build 22 (1), see release notes (2) and test (3). To confirm this is indeed the issue, you can either relax the filter to allow your target classes to be deserialized, or disable the filter. (1) https://bugs.openjdk.org/browse/JDK-8283093 (2) https://bugs.openjdk.org/browse/JDK-8295938 (3) https://github.com/openjdk/jdk20/commit/628820f47ef9c9ad3cc62e68db9c4dbc7e659154 Thanks, --David On 21/12/2022 02:36, Rick Hillegas wrote: Hi David, Open JDK build 20-ea+27-2213 introduces another problem. I see the following error when unmarshalling an object on behalf of an MBean: java.io.InvalidClassException: filter status: REJECTED I do not see this problem under build 19+36-2238. Can you point me at the experts who can advise me on how to address this issue? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTyiVEIUD$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!OqdzOerVCrwa1pDUQisIwaR0A2LNK9SOsJuYn2zDbXx3jTrmzCEkj-23LGHp_Oveh2PZXokzY1AdUBFBB1uoTzqxD5c4$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JDK 21: First Early-Access Builds When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a JDK 20 s
Re: [External] : Re: JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds
Hi Rick, I suggest to bring this on https://mail.openjdk.org/mailman/listinfo/net-dev Thanks, --David On 15/12/2022 00:06, Rick Hillegas wrote: Thanks for the heads-up, David. I see many deprecation warnings and javadoc warnings when I build Derby with Open JDK build 20-ea+27-2213. Right now, I am trying to track down a fix for the problems introduced by this change: - JDK-8294241: Deprecate URL public constructors My naive attempt to workaround this deprecation was to replace instances of new URL(urlString) with (new URI(urlString)).toURL() Unfortunately, this breaks Derby. I see errors like the following: java.lang.IllegalArgumentException: URI is not absolute at java.base/java.net.URL.of(URL.java:854) at java.base/java.net.URI.toURL(URI.java:1144) at org.apache.derby.impl.store.raw.RawStore.backup(RawStore.java:641) Can you point me at an expert who can advise me on best practices for working around this deprecation? Thanks, -Rick On 12/12/22 2:07 AM, David Delabassee wrote: Welcome to the final OpenJDK Quality Outreach update for 2022! JDK 20, scheduled for General Availability on March 21 2023, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] feature set is frozen (see below the final list of JEPs integrated into JDK 20) and only low-risk enhancements might still be considered. The coming weeks should be used to identify and resolve as many issues as possible, i.e. before JDK 20 enters the Release Candidates phase in early February 2023. ## JDK 20 Early-Access builds The latest Early-Access (builds 27) are available [2] with the Release Notes here [3]. Those builds are provided under the GNU GPL v2, with the Classpath Exception. ### JEPs integrated into JDK 20: JEP 429: Scoped Values (Incubator) JEP 432: Record Patterns (2nd Preview) JEP 433: Pattern Matching for switch (4th Preview) JEP 434: Foreign Function & Memory API (2nd Preview) JEP 436: Virtual Threads (2nd Preview) JEP 437: Structured Concurrency (2nd Incubator) [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html [2] https://urldefense.com/v3/__https://jdk.java.net/20/__;!!ACWV5N9M2RV99hQ!JlAX3Q24L6xKnmCWqVSLexNFj1Ur8YNiWzrUoN5g4vc3ks1238-ajUkxY3UuW2yFFOgqtyyYShAGPbi5Td8Z9h0LcELZ$ [3] https://urldefense.com/v3/__https://jdk.java.net/20/release-notes__;!!ACWV5N9M2RV99hQ!JlAX3Q24L6xKnmCWqVSLexNFj1Ur8YNiWzrUoN5g4vc3ks1238-ajUkxY3UuW2yFFOgqtyyYShAGPbi5Td8Z9pmawnai$ ### Changes in recent JDK 20 builds that may be of interest: Build 27: - JDK-8297794: Deprecate JMX Management Applets for Removal - JDK-8297118: Change IncompatibleClassChangeError to MatchException for exhaustive switch statements and switch expressions - JDK-8294047: HttpResponseInputStream swallows interrupts - JDK-8281236: (D)TLS key exchange named groups - JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification - JDK-8295350: JFR: Add stop methods for recording streams - JDK-8295044: Implementation of Foreign Function and Memory API (2nd Preview) - JDK-8296896: Change virtual Thread.yield to use external submit - JDK-8297804: (tz) Update Timezone Data to 2022g - JDK-8295803: Console should be usable in jshell and other environments - JDK-828: Implementation of Scoped Values (Incubator) - JDK-8296672: Implementation of Virtual Threads (2nd Preview) Build 26: - JDK-8297276: Remove thread text from Subject.current - JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient - JDK-8247645: ChaCha20 Intrinsics Build 25: - JDK-8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call - JDK-8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist - JDK-8288717: Add a means to close idle connections in HTTP/2 connection pool - JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions - JDK-8059632: Method reference compilation uses incorrect qualifying type - JDK-8297161: Add additional Service Attributes to Standard Algorithm Names guide - JDK-8294073: Performance improvement for message digest implementations Build 24: - JDK-8294731: Improve multiplicative inverse for secp256r1 implementation - JDK-8296715: CLDR v42 update for tzdata 2022f - JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes Build 23: - JDK-8296226: Add constructors (String,Throwable) and (Throwable) to InvalidParameterException - JDK-8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders - JDK-8294241: Deprecate URL public constructors - JDK-8289689: (fs) Re-examine the need for normalization to Unicode Normalization Format D (macOS) - JDK-8279164: Disable TLS_ECDH_* cipher suites - JDK-8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) - JDK-8296108: (tz) Update Timezone Data to 2022f ## Heads-up - JD
