JUnit 6 is here, eight years after JUnit 5 was released. This isn’t just an incremental update; it’s a significant modernization leap.

Let’s explore the main breaking changes and improvements.

JUnit 6 requires Java 17+ (and Kotlin 2.2+)

JUnit 6 raises the minimum required Java version from 8 to 17. This change is driven by two key factors:

1. Java’s evolution: a lot of improvements have been introduced since version 8.
2. Ecosystem shift towards Java 17.

For example:

• Spring Framework 6 and Spring Boot 3 has changed its baseline to Java 17+.
• AssertJ has moved to Java 17+.

For projects still using Java versions older than 17, JUnit 5 will continue to be supported for at least one more year.

For Kotlin users, JUnit 6 now requires Kotlin 2.2 or later.

JUnit Platform, Jupiter, and Vintage share the same version

The JUnit framework consists of three major architecture components:

• Platform — provides the engine API for launching tests.
• Jupiter — provides the API for writing tests.
• Vintage — implements an engine that allows running tests written in JUnit 3 and 4.

However, in JUnit 5 only Jupiter and Vintage artifacts shared the same version, while the Platform artifacts followed a separate versioning scheme.

For example:

• junit-jupiter-engine:5.13.3
• junit-vintage-engine:5.13.3
• junit-platform-engine:1.13.3

As you can see, the junit-platform-engine version differs from others.

To simplify the dependency management, JUnit 6 unifies versioning across all the components, meaning that all three of them, including JUnit Platform, will share the same version.

As a result, after migrating to JUnit 6, a single version can be used:

• junit-jupiter-engine:6.0.0
• junit-vintage-engine:6.0.0
• junit-platform-engine:6.0.0

Various improvements and deprecated APIs

JUnit 6 introduces significant cleanup of the codebase by removing deprecated APIs and behaviors, while also adding several improvements:

New features and API improvements:

• Kotlin’s suspend modifier may now be applied to test and lifecycle methods.
• Display names for @ParameterizedClass and @ParameterizedTest now consistently style name-value pairs for arguments using name = value formatting – for example, fruit = apple instead of fruit=apple.
• For consistency with test methods, @Nested classes declared in the same enclosing class or interface are now ordered in a deterministic but intentionally nonobvious way.

Public API deprecations and removals:

• The JRE enum constants for JAVA_8 to JAVA_16 have been deprecated because they can no longer be used at runtime since JAVA_17 is the new baseline.
• @EnabledForJreRange and @DisabledForJreRange now use JAVA_17 as their default min value.
• MethodOrderer.Alphanumeric class removed.
• ReflectionSupport.loadClass(String) method removed.
• ReflectionUtils.readFieldValue(…​) method removed.
• ReflectionUtils.getMethod(…​) method
• InvocationInterceptor.interceptDynamicTest(Invocation, ExtensionContext) method removed.
• The JUnit Vintage engine is now deprecated and will report an INFO level discovery issue when it finds at least one JUnit 4 test class.

Module removals and integrations:

• junit-platform-runner and junit-platform-jfr modules removed. The JFR functionality is now integrated in junit-platform-launcher.
• The junit-platform-suite-commons module is now integrated into junit-platform-suite.
• The junit-jupiter-migrationsupport artifact and its contained classes are now deprecated and will be removed in the next major version.

Build tools compatibility:

• Support for Maven Surefire/Failsafe versions less than 3.0.0 has been dropped.

The full list of changes can be found in the official Release Notes.

More consistent and performant CSV parsing for @CsvSource and @CsvFileSource

JUnit 6 has migrated its CSV parsing implementation from the no longer maintained univocity-parsers library to FastCSV.

This provides:

• More consistent CSV input handling (including for malformed entries).
• Better error reporting.
• Improved performance.

Although the overall behavior remains largely compatible with JUnit 5, there are a few notable changes that might require updates to your tests or input files:

• The lineSeparator attribute in @CsvFileSource has been removed. The line separator is now automatically detected, meaning that any of \r, \n, or \r\n is treated as a line separator.
• Extra characters after a closing quote are no longer allowed in @CsvSource and @CsvFileSource. For example, if a single quote is used as the quote character, the following CSV value 'foo’INVALID,'bar' will now cause an exception to be thrown. This helps ensure that malformed input is not silently accepted or misinterpreted.
• Attributes such as ignoreLeadingAndTrailingWhitespace, nullValues, and others in @CsvSource and @CsvFileSource now apply to header fields as well as to regular fields.
• Root causes and messages of exceptions thrown for malformed CSV input may differ in some cases.

