Make `GenericType<T>` not implement `java.lang.reflect.Type`
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
Piste de recherche
Localisez GenericType et examinez ses appelants et ses tests existants, en particulier le comportement qui dépend du fait qu'il s'agit d'un java.lang.reflect.Type. Consultez la discussion dans #73 et les problèmes de compatibilité de l'issue avant de modifier l'API publique. La tâche est terminée lorsque GenericType n'implémente plus Type, tout en conservant un comportement de conteneur de type correct et des tests affectés corrects.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
In the same vein as #73, probably GenericType should not implement java.lang.reflect.Type. It's not really a "type" itself—it's a type holder.
I can appreciated that the original conception was to have GenericType be a "type" representing a "type with generics" (sort of like an improved ParameterizedType). But in the larger scheme of things and in hindsight, it's really just one of many duplicates of the Super Type Token pattern. And to put this in context:
- The original example in Neil Gafter's famous Super Type Tokens does not implement
Type. - Jackson's
TypeReferencedoes not implementType. - Spring's
ParameterizedTypeReferencedoes not implementType. - The Guice
TypeLiteraldoes not implementType. - The GeantyRef fork of gentyref has a
TypeTokenwhich does not implementType. - Guava's
TypeTokendoes not implementType.
Thus ClassMate's GenericType<T> is the only one that implements java.lang.reflect.Type.
The reason I bring this up is that the whole Type system (as you explain so well) is already confusing and awkward; adding one other wrapper that itself pretends to be a Type, in contrast with all the other uses of this pattern, adds even more confusion.
Let me give an illustration of the confusion it can cause. Let's say (following the discussion in #69) that I want to make a general method to convert some "type token" to a Type (so that I can then use Jackson to convert it to a JavaType, etc.). Look closely at this code:
public static Type typeTokenToType(@Nonnull final Object typeToken) {
//super type token (check first, because ClassMate `GenericType<T>` is also a `Type`)
final Type superTypeTokenSuperClass = typeToken.getClass().getGenericSuperclass();
if(superTypeTokenSuperClass instanceof ParameterizedType parameterizedType) {
final Type[] actualTypeArguments = parameterizedType.getActualTypeArguments();
if(actualTypeArguments.length == 1) {
return actualTypeArguments[0];
}
}
//type
if(typeToken instanceof Type) { //types in general, if they are not super type tokens needing "unwrapping", can be returned directly
return (Type)typeToken;
}
throw new IllegalArgumentException("Type token must be an instance of `Class`, or have a super class providing a single generic type argument.");
}
You see the potential bug if the developer weren't paying attention? In a perfect world, I would first test to see if typeToken is a Type, and just return it, because the type token is already a Type (e.g. a Class<?> or a ParameterizedType). Otherwise I would see if it is a "super type token". And that approach would work with all the other super type tokens—except for ClassMate's GenericType<T>, because GenericType<T> claims it is a Type itself already!
The fix for this example is easy (as shown in the method above): just leave the instanceof Type check for last. But it would be more efficient to test for Type up front. More worrisome, I would have had to have noticed before writing the method (I actually didn't at first) that GenericType<T> implements Type, or I would have wound up with such a bug.
Lots of other bugs may crop up. A developer may write a doFoo(Type type) method, assuming the type has already been "unwrapped", and someone could send it a GenericType<T>, forgetting to unwrap/extract the Type first. I could see this happening all over the place.
At the end of the day this isn't a blocker, and it's certainly not a critical bug. And if you don't agree with me, and you see value in having GenericType<T> implement Type, that's fine. Nevertheless I thought I'd document what I see as an issue so that you can think about it. Cheers!
- Langage dominant
- Java
- Étoiles
- 266
- Forks
- 47
- Merge moyen
- 1 h 42 min
- PR mergées (30 j)
- 1
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de FasterXML/java-classmate
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
FasterXML/java-classmate#111 · 10 commentaires ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 20/100
FasterXML/java-classmate#81 · 1 commentaire ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 20/100
FasterXML/java-classmate#72 · 3 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
FasterXML/java-classmate#69 · 22 commentaires ·
-
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
FasterXML/java-classmate#57 · 1 commentaire ·
Toutes les issues de FasterXML/java-classmate
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
HL7/fhir-ig-publisher#1375 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
-
Flaky: a relaunched catch-up replay can still report catching up right after its marker is written Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
johanhaleby/occurrent#1134 ·
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
objectionary/jeo-maven-plugin#1811 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100