wie clont sich eine TreeMap?

[paul3]

Hallo!

Ich wollte mal wissen, wie sich denn eine TreeMap selber klont. Deshalb hab ich mir die source dateien von sun angeschaut.

public class TreeMap<K,V>
    extends AbstractMap<K,V>
    implements NavigableMap<K,V>, Cloneable, java.io.Serializable

und hier die clone() Methode:

 public Object clone() {
        TreeMap<K,V> clone = null;
        try {
            clone = (TreeMap<K,V>) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new InternalError();
        }

        // Put clone into "virgin" state (except for comparator)
        clone.root = null;
        clone.size = 0;
        clone.modCount = 0;
        clone.entrySet = null;
        clone.navigableKeySet = null;
        clone.descendingMap = null;

        // Initialize clone with our mappings
        try {
            clone.buildFromSorted(size, entrySet().iterator(), null, null);
        } catch (java.io.IOException cannotHappen) {
        } catch (ClassNotFoundException cannotHappen) {
        }

Wie wir sehen, greift die clone() Methode aus TreeMap mit

super.clone()

auf die clone() methode der Obeklasse zurück, und präpariert dann die geklonte Map noch vorm returnen. Ich muss mir also die Oberklasse anschaun, um zu verstehen, wie sich die TreeMap clont - also die AbstractMap ??

public abstract class AbstractMap<K,V> implements Map<K,V> {

und hier die clone() Methode:

 protected Object clone() throws CloneNotSupportedException {
        AbstractMap<K,V> result = (AbstractMap<K,V>)super.clone();
        result.keySet = null;
        result.values = null;
        return result;
    }

Greift die TreeMap mit super.clone() also auf diese Methode zurück? Wenn ja, worauf greift dann in AbstractMap super.clone() zurück? AbstractMap extended ja keine Klasse sondern implementiert nur eine Interface...

 

[Bit2_Gosu]

Ich bin mir nicht sicher, aber vielleicht verweist super() aus der TreeMap ja auf die Klasse Objekt und nicht auf AbstractMap.

 

[paul3]

Wieso die Oberklasse von TreeMap ist doch AbstractMap oder nicht??

Ich verstehe wirklich nicht ganz, an welcher Stelle, denn jetzt eine Funktion steht, die auch wirklich klont und nicht nur mit super() auf eine überliegende clone() Funktion verweist.

 

[Guest]

Die clone() Methode ist in Object native implementiert. In überschreibenden Klassen muss man "nur" mutable und nicht primitive
Attribute klonen. Desweiteren muss die Klasse das Interface Cloneable implementieren. Es ist ähnlich wie Serializable
ein reines Marker-Interface. All dies ist in der Beschreibung von Object#clone() und in der API Doku von Clonable beschrieben.

 

[Shadeo]

public abstract class AbstractMap<K,V>
extends Object
implements Map<K,V>

Object hat ne Methode clone()

 

[musiKk]

Die ist aber nicht implementiert und wirft beim Aufruf eine Exception. Um die API Dokumentation zu zitieren:

The class Object does not itself implement the interface Cloneable, so calling the clone method on an object whose class is Object will result in throwing an exception at run time.

Hab auch eben mal was aehnliches nachgebaut und steh ebenfalls auf dem Schlauch.

 

[paul3]

Das hatte ich mir auch überlegt, dass alle Klassen letztendlich eine Unterklasse der "Object" Klasse sind. Dann verweist das super() in der clone() Funktion aus AbstractMap also auf die clone() Funktion der Klasse "Object".

Nur blöderweise, sieht die clone() Funktion in "Object" so aus:

protected native Object clone() throws CloneNotSupportedException;

Dieser Funktionskopf ist ja wohl nicht in der Lage irgendwas zu klonen oder doch?

 

[Shadeo]

Die Methode ist native, die wird vermutlich in C programmiert sein

Fremdfunktionen werden innerhalb des Java-Codes wie normale Methoden deklariert. Der einzige Unterschied ist das zusätzliche Schlüsselwort native. Parameter und Rückgabewert werden ebenfalls als Java-Datentypen bzw. Objekte angegeben. Der C-Code, der die Funktion implementiert, wird übersetzt und zu einer shared library gebunden. Diese Bibliothek wird beim Instantiieren der Klasse über einen static initializer automatisch geladen. Hierdurch wird die Implementierung der Fremdfunktion auf die Deklaration der native method abgebildet

 

[paul3]

Ah ok, das erklärt einiges :wink:

Gibt es einen Sinn dafür, irgendwann native Funktionen einzusetzen ? Wäre es nicht viel schöner in immer kleineren Teilen nach unten zu gehen und dort mit assembler zu arbeiten ?