Có thể giải quyết được một mảng chung của T được tạo cho cảnh báo trình biên dịch tham số varargs không?

Đây là một phiên bản đơn giản của mã đang được đề cập, một lớp chung sử dụng một lớp khác với các tham số kiểu chung và cần truyền một trong các kiểu chung cho một phương thức có tham số varargs:

class Assembler<X, Y> {
    void assemble(X container, Y... args) { ... }
}

class Component<T> {
    void useAssembler(T something) {

        Assembler<String, T> assembler = new Assembler<String, T>();

        //generates warning:
        // Type safety : A generic array of T is
        // created for a varargs parameter
        assembler.assemble("hello", something);
    }

}

Có cách nào chính xác để chuyển dọc theo tham số chung cho phương thức varargs mà không gặp phải cảnh báo này không?

Tất nhiên một cái gì đó như

assembler.assemble("hello", new T[] { something });

không hoạt động vì bạn không thể tạo mảng chung.

Ngoài việc thêm vào @SuppressWarnings("unchecked"), tôi không nghĩ vậy.

Đây báo cáo lỗi có thêm thông tin nhưng nó nắm để trình biên dịch không thích mảng của các kiểu generic.

Tom Hawtin đã chỉ ra điều này trong một bình luận, nhưng để rõ ràng hơn: có, bạn có thể giải quyết vấn đề này tại trang web khai báo (chứ không phải là các trang web gọi (có khả năng nhiều)): chuyển sang JDK7.

Như bạn có thể thấy trong bài đăng trên blog của Joseph Darcy, bài tập Project Coin để chọn một số cải tiến ngôn ngữ gia tăng nhỏ cho Java 7 đã chấp nhận đề xuất của Bob Lee để cho phép một cái gì đó giống như @SuppressWarnings("varargs")ở phương thức biến cảnh báo này biến mất trong tình huống mà nó được biết đến an toàn

Điều này đã được thực hiện trong OpenJDK với cam kết này .

Điều này có thể hữu ích hoặc không hữu ích cho dự án của bạn (nhiều người sẽ không vui khi chuyển sang phiên bản không ổn định trước khi phát hành của JVM!) Nhưng có lẽ nó - hoặc có lẽ ai đó đã tìm thấy câu hỏi này sau đó (sau khi JDK7 không hoạt động ) sẽ tìm thấy nó hữu ích.

Nếu bạn đang theo một giao diện thông thạo, bạn có thể thử mẫu xây dựng. Không ngắn gọn như varargs nhưng nó là loại an toàn.

Một phương pháp gõ tổng quát tĩnh có thể loại bỏ một số mẫu soạn sẵn khi sử dụng trình xây dựng, trong khi vẫn giữ được độ an toàn của loại.

Người xây dựng

public class ArgBuilder<T> implements Iterable<T> {

    private final List<T> args = new ArrayList<T>();

    public ArgBuilder<T> and(T arg) {
        args.add(arg);
        return this;
    }

    @Override
    public Iterator<T> iterator() {
        return args.iterator();
    }

    public static <T> ArgBuilder<T> with(T firstArgument) {
        return new ArgBuilder<T>().and(firstArgument);
    }
}

Sử dụng nó

import static com.example.ArgBuilder.*;

public class VarargsTest {

    public static void main(String[] args) {
        doSomething(new ArgBuilder<String>().and("foo").and("bar").and("baz"));
        // or
        doSomething(with("foo").and("bar").and("baz"));
    }

    static void doSomething(Iterable<String> args) {
        for (String arg : args) {
            System.out.println(arg);
        }
    }
}

Hoàn toàn truyền tham số cho Object trong lời gọi phương thức vararg sẽ làm cho trình biên dịch hài lòng mà không cần dùng đến @SuppressWarnings.

public static <T> List<T> list( final T... items )
{
    return Arrays.asList( items );
}

// This will produce a warning.
list( "1", 2, new BigDecimal( "3.5" ) )

// This will not produce a warning.
list( (Object) "1", (Object) 2, (Object) new BigDecimal( "3.5" ) )

// This will not produce a warning either. Casting just the first parameter to 
// Object appears to be sufficient.
list( (Object) "1", 2, new BigDecimal( "3.5" ) )

Tôi tin rằng vấn đề ở đây là trình biên dịch cần phải tìm ra loại mảng cụ thể để tạo. Nếu phương thức không chung chung, trình biên dịch có thể sử dụng thông tin loại từ phương thức. Nếu phương thức này là chung, nó cố gắng tìm ra kiểu mảng dựa trên các tham số được sử dụng trong lệnh gọi. Nếu các loại tham số là homogen, nhiệm vụ đó là dễ dàng. Nếu chúng khác nhau, trình biên dịch cố gắng quá thông minh theo ý kiến ​​của tôi và tạo ra một mảng chung kiểu kết hợp. Sau đó, nó cảm thấy buộc phải cảnh báo bạn về nó. Một giải pháp đơn giản hơn là tạo Object [] khi loại không thể thu hẹp tốt hơn. Các giải pháp trên chỉ có thế.

Để hiểu rõ hơn về điều này, hãy chơi xung quanh với các yêu cầu cho phương thức danh sách trên so với phương thức list2 sau đây.

public static List<Object> list2( final Object... items )
{
    return Arrays.asList( items );
}

Bạn có thể thêm @SafeVarargs vào phương thức kể từ Java 7 và bạn không phải chú thích vào mã máy khách.

class Assembler<X, Y> {

    @SafeVarargs
    final void assemble(X container, Y... args) {
        //has to be final...
    }
}

Bạn có thể có quá tải các phương thức. Điều này không giải quyết được vấn đề của bạn nhưng nó giảm thiểu số lượng cảnh báo (và vâng, đó là một vụ hack!)

class Assembler<X, Y> {
  void assemble(X container, Y a1) { ... }
  void assemble(X container, Y a1, Y a2) { ... }
  void assemble(X container, Y a1, Y a2, Y a3) { ... }
  void assemble(X container, Y a1, Y a2, Y a3, Y a4) { ... }
  void assemble(X container, Y... args) { ... }
}

Đây là một vấn đề rất dễ giải quyết: Sử dụng List<T>!

Mảng loại tham chiếu nên tránh.

Trong phiên bản hiện tại của Java (1.7), bạn có thể đánh dấu phương thức @SafeVargssẽ loại bỏ cảnh báo khỏi người gọi. Mặc dù cẩn thận với điều đó, và bạn vẫn tốt hơn nếu không có mảng kế thừa.

Xem thêm Các cảnh báo và lỗi trình biên dịch được cải tiến khi sử dụng các tham số chính thức không thể xác định lại với ghi chú công nghệ của phương thức Varargs .

Khi làm việc với các mảng thuộc loại chung, tôi buộc phải chuyển một tham chiếu đến loại chung. Với điều đó, tôi thực sự có thể thực hiện mã chung, sử dụng java.lang.reflect.Array.

http://java.sun.com/javase/6/docs/api/java/lang/reflect/Array.html