Klasa to typ surowy. Odniesienia do typu klasy generycznej <T> powinny być parametryzowana

Question

I mają następujące klasy (od prostego wiosennego poradniku)

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!"); 
      } 
     } 

    } 
} 

gdzie klasa Weryfikacji jest klasa org.springframework.validation.Validator od wiosny 2.5.

Sposób podpory wyświetla ostrzeżenie (Klasa jest typem surowe. Odniesienia do typu rodzajowego klasy powinny być parametryzowane), gdy próbuję dodać parametry do tego takie jak

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

otrzymuję następujący błąd :

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

Istnieje wiele wątków na temat tego typu pytanie, ale chcę, aby uzyskać pełną odpowiedź i rzeczywiście zrozumieć go bez „ukrywanie” problem z @SupressWarnings!

Answer 1

Interfejs deklaruje metodę z typem nieprzetworzonym. W takim przypadku nie można go przesłonić ładnie bez ostrzeżenia.

Źródłem problemu jest fakt, że interfejs Spring został zadeklarowany jako zgodny z językiem Java 1.4. Należy zauważyć, że Spring 3.0 ma dostarczać wszystkie klasy zgodne z Javą 1.5, aby rozwiązać problem. Przed uaktualnieniem, domyślam się, że musiałbyś żyć z ostrzeżeniem lub @SuppressWarning.

Answer 2

Ponieważ interfejs zmusza użytkownika do używania typu surowego (tzn. Nie pozwala określić poprawnych informacji o typie), nie można go wdrożyć bez ostrzeżeń, chyba że użyto @SupressWarnings.

Jedyną prawdziwą poprawką jest naprawienie interfejsu (tzn. Zdefiniowanie go jako boolean supports(Class<?> aClass)).