Wie gehe ich mit ungeprüften Besetzungswarnungen um?

Eclipse warnt mich vor folgendem Formular:

Typensicherheit: Deaktivierte Umwandlung von Objekt in HashMap

Dies ist von einem Aufruf einer API, über die ich keine Kontrolle habe, welche Objekt zurückgibt:

HashMap<String, String> getItems(javax.servlet.http.HttpSession session) {
  HashMap<String, String> theHash = (HashMap<String, String>)session.getAttribute("attributeKey");
  return theHash;
}

Ich möchte Eclipse-Warnungen nach Möglichkeit vermeiden, da sie theoretisch zumindest auf ein potenzielles Codeproblem hinweisen. Ich habe jedoch noch keinen guten Weg gefunden, diesen zu beseitigen. Ich kann die einzelne betroffene Zeile selbst in eine Methode extrahieren und @SuppressWarnings("unchecked")zu dieser Methode hinzufügen , wodurch die Auswirkungen eines Codeblocks begrenzt werden, in dem ich Warnungen ignoriere. Irgendwelche besseren Optionen? Ich möchte diese Warnungen in Eclipse nicht deaktivieren.

Bevor ich zum Code kam, war es einfacher, aber dennoch provozierte Warnungen:

HashMap getItems(javax.servlet.http.HttpSession session) {
  HashMap theHash = (HashMap)session.getAttribute("attributeKey");
  return theHash;
}

Das Problem war anderswo, als Sie versuchten, den Hash zu verwenden, erhielten Sie Warnungen:

HashMap items = getItems(session);
items.put("this", "that");

Type safety: The method put(Object, Object) belongs to the raw type HashMap.  References to generic type HashMap<K,V> should be parameterized.

Die offensichtliche Antwort ist natürlich nicht, die ungeprüfte Besetzung zu machen.

Wenn dies unbedingt erforderlich ist, versuchen Sie zumindest, den Umfang der @SuppressWarningsAnmerkung einzuschränken. Laut seinen Javadocs kann es auf lokale Variablen gehen; Auf diese Weise wirkt sich dies nicht einmal auf die gesamte Methode aus.

Beispiel:

@SuppressWarnings("unchecked")
Map<String, String> myMap = (Map<String, String>) deserializeMap();

Es gibt keine Möglichkeit zu bestimmen, ob die Mapwirklich die generischen Parameter haben sollten <String, String>. Sie müssen vorher wissen, wie die Parameter lauten sollen (oder Sie werden herausfinden, wann Sie eine erhalten ClassCastException). Aus diesem Grund generiert der Code eine Warnung, da der Compiler möglicherweise nicht wissen kann, ob er sicher ist.

Leider gibt es hier keine guten Möglichkeiten. Denken Sie daran, das Ziel all dessen ist es, die Typensicherheit zu gewährleisten. " Java Generics " bietet eine Lösung für den Umgang mit nicht generisierten Legacy-Bibliotheken, und es gibt eine, die in Abschnitt 8.2 als "Leerschleifentechnik" bezeichnet wird. Machen Sie im Grunde die unsichere Besetzung und unterdrücken Sie die Warnung. Dann durchlaufen Sie die Karte wie folgt:

@SuppressWarnings("unchecked")
Map<String, Number> map = getMap();
for (String s : map.keySet());
for (Number n : map.values());

Wenn ein unerwarteter Typ auftritt, erhalten Sie eine Laufzeit ClassCastException, die jedoch zumindest in der Nähe der Ursache des Problems auftritt.

Beeindruckend; Ich glaube, ich habe die Antwort auf meine eigene Frage herausgefunden. Ich bin mir nur nicht sicher, ob es sich lohnt! :) :)

Das Problem ist, dass die Besetzung nicht überprüft wird. Sie müssen es also selbst überprüfen. Sie können einen parametrisierten Typ nicht einfach mit instanceof überprüfen, da die parametrisierten Typinformationen zur Laufzeit nicht verfügbar sind, da sie zur Kompilierungszeit gelöscht wurden.

Sie können jedoch jedes Element im Hash mit instanceof überprüfen und dabei einen neuen Hash erstellen, der typsicher ist. Und Sie werden keine Warnungen provozieren.

Dank mmyers und Esko Luontola habe ich den Code, den ich ursprünglich hier geschrieben habe, parametrisiert, sodass er irgendwo in eine Utility-Klasse eingepackt und für jede parametrisierte HashMap verwendet werden kann. Wenn Sie es besser verstehen möchten und mit Generika nicht sehr vertraut sind, empfehlen wir Ihnen, den Bearbeitungsverlauf dieser Antwort anzuzeigen.

