Điểm của toán tử kim cương (<>) trong Java 7 là gì?

Toán tử kim cương trong java 7 cho phép mã như sau:

List<String> list = new LinkedList<>();

Tuy nhiên, trong Java 5/6, tôi chỉ có thể viết:

List<String> list = new LinkedList();

Sự hiểu biết của tôi về loại tẩy là những cái này hoàn toàn giống nhau. (Cái chung được loại bỏ trong thời gian chạy anyway).

Tại sao phải bận tâm với kim cương cả? Những gì chức năng / loại an toàn mới mà nó cho phép? Nếu nó không mang lại bất kỳ chức năng mới nào thì tại sao họ lại đề cập đến nó như một tính năng? Là sự hiểu biết của tôi về khái niệm này là thiếu sót?

Vấn đề với

List<String> list = new LinkedList();

là ở phía bên tay trái, bạn đang sử dụng chung loại List<String>nơi ở phía bên phải bạn đang sử dụng các nguyên liệu loại LinkedList. Các kiểu thô trong Java thực sự chỉ tồn tại để tương thích với mã tiền chung và không bao giờ được sử dụng trong mã mới trừ khi bạn thực sự phải làm vậy.

Bây giờ, nếu Java có các tổng quát ngay từ đầu và không có các kiểu, chẳng hạn như LinkedListđược tạo ra trước khi có các tổng quát, thì có lẽ nó đã tạo ra nó để hàm tạo cho một kiểu chung tự động truyền các tham số kiểu của nó từ bên trái bên tay của nhiệm vụ nếu có thể. Nhưng nó đã không, và nó phải xử lý các loại thô và loại chung khác nhau để tương thích ngược. Điều đó khiến họ cần phải thực hiện một cách khác để khai báo một thể hiện mới của một đối tượng chung mà không phải lặp lại các tham số loại của nó ... toán tử kim cương.

Theo như ví dụ ban đầu của bạn List<String> list = new LinkedList(), trình biên dịch tạo cảnh báo cho phép gán đó bởi vì nó phải. Xem xét điều này:

List<String> strings = ... // some list that contains some strings

// Totally legal since you used the raw type and lost all type checking!
List<Integer> integers = new LinkedList(strings);

Generics tồn tại để cung cấp bảo vệ thời gian biên dịch chống lại việc làm sai. Trong ví dụ trên, sử dụng loại thô có nghĩa là bạn không nhận được sự bảo vệ này và sẽ gặp lỗi khi chạy. Đây là lý do tại sao bạn không nên sử dụng các loại thô.

// Not legal since the right side is actually generic!
List<Integer> integers = new LinkedList<>(strings);

Tuy nhiên, toán tử kim cương cho phép phía bên phải của phép gán được xác định là một thể hiện chung thực sự với các tham số cùng loại với bên trái ... mà không phải nhập lại các tham số đó. Nó cho phép bạn giữ sự an toàn của thuốc generic với nỗ lực gần như tương tự như sử dụng loại thô.

Tôi nghĩ điều quan trọng cần hiểu là các loại thô (không có <>) không thể được đối xử giống như các loại chung. Khi bạn khai báo một loại thô, bạn sẽ không nhận được bất kỳ lợi ích và kiểm tra loại tổng quát nào. Bạn cũng phải nhớ rằng thuốc generic là một phần mục đích chung của ngôn ngữ Java ... chúng không chỉ áp dụng cho các nhà xây dựng không tranh cãi của Collections!

Sự hiểu biết của bạn hơi thiếu sót. Toán tử kim cương là một tính năng hay vì bạn không cần phải lặp lại. Thật hợp lý khi xác định loại một lần khi bạn khai báo loại nhưng không có nghĩa là xác định lại loại ở bên phải. Nguyên tắc DRY.

Bây giờ để giải thích tất cả các fuzz về việc xác định các loại. Bạn đúng rằng loại được loại bỏ trong thời gian chạy nhưng một khi bạn muốn lấy một cái gì đó ra khỏi Danh sách với định nghĩa loại, bạn sẽ lấy lại như loại bạn đã xác định khi khai báo danh sách nếu không nó sẽ mất tất cả các tính năng cụ thể và chỉ có Các tính năng đối tượng ngoại trừ khi bạn chuyển đối tượng được truy xuất về loại ban đầu, đôi khi có thể rất phức tạp và dẫn đến ClassCastException.

Sử dụng List<String> list = new LinkedList()sẽ giúp bạn có được cảnh báo rawtype.

Dòng này gây ra cảnh báo [không được kiểm tra]:

List<String> list = new LinkedList();

Vì vậy, câu hỏi biến đổi: tại sao cảnh báo [không được kiểm tra] không tự động bị chặn chỉ dành cho trường hợp khi bộ sưu tập mới được tạo?

