JDK 20 EAb22, ZenGC EA builds, JavaFX 20 EAb5 and several heads-ups!

[David Delabassee]

Greetings,

With JavaOne in Las Vegas, last month was epically busy! It was great to 
finally have the ability to meet and discuss the Quality Outreach 
program with some of you... face-to-face!


This installment of the newsletter is packed as we have several 
heads-ups, including new Early-Access builds being made available. The 
JDK 20 schedule has been proposed [1]. The next major milestone is 
Rampdown Phase One which should happen in just a month on December 8! 
The next few weeks will be particularly interesting as we will see which 
from the candidate JEPs recently announced (see 'Topics of Interest' 
section below) will be proposed to target JDK 20 [2]. And given that JDK 
20 is getting closer, we are eagerly waiting for your test feedback on 
your projects running with the latest JDK 20 EA builds.


[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-October/007108.html
[2] https://openjdk.org/projects/jdk/20/


### Heads-up - JDK 20: `java.net.URL` parsing fix & behavior change

Before JDK 20, some of the parsing/validation performed by the JDK 
built-in `URLStreamHander` implementations were delayed until 
`URL::openConnection` or `URLConnection::connect` was called. Starting 
JDK 20, some of these parsing/validations are now performed early, i.e. 
within URL constructors.


An exception caused by a malformed URL that would have been delayed 
until the connection was opened or connected may starting JDK 20, throw 
a `MalformedURLException` at URL construction time.


We suggest testing your project(s) against this change. And for those 
who want to rely on the old behavior, a new system property has been 
introduced to revert, on the command line, to the previous behavior.


For more details, please see JBS-8293590 [3] and the release notes [4].

[3] https://bugs.openjdk.org/browse/JDK-8293590
[4] https://bugs.openjdk.org/browse/JDK-8295750


### Heads-up - JDK 20: Thread.stop(), Thread.suspend() and 
Thread.resume() degradation


The ability to stop, suspend, or resume a thread with the corresponding 
Thread.stop(), Thread.suspend() or Thread.resume() methods have been 
removed in JDK 20. Those methods have been degraded to throw a UOE 
exception (UnsupportedOperationException).


Using those methods was inherently unsafe. That is also why they were 
deprecated since JDK 1.2 (1998!) and were flagged 'forRemoval' in 
previous features release.


We do not expect this behavior change to cause issues on well-maintained 
codebase.


For more details please check JDK-8289610 [5], JDK-8249627 [6], and the 
Java Thread Primitive Deprecation FAQ [7].


[5] https://bugs.openjdk.org/browse/JDK-8289610
[6] https://bugs.openjdk.org/browse/JDK-8249627
[7] 
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/doc-files/threadPrimitiveDeprecation.html



### Heads-up - JDK 20: Deprecate and disable the legacy parallel class 
loading workaround for non-parallel-capable class loaders.


Prior to JDK 7, custom class loaders using non-hierarchical class 
delegation model were prone to deadlock. A workaround was added in the 
HotSpot VM (JDK 6) to allow parallel class loading for 
non-parallel-capable class loaders to avoid deadlocks.


Parallel-capable class loaders were introduced in Java SE 7 [8] to 
support parallel class loading to implement a deadlock-free class loader 
using a non-hierarchical class delegation model. [8] and [9] describe 
how to migrate those class loaders depending on this workaround to be 
multi-threaded parallel-capable class loaders.


This workaround was intended to allow those developers to migrate to the 
new mechanism. JDK 7 was released 11 years ago so it is now expected 
that those deadlock-prone custom class loaders have been migrated to the 
parallel-capable class loaders. As a consequence, this workaround is 
removed in JDK 20 as it impedes eliminating the object monitors from 
pinning for virtual threads.


We suggest confirming that your codebase is not relying on this legacy 
workaround. If it still is, you should migrate away from it ASAP. Please 
note that the legacy behavior can be temporary re-enabled using a 
special flag. For additional details, please check [10] and [11].


[8] https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html
[9] https://openjdk.org/groups/core-libs/ClassLoaderProposal.html
[10] https://bugs.openjdk.org/browse/JDK-8295848
[11] https://bugs.openjdk.org/browse/JDK-8296446


### Heads-up - JavaFX builds

Oracle is now publishing JavaFX builds, starting with early access 
builds of JavaFX 20, at jdk.java.net/javafx20 [12]. Developers are now 
able to download JavaFX and JDK builds from the same place, and use 
jlink to create a custom JDK that includes the JavaFX modules.


The latest JavaFX 20 EA builds (b5-2022/10/28) are now available [12] 
along with the related javadoc [13]. These early-access builds are 
provided under the GNU General Public License, version 2, with the 
Classpath Exception. Feedback should 

Re: [DISCUSSION] Add SpotBugs to the build

[David Capwell]

Since there was not major pushback, ill see this as green line for JIRA, ill 
file later today

> On Nov 8, 2022, at 9:46 AM, David Capwell  wrote:
> 
> Thanks all for the replies, I hope I am posting a summary of all the feedback
> 
> 1) double check with legal due to LGPL
> 2) need way to opt-out during development similar to checkstyle
> 3) patch should be in the same spirit as the other build changes, hiding 
> details in .build and following naming
> 4) cool with this idea, but why not X instead?
> 5) rather than processing all the code, can we do a delta instead?
> 
> For #2/#3 strongly agree, we should not reinvent the wheel and should follow 
> norms (even if they are new or slowly developing as we enhance build.xml).  
> If you wish to opt-out during development, that’s totally fine by me, though 
> strongly feel we should guard in CI.  
> 
> #4, I am cool with others if they solve the problem I had, detecting lack of 
> serialize version UID for serializable classes; this is an issue with 
> simulator so want to make sure the tool solves this problem for us.  I looked 
> into error-prone and found its checks very limiting and lacking this check…. 
> So if you know of a checker that solves the serialize version UID issue, I am 
> open to switching
> 
> #5. The issue I have with delta is that we need to start building “smarts” 
> into our ant build to detect what has changed (similar to other build tools), 
> this looks to be more work than I am willing to put into this work, but I am 
> cool if someone else would be willing to enhance our build to be less 
> wasteful.
> 
>> On Nov 8, 2022, at 7:48 AM, Mick Semb Wever > > wrote:
>> 
>> 
>> 
>> Fair point on the name both being more representative of what it does and 
>> being less scary. Wish we could think of something alpha-adjacent to "ant 
>> jar" so folks that are thinking "I want to build this thing" immediately see 
>> both options; the ant -p output is getting pretty long.
>> 
>> 
>> What's the saying when the fish can't help but bite that bait… 
>> 
>> the patch in my last post, it introduces aggregate skip flags, like 
>> `-Dno-linter=` and `-Dno-docs=`, so it would also be easy to introduce a 
>> top-level cheat like `-Dfast=` and you'd get this with
>> 
>> `ant jar -Dfast=` 
>> 
>> 
> 

