Nhiều tổ chức sẵn sàng di chuyển từ Oracle Java SE sẽ tự hỏi quá trình này sẽ mất bao lâu. Tuy nhiên, không có câu trả lời chung cho tất cả câu hỏi đó. Thời gian cần thiết cho việc di chuyển phụ thuộc vào ít nhất sáu biến số dành riêng cho một tổ chức.
Một trong những biến số đó là mục tiêu di cư của công ty – một số mục tiêu mất nhiều thời gian hơn để đạt được so với các mục tiêu khác. Ví dụ: nếu mục tiêu là chuyển đổi hoàn toàn khỏi Oracle Java càng nhanh càng tốt thì kế hoạch di chuyển sẽ khác với kế hoạch của một tổ chức chủ yếu tìm kiếm sự hỗ trợ cho các ứng dụng cũ chạy các phiên bản Java cũ hơn, chẳng hạn như Java 6 và 7, và thích cách tiếp cận theo từng giai đoạn trong thời gian dài hơn.
Chuẩn bị di chuyển từ Oracle Java SE
Giai đoạn đầu tiên của quá trình di chuyển là lấy bản kiểm kê Java, đây thường là phần tốn nhiều thời gian nhất trong quá trình di chuyển Bộ công cụ phát triển Java (JDK) do có nhiều phiên bản JDK được sử dụng. Thông thường, khi một ứng dụng mới được triển khai, nó sẽ sử dụng phiên bản JDK mới nhất tại thời điểm đó và tiếp tục sử dụng ngay cả khi các phiên bản Java mới hơn được phát hành. Điều này khá logic vì nó đã được thử nghiệm với phiên bản đã triển khai.
Giả sử ứng dụng hoạt động mà không gặp sự cố thì không cần phải cập nhật phiên bản JDK của nó. Chỉ cần cập nhật khi các bản vá bảo mật và sửa lỗi không còn có sẵn cho phiên bản đang sử dụng và có những lo ngại về hiệu suất của ứng dụng hoặc một lỗ hổng bảo mật đã biết cần được giải quyết.
Để tạo bản kiểm kê mức sử dụng JDK hoàn chỉnh, các tổ chức phải kiểm tra từng máy trong khu vực của mình có chạy bất kỳ ứng dụng dựa trên máy ảo Java (JVM) nào hay không. Điều này có thể đơn giản nếu các công cụ quản lý tài sản CNTT (ITAM) được sử dụng để giám sát việc sử dụng phần mềm. Nhiều doanh nghiệp triển khai những công cụ này để đảm bảo họ tuân thủ các điều khoản và điều kiện cấp phép. Những công cụ này có thể nhanh chóng tạo ra một báo cáo cho biết máy nào đã cài đặt phiên bản Java nào. Các tập lệnh cũng có sẵn từ các nhà cung cấp như Azul để giúp kiểm kê các JVM một cách liền mạch.
Tiếp theo, tổ chức nên bắt đầu suy nghĩ về các vấn đề tiềm ẩn có thể nảy sinh dựa trên những gì được phát hiện trong quá trình kiểm kê.
Ví dụ: việc người dùng mua ứng dụng thay vì phát triển chúng là điều rất bình thường. Việc không phải phát triển và duy trì phần mềm riêng biệt trong nội bộ có thể rất tiết kiệm chi phí. Nhiều ứng dụng sử dụng Java sẽ chỉ định phiên bản JDK bắt buộc và thậm chí có thể là mức cập nhật phiên bản tối thiểu – điều này không khác với cách các ứng dụng khác chỉ định phiên bản tối thiểu của Windows hoặc Linux.
Người dùng phải lấy JDK và cung cấp nó cho ứng dụng. Các nhà cung cấp ứng dụng thường nêu rõ trong tài liệu của họ rằng họ sẽ chỉ hỗ trợ ứng dụng nếu được sử dụng với đúng JDK. Điều này là hợp lý đối với nhà phát triển ứng dụng vì nó có thể giúp loại bỏ các vấn đề gây ra do việc sử dụng thời gian chạy Java lỗi thời hoặc không phù hợp. Bởi vì Oracle JDK đã rất phổ biến trong quá khứ nên nhiều nhà cung cấp ứng dụng đã tuyên bố rằng chỉ có Oracle JDK mới đủ điều kiện được hỗ trợ.
Tuy nhiên, những thay đổi gần đây về cấp phép và định giá JDK của Oracle có nghĩa là người dùng ngày càng yêu cầu hỗ trợ khi chạy trên các JDK thay thế. Nhiều nhà cung cấp ứng dụng hiện sẽ cung cấp hỗ trợ miễn là ứng dụng đó đang chạy trên bản dựng OpenJDK được chứng nhận bởi Bộ công cụ tương thích công nghệ (TCK). Bởi vì họ có thể tin tưởng các bản phân phối như vậy có chức năng giống hệt với Oracle JDK nên họ không cần phải lo lắng về việc thử nghiệm nhiều bản phân phối bằng ứng dụng của mình.
Đôi khi, một ứng dụng sẽ nêu rõ rằng một số bản phân phối OpenJDK nhất định có giá trị để được hỗ trợ, nhưng không phải là bản phân phối mà tổ chức muốn sử dụng. Trong trường hợp này, người dùng nên liên hệ với nhà cung cấp ứng dụng để thêm bản phân phối cần thiết vào danh sách của họ. Miễn là nó đã được kiểm tra TCK thì nhà cung cấp sẽ không phản đối.
Trong bất kỳ tổ chức lớn nào sử dụng nhiều ứng dụng Java, các ứng dụng sẽ có các chủ sở hữu khác nhau. Khi lập kế hoạch di chuyển thành công, điều cần thiết là phải bao gồm tất cả các bên liên quan – nghĩa là tất cả chủ sở hữu ứng dụng phải sử dụng thời gian chạy Java mới và/hoặc quan tâm đến tình trạng của ứng dụng của họ.
Di chuyển sang OpenJDK
Các bản phân phối OpenJDK không hỗ trợ bản vá tại chỗ cho các bản cập nhật – việc áp dụng bản cập nhật cho JDK yêu cầu cài đặt một JDK hoàn toàn mới. Điều này có nghĩa là quá trình cài đặt di chuyển có thể được xử lý giống hệt như triển khai một bản cập nhật mới, ngoại trừ việc nó cài đặt bản cập nhật Zulu JDK thay vì bản cập nhật Oracle JDK.
Trừ khi có một lỗi cụ thể gây ra vấn đề về độ ổn định của ứng dụng, người dùng sẽ không thấy bất kỳ nhu cầu cấp thiết nào để chuyển sang phiên bản Java mới, ngay cả khi họ đang sử dụng một phiên bản khá cũ. Tuy nhiên, từ quan điểm quản trị, bạn nên cài đặt bản cập nhật mới nhất khi di chuyển sang bản phân phối OpenJDK mới để duy trì mức bảo mật cao nhất cho các ứng dụng.
Trong phần lớn các trường hợp, quá trình cập nhật diễn ra đơn giản và không có vấn đề gì. Tuy nhiên, đôi khi bản cập nhật bao gồm những thay đổi có thể thay đổi hoạt động của ứng dụng.
Một ví dụ về Tomcat
Hãy xem một ví dụ sử dụng công cụ servlet Apache Tomcat được sử dụng rất phổ biến. Giả sử chúng ta có Tomcat 8 chạy trên Oracle JDK 8u202. Đây không phải là bản phát hành mới nhất của Tomcat nhưng nó hoạt động hoàn hảo cho ứng dụng của chúng tôi nên chưa được nâng cấp. Chúng tôi có một servlet đang chạy lấy dữ liệu từ máy khách, thực hiện truy vấn trong cơ sở dữ liệu MySQL và trả về kết quả.
Để di chuyển, chúng tôi cài đặt bản cập nhật Zulu 8 372 và khởi động lại máy chủ. Tuy nhiên, khi cố gắng sử dụng ứng dụng, chúng tôi nhận được thông báo lỗi cho biết đã xảy ra lỗi liên kết giao tiếp. Điều này không liên quan gì đến việc chuyển từ Oracle sang Zulu.
Thay vào đó, nó là kết quả của một thay đổi được thực hiện trong bản cập nhật JDK 8 291 từ tháng 10 năm 2021. Trong bản cập nhật này, cài đặt mặc định cho Transport Layer Security (TLS) đã được thay đổi để tắt TLSv1.0 và TLSv1.1 theo mặc định. Do đó, để ứng dụng hoạt động như trước, chúng ta phải sửa đổi tệp jre/lib/security/java.security và xóa các tham chiếu TLS khỏi cài đặt thuật toán jdk.tls.disabled.
Khi điều tương tự xảy ra, điều quan trọng là phải xác minh rằng sự cố xảy ra do sử dụng bản cập nhật JDK khác chứ không phải do bản phân phối khác. Việc có một nhà cung cấp hỗ trợ thương mại có thể cung cấp các bản cập nhật cũ hơn có thể cực kỳ có lợi trong những trường hợp như vậy. Chỉ cần cài đặt cùng mức cập nhật của JDK, sau đó kiểm tra lại ứng dụng. Trong trường hợp ví dụ của chúng tôi, nhóm hỗ trợ Azul có thể cung cấp chi tiết về những thay đổi cấu hình cần thiết để giải quyết vấn đề.
Sau khi cài đặt JDK mới, chúng ta cần thực hiện mọi thay đổi bắt buộc để chuyển đổi ứng dụng sang sử dụng nó. Ví dụ: có thể cần phải thay đổi biến môi trường JAVA_HOME và các trình khởi chạy được sử dụng cho các ứng dụng riêng lẻ, chẳng hạn như công cụ servlet Tomcat. Tùy chọn an toàn nhất là thay đổi biến môi trường này trên tất cả các máy được di chuyển.
Sau khi cài đặt, chúng ta nên kiểm tra tất cả các ứng dụng đã được chuyển sang JDK mới để đảm bảo chức năng chính xác. Người dùng có thể sẽ không quan sát thấy bất kỳ hành vi nào khác trừ khi có thay đổi xảy ra giữa các lần cập nhật.
Kiểm tra để xác minh hành vi đúng
Quá trình thử nghiệm sẽ khác nhau rất nhiều tùy thuộc vào từng ứng dụng. Các ứng dụng được phát triển nội bộ có thể có các bài kiểm tra hồi quy mở rộng có thể thực hiện đầy đủ tất cả các phần của ứng dụng để xác minh hành vi đúng.
Các ứng dụng của bên thứ ba (nguồn mở hoặc thương mại) có thể có một bộ thử nghiệm tiêu chuẩn có thể chạy được. Nếu không, người dùng có kinh nghiệm nên chạy ứng dụng và thử càng nhiều khía cạnh chức năng càng tốt.
Sau khi tất cả các thử nghiệm đã vượt qua và làm hài lòng từng người dùng, quá trình di chuyển đã hoàn tất. Tổ chức giờ đây sẽ ở vị thế vững chắc để duy trì tính chất Java của mình ở mức độ bảo mật và ổn định cao nhất, thường là cao hơn trước. Ngoài ra, nó sẽ có một bức tranh rõ ràng về nơi sử dụng thời gian chạy Java và có thêm kinh nghiệm trong việc nâng cấp máy lên bản cập nhật Java mới nhất.
Bài viết này dựa trên một đoạn trích từ Di chuyển OpenJDK dành cho người giả, phiên bản đặc biệt Azulcủa nhà vô địch Java Simon Ritter.