Java 現代化：讓企業級升級切實可行

走進任何一家大型企業——銀行、航空公司、電信業者——Java 通常都在承擔最繁重的工作。核心銀行系統、詐騙偵測管道、訂單管理、在日出前完成數百萬筆交易對帳的夜間批次作業。它能運行，能擴展——而正是因此，大量系統至今仍在 Java 8 甚至更早的版本上運行。

能運行和健康運行是兩回事。各框架停留在不再接收安全修補程式的版本上。最初的開發者早已離開。「別動它，能用就行」已演變成一種架構原則。差距還在不斷擴大：records、sealed classes、pattern matching、virtual threads、G1/ZGC 收集器、更好的容器感知能力以及更快的啟動速度——這一切都在一次沒有人願意安排的升級的彼岸等待。

這篇文章講的就是如何縮小這一差距。它解釋了這些應用程式為何被困住，然後逐一介紹 Premium Package for Java 的五項能力——JDK 版本升級、Liberty 遷移平台、UI 現代化、單元測試產生和安全性修復——以及每項能力如何在確定性自動化與 AI 之間分配工作。最後會說明儲存庫需要做好哪些準備、如何取得存取權限，以及如何開始。

為什麼這麼多 Java 應用落後了整整十年

如果現代化如此明顯地值得，為什麼那麼多企業 Java 應用看起來還凍結在 2014 年前後？原因是結構性的：組織慣性與真實的工程風險。

• 有機成長，而非規劃成長。 這些系統一個功能一個功能、一次收購一次收購地成長起來。程式碼層疊加在更早的程式碼層之上，每一層都是在不同的截止日期和規範下寫就的。你今天繼承的程式碼，像極了地質沉積物——十年間數十個團隊的決策積累。
• 編寫核心模組的工程師早已離去，隱性知識也隨之消失。留下的是稀薄的文件，以及幾位「大概記得那個模組怎麼運作」的資深工程師。
• 升級 Java 意味著依賴審查、框架升級（Spring、Hibernate、Jakarta EE 命名空間遷移）、廢棄 API 的移除，以及在每個環境中的重新驗證——數月的工作量、真實的預算和真實的機會成本，在系統本已運行良好的情況下很難說服人。
• 即使只是從 Java 8 跳到 17 或 21，也可能暴露出模組系統衝突、已移除的內部 API（sun.misc.Unsafe）、變成硬錯誤的 reflection 警告，以及垃圾回收器行為的細微變化。紙面上的版本升級在實踐中會變成數週的調查。
• 回歸週期很長。 龐大的測試套件——單元、整合、效能、UAT，有時還有手動審批——意味著一次升級可能在發布前觸發數週的測試。
• 一切之下是：害怕弄壞正在運行的東西。當一個應用每天處理數百萬元的業務時，一次糟糕部署的代價遠超不升級的代價——於是升級的討論被推到下個季度。再下下個季度。

出路是漸進式的，而不是重寫。有了合適的工具，你可以用足夠小的步驟償還技術債，每一步都可以安全地發布。

Premium Package for Java

Premium Package for Java 是面向企業 Java 現代化的五個工作流程套件。每個工作流程都建立在同樣的分工原則上：讓確定性自動化做可預測的機械性工作，讓 AI 處理那些靠規則無法編碼的上下文決策。

基於規則的引擎（如 OpenRewrite）在數千個檔案上進行機械性重構時表現可靠。AI 則更擅長處理混亂的部分——解讀建構錯誤、推理業務邏輯、在權衡之間做選擇。Bob 在一個逐步執行的工作流程中編排兩者，由人來審批重要的步驟。

背後的專業知識在這裡很重要。這些工作流程由曾建構 JIT 編譯器、發布 WebSphere 和 Open Liberty、參與 Quarkus 先驅工作，並為 OpenJDK、Jakarta EE 和 MicroProfile 做出貢獻的 IBM 和 Red Hat 工程師共同打磨。工具將這些團隊的遷移方法論編碼其中——這是模型僅憑眼前的程式碼無法重建的知識。

以下是五項能力上的分工情況。

能力 1：JDK 版本升級——從 Java 8 到 11、17、21 或 25

JDK 升級是最常見的現代化任務，也是最容易被低估的。Bob 將它視為一段多階段的、以證據為驅動的旅程，而非單一命令。

