Qu'est-ce qu'un type brut?
La spécification du langage Java définit un type brut comme suit:
Un type brut est défini comme étant:
Type de référence formé en prenant le nom d'une déclaration de type générique sans liste d'arguments de type associée.
Un type de tableau dont le type d'élément est un type brut.
Un statictype non membre d'un type brut Rqui n'est pas hérité d'une superclasse ou d'une superinterface de R.
Voici un exemple pour illustrer:
public class MyType<E> {
class Inner { }
static class Nested { }
public static void main(String[] args) {
MyType mt; // warning: MyType is a raw type
MyType.Inner inn; // warning: MyType.Inner is a raw type
MyType.Nested nest; // no warning: not parameterized type
MyType<Object> mt1; // no warning: type parameter given
MyType<?> mt2; // no warning: type parameter given (wildcard OK!)
}
}
Voici MyType<E>un type paramétré ( JLS 4.5 ). Il est courant de se référer familièrement à ce type simplement MyTypepour faire court, mais techniquement le nom est MyType<E>.
mta un type brut (et génère un avertissement de compilation) par le premier point de la définition ci-dessus; inna également un type brut par le troisième point.
MyType.Nestedn'est pas un type paramétré, même s'il s'agit d'un type membre d'un type paramétré MyType<E>, car il l'est static.
mt1et mt2sont tous deux déclarés avec des paramètres de type réels, donc ce ne sont pas des types bruts.
Quelle est la particularité des types bruts?
Essentiellement, les types bruts se comportent comme ils l'étaient avant l'introduction des génériques. Autrement dit, ce qui suit est entièrement légal au moment de la compilation.
List names = new ArrayList(); // warning: raw type!
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // not a compilation error!
Le code ci-dessus fonctionne très bien, mais supposez que vous disposiez également des éléments suivants:
for (Object o : names) {
String name = (String) o;
System.out.println(name);
} // throws ClassCastException!
// java.lang.Boolean cannot be cast to java.lang.String
Maintenant, nous rencontrons des problèmes au moment de l'exécution, car namescontient quelque chose qui n'est pas un instanceof String.
On peut supposer que si vous voulez namescontenir seulement String, vous pourriez peut - être utiliser encore un type cru et vérifier manuellement chaque add vous, puis jeter manuellement à Stringchaque élément de names. Encore mieux , il ne faut PAS utiliser un type brut et laisser le compilateur faire tout le travail pour vous , en exploitant la puissance des génériques Java.
List<String> names = new ArrayList<String>();
names.add("John");
names.add("Mary");
names.add(Boolean.FALSE); // compilation error!
Bien sûr, si vous NE voulez namespermettre un Boolean, vous pouvez le déclarer comme List<Object> names, et le code ci - dessus compilerez.
Voir également
En quoi un type brut est-il différent de l'utilisation <Object>comme paramètres de type?
Ce qui suit est une citation de Effective Java 2nd Edition, article 23: N'utilisez pas de types bruts dans le nouveau code :
Quelle est la différence entre le type brut Listet le type paramétré List<Object>? En gros, le premier a désactivé la vérification de type générique, tandis que le second a explicitement déclaré au compilateur qu'il était capable de contenir des objets de tout type. Bien que vous puissiez passer un List<String>à un paramètre de type List, vous ne pouvez pas le passer à un paramètre de type List<Object>. Il existe des règles de sous-typage pour les génériques, et il List<String>s'agit d'un sous-type du type brut List, mais pas du type paramétré List<Object>. Par conséquent, vous perdez la sécurité du type si vous utilisez un type brut comme List, mais pas si vous utilisez un type paramétré commeList<Object> .
Pour illustrer ce point, considérons la méthode suivante qui prend a List<Object>et ajoute a new Object().
void appendNewObject(List<Object> list) {
list.add(new Object());
}
Les génériques en Java sont invariants. A List<String>n'est pas un List<Object>, donc ce qui suit générerait un avertissement du compilateur:
List<String> names = new ArrayList<String>();
appendNewObject(names); // compilation error!
Si vous aviez déclaré appendNewObjectprendre un type brut Listcomme paramètre, cela se compilerait et vous perdriez donc la sécurité de type que vous obtenez des génériques.
Voir également
En quoi un type brut est-il différent de l'utilisation <?>comme paramètre de type?
List<Object>, List<String>, Etc sont tous List<?>, donc il peut être tentant de simplement dire qu'ils sont juste à la Listplace. Cependant, il y a une différence majeure: puisque a List<E>définit uniquement add(E), vous ne pouvez pas ajouter n'importe quel objet arbitraire à a List<?>. D'un autre côté, puisque le type brut Listn'a pas de sécurité de type, vous pouvez à addpeu près n'importe quoi pour a List.
Considérez la variante suivante de l'extrait précédent:
static void appendNewObject(List<?> list) {
list.add(new Object()); // compilation error!
}
//...
List<String> names = new ArrayList<String>();
appendNewObject(names); // this part is fine!
Le compilateur a fait un excellent travail pour vous protéger contre la violation potentielle de l'invariance de type du List<?>! Si vous aviez déclaré le paramètre comme type brut List list, le code se compilerait et vous violeriez l'invariant de type List<String> names.
Un type brut est l'effacement de ce type
Retour à JLS 4.8:
Il est possible d'utiliser comme type l'effacement d'un type paramétré ou l'effacement d'un type tableau dont le type d'élément est un type paramétré. Un tel type est appelé type brut .
[...]
Les superclasses (respectivement, superinterfaces) d'un type brut sont les effacements des superclasses (superinterfaces) de n'importe laquelle des paramétrisations du type générique.
Le type d'un constructeur, d'une méthode d'instance ou d'un non- staticchamp d'un type brut Cqui n'est pas hérité de ses superclasses ou superinterfaces est le type brut qui correspond à l'effacement de son type dans la déclaration générique correspondant à C.
En termes plus simples, lorsqu'un type brut est utilisé, les constructeurs, les méthodes d'instance et les non- staticchamps sont également effacés .
Prenons l'exemple suivant:
class MyType<E> {
List<String> getNames() {
return Arrays.asList("John", "Mary");
}
public static void main(String[] args) {
MyType rawType = new MyType();
// unchecked warning!
// required: List<String> found: List
List<String> names = rawType.getNames();
// compilation error!
// incompatible types: Object cannot be converted to String
for (String str : rawType.getNames())
System.out.print(str);
}
}
Lorsque nous utilisons le brut MyType, il getNamesest également effacé, de sorte qu'il renvoie un brut List!
JLS 4.6 continue d'expliquer les éléments suivants:
L'effacement de type mappe également la signature d'un constructeur ou d'une méthode à une signature qui n'a pas de types ou de variables de type paramétrés. L'effacement d'une signature de constructeur ou de méthode sest une signature composée du même nom set des effacements de tous les types de paramètres formels indiqués dans s.
Le type de retour d'une méthode et les paramètres de type d'une méthode générique ou d'un constructeur subissent également un effacement si la signature de la méthode ou du constructeur est effacée.
L'effacement de la signature d'une méthode générique n'a pas de paramètres de type.
Le rapport de bogue suivant contient quelques réflexions de Maurizio Cimadamore, développeur de compilateur, et d'Alex Buckley, l'un des auteurs du JLS, sur les raisons pour lesquelles ce type de comportement devrait se produire: https://bugs.openjdk.java.net/browse / JDK-6400189 . (En bref, cela rend la spécification plus simple.)
Si ce n'est pas sûr, pourquoi est-il autorisé à utiliser un type brut?
Voici une autre citation de JLS 4.8:
L'utilisation de types bruts n'est autorisée qu'à titre de concession à la compatibilité du code hérité. L'utilisation de types bruts dans du code écrit après l'introduction de la généricité dans le langage de programmation Java est fortement déconseillée. Il est possible que les futures versions du langage de programmation Java interdisent l'utilisation de types bruts.
Efficace Java 2nd Edition a également ceci à ajouter:
Étant donné que vous ne devez pas utiliser de types bruts, pourquoi les concepteurs de langage les ont-ils autorisés? Pour assurer la compatibilité.
La plate-forme Java était sur le point d'entrer dans sa deuxième décennie avec l'introduction des génériques, et il existait une énorme quantité de code Java qui n'utilisait pas de génériques. Il a été jugé essentiel que tout ce code reste légal et interopérable avec un nouveau code qui utilise des génériques. Il devait être légal de transmettre des instances de types paramétrés à des méthodes conçues pour être utilisées avec des types ordinaires, et vice versa. Cette exigence, connue sous le nom de compatibilité de migration , a conduit à prendre la décision de prendre en charge les types bruts.
En résumé, les types bruts ne doivent JAMAIS être utilisés dans un nouveau code. Vous devez toujours utiliser des types paramétrés .
N'y a-t-il pas d'exceptions?
Malheureusement, comme les génériques Java ne sont pas réifiés, il existe deux exceptions où les types bruts doivent être utilisés dans le nouveau code:
- Littéraux de classe, par exemple
List.class, nonList<String>.class
instanceofopérande, par exemple o instanceof Set, paso instanceof Set<String>
Voir également