Java 25 is Here — Try It Today

It's here.

Back in December, we announced our roadmap for Java 25 and told you a new container image was coming. In February, dotCMS started publishing working container images built and running on Java 25 and it's ready for you to test against right now.

This image is the first concrete milestone in our Java 25 migration. Here's what you need to know.

What's new between Java 11 and Java 25?

A lot. Truthfully, there's far too much that is new and improved across those fourteen major versions to cover in a single post; from modern language features and record types, to significant garbage collection improvements and virtual threads via Project Loom. We'll dig into the specifics of what it means for your experience on dotCMS in upcoming posts. For now, the short version: your dotCMS instance will be faster, leaner on memory, and running on a platform with a much stronger long-term security footing. It will also enable us to build more innovative and creative features for dotCMS.

Try it now: Spin up a local instance

If you have Docker installed, getting a full Java 25 dotCMS environment running locally is as simple as a single command. This uses our all-in-one developer image (Postgres and OpenSearch included), no separate setup required. All data and assets are stored in a local ./data directory:

docker run --rm \ 
-p 8443:8443 \
-v $PWD/data:/data \
-e DOT_INITIAL_ADMIN_PASSWORD=admin \
dotcms/dotcms-dev:java-25

Once it's up, log in at https://local.dotcms.site:8443/dotAdmin with admin@dotcms.com / admin.

Note: The Run Locally quickstart docs reference the dotcms/dotcms-dev:nightly tag — swap that for dotcms/dotcms-dev:java-25 anywhere you see it to test against this image instead.

You can also find the image on Docker Hub: https://hub.docker.com/r/dotcms/dotcms/tags?name=java-25

Want to test against your actual site data? You can clone an existing environment by passing in DOTCMS_SOURCE_ENVIRONMENT and credentials — full details in the quickstart docs.

Go ahead, try your plugins, mock your data, and put it through its paces. If you're self-hosting dotCMS, this is also a good time to explore the speed and memory management improvements firsthand.

What's with the Java-25 tag?

The java-25 tag is dynamic. We'll move it forward over time to keep pace with the latest dotEvergreen releases. This is intentional. You want to be testing against the image that will actually be running when we cut over, not a snapshot that falls further and further behind your production codebase. A big gap between your test image and your eventual production image defeats the purpose of testing early. When it’s time for the sunset of Java 11, we’ll move the latest tag over to use the Java-25 image as well, so if you’ve got that in your configuration, there won’t be any changes necessary.

A quick note on images: Both the dotcms/dotcms-dev and the dotcms/dotcms Images have Java-25 tags available, as they share the same core code. The difference is that dotcms/dotcms-dev the all-in-one image is used here and in our quickstart docs. It bundles Postgres and OpenSearch so you can run everything locally with a single command. The separate dotcms/dotcms image is the production-grade core image, intended for environments where you're managing your own data layer. For testing your plugins and custom code against Java-25, dotcms-dev is what you want for local development.

Is it production-ready?

Kind of… but we'd rather be straight with you.

It's the same dotCMS core codebase. It's not a fork or an experiment. However, we're not recommending production use quite yet. We want to give it more time to soak, build confidence in Java 25 behaviors at scale, and make sure we're fully comfortable before we tell you to run your business on it. You can expect a production-ready recommendation later this year.

In the meantime, feel free to test your custom code thoroughly. We will take care of the dotCMS core code.

What we're seeing so far

In our internal experience, sites have just worked. Everything we've run against this image has come up cleanly without modification. It's a real testament to the Java community's effort in making version-to-version migrations significantly more stable and predictable than they once were, and to the dedication and skill of our dotCMS developers who have kept up with the best practices of the Java community.

That said, one of the things dotCMS users love most is the levels of flexibility and customization they get with OSGi plugins. That creates the potential for every environment to be different, which is exactly why we're giving you early access now, well ahead of the June 1, 2026, deadline.

How we built this

Under the hood, we use an optional flag in our CI/CD pipeline that runs a parallel build with a different Java version, producing a second set of artifacts alongside our standard build:

This approach gives us flexibility going forward (Java’s release cadence continues to accelerate), but crucially; It also lets us determine whether any given bug is Java-version-related or not, because we can compare artifacts from the same commit across both versions. That's a powerful diagnostic tool as we move toward full cutover.

Updating your plugin for Java 25

For most plugins, rebuilding for Java 25 is a small change. Here's what to do:

1. Install Java 25

We use Microsoft Build of OpenJDK. That's what our java-25 image runs, so it's the best choice for minimizing variables when testing. The current version we're building against is 25.0.2-ms, though we'll be updating that more frequently going forward as Java's release cadence accelerates.
If you're using SDKMAN (recommended), it's one command:

sdk install java 25.0.2-ms
sdk use java 25.0.2-ms

2. Update your pom.xml

In your plugin's pom.xml, find the Maven compiler properties and update the version to 25:

<properties>
    <maven.compiler.source>25</maven.compiler.source>
    <maven.compiler.target>25</maven.compiler.target>
</properties>

3. Rebuild and redeploy

mvn clean jar

Then upload the resulting JAR via the Dynamic Plugins tool in dotAdmin, or via the API. Full instructions in the plugin development docs.

If you find something

If you encounter errors or warnings in your plugins while testing:

1. Start with self-service. Check your Maven build output for warnings and errors when rebuilding for Java 25, then check dotcms.log at startup and during runtime for anything plugin-related.

2. Reach out to support. If you have a plugin support agreement, our team can help triage and remediate incompatibilities. For more complex work, we can scope a Statement of Work to upgrade and rewrite what's needed.

Timeline recap

🚀🚀🚀 Let’s go

— Steve Freudenthaler, Director of Engineering, dotCMS

Questions? Reach out to your Customer Success Manager or ping us at support@dotcms.com.