public static <K, V> HashMap<K, V> castHash(HashMap input,
                                            Class<K> keyClass,
                                            Class<V> valueClass) {
  HashMap<K, V> output = new HashMap<K, V>();
  if (input == null)
      return output;
  for (Object key: input.keySet().toArray()) {
    if ((key == null) || (keyClass.isAssignableFrom(key.getClass()))) {
        Object value = input.get(key);
        if ((value == null) || (valueClass.isAssignableFrom(value.getClass()))) {
            K k = keyClass.cast(key);
            V v = valueClass.cast(value);
            output.put(k, v);
        } else {
            throw new AssertionError(
                "Cannot cast to HashMap<"+ keyClass.getSimpleName()
                +", "+ valueClass.getSimpleName() +">"
                +", value "+ value +" is not a "+ valueClass.getSimpleName()
            );
        }
    } else {
        throw new AssertionError(
            "Cannot cast to HashMap<"+ keyClass.getSimpleName()
            +", "+ valueClass.getSimpleName() +">"
            +", key "+ key +" is not a " + keyClass.getSimpleName()
        );
    }
  }
  return output;
}

Das ist viel Arbeit, möglicherweise für sehr wenig Belohnung ... Ich bin mir nicht sicher, ob ich es verwenden werde oder nicht. Ich würde mich über Kommentare freuen, ob die Leute denken, dass es sich lohnt oder nicht. Ich würde mich auch über Verbesserungsvorschläge freuen: Gibt es etwas Besseres, als AssertionErrors zu werfen? Gibt es etwas Besseres, das ich werfen könnte? Soll ich es zu einer geprüften Ausnahme machen?

Gehen Sie in den Eclipse-Einstellungen zu Java-> Compiler-> Fehler / Warnungen-> Generische Typen und aktivieren Sie das Ignore unavoidable generic type problemsKontrollkästchen.

Dies erfüllt die Absicht der Frage, dh

Ich möchte Eclipse-Warnungen vermeiden ...

wenn nicht der Geist.

Sie können eine Dienstprogrammklasse wie die folgende erstellen und damit die nicht aktivierte Warnung unterdrücken.

public class Objects {

    /**
     * Helps to avoid using {@code @SuppressWarnings({"unchecked"})} when casting to a generic type.
     */
    @SuppressWarnings({"unchecked"})
    public static <T> T uncheckedCast(Object obj) {
        return (T) obj;
    }
}

Sie können es wie folgt verwenden:

import static Objects.uncheckedCast;
...

HashMap<String, String> getItems(javax.servlet.http.HttpSession session) {
      return uncheckedCast(session.getAttribute("attributeKey"));
}

Weitere Diskussionen hierzu finden Sie hier: http://cleveralias.blogs.com/thought_spearmints/2006/01/suppresswarning.html

Dieses Zeug ist schwer, aber hier sind meine aktuellen Gedanken:

Wenn Ihre API Object zurückgibt, können Sie nichts tun - egal was passiert, Sie werden das Objekt blind umwandeln. Sie lassen Java ClassCastExceptions auslösen, oder Sie können jedes Element selbst überprüfen und Assertions oder IllegalArgumentExceptions oder ähnliches auslösen, aber diese Laufzeitprüfungen sind alle gleichwertig. Sie müssen die ungeprüfte Umwandlung der Kompilierungszeit unterdrücken , unabhängig davon, was Sie zur Laufzeit tun.

Ich würde es einfach vorziehen, blind zu besetzen und die JVM ihre Laufzeitprüfung für mich durchführen zu lassen, da wir "wissen", was die API zurückgeben soll, und normalerweise bereit sind anzunehmen, dass die API funktioniert. Verwenden Sie Generika überall über der Besetzung, wenn Sie sie benötigen. Sie kaufen dort eigentlich nichts, da Sie immer noch den Single Blind Cast haben, aber zumindest können Sie von da an Generika verwenden, damit die JVM Ihnen hilft, Blind Casts in anderen Teilen Ihres Codes zu vermeiden.

In diesem speziellen Fall können Sie vermutlich den Aufruf von SetAttribute sehen und sehen, dass der Typ eingeht. Es ist also nicht unmoralisch, den Typ auf dem Weg nach draußen blind zu machen. Fügen Sie einen Kommentar hinzu, der auf das SetAttribute verweist, und fertig.

