days
-4
-6
hours
-1
-6
minutes
-5
-3
seconds
-5
-6
search

#jep

Just the algorithm, not the GCs themselves

JEP 366: Deprecate the ParallelScavenge + SerialOld GC Combination

We’ve seen a lot of talk about different garbage collectors lately; JEPs 364 and 365 want to port the Z Garbage Collector to macOS and Windows respectively, JEP 363 wants to remove the deprecated Concurrent Mark Sweep (CMS) garbage collector. And now we have JEP 366, which is proposed to target JDK 14 and wants to deprecate the combination of the Parallel Scavenge and Serial Old garbage collection algorithms. Let’s take a closer look.

Something something Windows garbage

JEP 365: ZGC on Windows

The Z Garbage Collector or ZGC is a scalable low latency garbage collector that’s included in the JDK. Until now, it has not been compatible with Windows, but JEP 365 wants to change that. Let’s take a closer look at the future of Java.

A glimpse into the future of Java

JEP 364: ZGC on macOS

The Z Garbage Collector or ZGC is a scalable low latency garbage collector that’s included in the JDK. Until now, it has not been compatible with macOS, but JEP 364 wants to change that. Let’s take a closer look.

Déjà preview

JEP 368: Text Blocks (Second Preview)

Remember text blocks? That’s right, they were a preview feature in the recently released Java 13! Now that some time has passed, the community has a feel for them and where there’s room for improvement. With JEP 368, Jim Laskey proposes a second text blocks preview, this time with two more escape sequences. Let’s take a closer look.

Taking out the trash

JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector

A new Java enhancement proposal, JEP 363, has graduated from being a simple draft. It proposes to remove the Concurrent Mark Sweep garbage collector, which was deprecated two years ago to accelerate the development of other collectors. Let’s take a closer look at the future of Java.

Simpler is better

JEP draft: Throughput post-write barrier for G1

Java Platform Team software engineer Man Cao has published a new JEP draft proposing to improve the performance of the G1 garbage collector when concurrent refinement is disabled. He proposes to do this by introducing a simplified post-write barrier. Let’s take a closer look at what could be the future of Java.

My data types are sealed

JEP 360: Sealed Types

A new Java enhancement proposal, JEP 360, has graduated from being a simple draft. It proposes to bring sealed types to Java, allowing developers to impose restrictions on which other classes or interfaces may extend or implement them. Sealed types could work in tandem with records, which is the business of its older sibling, JEP 359. Let’s take a closer look at the future of Java.

That's got to be a new record

JEP 359: Records

A new Java enhancement proposal, JEP 359, has graduated from being a simple draft. It proposes to bring records to Java, a new kind of type declaration. Records could work in tandem with sealed types, which is the business of its younger sibling, JEP 360. Let’s take a closer look at the future of Java.

Null marks the spot

JEP 358 – Improved NullPointerExceptions

No matter how carefully they wrote their program, nearly every developer knows the dreaded NullPointerException all too well. The JVM points to the location of the problem, but not in as much detail as you might like. With JEP 358, Goetz Lindemaier and Ralf Schmelter propose a solution to this problem.