Should we change 4.1 to G1 and offheap_objects ?

[Mick Semb Wever]

Any objections to making these changes, at the very last minute, for
4.1-rc1 ?
This is CASSANDRA-12029 and CASSANDRA-7486

Provided we figure out patches for them in the next day or two.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Brandon Williams]

CMS was deprecated in JDK 9, I don't see a good reason to follow it
until it's dying breath, and we already have G1 ready in the jvm
options files so this should be an easy switch, +1.

Kind Regards,
Brandon

On Wed, Nov 9, 2022 at 1:22 PM Mick Semb Wever  wrote:
>
> Any objections to making these changes, at the very last minute, for 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day or two.

Re: Should we change 4.1 to G1 and offheap_objects ?

[David Capwell]

CASSANDRA-12029/CASSANDRA-7486 I am not in favor of doing for 4.1, we spend 
time validating the current settings, so changing at the last minute adds risk; 
so rather push that to 4.2/5.0


> On Nov 9, 2022, at 11:25 AM, Brandon Williams  wrote:
> 
> CMS was deprecated in JDK 9, I don't see a good reason to follow it
> until it's dying breath, and we already have G1 ready in the jvm
> options files so this should be an easy switch, +1.
> 
> Kind Regards,
> Brandon
> 
> On Wed, Nov 9, 2022 at 1:22 PM Mick Semb Wever  wrote:
>> 
>> Any objections to making these changes, at the very last minute, for 4.1-rc1 
>> ?
>> This is CASSANDRA-12029 and CASSANDRA-7486
>> 
>> Provided we figure out patches for them in the next day or two.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Jeremiah D Jordan]

