Java 8: Trình tách, bộ lặp, bộ sưu tập và các thực thi "mặc định" trong giao diện (Các phương thức trùng lặp có tên là bộ tách)

Question

Có một tình huống thú vị sau khi phát hành Java 1.8.0_25 vào vùng hoang dã ... Tôi tin rằng gốc của vấn đề của tôi là liên quan chủ yếu đến các tính năng mới (đến 1.8) của việc triển khai "mặc định" trong Giao diện.

Ứng dụng tôi đang làm việc hiện được nhắm mục tiêu là 1.7, cho đến bây giờ đã hoạt động tốt. Cho đến khi người dùng bắt đầu cập nhật lên 1.8. Bây giờ người dùng của chúng tôi đã bắt đầu cập nhật lên 1,8, bàn tay của chúng tôi buộc phải chuyển sang hỗ trợ 1,8.

Chúng tôi đã khắc phục hầu hết các sự cố (chủ yếu liên quan đến các thay đổi đối với các gói JavaFX trong khoảng từ 1.7 đến 1.8) nhưng vẫn còn một vấn đề.

Trong sự khôn ngoan của tôi, hoặc thiếu đó, tôi, một số thời gian trước đây, quyết định tạo ra một SortedList <T> mà kéo dài từ AbstractList <T>. Cho đến nay, lớp học này đã làm việc tốt, tuy nhiên khi chạy trên một thời gian chạy 1.8, tôi nhận được:

Duplicate methods named spliterator with the parameters() and() are inherited 
from the types Collection<T> and Iterable<T> 

này, với tôi, dường như được gây ra bởi việc triển khai "mặc định" trong một số các giao diện được thực hiện bởi AbstractList <T> (lớp SortedList <T> không thực hiện bất kỳ Giao diện bổ sung nào khác ngoài Serializable). Thực hiện Serializable là một vấn đề khác đối với chúng tôi, vì chúng tôi cần hỗ trợ deserialisation của các đối tượng SortedList <T>, không có cách nào xung quanh điều đó!).

Tôi có thể loại bỏ lỗi bằng cách cung cấp triển khai ghi đè bộ tách() trong lớp SortedList <T> của tôi. Tuy nhiên, nếu điều này được xây dựng, nó không còn chạy trên môi trường Java 1.7 nữa. Nếu tôi cố gắng sử dụng SortedList <T> với một thời gian chạy 1.7, tôi nhận được:

Problem: 
Error: Unresolved compilation problems: 
The import java.util.Spliterator cannot be resolved 
Spliterator cannot be resolved to a type 

com.xxxx.xxxx.util.SortedList.<init>(SortedList.java:13) 

Lỗi này là khá rõ ràng, kể từ bây giờ chúng tôi đã ghi đè phương pháp spliterator() trong SortedList <T> nó cần phải bao gồm java.util.Spliterator, nhưng điều đó không tồn tại trong 1.7.

Lý tưởng nhất là chúng tôi KHÔNG yêu cầu khách hàng của chúng tôi cập nhật lên Java 1.8 nếu họ không muốn.

Bàn tay của chúng tôi có bị ép buộc ở đây không? Chúng ta có cần buộc người dùng cập nhật lên 1.8 và cũng tung ra phiên bản mới cho bất kỳ người dùng nào đã tự cập nhật lên 1.8 không?

Có ai biết cách giải quyết vấn đề này không?

Trên một lưu ý mang tính triết học hơn, tại sao Giao diện bị hỏng với việc thực hiện :-(Có thể là một tính năng mới tiện lợi, nhưng họ thực sự nên tránh làm bất cứ điều gì dẫn đến vi phạm các thay đổi đối với mã hiện có, đặc biệt là một số điều cơ bản như danh sách/bộ sưu tập, v.v.

Bất kỳ trợ giúp hoặc đề xuất nào về tình trạng khó khăn này sẽ được đánh giá cao.

Chúc mừng,

Đánh dấu

Answer 1

Ok, do đó cả hai bạn (@Holger và @assylias) là đúng ... Nhưng, tình hình của chúng tôi là một chút phức tạp hơn.

Môi trường chúng tôi đang làm việc là Eclipse 3.8.1 không hỗ trợ Java 8 (và sẽ không tương lai với kiến ​​thức của tôi). Vì vậy, chúng tôi không thể thay đổi sang trình biên dịch Java 8 để khắc phục sự cố.

Sản phẩm của chúng tôi là một ứng dụng RCP Eclipse khá lớn. Việc nâng cấp IDE của chúng tôi hiện không phải là một lựa chọn, vì sẽ có những sửa đổi lớn liên quan. Chúng tôi sẽ cần tiếp tục để phát triển theo môi trường Java 1.7 vì lý do này.

Nếu có ai quan tâm, chúng tôi đã giải quyết vấn đề bằng cách:

• mảnh Tạo (một cho mỗi phiên bản Java gây ra các vấn đề, vì vậy ba trong trường hợp của chúng tôi) cho plugin chính của chúng tôi. Những mảnh vỡ này được cấu hình như các mảnh vá.
• Đã thêm Java FX JAR vào các đoạn (Điều này được thực hiện để giải quyết một số vấn đề với Java FX trong bản phát hành trước đó và một lần nữa cho bản phát hành 1.8.0_25).
• Cũng trong các đoạn, trong cùng một không gian tên như plugin chính, chúng tôi đã thêm việc triển khai lớp SortedList. Mã này giống hệt nhau cho mỗi trường hợp, nhưng đoạn cho Java 8 được biên dịch riêng với trình biên dịch Java 8. Việc ghi đè phương thức spliterator() không cần thiết ở cuối (khi được biên dịch bằng trình biên dịch Java 8 , nó hoạt động ok và vẫn biên dịch với trình biên dịch 1.7 vì không có tham chiếu đến lớp Spliterator nữa).

Đây có lẽ không phải là giải pháp lý tưởng, nhưng nó sẽ hoạt động mà chúng tôi nghĩ :-).

Cảm ơn bạn đã nhập ý kiến ​​&, được đánh giá cao.

Answer 2

Toàn bộ vấn đề của phương pháp mặc định là để tránh những tình huống mà bạn mô tả. Mã bên dưới biên dịch và chạy như mong đợi với Java 7 và 8:

public class SortedList<T> extends AbstractList<T> implements Serializable { 
    @Override public T get(int index) { return null; } 
    @Override public int size() { return 0; } 

    public static void main(String[] args) { 
    SortedList<String> s = new SortedList<>(); 
    System.out.println(s.size()); 
    } 
} 

Answer 3

thử Tạo một lớp trừu tượng đó sẽ ghi đè các spliterator() với hành vi ưa thích định nghĩa tức là

abstract class Java8_AbstractCollection<E> extends AbstractCollection<E> { 

    /* (non-Javadoc) 
    * @see java.util.Collection#spliterator() 
    */ 
    public Spliterator<E> spliterator() { 
     return (Spliterator<E>) super.spliterator(); 
    } 
}