@SuppressWarnings("unchecked") Frage

Java-Forum Allgemeine Themen
1

Mein Projekt, an dem ich gerad arbeite besitzt u.a. folgende Interfaces / Klassen

...
public interface IGenericDAO<T extends Object, ID extends Serializable> {
          ...
           public T load(Class<T> theClass, ID id);
          ...
}

...
public class GenericHibernateDAO<T extends Object, ID extends Serializable> implements IGenericDAO<T, ID> {
          ...
         @SuppressWarnings("unchecked")
	 public T load(Class<T> theClass, ID id) {
    	      return (T)sessionFactory.getCurrentSession().load(theClass, id);
         }
          ...
}

...
public class UserModel {
        IGenericDAO dao;

        ...
       @SuppressWarnings("unchecked")
	public User getUserById(int id) {
    	          return (User)getDAO().load(User.class, id);
        }
}

Was mich persönlich hieran stört ist das ich für die Unterdrückung der Fehlermeldung sooft “@SuppressWarnings(“unchecked”)” verwenden muss. Wie könnte ich das umgehen? Bzw. wie würdet ihr es ggf. anders realisieren?

2

Moin,

bei Eclipse kannst Du es doch in den Benutzervorgaben ausschalten !

Gruß
Klaus

3

Steig von nativem Hibernate auf JPA um (kann unter der Haube gerne Hibernate bleiben). Das bietet getypte Queries und erspart Dir das eigene Casten. Damit sind dann auch die Annotationen in Deinem Code überflüssig.

P.S. Außerdem passen die von Dir geposteten Codeabschnitte nicht zusammen. Ich meine speziell das Feld dao in der Klasse UserModel. Da hätte ich ein generisches IGenericDao<User,Integer> als Typ erwartet.

4

grundsätzlich haben die suppress-annos nur was mit der compile-time zu tun, steuern also den compiler … und das auch nur dahingehend das prüfungen die normalerweise zu warnings führen, also einem HINWEIS das der code möglicherweise nicht ganz so durchdacht und sauber gesaltet ist, unterdrückt werden

kann man grundsätzlich machen wenn man ganz genau weis was man da macht und auch genau weis das man eben bewusst diese eine meldung unterdrücken will, man sollte aber in der regel vom suppressing absehen und versuchen die angemerkten problemstellen sauber zu lösen

gerade was generics und casting angeht ist das aber nicht immer ganz einfach, mal von type-erasure ganz zu schweigen

was deine IDE hier macht ist eigentlich nichts weiter außer automatisch eine regel hinzufügen die den compiler zum schweigen bringt … da dieser sonst an diesen stellen eine meldung geben würde das der cast unsicher ist

dem ganzen könnte man mit einem (im fall von generics meist überflüssigen, aber laut rule-set dennoch korrektem) if(instanceof) bei kommen und so halt sicherstellen das der cast auch erfolgreich laufen würde
oder man gibt halt seinen methoden direkt parameter- und return-types gegen interfaces und castet dann einfach aufs interface (ich bin einfach ein fan von interface-programmierung, finde daher persönlich dies die schönste variante, auch wenn es durch aus “sinnvollere” geben wird)

5

an Stellen wie der load-Methode hier erfolgt im Fehlerfall eh eine ClassCastException,
da bringt es nicht viel das vorher selber mit einem if abzufragen und dann genauso Exception zu werfen,
andere Möglichkeit hat man an der Stelle kaum

ein bisschen wie if( == null) zu testen vor manchem Zugriff, da hat man teils auch nur die Möglichkeit, ‚da ist was null‘ in eigener Exception zu formulieren,

wenn man noch Parameter dazu ausgeben kann ganz gut („nix zu Id = 45498 gefunden“), ansonsten NullPointerException auch voll akzeptabel, kein Teufelszeug

das gepostete Beispiel ist eher ein Gegenbeispiel, unchecked sollte nicht „sooft“ zu unterdrücken sein,
sondern nur an klar gewählten zentralen Punkten wie in der GenericHibernateDAO-Klasse,
falls dort in 5 oder 25 verschiedenen Methoden, dann auch nicht dramatisch, notfalls von Methoden auf Klasse wechseln, dann nur 1x hinzuschreiben

andere Klassen wie UserModel sollten kein unchecked benötigen!
IGenericDao<User,Integer> wurde ja schon angesprochen, vielleicht noch nicht deutlich genug, so dass ich nochmal was schreibe

ich bin in einem recht ähnlichen Programm, habe vielleicht paar Dutzend unchecked in so zentralen Klassen
und noch paar Hundert an sonstigen unschönen unwichtigen Alt-Code (benötigt, aber kaum gelesen/ in Bearbeitung),

aber mir würde im Traum nicht einfallen die Warnung allgemein zu deaktivieren, die ist eine recht wichtige und nützliche,
jede suppress-Verwendung nur begründet, GenericHibernateDAO ist ein guter Grund