2017-06-23 2 views
0

J'essaie de comprendre la pensée du compilateur Java (je sais, mauvaise idée) ...Java erreur du compilateur: Type brut avec la méthode de retour en option

Tenir compte de ce programme:

import java.util.Optional; 
public class xx { 

    public static class Foo<T> { 
     public interface Bar<T> { 
      int getX(); 
     } 
     public Optional<Bar<T>> getBar() { 
      return Optional.empty(); 
     } 
    } 

    public static void main(String[] args) throws Exception { 
     Foo foo = new Foo();    // note raw type 
     foo.getBar().get().getX(); 
    } 
} 

java 1.8.0_112 compilateur donne:

xx.java:15: error: cannot find symbol 
     foo.getBar().get().getX(); 
         ^
    symbol: method getX() 
    location: class Object 
1 error 

la question est: pourquoi ne pas le compilateur, étant donné le type brut Foo pour foo, se rendre compte que le type de retour foo.getBar() est Optional<? extends Bar> au lieu de ce qu'il semble penser, qui est Optional<?>?

Note: Je sais comment changer ce programme pour qu'il soit compilé, ce n'est pas la question.

+0

[Effacement de type] (https://docs.oracle.com/javase/tutorial/java/generics/bridgeMethods.html)? –

+0

L'effacement de type est un problème d'exécution, pas un problème de compilation. Mais je sais ce que vous voulez dire - cela a clairement quelque chose à voir avec l'utilisation d'un type brut. – Archie

Répondre

1

Une fois que vous utilisez des types premières en conjonction avec l'inférence de type, ce qui suit de JLS 18.5.2 appliquera

If unchecked conversion was necessary for the method to be applicable during constraint set reduction in §18.5.1, then [...] the return type and thrown types of the invocation type of m are given by the erasure of the return type and thrown types of m's type.

De ce fait suite, que le type de retour de foo.getBar() est en effet juste Optional avec tous les arguments de type effacés . Solution: éviter les types bruts, toujours.

+0

Merci. Un peu décevant mais compréhensible je suppose. – Archie