Hier ist ein verkürztes Beispiel, das die Warnung "ungeprüfte Besetzung" vermeidet, indem zwei in anderen Antworten erwähnte Strategien angewendet werden.

1. Übergeben Sie zur Laufzeit ( Class<T> inputElementClazz) die Klasse des interessierenden Typs als Parameter . Dann können Sie verwenden:inputElementClazz.cast(anyObject);

2. Verwenden Sie für das Typ-Casting einer Sammlung den Platzhalter? anstelle eines generischen Typs T, um zu bestätigen, dass Sie tatsächlich nicht wissen, welche Art von Objekten Sie vom Legacy-Code erwarten sollen ( Collection<?> unknownTypeCollection). Immerhin ist es das, was die Warnung "ungeprüfte Besetzung" uns sagen will: Wir können nicht sicher sein, dass wir eine bekommen Collection<T>, also ist es ehrlich, eine zu verwenden Collection<?>. Bei Bedarf kann weiterhin eine Sammlung eines bekannten Typs erstellt werden ( Collection<T> knownTypeCollection).

Der im folgenden Beispiel angeschlossene Legacy-Code hat im StructuredViewer das Attribut "input" (StructuredViewer ist ein Baum- oder Tabellen-Widget, "input" ist das dahinter stehende Datenmodell). Diese "Eingabe" kann jede Art von Java-Sammlung sein.

public void dragFinished(StructuredViewer structuredViewer, Class<T> inputElementClazz) {
    IStructuredSelection selection = (IStructuredSelection) structuredViewer.getSelection();
    // legacy code returns an Object from getFirstElement,
    // the developer knows/hopes it is of type inputElementClazz, but the compiler cannot know
    T firstElement = inputElementClazz.cast(selection.getFirstElement());

    // legacy code returns an object from getInput, so we deal with it as a Collection<?>
    Collection<?> unknownTypeCollection = (Collection<?>) structuredViewer.getInput();

    // for some operations we do not even need a collection with known types
    unknownTypeCollection.remove(firstElement);

    // nothing prevents us from building a Collection of a known type, should we really need one
    Collection<T> knownTypeCollection = new ArrayList<T>();
    for (Object object : unknownTypeCollection) {
        T aT = inputElementClazz.cast(object);
        knownTypeCollection.add(aT);
        System.out.println(aT.getClass());
    }

    structuredViewer.refresh();
}

Natürlich kann der obige Code Laufzeitfehler verursachen, wenn wir den Legacy-Code mit den falschen Datentypen verwenden (z. B. wenn wir anstelle einer Java-Sammlung ein Array als "Eingabe" des StructuredViewer festlegen).

Beispiel für den Aufruf der Methode:

dragFinishedStrategy.dragFinished(viewer, Product.class);

In der HTTP-Sitzungswelt können Sie die Umwandlung nicht wirklich vermeiden, da die API so geschrieben ist (nur Takes und Returns Object).

Mit ein wenig Arbeit können Sie jedoch die ungeprüfte Besetzung leicht vermeiden. Dies bedeutet, dass es sich in eine traditionelle Besetzung verwandelt, die ClassCastExceptionim Fehlerfall ein Recht gibt. Eine ungeprüfte Ausnahme kann zu einem CCEspäteren Zeitpunkt anstelle des Besetzungspunkts zu einer Ausnahme werden (aus diesem Grund handelt es sich um eine separate Warnung).

Ersetzen Sie die HashMap durch eine dedizierte Klasse:

import java.util.AbstractMap;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

public class Attributes extends AbstractMap<String, String> {
    final Map<String, String> content = new HashMap<String, String>();

    @Override
    public Set<Map.Entry<String, String>> entrySet() {
        return content.entrySet();
    }

    @Override
    public Set<String> keySet() {
        return content.keySet();
    }

    @Override
    public Collection<String> values() {
        return content.values();
    }

    @Override
    public String put(final String key, final String value) {
        return content.put(key, value);
    }
}

Dann in diese Klasse Map<String,String>umwandeln und alles wird genau an der Stelle überprüft, an der Sie Ihren Code schreiben. Kein unerwartetes ClassCastExceptionsspäter.

Wenn Sie in Android Studio die Inspektion deaktivieren möchten, können Sie Folgendes verwenden:

//noinspection unchecked
Map<String, String> myMap = (Map<String, String>) deserializeMap();