At DataStax we’ve been shipping those optional G1 settings as the default for 
many years now, so I am +1 to at the very least making the change in trunk, but 
really I would think it fine to make it back in 4.0 and 4.1 as well.

-Jeremiah

> On Nov 9, 2022, at 1:32 PM, David Capwell  wrote:
> 
> CASSANDRA-12029/CASSANDRA-7486 I am not in favor of doing for 4.1, we spend 
> time validating the current settings, so changing at the last minute adds 
> risk; so rather push that to 4.2/5.0
> 
> 
>> On Nov 9, 2022, at 11:25 AM, Brandon Williams > > wrote:
>> 
>> CMS was deprecated in JDK 9, I don't see a good reason to follow it
>> until it's dying breath, and we already have G1 ready in the jvm
>> options files so this should be an easy switch, +1.
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Wed, Nov 9, 2022 at 1:22 PM Mick Semb Wever > > wrote:
>>> 
>>> Any objections to making these changes, at the very last minute, for 
>>> 4.1-rc1 ?
>>> This is CASSANDRA-12029 and CASSANDRA-7486
>>> 
>>> Provided we figure out patches for them in the next day or two.
> 

Re: Should we change 4.1 to G1 and offheap_objects ?

[Jeff Jirsa]

G1 you can argue for with the changes in the JDK, though it's MUCH  less
friendly to small heaps (e.g. probably our default simple user).

Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd be useful, but I'm pretty sure that's not true, and bugs
like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains
undiagnosed) reinforce that it's less commonly used and may have latent
undiscovered bugs for default users.





On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:

> Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day or two.
>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Josh McKenzie]

My recollection (and brief sleuthing now) surfaces: we've gone back and forth 
on the G1 vs. CMS debate over the years and I think we settled on "it all 
depends on your environment, workload, and you need to tune it anyway. It might 
be worth having a 'default' mode that selects one of the two based on heap size 
unless otherwise specified".

I certainly wouldn't make changes to any defaults on a release between beta and 
rc personally.

On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
> G1 you can argue for with the changes in the JDK, though it's MUCH  less 
> friendly to small heaps (e.g. probably our default simple user).
> 
> Offheap memtables are different though. If someone wants to attest that 
> offheap_objects get the same level of rigorous testing as the existing 
> default, that'd be useful, but I'm pretty sure that's not true, and bugs like 
> https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains 
> undiagnosed) reinforce that it's less commonly used and may have latent 
> undiscovered bugs for default users. 
> 
> 
> 
> 
> 
> On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
>> Any objections to making these changes, at the very last minute, for 4.1-rc1 
>> ? 
>> This is CASSANDRA-12029 and CASSANDRA-7486 
>> 
>> Provided we figure out patches for them in the next day or two.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Brandon Williams]

If CMS is gone, is there a friendlier alternative to G1?

On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie  wrote:
>
> My recollection (and brief sleuthing now) surfaces: we've gone back and forth 
> on the G1 vs. CMS debate over the years and I think we settled on "it all 
> depends on your environment, workload, and you need to tune it anyway. It 
> might be worth having a 'default' mode that selects one of the two based on 
> heap size unless otherwise specified".
>
> I certainly wouldn't make changes to any defaults on a release between beta 
> and rc personally.
>
> On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
>
> G1 you can argue for with the changes in the JDK, though it's MUCH  less 
> friendly to small heaps (e.g. probably our default simple user).
>
> Offheap memtables are different though. If someone wants to attest that 
> offheap_objects get the same level of rigorous testing as the existing 
> default, that'd be useful, but I'm pretty sure that's not true, and bugs like 
> https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains 
> undiagnosed) reinforce that it's less commonly used and may have latent 
> undiscovered bugs for default users.
>
>
>
>
>
> On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
>
> Any objections to making these changes, at the very last minute, for 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day or two.
>
>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Derek Chen-Becker]

There's a lot of work that's gone into G1 to the point where for
almost all workloads it will perform better than CMS. However, there
are almost no knobs to tune (most G1 params are "advisory" and G1 will
happily ignore them if it wants to), so there may not be a great
replacement if people are tuning CMS heavily for a specific workload.
Can you define "friendlier" in the context of CMS?

