Keine clone-Methode für BigDecimal und BigInteger?

[0xdeadbeef]

Ich bin etwas irritiert, daß es in den Klassen BigDecimal und BigInteger keine Implementierung der clone-Methode gibt. Zwar wird "clone" ja von Object geerbt, ist aber protected, also steht die Methode nicht zur Verfügung, wenn sie nicht überladen wird.

Das ist IMHO eine ziemlich Einschränkung der o.g. Klassen, weil man somit nicht in üblicher Java-Manier Kopien von BigXXX-Objekten anlegen kann.

Zum Kopieren muß man nun ziemlich unschöne Umwege gehen:

    private BigDecimal target;
    target = new BigDecimal(0);
    target.add(source);

Anscheinend ist das auch in der v1.5 so geblieben, obwohl beide BigXXX-Klassen erweitert wurden.

Stelle ich mich da irgendwie blöd an oder gibt es wenigsten irgendeinen Grund für diesen Verstoß gegen typisches Java-Klassen-Design?

 

[meez]

Du kannst ja eine Subklasse erstellen, und die Methode selber implementieren..

 

[0xdeadbeef]

Das könnte ich natürlich, aber das war ja nicht die Frage,

 

[Guest]

Ja die Typen von SUN sind schon komische Kreaturen. :wink:
Auf folgendes bin ich neulich gestossen als mir ein TableModel
"mutiert" und um die Ohren geflogen ist. (Beachte den Kommentar)

private void justifyRows(int from, int to) { 
	// Sometimes the DefaultTableModel is subclassed 
	// instead of the AbstractTableModel by mistake. 
	// Set the number of rows for the case when getRowCount 
	// is overridden. 
	dataVector.setSize(getRowCount()); 

        for (int i = from; i < to; i++) { 
	    if (dataVector.elementAt(i) == null) { 
		dataVector.setElementAt(new Vector(), i); 
	    }
	    ((Vector)dataVector.elementAt(i)).setSize(getColumnCount());
	}
    }

Wenn's ein "mistake" ist DefaultTableModel zu überschreiben, dann
warum ist die Klasse (oder zumindest die kritischen Methoden darin) nicht final? :roll:

Alle paar Wochen stößt man auf eine solche "Perle" im Swing-Code und
will Amock laufen.