Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around light-4j’s compatibility with future JDK versions.
This is not a request for the official project to immediately raise its current Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, light-4j already uses Java 21 as its current build and compilation baseline, and its dependency ecosystem is fairly modern. As a Java framework for cloud-native and microservice use cases, light-4j is not just a single core library. It includes HTTP server, client, config, security, metrics, health check, tracing, logging, database integration, and other runtime components.
Because of that, our goal is not to push light-4j to move from Java 21 to a newer version right now. It is also not to ask the project to immediately change the current Java 21 baseline. Instead, we would like to do external compatibility validation while the current compatibility strategy remains unchanged.
More specifically, we would like to observe whether light-4j remains stable on JDK 25 or later LTS versions while continuing to keep the current Java 21 baseline and existing module structure.
The purpose of doing this is to collect evidence in advance for possible future maintenance decisions. For example, if the project later considers moving from Java 21 to JDK 25 or a later LTS baseline, upgrading Maven plugins or dependencies, adjusting module-system-related configuration, or expanding the CI test matrix, these external validation results could serve as useful reference material. They may help identify potential risks earlier, rather than discovering most compatibility issues only after an actual migration effort begins.
This kind of validation may include, but is not limited to:
- Whether light-4j can be built reliably with JDK 25 or later versions while keeping the current Java 21 baseline
- Whether the multi-module test suite shows behavioral differences on newer JDKs
- Compatibility of Undertow / XNIO / HTTP server runtime on newer JDKs
- Behavior differences involving HTTP clients, TLS, JWT, OAuth2, and security providers
- Runtime behavior of config, service discovery, handler chain, and middleware-related modules on newer JDKs
- Compatibility of metrics, health check, tracing, and logging modules on newer JDKs
- Compatibility issues in third-party dependencies such as Jackson, Caffeine, HikariCP, JDBC drivers, PostgreSQL, and MySQL on newer JDKs
- Issues related to Maven Surefire,
--add-opens, the Java module system, or reflective access restrictions
- Issues that may appear when using newer JDK container images in Docker / Kubernetes / cloud-native deployments
- Issues downstream NetworkNT ecosystem projects or user services may encounter when integrating light-4j on newer Java runtime environments
- CI, local development, or test environment configuration issues on newer JDKs
Our current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, current Java 21 baseline, current module structure, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future JDK upgrades, dependency updates, CI matrix expansion, or adaptation to newer runtime environments.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks light-4j may face on future JDK versions as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, dependency upgrades, runtime adaptation, CI matrix expansion, or any possible future Java baseline adjustment.
Thank you for your time, and thank you for maintaining light-4j.
Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around light-4j’s compatibility with future JDK versions.
This is not a request for the official project to immediately raise its current Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, light-4j already uses Java 21 as its current build and compilation baseline, and its dependency ecosystem is fairly modern. As a Java framework for cloud-native and microservice use cases, light-4j is not just a single core library. It includes HTTP server, client, config, security, metrics, health check, tracing, logging, database integration, and other runtime components.
Because of that, our goal is not to push light-4j to move from Java 21 to a newer version right now. It is also not to ask the project to immediately change the current Java 21 baseline. Instead, we would like to do external compatibility validation while the current compatibility strategy remains unchanged.
More specifically, we would like to observe whether light-4j remains stable on JDK 25 or later LTS versions while continuing to keep the current Java 21 baseline and existing module structure.
The purpose of doing this is to collect evidence in advance for possible future maintenance decisions. For example, if the project later considers moving from Java 21 to JDK 25 or a later LTS baseline, upgrading Maven plugins or dependencies, adjusting module-system-related configuration, or expanding the CI test matrix, these external validation results could serve as useful reference material. They may help identify potential risks earlier, rather than discovering most compatibility issues only after an actual migration effort begins.
This kind of validation may include, but is not limited to:
--add-opens, the Java module system, or reflective access restrictionsOur current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, current Java 21 baseline, current module structure, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future JDK upgrades, dependency updates, CI matrix expansion, or adaptation to newer runtime environments.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks light-4j may face on future JDK versions as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, dependency upgrades, runtime adaptation, CI matrix expansion, or any possible future Java baseline adjustment.
Thank you for your time, and thank you for maintaining light-4j.