Derek

On Wed, Nov 9, 2022 at 3:10 PM Brandon Williams  wrote:
>
> If CMS is gone, is there a friendlier alternative to G1?
>
> On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie  wrote:
> >
> > My recollection (and brief sleuthing now) surfaces: we've gone back and 
> > forth on the G1 vs. CMS debate over the years and I think we settled on "it 
> > all depends on your environment, workload, and you need to tune it anyway. 
> > It might be worth having a 'default' mode that selects one of the two based 
> > on heap size unless otherwise specified".
> >
> > I certainly wouldn't make changes to any defaults on a release between beta 
> > and rc personally.
> >
> > On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
> >
> > G1 you can argue for with the changes in the JDK, though it's MUCH  less 
> > friendly to small heaps (e.g. probably our default simple user).
> >
> > Offheap memtables are different though. If someone wants to attest that 
> > offheap_objects get the same level of rigorous testing as the existing 
> > default, that'd be useful, but I'm pretty sure that's not true, and bugs 
> > like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains 
> > undiagnosed) reinforce that it's less commonly used and may have latent 
> > undiscovered bugs for default users.
> >
> >
> >
> >
> >
> > On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
> >
> > Any objections to making these changes, at the very last minute, for 
> > 4.1-rc1 ?
> > This is CASSANDRA-12029 and CASSANDRA-7486
> >
> > Provided we figure out patches for them in the next day or two.
> >
> >



-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Re: Should we change 4.1 to G1 and offheap_objects ?

[Brandon Williams]

> Can you define "friendlier" in the context of CMS?

Friendlier to small heaps, to Jeff's point about it being much less
friendly to them.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Brad]

The default garbage collector in Java 11 is G1*.  *It's designed to be
self-tuning, so I'd call it friendly.  We have run Java 8 and 11 on G1 in
production on all of our 1,000+ clusters for several years.

I'd agree with Jeremiah that it's worth changing in trunk at the very least
and consider backporting.

On Wed, Nov 9, 2022 at 5:10 PM Brandon Williams  wrote:

> If CMS is gone, is there a friendlier alternative to G1?
>
> On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie  wrote:
> >
> > My recollection (and brief sleuthing now) surfaces: we've gone back and
> forth on the G1 vs. CMS debate over the years and I think we settled on "it
> all depends on your environment, workload, and you need to tune it anyway.
> It might be worth having a 'default' mode that selects one of the two based
> on heap size unless otherwise specified".
> >
> > I certainly wouldn't make changes to any defaults on a release between
> beta and rc personally.
> >
> > On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
> >
> > G1 you can argue for with the changes in the JDK, though it's MUCH  less
> friendly to small heaps (e.g. probably our default simple user).
> >
> > Offheap memtables are different though. If someone wants to attest that
> offheap_objects get the same level of rigorous testing as the existing
> default, that'd be useful, but I'm pretty sure that's not true, and bugs
> like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which
> remains undiagnosed) reinforce that it's less commonly used and may have
> latent undiscovered bugs for default users.
> >
> >
> >
> >
> >
> > On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
> >
> > Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> > This is CASSANDRA-12029 and CASSANDRA-7486
> >
> > Provided we figure out patches for them in the next day or two.
> >
> >
>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Josh McKenzie]

fwiw, the "CMS is friendlier for small heaps with C*" conclusion may no longer 
be accurate; a lot of work has gone into G1 since the last time we've covered 
the topic as a project. Nevermind the changes in C*.

Lots of moving targets.

