Java 8 Compiler Confusion Z przeciążonymi metodami

Question

Podczas aktualizacji aplikacji do Java 8 natknąłem się na dziwny problem z numerem Google Guava newArrayList w kilku miejscach.

Spójrz na ten przykład:

import com.google.common.collect.UnmodifiableIterator; 

import javax.naming.NamingException; 
import javax.naming.directory.Attribute; 
import javax.naming.directory.BasicAttribute; 
import java.util.ArrayList; 

import static com.google.common.collect.Iterators.forEnumeration; 
import static com.google.common.collect.Lists.newArrayList; 

public class NewArrayListIssue { 
    public static void main(String[] args) throws NamingException { 

     UnmodifiableIterator<?> elements = forEnumeration(getEnumeration().getAll()); 
     System.out.println("declarefirst = " + newArrayList(elements)); // calls newArrayList(Iterator<? extends E> elements) 

     ArrayList directCopy = newArrayList(forEnumeration(getEnumeration().getAll())); 
     System.out.println("useDirectly = " + directCopy); //calls newArrayList(E... elements) 
    } 

    public static Attribute getEnumeration(){ 
     return new BasicAttribute("foo",1); 
    } 
} 

w pierwszym przykładzie, kiedy dostanę UnmodifiableIterator najpierw do własnej zmiennej, a następnie zadzwonić newArrayList dostanę to, czego oczekuję, czyli wartości Iteratory kopiowane do nowy List.

W drugim przykładzie, gdzie forEnumeration idzie bezpośrednio do metody newArrayList, otrzymuję z powrotem List z zawierającym iterator (który zawiera wartość).

Według IntelliJ nim myśli że oba połączenia metody należy do newArrayList(Iterator<? extends E> elements) ale znalazłem podczas debugowania, że ​​druga rozmowa faktycznie idzie do newArrayList(E... elements).

Dzieje się tak tylko wtedy, gdy kompiluję się z Oracle JDK8 ukierunkowanym na Java8. Jeśli celuję na 7, działa dobrze.

Answer 1

Problem polega na tym, że kompilator uważa, że ​​nie ma zastosowania newArrayList(Iterator<? extends E>) (być może z powodu this bug), a następnie po cichu wybiera ogólną metodę varargs, która ma zawsze zastosowanie (co świadczy o niebezpieczeństwie takiego przeciążenia), gdy nie używasz określonego typu elementu dla listy wyników.

Błąd pojawia się z typów wieloznacznych, czyli w kodzie to Attribute.getAll() Zwracanie NamingEnumeration<?> stąd wynik forEnumeration jest UnmodifiableIterator<?> który kompilator odmawia przypisać Iterable<? extends E>, typ parametru newArrayList. Jeśli rzucisz wartość zwracaną wewnętrznego wywołania na Enumeration, problem zniknie, tak jak podczas przesyłania wartości zwracanej zewnętrznego połączenia do Iterator.

Nie widzę prostego, krótkoterminowego rozwiązania tego problemu. W końcu nie rozumiem, dlaczego nie używałeś List<?> directCopy=Collections.list(getEnumeration().getAll()); w pierwszej kolejności ...

Pamiętaj, że jeśli chcesz znaleźć wszystkie wystąpienia tego problemu, możesz po prostu użyć poprawionej wersji guawy, w której newArrayList(E...) został usunięty i sprawdź wszystkie błędy kompilatora (zakładając, że nie masz wielu przypadków, w których naprawdę chcesz nazwać to przeciążeniem). Po przepisaniu stron z ogłoszeniami możesz wrócić do pierwotnego guawy.

Answer 2

Widziałem to z przeciążonymi metodami i typami ogólnymi. W tym przypadku wybiera się bardziej ogólną wersję newArrayList(), gdy parametr nie jest jawnie wpisany.

nie mam technicznego wyjaśnienia dla ciebie, ale polecam wymusić korzystanie z żądanym przez przeciążenie metody rzucania:

ArrayList directCopy = newArrayList((Iterator)forEnumeration(getEnumeration().getAll()));