• 先做專案分析。 Bob 分析建構工具（Maven 或 Gradle）、模組拓撲、目前的 Java 版本和框架使用情況，然後提出可行的升級路徑（8→17、8→21，是否含 Jakarta EE），每條路徑都標注了難度評級和預期的技術挑戰。
• 對於選定的目標版本，精選的 OpenRewrite 規則以安全、大規模的方式處理機械性轉換。
• 規則能覆蓋其中一部分——實踐中大約 40–50%。剩餘部分——特殊的依賴衝突、已刪除的內部 API、特定函式庫的相容性問題——正是智能體循環介入的地方。Bob 編譯專案，解析 Maven/Gradle 建構日誌，按根因對異常分組，然後逐模組向 AI 請求針對性的修復。
• 尊重意圖的護欄。 AI 被明確指示不得悄悄地在 javax 和 jakarta 命名空間之間切換，不得為了「讓程式碼能編譯」而註解掉程式碼或移動檔案，並在任何套件或依賴變更前請求明確審批。

最終你得到的升級，在可以自動化的地方很快，在不能自動化的地方很謹慎——並在最後留下完整的稽核追蹤。

能力 2：Liberty 遷移平台——從傳統 WebSphere 到 Liberty

從傳統 WebSphere Application Server 遷移到 WebSphere Liberty 或 Open Liberty，可以獲得更低的記憶體佔用、對容器友好的封裝方式、更快的啟動速度和現代 Jakarta EE 支援。這也是手動操作時最為複雜的遷移之一。

• AMA 驅動的評估。 Bob 讀取 IBM Application Modernization Accelerator 的輸出，將其報告解析為具體的、檔案層級的遷移問題，並附帶基於規則的修復建議。
• 每條 AMA 規則都攜帶規範性指導——「將 com.ibm.websphere.* 替換為 Jakarta EE 標準等效項」，「將 ibm-web-ext.xml 設定遷移到 server.xml」。Bob 將這些問題按根因分組後連同規則說明文字一起傳給 AI，讓模型直接套用已知的修復方案而非猜測。
• 當遷移涉及 Jakarta 命名空間跳躍時，同一個 OpenRewrite 規則庫以確定性方式處理命名空間的轉換工作。
• 建構、部署、驗證。 Bob 建構 WAR/EAR，透過 liberty-maven-plugin 或 liberty-gradle-plugin 部署，追蹤伺服器日誌中的啟動和類別載入失敗，並以迭代方式解決它們。用 curl 對 REST 端點進行功能驗證是標準流程的一部分。

該工作流程將 Liberty 工程師的遷移方法論編碼進來，而非將它交給一個通用的提示。

能力 3：UI 現代化——從 JSP/Struts 到現代 SPA

大多數舊有 Java 應用仍透過 JSP、Struts 或 Servlet 驅動 UI。Bob 將其拆分為五階段的管道。

• 架構提取。 在任何程式碼重寫之前，Bob 先分析應用，產生一份 architecture.md，將每個控制器、action、Servlet、頁面、表單、驗證規則和資料流路徑都編錄進去。該文件是後續遷移工作的唯一真實來源。
• 舊有表現層（Struts actions、Servlet、JSP 控制器）被轉換為現代後端（Spring Boot、Quarkus 或 Liberty）上的 REST 端點，同時保留原有的 DAO 和模型類別不動，以保護資料庫完整性。
• 前端鷹架。 一個新的 TypeScript 專案（Angular、React 或其他框架）與所選的設計系統（Carbon、Material UI 或 shadcn/ui）連接，在任何功能開發開始前，HTTP 客戶端、主題、路由、狀態管理、錯誤邊界和 CORS 均已設定完畢。
• JSP 表單和表格隨後被映射到設計系統的等效元件——DataTable、Card、DatePicker、驗證過的表單——並保留原有的業務規則。
• 每個步驟的驗證門控。 Bob 從不自行啟動應用。每個階段結束後，它會請開發者執行建構/啟動命令並確認，將驗證權留在人類手中。

AI 處理從 JSP 標籤湯到現代元件的上下文翻譯；自動化處理鷹架、依賴和建構驗證。

能力 4：單元測試——先制定策略，再產生測試

測試覆蓋率通常是現代化最大的單一障礙：無法安全驗證的東西，也無法安全升級。Bob 在產生測試之前先產生測試策略。