On Wed, Nov 9, 2022, at 6:13 PM, Brad wrote:
> The default garbage collector in Java 11 is G1*.  *It's designed to be 
> self-tuning, so I'd call it friendly.  We have run Java 8 and 11 on G1 in 
> production on all of our 1,000+ clusters for several years.
> 
> I'd agree with Jeremiah that it's worth changing in trunk at the very least 
> and consider backporting.
> 
> On Wed, Nov 9, 2022 at 5:10 PM Brandon Williams  wrote:
>> If CMS is gone, is there a friendlier alternative to G1?
>> 
>> On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie  wrote:
>> >
>> > My recollection (and brief sleuthing now) surfaces: we've gone back and 
>> > forth on the G1 vs. CMS debate over the years and I think we settled on 
>> > "it all depends on your environment, workload, and you need to tune it 
>> > anyway. It might be worth having a 'default' mode that selects one of the 
>> > two based on heap size unless otherwise specified".
>> >
>> > I certainly wouldn't make changes to any defaults on a release between 
>> > beta and rc personally.
>> >
>> > On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
>> >
>> > G1 you can argue for with the changes in the JDK, though it's MUCH  less 
>> > friendly to small heaps (e.g. probably our default simple user).
>> >
>> > Offheap memtables are different though. If someone wants to attest that 
>> > offheap_objects get the same level of rigorous testing as the existing 
>> > default, that'd be useful, but I'm pretty sure that's not true, and bugs 
>> > like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains 
>> > undiagnosed) reinforce that it's less commonly used and may have latent 
>> > undiscovered bugs for default users.
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
>> >
>> > Any objections to making these changes, at the very last minute, for 
>> > 4.1-rc1 ?
>> > This is CASSANDRA-12029 and CASSANDRA-7486
>> >
>> > Provided we figure out patches for them in the next day or two.
>> >
>> >

Re: Should we change 4.1 to G1 and offheap_objects ?

[Elliott Sims]

>From a user PoV, I'd call G1 drastically friendlier than CMS in that it
tends to be well-behaved under a variety of workloads and heap sizes right
out of the box without the kind of dark-art tuning and overnight surprises
you get with CMS.  Granted the smallest heap I have now is 2GB, but that's
not really small by 2022 standards and it seems to be the minimum
recommended in the docs (though the config calculator will go as low as 1GB)

It feels like the sort of change that wouldn't be a bad surprise in an RC,
but maybe a bit too big of a change for backporting to 4.0.

On Wed, Nov 9, 2022 at 4:30 PM Josh McKenzie  wrote:

> fwiw, the "CMS is friendlier for small heaps with C*" conclusion may no
> longer be accurate; a lot of work has gone into G1 since the last time
> we've covered the topic as a project. Nevermind the changes in C*.
>
> Lots of moving targets.
>
> On Wed, Nov 9, 2022, at 6:13 PM, Brad wrote:
>
> The default garbage collector in Java 11 is G1*.  *It's designed to be
> self-tuning, so I'd call it friendly.  We have run Java 8 and 11 on G1 in
> production on all of our 1,000+ clusters for several years.
>
> I'd agree with Jeremiah that it's worth changing in trunk at the very
> least and consider backporting.
>
> On Wed, Nov 9, 2022 at 5:10 PM Brandon Williams  wrote:
>
> If CMS is gone, is there a friendlier alternative to G1?
>
> On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie  wrote:
> >
> > My recollection (and brief sleuthing now) surfaces: we've gone back and
> forth on the G1 vs. CMS debate over the years and I think we settled on "it
> all depends on your environment, workload, and you need to tune it anyway.
> It might be worth having a 'default' mode that selects one of the two based
> on heap size unless otherwise specified".
> >
> > I certainly wouldn't make changes to any defaults on a release between
> beta and rc personally.
> >
> > On Wed, Nov 9, 2022, at 4:20 PM, Jeff Jirsa wrote:
> >
> > G1 you can argue for with the changes in the JDK, though it's MUCH  less
> friendly to small heaps (e.g. probably our default simple user).
> >
> > Offheap memtables are different though. If someone wants to attest that
> offheap_objects get the same level of rigorous testing as the existing
> default, that'd be useful, but I'm pretty sure that's not true, and bugs
> like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which
> remains undiagnosed) reinforce that it's less commonly used and may have
> latent undiscovered bugs for default users.
> >
> >
> >
> >
> >
> > On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:
> >
> > Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> > This is CASSANDRA-12029 and CASSANDRA-7486
> >
> > Provided we figure out patches for them in the next day or two.
> >
> >
>
>
>

-- 
This email, including its contents and any attachment(s), may contain 
confidential and/or proprietary information and is solely for the review 
and use of the intended recipient(s). If you have received this email in 
error, please notify the sender and permanently delete this email, its 
content, and any attachment(s).  Any disclosure, copying, or taking of any 
action in reliance on an email received in error is strictly prohibited.