Tôi nghĩ rằng, nó sẽ là nhiệm vụ khó khăn hơn nhiều sau đó thêm <>tính năng.

CẬP NHẬT : Tôi cũng nghĩ rằng sẽ có một mớ hỗn độn nếu sử dụng hợp pháp các loại thô 'chỉ cho một vài thứ'.

Về lý thuyết, toán tử kim cương cho phép bạn viết mã nhỏ gọn hơn (và có thể đọc được) bằng cách lưu các đối số kiểu lặp lại. Trong thực tế, đó chỉ là hai ký tự khó hiểu hơn cho bạn không có gì. Tại sao?

1. Không có lập trình viên lành mạnh sử dụng các loại thô trong mã mới. Vì vậy, trình biên dịch có thể đơn giản giả định rằng bằng cách viết không có đối số kiểu nào bạn muốn nó suy ra chúng.
2. Toán tử kim cương không cung cấp thông tin loại, nó chỉ nói trình biên dịch, "nó sẽ ổn thôi". Vì vậy, bằng cách bỏ qua nó, bạn có thể không làm hại. Tại bất kỳ nơi nào mà toán tử kim cương là hợp pháp, trình biên dịch có thể được "suy ra".

IMHO, có một cách rõ ràng và đơn giản để đánh dấu một nguồn là Java 7 sẽ hữu ích hơn là phát minh ra những thứ kỳ lạ như vậy. Trong mã được đánh dấu như vậy, các loại thô có thể bị cấm mà không mất gì.

Btw., Tôi không nghĩ rằng nó nên được thực hiện bằng cách sử dụng một công tắc biên dịch. Phiên bản Java của tệp chương trình là một thuộc tính của tệp, không có tùy chọn nào cả. Sử dụng một cái gì đó tầm thường như

package 7 com.example;

có thể làm cho nó rõ ràng (bạn có thể thích một cái gì đó tinh vi hơn bao gồm một hoặc nhiều từ khóa ưa thích). Nó thậm chí sẽ cho phép biên dịch các nguồn được viết cho các phiên bản Java khác nhau mà không gặp vấn đề gì. Nó sẽ cho phép giới thiệu các từ khóa mới (ví dụ: "mô-đun") hoặc loại bỏ một số tính năng lỗi thời (nhiều lớp không lồng nhau không công khai trong một tệp hoặc bất cứ điều gì) mà không mất bất kỳ khả năng tương thích nào.

Khi bạn viết List<String> list = new LinkedList();, trình biên dịch sẽ tạo ra một cảnh báo "không được kiểm tra". Bạn có thể bỏ qua nó, nhưng nếu bạn thường bỏ qua những cảnh báo này, bạn cũng có thể bỏ lỡ một cảnh báo thông báo cho bạn về một vấn đề an toàn loại thực.

Vì vậy, tốt hơn là viết một mã không tạo ra các cảnh báo bổ sung và toán tử kim cương cho phép bạn thực hiện theo cách thuận tiện mà không cần lặp lại không cần thiết.

Tất cả cho biết trong các phản hồi khác là hợp lệ nhưng các trường hợp sử dụng không hoàn toàn hợp lệ IMHO. Nếu một người kiểm tra Guava và đặc biệt là các bộ sưu tập liên quan đến công cụ, điều tương tự đã được thực hiện với các phương thức tĩnh. Ví dụ: Lists.newArrayList () cho phép bạn viết

List<String> names = Lists.newArrayList();

hoặc với nhập tĩnh

import static com.google.common.collect.Lists.*;
...
List<String> names = newArrayList();
List<String> names = newArrayList("one", "two", "three");

Quả ổi có các tính năng rất mạnh khác như thế này và tôi thực sự không thể nghĩ ra nhiều cách sử dụng cho <>.

Sẽ hữu ích hơn nếu họ định biến hành vi của toán tử kim cương thành mặc định, nghĩa là kiểu được suy ra từ phía bên trái của biểu thức hoặc nếu kiểu bên trái được suy ra từ phía bên phải. Cái sau là những gì xảy ra trong Scala.

Điểm cho toán tử kim cương chỉ đơn giản là giảm việc gõ mã khi khai báo các kiểu chung. Nó không có bất kỳ ảnh hưởng nào đến thời gian chạy.

Sự khác biệt duy nhất nếu bạn chỉ định trong Java 5 và 6,

List<String> list = new ArrayList();

là bạn phải chỉ định @SuppressWarnings("unchecked")cho list(nếu không bạn sẽ nhận được cảnh báo truyền không được kiểm tra). Hiểu biết của tôi là nhà điều hành kim cương đang cố gắng để phát triển dễ dàng hơn. Không có gì để làm trong thời gian chạy thực thi chung chung.