• 策略產生。 Bob 分析專案，產生一份 UNITTEST.md，涵蓋架構、需要覆蓋的模組、推薦的框架（JUnit 5、Mockito、AssertJ）、命名規範、覆蓋率門檻，以及帶和不帶覆蓋率報告執行測試的精確命令。
• 候選項選擇支援多個粒度——整個套件、特定類別、單個方法——也可以基於 git diff 執行，將精力集中在最近改動的程式碼上。
• 產生、執行、修復。 每個測試提示都以同一條指令結束：執行測試，修復失敗。AI 執行、觀察失敗，並迭代直到測試套件變綠，而不是停留在程式碼產生階段。
• Bob 與 JaCoCo 整合，讓循環以測量到的覆蓋率為目標，而不僅僅是一次綠色的測試執行。

自動化執行測試；AI 編寫測試並對失敗進行推理。由此產生的覆蓋率正是解鎖另外四個工作流程的關鍵。

能力 5：安全性修復——作為同一循環的一部分的 CVE

一個完成了現代化卻仍然攜帶充滿 CVE 的依賴的應用，只做了一半。安全性修復複用與 JDK 升級相同的架構，指向安全漏洞。

• 建構驅動的偵測。 Bob 複用升級工作流程中的 Maven 和 Gradle 日誌分析器，專門調優以從建構輸出、dependency-check 外掛和 SBOM 工具中偵測依賴建議、棄用警告和已知有漏洞的傳遞性依賴。
• 當一個修復不是簡單的版本升級時——比如打了修補程式的函式庫更改了簽章，而呼叫點需要遷移——智能體循環按根因將問題分組，跨模組套用修復，然後重新建構以驗證。
• 同樣的護欄同樣適用。 沒有明確審批不更改依賴，不註解程式碼，不搞命名空間意外。修復在落地前會被呈現、解釋並確認。

安全強化與其他現代化工作在同一條軌道上執行，而不是作為單獨的路線圖。

共同主線

在五項能力中，同樣的分工始終成立：

自動化處理確定性的事，AI 處理上下文性的事，人類審批重要的事——背後有建構了底層平台的 IBM 和 Red Hat 工程師的支撐。

讓你的儲存庫做好準備

這些工作流程在已經具備良好可讀性的程式碼庫上能走得更遠——幫助 Bob 的事情，和幫助任何接手這段程式碼的工程師的事情，是同一件事：

• 一個綠色且足夠快的建構。 這裡的每個循環都錨定於編譯和測試輸出。你的 mvn/gradle 建構越快越可靠，產生-執行-修復的循環就越緊。
• 已有的測試，哪怕是部分的。 覆蓋率既是升級的安全網，也是 Bob 讀取的訊號。如果覆蓋率不足，先從能力 4 開始，再嘗試版本跳躍。
• 固定的、宣告的依賴樹。 pom.xml/build.gradle 中明確的版本和最新的依賴鎖定檔案，決定了是一次乾淨的規則執行，還是數天的衝突排查。
• Bob 可以驅動的建構工具。 Liberty 和安全工作流程依賴標準外掛（liberty-maven-plugin、dependency-check、SBOM 工具）；將它們設定好，自動化的那一半才能完成自己的工作。

如何取得存取權限

Premium Package for Java 是 Bob 基礎計劃的附加包，而不是單獨的下載。

如何取得授權取決於你的計劃：

• 個人計劃（Pro、Pro+、Ultra）。 前往 bob.ibm.com 的定價頁面，選擇計劃並在結帳時新增 Java 附加包。完成訂單並安裝 Bob IDE 後，登入時會自動偵測授權。在 bob.ibm.com 的訂閱中管理席位和附加包。
• 企業計劃。 你的 Bob 管理員透過 Bob Admin UI 分配基礎計劃席位和 Java 附加包。一旦席位分配給你，同樣的自動偵測就會生效——登入後工作流程即會顯示。

兩件值得明確說明的事：

• 結帳時必須選擇 Java 附加包。 它預設不包含在基礎計劃中。如果在購買時跳過，即使在付費計劃下，工作流程也不會出現。
• 試用計劃無法使用附加包。 Premium Package for Java 需要付費的 Pro、Pro+、Ultra 或企業計劃。

開始使用

當你的計劃包含附加包且已登入 Bob IDE：

• 先在單個模組上執行 JDK 升級評估，在確定目標之前查看建議的路徑和難度評級。
• 如果覆蓋率不足，先產生一份 UNITTEST.md 策略，建立安全網，再進行任何版本跳躍。
• 逐模組審批變更——護欄的存在正是為了讓命名空間和依賴變更始終在你的掌控之中。

在 bob.ibm.com 查看案例研究，了解各團隊是如何端到端地完成這些遷移的。