Le piège que l'implémentation par défaut de l'interface Java 8 apporte
Arrêtons d'utiliser la version EOL ...
Cela fait un moment que j'ai implémenté Iterator, ce qui peut être la première fois. Lorsque je m'engage, il devient rouge dans Eclipse des autres pour une raison quelconque.
Java8Iterator.java
import java.util.Iterator;
public class Java8Iterator implements Iterator<Integer> {
@Override
public boolean hasNext() {
// TODO Auto-generated method stub
return false;
}
@Override
public Integer next() {
// TODO Auto-generated method stub
return null;
}
}
Java7Iterator.java
import java.util.Iterator;
public class Java7Iterator implements Iterator<Integer> {
@Override
public boolean hasNext() {
// TODO Auto-generated method stub
return false;
}
@Override
public Integer next() {
// TODO Auto-generated method stub
return null;
}
@Override
public void remove() {
// TODO Auto-generated method stub
}
}
Pouvez-vous voir la différence? Java7Iterator a une méthode de suppression et Java8Iterator n'a pas de méthode de suppression. Il existe des environnements dans lesquels il n'y a pas de problème même s'il n'est pas implémenté, et il y a des environnements où des erreurs de compilation se produisent s'il n'est pas implémenté.
En regardant le chemin de construction Java du projet, il s'agit de "JRE System Library [Java SE-1.6]". N'était-ce même pas Java7!
Si les paramètres du projet sont Java 1.6 mais que jre 1.8.0 est utilisé, le code généré par "Ajouter des méthodes non implémentées" d'Eclipse n'inclut pas la méthode remove. Lorsque j'ai configuré le JRE compatible pour utiliser correctement jre 1.6, le code généré inclut désormais une méthode de suppression.
Si vous cochez src.zip de JDK8, l'implémentation par défaut est décrite dans l'interface Iterator. S'il existe une implémentation par défaut, elle ne sera pas traitée comme une méthode non implémentée.
C'est pourquoi vous devez soit enterrer une version EOL de Java, soit configurer un JRE étroitement compatible.
Recommended Posts