Klasse ist ein Rohtyp. Verweise auf generische Typklasse <T> sollte parametrisierte

Question

sein ich die folgende Klasse haben (von einer einfachen Feder-Tutorial)

public class CarValidator implements Validator { 

    public boolean supports(Class aClass) { 
     return Car.class.equals(aClass); 
    } 

    public void validate(Object obj, Errors errors) { 
     Car car = (Car) obj; 

     ValidationUtils.rejectIfEmptyOrWhitespace(errors, "model", "field.required", "Required field"); 

     ValidationUtils.rejectIfEmptyOrWhitespace(errors, "price", "field.required", "Required field"); 

     if(! errors.hasFieldErrors("price")) { 
      if (car.getPrice().intValue() == 0) { 
       errors.rejectValue("price", "not_zero", "Can't be free!"); 
      } 
     } 

    } 
} 

Wenn der Validator-Klasse die org.springframework.validation.Validator Klasse von Spring 2.5 ist.

Die Träger Methode zeigt eine Warnung (Klasse ein Roh-Typ ist. Verweis auf generische Typ Klasse sollte parametrierbar), wenn ich versuche, so zu diesen Parameter hinzufügen, wie

public boolean supports(Class<?> aClass) ... 

Ich erhalte die folgenden Fehler :

The method supports(Class<?>) of type CarValidator has the same erasure as supports(Class) of type Validator but does not override it

es gibt viele Themen über diese Art von Frage, aber ich mag eine vollständige Antwort zu bekommen und zu verstehen, es tatsächlich ohne das Problem mit einem @SupressWarnings ‚versteckt‘!

Answer 1

Die Schnittstelle deklariert die Methode mit einem Rohtyp. In diesem Fall können Sie sie nicht ohne Warnung überschreiben.

Der Ursprung Ihres Problems ist, dass die Spring-Schnittstelle als Java 1.4-kompatibel deklariert wurde. Beachten Sie, dass Spring 3.0 alle Klassen als Java 1.5-konform liefern soll, damit Ihr Problem behoben wird. Vor dem Upgrade, denke ich, müssten Sie entweder mit der Warnung oder der @SuppressWarning leben.

Answer 2

Da die Schnittstelle die Verwendung des unformatierten Typs erzwingt (d. H. Keine Angabe der korrekten Typinformationen ermöglicht), können Sie sie ohne Warnungen nur implementieren, wenn Sie @SupressWarnings verwenden.

Die einzige wirkliche Lösung ist es, die Schnittstelle zu reparieren (d. H. Sie definiert boolean supports(Class<?> aClass)).