java: Verwendung von clone() und was über die cast-check

Diesem code:

class RawStringIterator {
        java.util.Stack<State> stateStack = new java.util.Stack<State>();
        RawStringIterator(RawStringIterator i) {
              stateStack = (java.util.Stack<State>) i.stateStack.clone();
        }
        /* ... */
}

gibt mir diese Warnung:

Type safety: Unchecked cast from Object to Stack<Utils.OperatorTree.RawStringIterator.State>

Ich denke, ich kann die Warnung ignorieren hier. Aber ich Frage mich, über wie zu verwenden clone() im Allgemeinen? Muss ich immer einen @SuppressWarnings("unchecked") jedes mal, wenn ich clone()? Oder sollte ich immer das tun, völlig überflüssig extra prüfen?

InformationsquelleAutor Albert | 2010-10-15
  1. 12

    Wenn Sie die Wahl haben, das beste ist, nicht zu implementieren /benutzen clone() überhaupt, weil es ist eine kaputte API. Nur umsetzen /verwenden einen copy-Konstruktor statt.

    Wenn aus irgendeinem Grund müssen Sie clone() aber ändern kann ist seine Umsetzung, sollten Deklaration Stack<T>.clone() zurück Stack<T> statt Object - kovariante Rückgabetypen sind legal, da Java5.

    Update: wenn die Stack in Frage java.util.Stack betrachten seine Javadoc:

    Einer mehr vollständigen und konsistenten Satz von LIFO-stack-Operationen wird durch die Deque - Schnittstelle und Ihrer Implementierungen, die verwendet werden sollten, in den Vorzug dieser Klasse.

    Werden und z.B. ArrayDeque bietet eine copy-Konstruktor.

    • Stack<T> ist java.util.Stack<T> hier. Ich kann also nicht wirklich ändern, eine Erklärung gibt.
    • Sie können weiterhin in der Lage, wechseln Sie zu einer anderen Sammlung, obwohl - siehe mein update.
    • Würde die downvoter Pflege fügen Sie eine Erklärung?
    InformationsquelleAutor Péter Török
  2. 2

    Gibt es keine Möglichkeit zu vermeiden, die hier gewirkt. clone() zurück Object, wenn es java.util.Stack ist es nicht mit der co-Variante Rückgabetypen.

    Ist dies nicht java.util.Stack, dann nicht implementieren clone() - es ist wirklich schwer, es richtig zu machen. Machen Sie einen copy-Konstruktor statt.

    • Sie können (und sind empfehlenswert) verwenden kovariante Rückgabetypen mit Ihrem clone() - Effective Java 2nd Ed. Item 11 zeigt explizite Beispiele.
    • ja, aber java.util.Stapel nicht. Das war mein Punkt. Ich werde klären
    • Nein, java.util.Stack keinen Kopie-Konstruktor. Sonst hätte ich es verwendet.
    • sorry, war unter einem falschen Eindruck. entfernt, Teil.
    InformationsquelleAutor Bozho
  3. 0

    Haben Sie sehr wenig Auswahl, aber es zu ignorieren.

    Ist zwar nicht direkt relevant ist (weil Sie nicht das schreiben eines clone() - Methode), wird dieser Eintrag in der Java Generics FAQ macht gut Lesen (wie funktioniert das ganze FAQ!)

    InformationsquelleAutor dty
  4. 0

    Ja, müssen Sie explizit die Warnungen unterdrücken, jedes mal, wenn Sie clone().

    Dies ist einer der Gründe, die Sie vielleicht lieber mit copy-Konstruktoren statt clone(), wenn verfügbar.

    Durch die Art und Weise in Ihrem code, wenn die RawStringIterator(RawStringIterator i) - Konstruktor verwendet wird, der ersten Initialisierung des stateStack ist unnötig:

    class RawStringIterator {
    Stack<State> stateStack = new Stack<State>();
    RawStringIterator(RawStringIterator i) {
          stateStack = (Stack<State>) i.stateStack.clone();
    }
    /* ... */
}

    Möchten Sie vielleicht zu entfernen.

    InformationsquelleAutor Grodriguez
Schreibe einen Kommentar