In diesem speziellen Fall würde ich Maps nicht direkt in der HttpSession speichern, sondern eine Instanz meiner eigenen Klasse, die wiederum eine Map (ein Implementierungsdetail der Klasse) enthält. Dann können Sie sicher sein, dass die Elemente in der Karte vom richtigen Typ sind.

Wenn Sie jedoch trotzdem überprüfen möchten, ob der Inhalt der Karte vom richtigen Typ ist, können Sie einen Code wie den folgenden verwenden:

public static void main(String[] args) {
    Map<String, Integer> map = new HashMap<String, Integer>();
    map.put("a", 1);
    map.put("b", 2);
    Object obj = map;

    Map<String, Integer> ok = safeCastMap(obj, String.class, Integer.class);
    Map<String, String> error = safeCastMap(obj, String.class, String.class);
}

@SuppressWarnings({"unchecked"})
public static <K, V> Map<K, V> safeCastMap(Object map, Class<K> keyType, Class<V> valueType) {
    checkMap(map);
    checkMapContents(keyType, valueType, (Map<?, ?>) map);
    return (Map<K, V>) map;
}

private static void checkMap(Object map) {
    checkType(Map.class, map);
}

private static <K, V> void checkMapContents(Class<K> keyType, Class<V> valueType, Map<?, ?> map) {
    for (Map.Entry<?, ?> entry : map.entrySet()) {
        checkType(keyType, entry.getKey());
        checkType(valueType, entry.getValue());
    }
}

private static <K> void checkType(Class<K> expectedType, Object obj) {
    if (!expectedType.isInstance(obj)) {
        throw new IllegalArgumentException("Expected " + expectedType + " but was " + obj.getClass() + ": " + obj);
    }
}

Die Dienstprogrammfunktion Objects.Unchecked in der obigen Antwort von Esko Luontola ist eine hervorragende Möglichkeit, Programmunordnung zu vermeiden.

Wenn Sie die SuppressWarnings nicht für eine gesamte Methode verwenden möchten, werden Sie von Java gezwungen, sie auf eine lokale Methode zu setzen. Wenn Sie eine Besetzung für ein Mitglied benötigen, kann dies zu folgendem Code führen:

@SuppressWarnings("unchecked")
Vector<String> watchedSymbolsClone = (Vector<String>) watchedSymbols.clone();
this.watchedSymbols = watchedSymbolsClone;

Die Verwendung des Dienstprogramms ist viel sauberer und es ist immer noch offensichtlich, was Sie tun:

this.watchedSymbols = Objects.uncheckedCast(watchedSymbols.clone());

HINWEIS: Ich halte es für wichtig hinzuzufügen, dass die Warnung manchmal wirklich bedeutet, dass Sie etwas falsch machen, wie:

ArrayList<Integer> intList = new ArrayList<Integer>();
intList.add(1);
Object intListObject = intList; 

 // this line gives an unchecked warning - but no runtime error
ArrayList<String> stringList  = (ArrayList<String>) intListObject;
System.out.println(stringList.get(0)); // cast exception will be given here

Der Compiler teilt Ihnen mit, dass diese Umwandlung zur Laufzeit NICHT überprüft wird, sodass kein Laufzeitfehler ausgelöst wird, bis Sie versuchen, auf die Daten im generischen Container zuzugreifen.

Die Unterdrückung von Warnungen ist keine Lösung. Sie sollten kein zweistufiges Casting in einer Anweisung durchführen.

HashMap<String, String> getItems(javax.servlet.http.HttpSession session) {

    // first, cast the returned Object to generic HashMap<?,?>
    HashMap<?, ?> theHash = (HashMap<?, ?>)session.getAttribute("attributeKey");

    // next, cast every entry of the HashMap to the required type <String, String>
    HashMap<String, String> returingHash = new HashMap<>();
    for (Entry<?, ?> entry : theHash.entrySet()) {
        returingHash.put((String) entry.getKey(), (String) entry.getValue());
    }
    return returingHash;
}

Eine schnelle Vermutung, ob Sie Ihren Code veröffentlichen, kann sicher sagen, aber Sie haben möglicherweise etwas in der Art von getan

HashMap<String, Object> test = new HashMap();

Dies wird die Warnung erzeugen, wenn Sie dies tun müssen

HashMap<String, Object> test = new HashMap<String, Object>();

es könnte einen Blick wert sein

Generika in der Programmiersprache Java

wenn Sie nicht wissen, was zu tun ist.

Ich habe die Frage vielleicht falsch verstanden (ein Beispiel und ein paar umgebende Zeilen wären nett), aber warum verwenden Sie nicht immer eine geeignete Schnittstelle (und Java5 +)? Ich sehe keinen Grund, warum Sie jemals zu einem HashMapstatt zu einem werfen möchten Map<KeyType,ValueType>. Tatsächlich kann ich mir keinen Grund vorstellen , den Typ einer Variablen auf HashMapanstatt zu setzen Map.

Und warum ist die Quelle eine Object? Ist es ein Parametertyp einer Legacy-Sammlung? Verwenden Sie in diesem Fall Generika und geben Sie den gewünschten Typ an.

Wenn ich eine API verwenden muss, die Generics nicht unterstützt. Ich versuche, diese Aufrufe in Wrapper-Routinen mit so wenig Zeilen wie möglich zu isolieren. Ich verwende dann die SuppressWarnings-Annotation und füge gleichzeitig die Typensicherheitsabdrücke hinzu.

Dies ist nur eine persönliche Präferenz, um die Dinge so ordentlich wie möglich zu halten.

Nehmen wir diese, es ist viel schneller als das Erstellen einer neuen HashMap, wenn es bereits eine ist, aber immer noch sicher, da jedes Element gegen seinen Typ geprüft wird ...

@SuppressWarnings("unchecked")
public static <K, V> HashMap<K, V> toHashMap(Object input, Class<K> key, Class<V> value) {
       assert input instanceof Map : input;

       for (Map.Entry<?, ?> e : ((HashMap<?, ?>) input).entrySet()) {
           assert key.isAssignableFrom(e.getKey().getClass()) : "Map contains invalid keys";
           assert value.isAssignableFrom(e.getValue().getClass()) : "Map contains invalid values";
       }

       if (input instanceof HashMap)
           return (HashMap<K, V>) input;
       return new HashMap<K, V>((Map<K, V>) input);
    }

Überprüfen Sie es einfach, bevor Sie es wirken.

Object someObject = session.getAttribute("attributeKey");
if(someObject instanceof HashMap)
HashMap<String, String> theHash = (HashMap<String, String>)someObject;  

Und für alle, die fragen, ist es durchaus üblich, Objekte zu erhalten, bei denen Sie sich nicht sicher sind, welchen Typ sie haben. Viele ältere "SOA" -Implementierungen geben verschiedene Objekte weiter, denen Sie nicht immer vertrauen sollten. (Die Schrecken!)

BEARBEITEN Der Beispielcode wurde einmal geändert, um ihn an die Aktualisierungen des Posters anzupassen. Nach einigen Kommentaren sehe ich, dass die Instanz von nicht gut mit Generika funktioniert. Das Ändern der Prüfung zur Validierung des äußeren Objekts scheint jedoch mit dem Befehlszeilen-Compiler gut zu funktionieren. Überarbeitetes Beispiel jetzt veröffentlicht.

Fast jedes Problem in der Informatik kann durch Hinzufügen einer Indirektionsebene * oder so etwas gelöst werden.

Führen Sie also ein nicht generisches Objekt ein, das eine höhere Ebene aufweist als a Map. Ohne Kontext wird es nicht sehr überzeugend aussehen, aber trotzdem:

public final class Items implements java.io.Serializable {
    private static final long serialVersionUID = 1L;
    private Map<String,String> map;
    public Items(Map<String,String> map) {
        this.map = New.immutableMap(map);
    }
    public Map<String,String> getMap() {
        return map;
    }
    @Override public String toString() {
        return map.toString();
    }
}

public final class New {
    public static <K,V> Map<K,V> immutableMap(
        Map<? extends K, ? extends V> original
    ) {
        // ... optimise as you wish...
        return Collections.unmodifiableMap(
            new HashMap<String,String>(original)
        );
    }
}

static Map<String, String> getItems(HttpSession session) {
    Items items = (Items)
        session.getAttribute("attributeKey");
    return items.getMap();
}

* Außer zu vielen Indirektionsebenen.

Hier ist eine Möglichkeit, wie ich damit umgehen kann, wenn ich den equals()Vorgang überschreibe .

public abstract class Section<T extends Section> extends Element<Section<T>> {
    Object attr1;

    /**
    * Compare one section object to another.
    *
    * @param obj the object being compared with this section object
    * @return true if this section and the other section are of the same
    * sub-class of section and their component fields are the same, false
    * otherwise
    */       
    @Override
    public boolean equals(Object obj) {
        if (obj == null) {
            // this exists, but obj doesn't, so they can't be equal!
            return false;
        }

        // prepare to cast...
        Section<?> other;

        if (getClass() != obj.getClass()) {
            // looks like we're comparing apples to oranges
            return false;
        } else {
            // it must be safe to make that cast!
            other = (Section<?>) obj;
        }

        // and then I compare attributes between this and other
        return this.attr1.equals(other.attr1);
    }
}

