基于Spring3.2.x的大型企业应用JDK1.8转JDK1.9：步骤及版本疑问

Hey there! Let's tackle your migration from JDK 1.8 to 1.9 for that large enterprise app. I’ve helped several teams navigate similar upgrades, so here’s a clear breakdown of what you need to do:

First: Do You Need to Upgrade to Spring 4.2.x? #

Short answer: No—you need to go higher, to Spring 4.3.x at minimum. Here’s why:

• Spring 3.2.x reached end-of-life years ago, and it was never built to support JDK 1.9’s module system (JPMS) or its stricter API access rules. Running Spring 3.2.x on JDK 1.9 will almost certainly lead to class loading errors, reflection access issues, and unexpected crashes.
• Spring 4.2.x also doesn’t fully support JDK 1.9. The first Spring version with official JDK 9 support is Spring 4.3.x (specifically 4.3.10+), which adds compatibility for JPMS and fixes issues with JDK 1.9’s restricted internal APIs. For a smoother transition, stick to the latest 4.3.x release (like 4.3.30.RELEASE)—it’s stable, supports JDK 1.8 through 11, and minimizes breaking changes from Spring 3.2.x.

Step-by-Step Migration Process #

1. Pre-Migration Prep #

• Backup everything: Tag your codebase in Git (e.g., pre-jdk9-migration) and save a copy of your current dependency JARs. This lets you roll back quickly if things go south.
• Set up a JDK 1.9 environment: Install JDK 1.9 locally, verify it works with java -version and javac -version, and configure your build tool (Maven/Gradle) to use it.
• Map your dependencies: Run mvn dependency:tree (Maven) or gradle dependencies (Gradle) to list all your project’s dependencies. Flag Spring, iBATIS, and Tiles artifacts—these are your high-risk areas.

2. Upgrade Spring to 4.3.x #

• Replace all Spring 3.2.x JARs: Swap out every Spring artifact (core, context, web, etc.) for matching 4.3.x versions. Keep versions consistent across all Spring modules to avoid compatibility gaps.
• Fix deprecated API usage: Spring 4.3.x marks some 3.2.x APIs as deprecated (e.g., certain WebApplicationContextUtils methods, old AOP utilities). Check the Spring 4.3 migration docs for replacement suggestions—most have straightforward alternatives.
• Address JPMS restrictions: JDK 1.9 blocks access to many internal JDK APIs (like sun.misc). Spring 4.3.x adapts to this, but if your code directly uses these APIs, replace them with public JDK APIs or add JVM flags like --add-opens java.base/java.lang=ALL-UNNAMED to grant access temporarily (though replacing is better long-term).

3. Adapt iBATIS and Tiles #

• iBATIS: If you’re using the legacy iBATIS 2.x, note that it’s no longer maintained. Most 2.3.4+ versions work on JDK 1.9, but watch for class loading issues with dependencies like commons-logging. If you hit roadblocks, consider upgrading to MyBatis 3.x (the official successor)—it’s fully JDK 9-compatible and integrates seamlessly with Spring 4.3.x.
• Tiles 3.0.x: Tiles 3.0.8+ supports JDK 1.8+, but verify its integration with Spring 4.3.x. If you see errors with tile initialization, upgrade to Tiles 3.1.x—it’s optimized for newer Spring versions and fixes minor compatibility quirks.

4. Code Adjustments #

• Fix JDK API changes: Remove calls to deprecated JDK 1.8 APIs that were removed or restricted in 1.9 (e.g., Thread.stop(), Date.getYear()). Replace them with modern alternatives (like ExecutorService for thread management, LocalDate for date handling).
• Handle missing JDK modules: JDK 1.9 moved some packages (like javax.annotation) out of the core JDK. If your app uses these, add explicit dependencies to your build file (e.g., javax.annotation:javax.annotation-api).
• Update reflection code: JDK 1.9 tightens reflection access. If your code uses reflection to access private fields/methods in JDK classes, add --add-opens flags to your JVM startup command to allow this access.

5. Test Thoroughly #

• Unit tests first: Run all unit tests to catch dependency or code issues early. Fix failures one by one—most will be related to deprecated APIs or class loading.
• Integration testing: Deploy to a test server (e.g., Tomcat 9, which supports JDK 1.9) and validate core workflows: database operations (iBATIS), page rendering (Tiles), API endpoints, and security features.
• Performance checks: JDK 1.9 uses G1 GC by default (replacing Parallel GC). Monitor memory usage, response times, and GC logs to ensure performance matches or exceeds JDK 1.8 levels. Adjust GC parameters if needed.

6. Pre-Production & Production Deployment #

• Stage in pre-production: Deploy the migrated app to a pre-production environment and run it for a few days. Monitor logs for errors like NoClassDefFoundError or IllegalAccessError—these often pop up only under real-world load.
• Adjust JVM arguments: Tweak JVM flags for JDK 1.9 (e.g., GC settings, module access flags) based on pre-production performance data.

内容的提问来源于stack exchange，提问作者Saravana Kumar