Summary
I am going to close the PR #3839 and re-approach this effort incrementally.
Right now, this migration is blocked by a mesh of related dependency and framework upgrades, and trying to land them in one PR introduces too much change at once for safe review and validation.
Problem
The current JDK 25 migration is not isolated. It pulls in a chain of related upgrades:
- newer JavaFX requires JDK 25
- Spring upgrade is needed for JDK 25 support
- Jackson 3 upgrade is needed for the Spring upgrade path
- Spring Security 6+ upgrade is needed as part of the Spring migration
- Elasticsearch upgrade is needed for Jackson 3 compatibility
- middle-layer service objects need updates, primarily for JSON/XML serialization and deserialization
Because of these dependencies, one PR ends up touching many layers of the system at once. That makes it difficult to:
- review effectively
- test confidently
- identify regressions quickly
- merge incrementally
Proposed approach
We should split this migration into a sequence of focused efforts instead of one large PR.
low-risk Spring service migration ( alarm-logger, alarm-config-logger )
- migrate the lowest-complexity Spring service first
- use that work to validate the Spring/JDK upgrade path
- confirm compile, test, and packaging behavior before moving on
high-risk Spring service migration (save-restore)
- migrate the most complex service last
- handle:
- Jakarta namespace changes
- Spring Security updates
- Elasticsearch compatibility
- Jackson 3 integration
- serialization/deserialization updates in service-layer objects
shared dependency reconciliation ( entire phoebus project )
- reconcile shared/root Spring and related dependency versions
- remove temporary overrides introduced during the transition
- validate all Spring services together
Suggested work breakdown
This effort will likely need to be split across multiple PRs, including some combination of:
- define and document the upgrade order for JDK 25, JavaFX, Spring, Jackson, Spring Security, and Elasticsearch
- migrate low-risk Spring services first
- upgrade Spring-dependent services iteratively
- update Spring Security usage as required by the newer Spring line
- update Jackson-related serialization/deserialization code
- update Elasticsearch integration for compatibility
- update middle-layer service objects impacted by JSON/XML mapping changes
- run targeted testing after each step
- run broader regression testing before final convergence on JDK 25
Notes
A more detailed upgrade analysis already exists and can be used as the implementation plan for follow-up issues/PRs, especially for:
- Spring Boot upgrade sequencing
- save-and-restore migration details
- springdoc changes
- Spring Security API updates
- Elasticsearch/Jackson compatibility
- Jakarta namespace migration
Summary
I am going to close the PR #3839 and re-approach this effort incrementally.
Right now, this migration is blocked by a mesh of related dependency and framework upgrades, and trying to land them in one PR introduces too much change at once for safe review and validation.
Problem
The current JDK 25 migration is not isolated. It pulls in a chain of related upgrades:
Because of these dependencies, one PR ends up touching many layers of the system at once. That makes it difficult to:
Proposed approach
We should split this migration into a sequence of focused efforts instead of one large PR.
low-risk Spring service migration ( alarm-logger, alarm-config-logger )
high-risk Spring service migration (save-restore)
shared dependency reconciliation ( entire phoebus project )
Suggested work breakdown
This effort will likely need to be split across multiple PRs, including some combination of:
Notes
A more detailed upgrade analysis already exists and can be used as the implementation plan for follow-up issues/PRs, especially for: