JDK, JRE một khả năng tương thích lọ

Question

Tôi biết một chút thông tin về JDK và JRE nguồn và khả năng tương thích nhị phân (ví dụ this và this), nhưng không chắc chắn về tình hình sau:

Cân nhắc tôi có một ứng dụng được biên dịch sử dụng JDK5 và chạy trên JRE6. Nó sử dụng một số thư viện (lọ) cũng được biên dịch bằng cách sử dụng JDK5.

Bây giờ tôi muốn biên dịch ứng dụng của mình bằng JDK6. Những vấn đề mới có thể phát sinh trong thời gian chạy trong trường hợp này (đặc biệt, trong khả năng tương thích với các lọ "cũ")? Tôi có nên thử lại hoàn toàn ứng dụng (chạm vào mọi thư viện) hay có thể dựa vào khả năng tương thích JDK/JRE đã hứa không?

Answer 1

Cho đến khi và trừ khi bạn không thay đổi mã của mình và thêm các tính năng Java 6 mới, sẽ không có vấn đề gì. Đối với các lọ khác, không có vấn đề gì cả. JDK luôn duy trì tính tương thích ngược.

Answer 2

Tính tương thích chủ yếu hoạt động. Tôi sẽ không mong đợi bất kỳ vấn đề nào cho bạn phát sinh ngoài một số cảnh báo khác nhau cho ví dụ: không sử dụng Generics. Có thể một số API được sử dụng hầu như không được chấp nhận, nhưng tôi cho rằng chúng đã được đặt đúng vị trí, chỉ được đánh dấu là không dùng nữa.

Chỉ cần dùng thử, nếu nó biên dịch bạn nên vẫn ổn.

Một khía cạnh thiết kế quan trọng của Java - thật không may - là khả năng tương thích ngược hoàn toàn.

Có rất ít ngoại lệ trong đó khả năng tương thích ngược không được bảo toàn; nổi bật nhất của Eclipse là khi thuật toán sắp xếp được thay đổi từ một thuật toán ổn định thành một thuật toán sắp xếp không ổn định (thứ tự của các đối tượng phân loại giống hệt nhau không còn được bảo tồn); nhưng đó không bao giờ là một phần của đặc tả Java, nhưng là một lỗi trong Eclipse.

Thật không may, bởi vì có một vài lựa chọn không tốt mà bây giờ không thể thay đổi. Iterator không được có chức năng remove() trong API, Vector không được đồng bộ hóa (được giải quyết bằng cách có ArrayList bây giờ), StringBuffer không được đồng bộ hóa, do đó StringBuilder. String có lẽ phải là một giao diện, không phải là một lớp, để cho phép, ví dụ: Chuỗi 8 bit, chuỗi 32 bit - CharSequence là giao diện chuỗi tốt hơn, nhưng có quá nhiều phương thức không chấp nhận CharSequence và yêu cầu trả lại String. Observable cũng là một giao diện: bạn không thể tạo một phân lớp có thể quan sát được với API này. Đến tên một vài. Nhưng vì khả năng tương thích ngược, chúng không thể được cố định nữa cho đến khi có thể mô đun hóa JDK (tại thời điểm đó một số có thể ít nhất biến mất thành một mô-đun không sử dụng ...).

Tất nhiên bạn nên đã có hàng ngàn đơn vị kiểm tra để giúp bạn thử nghiệm với JDK mới ... :-)

Answer 3

Thông thường không có vấn đề phát sinh nên nếu bạn thiết lập các tùy chọn trình biên dịch của JDK6 để sử dụng 1.5 khả năng tương thích nguồn. Tuy nhiên đôi khi điều này không phải lúc nào cũng đúng.

Tôi nhớ một lần khi biên dịch mã 1.4 với trình biên dịch 1.5 (sử dụng 1.4 khả năng tương thích). Các lọ nơi ok (1,4 mức độ nhị phân) nhưng ứng dụng bị hỏng do chuyển đổi buồn cười.

Chúng tôi đã sử dụng số BigDecimal chuyển số nguyên làm đối số cho hàm tạo. Chỉ 1.4 version chỉ có một hàm tạo từ double nhưng 1.5 version có cả hai, các nhà thầu int và double. Vì vậy, khi biên dịch với trình biên dịch 1.4 đã thực hiện chuyển đổi tự động từ int thành double, nhưng với trình biên dịch 1.5, nó đã kiểm tra rằng trình xây dựng int tồn tại và không nhận ra chuyển đổi đó. Sau đó, khi sử dụng mã tương thích nhị phân hoàn hảo trên 1,4 JRE, chương trình đã bị lỗi với NoSuchMethodException.

Tôi phải thừa nhận rằng đó là một trường hợp lạ, nhưng nó là một trong những trường hợp mà logic không hoạt động. Vì vậy, lời khuyên của tôi là nếu bạn có kế hoạch biên dịch cho các phiên bản cũ hơn của JRE, hãy thử sử dụng JDK phiên bản đích bất cứ khi nào có thể.