Redundante Klassen in der Standardbibliothek
-
Hi!
Ist euch das schon aufgefallen: Es gibt Klassen in der Standardbibliothek, die mehrfach in verschiedenen Packages vorkommen. ...oder zumindest ähnliche Klassen/Interfaces in verschiedenen Packages. Zum Beispiel:
- java.io.FileFilter - javax.swing.filechooser.FileFilter
- java.util.Timer - javax.swing.Timer
1. Gibt es dafür einen Grund?
2. Wie entscheidet man, welche Klasse man wofür nimmt?
3. Gibt es weitere Beispiele in der Art?
-
Ich denke diese beiden Interfaces/Klassen sind aus Kompatibilitätsgründen noch dort. Für mich haben diese beiden Klassen eindeutigen Bezug zu GUI-Belangen. Deswegen hat man sie ja wohl auch in das Swing-Package gelegt. Da aber bereits mit dem AWT viele Anwendungen erzeugt wurden, werden die Leute bei Sun sie noch drinnen gelassen haben. Was mich aber mehr stört ist die Tatsache, dass man keinen Hinweis auf die neuen Standorte gesetzt hat. Möglicherweise werden diese dann in irgendeinem JDK nicht mehr aufzufinden sein und dann ist das Geschrei groß ... na ja - shit happens!
-
das Problem hatte ich mal mit Date
java.util.Date
java.sql.DateDas Problem ist das Date aus util richtig unbrauchbar ist aber selbst Swing Komponenten (der Dreher mit Datum) arbeiten mit dem util.Date
-
java.sql.Date ist doch von java.util.Date abgeleitet .. oder nicht? Also ist das eher nicht das was Gregor beschrieben hat
-
Ach, ich bin da großzügig.
java.sql.Date bietet so wenig neues im Vergleich zu java.util.Date, dass ich mich Frage, wofür man diese Klasse braucht. Es hätte doch gereicht, wenn man java.util.Date mit den entsprechenden Methoden ergänzt hätte!Edit: Warum gibt es in java.sql.Date ne neue Methode "setTime"? Die gibt es doch auch schon in java.util.Date!
[ Dieser Beitrag wurde am 22.04.2003 um 14:42 Uhr von Gregor editiert. ]
-
Anhand des Formats wird erkannt dass es ein SQL_DATE ist. Da Fehlen wohl Informationen zu den Millisekunden oder sind sogar extra gekennzeichnet.