Dies scheint in Java 8 zu funktionieren (sogar kompiliert mit -Xlint:unchecked)

Wenn Sie sicher sind, dass der von session.getAttribute () zurückgegebene Typ HashMap ist, können Sie nicht genau auf diesen Typ typisieren, sondern nur die generische HashMap überprüfen

HashMap<?,?> getItems(javax.servlet.http.HttpSession session) {  
    HashMap<?,?> theHash = (HashMap<?,?>)session.getAttribute("attributeKey");
    return theHash;
} 

Eclipse wird dann Warnungen überraschen, aber dies kann natürlich zu Laufzeitfehlern führen, die schwer zu debuggen sind. Ich verwende diesen Ansatz nicht nur in betriebskritischen Kontexten.

Zwei Möglichkeiten, eine, die das Tag vollständig vermeidet, die andere mit einer frechen, aber netten Utility-Methode.
Das Problem sind vorgenerisierte Sammlungen ...
Ich glaube, die Faustregel lautet: "Objekte einzeln umwandeln " - was dies bedeutet, wenn Sie versuchen, Rohklassen in einer generisierten Welt zu verwenden, ist, dass Sie nicht wissen, was Befindet sich in dieser Karte <?,?> (und tatsächlich stellt die JVM möglicherweise sogar fest, dass es sich nicht einmal um eine Karte handelt!), ist es offensichtlich, wenn Sie darüber nachdenken, dass Sie sie nicht wirken können. Wenn Sie eine Map <String,?> Map2 hatten, gibt HashSet <String> keys = (HashSet <String>) map2.keySet () keine Warnung aus, obwohl dies ein "Glaubensakt" für den Compiler ist (weil es könnte sich als TreeSet herausstellen) ... aber es ist nur ein einziges Akt des Glaubens.

PS zu dem Einwand, dass das Iterieren wie auf meine erste Weise "langweilig" ist und "Zeit braucht", lautet die Antwort "kein Schmerz, kein Gewinn": Eine generierte Sammlung enthält garantiert Map.Entry <String, String> s und nichts sonst. Sie müssen für diese Garantie bezahlen. Bei der systematischen Verwendung von Generika erfolgt diese Zahlung in Form der Codierungskonformität und nicht in Form von Maschinenzeit!
Eine Denkrichtung könnte sagen, dass Sie die Einstellungen von Eclipse so einstellen sollten, dass solche ungeprüften Casts-Fehler statt Warnungen auftreten. In diesem Fall müssten Sie meinen ersten Weg benutzen.

package scratchpad;

import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Vector;

public class YellowMouse {

    // First way

    Map<String, String> getHashMapStudiouslyAvoidingSuppressTag(HttpSession session) {
      Map<?, ?> theHash = (Map<?, ?>)session.getAttribute("attributeKey");

      Map<String, String> yellowMouse = new HashMap<String, String>();
      for( Map.Entry<?, ?> entry : theHash.entrySet() ){
        yellowMouse.put( (String)entry.getKey(), (String)entry.getValue() );
      }

      return yellowMouse;
    }


    // Second way

    Map<String, String> getHashMapUsingNaughtyButNiceUtilityMethod(HttpSession session) {
      return uncheckedCast( session.getAttribute("attributeKey") );
    }


    // NB this is a utility method which should be kept in your utility library. If you do that it will
    // be the *only* time in your entire life that you will have to use this particular tag!!

    @SuppressWarnings({ "unchecked" })
    public static synchronized <T> T uncheckedCast(Object obj) {
        return (T) obj;
    }


}

Dadurch verschwinden die Warnungen ...

 static Map<String, String> getItems(HttpSession session) {
        HashMap<?, ?> theHash1 = (HashMap<String,String>)session.getAttribute("attributeKey");
        HashMap<String,String> theHash = (HashMap<String,String>)theHash1;
    return theHash;
}

Lösung: Deaktivieren Sie diese Warnung in Eclipse. Nicht @SuppressWarnings, sondern nur vollständig deaktivieren.

Einige der oben vorgestellten "Lösungen" sind weit von der Linie entfernt und machen Code unlesbar, um eine dumme Warnung zu unterdrücken.