If your test suite includes complex or custom-formatted CSV data, it’s worth reviewing and validating it after migration.

JUnit 6 enhances null-safety with JSpecify annotations

In JUnit 5, nullability was described informally via JavaDoc — useful for human readers, but invisible to tools. This led to a few common issues:

• NullPointerExceptions at runtime.
• Extra casting or null-safety assertions in Kotlin, due to its distinction between nullable and non-nullable types

JUnit 6 addresses these issues by introducing JSpecify annotation support. These annotations are:

• Recognized by IDEs.
• Supported by static analysis tools like ErrorProne and NullAway.
• Processed by the Kotlin compiler.

Starting with JUnit 6, all public APIs consistently declare their nullability using the @Nullable annotation.

For example, the Arguments.of() method now clearly indicates it accepts null arguments while always returning a non-null value:

static Arguments of(@Nullable Object... arguments) {
  return of(arguments);
}

Non-annotated types are considered non-nullable by default.

Conclusion

JUnit 6 represents a major evolution of the testing framework. While not a complete rewrite like JUnit 5 was, it delivers substantial improvements by:

• Embracing modern Java language features.
• Introducing comprehensive null-safety through JSpecify.
• Simplifying dependency management.

Useful links:

• JUnit 6 Release Notes
• JUnit architecture overview by Nicolai Parlog

What’s new in JUnit 6: Key Changes and Improvements was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve spent about 400$ and six everyday-study months to get it and I want to help you decide whether this exam is worth your time and effort.

A quick note, I passed Java SE 17 exam but given that all currently available OCP exams have similar structure and require about the same amount of study, my advice will probably be applicable to other versions as well.

Let’s start with what you’ll basically need to pass an exam and then see what benefits you get from it.

Price

The first and most obvious is that you need to buy an attempt to take an exam. The attempt is single-use meaning that you have only one try and if you fail — you’ll need to buy another one attempt.

The price ranges from 240$ to 300$ depending on your location. It isn’t cheap, that’s why I recommend you to talk to your management and let them sponsor this certification for you.

That was exactly my case, it was set as a part of my Personal Development Plan and my company agreed to pay for it.

Actually, it’s a common case, many companies encourage their engineers to pass industry recognised certifications, it’s especially true for outsourcing companies whose reputation benefits from having certified developers on board or companies relying heavily on Java ecosystem.

You’ll also need solid preparation resources to pass the exam from the first attempt. I recommend OCP Oracle Certified Professional Java SE 17 Developer Certification Kit by Jeanne Boyarsky and Scott Selikoff (≈75$) and Enthuware mock exams (≈10$).

Difficulty and preparation

The exam is fairly difficult even if you already have a couple of years of professional experience.

It covers a broad range of topics and some of them are not very common nowadays: Serialization, JDBC (PreparedStatement, CallableStatement, ResultSet etc.), Java Platform Module System.

You’ll need to grasp not just the basics of these technologies, but also be prepared to solve tricky questions — especially if you haven’t worked with them in real-world scenarios.

Fortunately, most questions focus on more familiar topics like Java Object-Oriented Approach, Stream API, Arrays and Collections. Making sure you know the basics is important but as always be ready for tricky questions.

Also, each exam covers features added since the previous LTS version, for example OCP Java 17 covers Record Classes (introduced in Java 14) and Sealed Classes and Interfaces (Java 15). Thus it may require an additional effort to learn new language features.

Last but not least: the exam includes questions about Concurrency and I/O. Both topics are quite challenging so I highly recommend spending extra time brushing up on them.

Is it worth it?

The exam will be beneficial if you want to:

• have an official confirmation of your knowledge and stand out during a recruitment process;
• deeper explore core language APIs, cover gaps and become familiar with newest language features;
• be able to read code faster and become a better code-reviewer;
• get a confidence boost after achieving a challenging goal.

However, the exam may not be for you if you:

• have just started learning Java;
• are not ready to invest 3–9 months in continuous learning;
• already possess solid confirmation of your skills;
• don’t wish to spend some time learning topics in which you’re not particularly interested in.

The road to OCP Certification is a challenging but rewarding journey and I wish you success if you decide to take it!

Useful links

• Exam topics
• Success stories from people passed the exam, Q&A
• Buy an exam attempt
• Java 17 Practice Test

Oracle Java Certification: do you need it? was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

We’ve all seen Singletons lots of times. In most cases, the implementation of this pattern looks rather formulaic and doesn’t raise any questions. But recently, in various projects, I started coming across a “Lazy” implementation, which puzzled me. My main question was: “What makes the Lazy implementation better?”.

Well, let’s look at what advantages the Lazy implementation offers over the Eager or Classic one, but before we do, let’s remember what an Eager Singleton looks like.

Eager Singleton

As an example, we chose a class whose only task is to output a randomly generated string of a certain length to the console.

An Eager implementation:

1. Stores reference to the only existing object of the class in a static final field.
2. Limits the access level of the constructor to private, forbidding “foreign” classes from calling it.
3. Has a public static getInstance() method that returns a reference to the same object each time it is called.
4. * Some implementations of the Eager version allow direct access to the INSTANCE field, weakening its access level to public.

Initialization

The nuance that matters most in the context of comparing the Eager and Lazy versions is at what point an instance is created. As you know, the values of static fields are written when a class is loaded. But what initiates the loading process?

There are 4 events that can serve as triggers to load the class:

1. Creating an object with the new operator.
   This event cannot be the trigger to load the RandomPrinter class, simply because the constructor of our printer is marked “private”, which prevents it from being used by “outside” classes.
2. Loading a child class.
   Would also not be a reason to load our class, for exactly the same reason: a private constructor prohibits inheritance.
3. Loading a class using the Class.forName() or ClassLoader.loadClass() method.
   It will definitely load our class and call its initialization, but it seems unrealistic as a standard approach to working with Singletons.
4. Accessing a static method or variable.
   This looks like the most likely option, doesn’t it? Let’s consider it in more detail.

Let’s imagine that we want to use our class for its intended purpose and print a random string. To do that, we need to get a RandomPrinter object. The only way to do so is to call the getInstance() method which, as mentioned in the point 4, will start the process of loading and initializing the class and will create a single RandomPrinter object.

It seems to be something like the idea of Lazy initialization, because the object was created exactly at the first request, isn’t it?

Lazy Singleton

Let’s implement a Lazy Singleton in its simplest form.

We only needed 2 changes to make the Singleton class Lazy:

1. The INSTANCE field is no longer final, which allows you to not initialize it at declaration, but do it later.
2. The getInstance() method now checks if the RandomPrinter object has already been created and if not, creates it and returns it to the caller. If the object already exists, the reference to it is returned immediately and no new object is created.

So what’s the difference?

Let’s go back to our object usage scenario. We want to print a random string again, again we call the getInstance() method, which… just like in the Eager Singleton, triggers the creation of the RandomPrinter object.

So what is the difference between the Eager and Lazy implementation in this case? The answer is simple: there is no difference!

In both cases, we need an object of the class. In fact, RandomPrinter doesn’t have any other use cases. All the client can ask our class to do is:

1. Request a single object of the class using the getInstance() method.
2. Call the printRandomString() method on the received object.

Thus, the client of our class needs the value of the INSTANCE field anyway, which means that it will be initialized whether our Singleton is Lazy or not. In other words, it makes absolutely no difference how we implement initialization: with or without null checking, any usage of the class will lead to the creation of a RandomPrinter object.

Consequently, any logic related to Lazy object creation in this case will only clutter the code and raise questions for its readers.

Of course, an extra null check added in the Lazy version and a non-final field will not significantly damage the functionality or readability of your code. However, if a class needs to be thread-safe, a trivial “null check” can easily turn into an unnecessary nested class or become a synchronized block with another redundant null reference check. None of this is good for your application or those who work on it with you, so, as they say:

Conclusion

Certainly a Lazy implementation has its use cases. For example a Lazy Singleton class could have a public static variable or method that doesn’t require an instance to be used.

But if all use cases of your Singleton class require an instance to be created, then the Eager version will probably be a better choice.

Lazy vs Eager Singleton in Java was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.