Why is OpenJDK 8 supported by Red Hat for longer than OpenJDK 11?
The OpenJDK Lifecycle shows that OpenJDK 8 will be supported until Nov 2026, nearly 2 years after OpenJDK 11 support will end in October 2024. That sounds strange.
- Why was OpenJDK 8 supported extended from June 2023 to Nov 2026?
- Why does support for OpenJDK 11 end before OpenJDK 8?
There’s a Red Hat article, solving these questions. tl;dr: Migration from Java 8 to 11 is a way more complicated step involving bigger changes than the migration past Java 11.
Short OpenJDK 11 to 17 Migration Guide
Introduction
With OpenJDK 11 reaching end-of-life in October 2024, many organizations are planning their migration to OpenJDK 17, which is the current LTS (Long Term Support) release. This guide outlines the key steps, potential issues, and solutions for a successful migration.
Key Changes in OpenJDK 17
Language Features
- Sealed Classes (Preview in Java 15, Final in Java 17)
- Pattern Matching for switch (Preview)
- Enhanced Pseudo-Random Number Generator
- New macOS Rendering Pipeline
- Strong encapsulation of JDK internals
Migration Steps
1. Preparation
- Audit your current Java 11 codebase
- Identify deprecated APIs and features
- Review third-party dependencies for Java 17 compatibility
- Set up a test environment with OpenJDK 17
- Pro Tip: Use Migration Toolkit for Applications (MTA) or its upstream project Konveyor for static code analysis
- MTA is included in all OpenShift SKUs
- Simply target Java 17 as your migration goal
- Get a detailed report of potential issues and migration paths
- Identify deprecated APIs, removed features, and compatibility issues
- Perfect for lazy developers (and as we know, laziness is the mother of invention in computer science!)
2. Build System Updates
- Update build tools (Maven/Gradle) to latest versions
- Update compiler settings to target Java 17
- Review and update build plugins
3. Code Changes
- Replace deprecated APIs with their modern alternatives
- Update sealed classes implementation
- Review and update reflection usage
- Check for removed features and APIs
Common Issues and Solutions
1. Reflection Access
Issue: Strong encapsulation of JDK internals may break reflection-based code Solution:
- Use
--add-opens
JVM arguments for specific modules - Refactor code to use public APIs
- Consider using
MethodHandles
instead of reflection
2. Removed Features
Issue: Some features like java.security.acl
package are removed
Solution:
- Use modern security APIs
- Replace removed features with their alternatives
- Update security-related code
3. Third-party Dependencies
Issue: Some libraries might not be compatible with Java 17 Solution:
- Update dependencies to latest versions
- Look for Java 17 compatible alternatives
- Contact library maintainers for support
Testing Strategy
Unit Tests
- Run existing test suite
- Add new tests for Java 17 specific features
- Verify behavior changes
Integration Tests
- Test with all dependent systems
- Verify performance characteristics
- Check memory usage patterns
Performance Testing
- Compare application performance
- Monitor GC behavior
- Analyze startup time
Deployment Considerations
JVM Arguments
- Review and update JVM arguments
- Add necessary
--add-opens
flags - Configure new GC options if needed
Monitoring
- Update monitoring tools
- Add Java 17 specific metrics
- Configure new logging options
Conclusion
Migrating from OpenJDK 11 to 17 requires careful planning and testing. While the migration process might seem daunting, the benefits of using a modern LTS release, including improved performance, security, and new language features, make it worthwhile. Start the migration process early to ensure a smooth transition before OpenJDK 11 reaches end-of-life. Remember that tools like Migration Toolkit for Applications (MTA) or Konveyor can significantly simplify the initial assessment phase by providing detailed static analysis and migration paths.