Exploring builds with Java 25

aaime-geosolutions · September 28, 2025, 4:35pm

Hi all,

I’ve spent a bit of time trying out basic build (no QA) of our various projects with Java25 (just like we build with java 21).

I’ve found they are largerly working, besides a few exceptions, and the necessity to upgrade a some libraries.

Common issues across projects:

Spotless and palantir need to be ugpraded, they are both using Java API that is not available in Java 25. As a side effect of the palantir upgrade, the formatting changes a bit, comments right before a switch case are now aligned with the case.
Bytecode processing based libraries like mockito and easymock need to be upgraded to the latest (this brings in the latest bytebuddy)

Here are some project specific notes:

Imagen

The pull request fails some builds because the plugin upgrades needed for Java 25 compatibility makes them incompatible with Java 11. So first important finding: if we want to build also with Java 25, we have to wave goodbye to Java 11.

ImageIO-Ext

This is a simple project, does not yet uses spotless and has no testing mocks, it was just a matter of adding the build, and can still build with java 11 as a result.

GeoTools

Nothing special regarding the updates, but does not have a Java 11 build anymore, so all good.

github.com/geotools/geotools

Updating dependencies to support building with java 25

main ← aaime:java25

opened 03:27PM - 28 Sep 25 UTC

aaime

+489 -442

Adds java 25 to the list of builds, updates some libraries to support java 25 (b…uild tools bytecode manipulation) # Checklist - [x] I have read the [contribution guidelines](https://github.com/geotools/geotools/blob/main/CONTRIBUTING.md). - [x] I have sent a [Contribution Licence Agreement](https://docs.geotools.org/latest/developer/procedures/contribution_license.html) (not required for small changes, e.g., fixing typos in documentation). - [x] First PR targets the `main` branch (backports managed later; ignore for branch specific issues). - [ ] Avoid [Java 9+ split packages](http://tutorials.jenkov.com/java/modules.html#split-packages-not-allowed). - [ ] All the build checks are green ([see automated QA checks](https://docs.geotools.org/latest/developer/conventions/code/qa.html)). For core and extension modules: - [ ] New unit tests have been added covering the changes. - [ ] [Documentation](https://github.com/geotools/geotools/tree/main/docs) has been updated (if change is visible to end users). - [ ] There is an issue in [GeoTools Jira](https://osgeo-org.atlassian.net/projects/GEOT) (except for changes not visible to end users). - [ ] Commit message(s) must be in the form ``[GEOT-XYZW] Title of the Jira ticket``. - [ ] Bug fixes and small new features are presented as a single commit. - [ ] The commit targets a single objective (if multiple focuses cannot be avoided, each one is in its own commit, and has a separate ticket describing it).

GeoWebCache

Same as above, easy peasy lemon squeezy

GeoServer

This one has the same basics, but with a few twists

geofence-server has a test that won’t pass no matter what. The reason is simple, GeoFence uses a version of Hiberante that requires a specific bytebuddy, which is too old to work with the latest Mockito. I have added a conditional exclusion for the test.
For the life of me, there is no way to run “jmap” as an external process, as needed by the JVM console. jmap is being run on the GeoServer process PID, and jmap forces a full GC, which in JDK 25 apparently causes a deadlock between the two processes. No matter, I’ve replaced that code with an internal call to a MBean, which seems to return the same output and is arguably better (no dependency on an external tool, should work on a JRE too)
The gs-rest-openapi-java-client community module needed a lombok upgrade to compile

github.com/geoserver/geoserver

Adding support for Java 25 build

main ← aaime:java25

opened 03:49PM - 28 Sep 25 UTC

aaime

+49 -40

Updating libraries and tools to work on JDK 25, excluding one of the GeoFence te…sts due to too old bytebuddy version required by hibernate, and rewriting how we get the heap memory histogram. # Checklist - [x] I have read the [contribution guidelines](https://github.com/geoserver/geoserver/blob/main/CONTRIBUTING.md). - [x] I have sent a [Contribution Licence Agreement](https://docs.geoserver.org/latest/en/developer/policies/committing.html) (not required for small changes, e.g., fixing typos in documentation). - [x] First PR targets the `main` branch (backports managed later; ignore for branch specific issues). For core and extension modules: - [ ] New unit tests have been added covering the changes. - [ ] [Documentation](https://github.com/geoserver/geoserver/tree/main/doc/en/user/source) has been updated (if change is visible to end users). - [ ] The [REST API docs](https://github.com/geoserver/geoserver/tree/main/doc/en/api/1.0.0) have been updated (when changing configuration objects or the REST controllers). - [ ] There is an issue in the [GeoServer Jira](https://osgeo-org.atlassian.net/browse/GEOS/summary) (except for changes that do not affect administrators or end users in any way). - [ ] Commit message(s) must be in the form ``[GEOS-XYZWV] Title of the Jira ticket``. - [ ] Bug fixes and small new features are presented as a single commit. - [ ] Each commit has a single objective (if there are multiple commits, each has a separate JIRA ticket describing its goal). The PR will be merged when all the build checks are green ([see automated QA checks](https://docs.geoserver.org/latest/en/developer/qa-guide/index.html)), there is a code committer review, and the checklist has been fulfilled.

In short

Overall the update seems reasonably easy. Across the projects, we need to:

Rebase all projects to work on jdk 17+ (imageio-ext depends on imagen, so if we switch the latter to jdk 17)
Update Palantir (this means we’ll reformat also stable/maintenance branches to follow suite, for ease of backporting)

Thoughts?

Cheers
Andrea