die Warnung kommt, da du entweder das Interface Serializable oder Externalizable implementierst..

grob gesprochen: mit den serialVersionUID kannst du unterscheiden (bzw. will dich Eclipse darauf aufmerksam machen), dass du eine Versionsnummer verwenden sollst:
wenn du ein abgespeichertes Objekt wieder neu einliest, kannst du dann abfragen, in welcher Version du es damals abgespeichert hast und gegebenfalls zB Variablen mit default-Werten versehen, die damals nicht abgespeichert wurden..

ich würd auf jeden Fall Externalizable verwenden, da du dann genau das (mit der Methode writeExternal) rauschreiben kannst, was du wirklich rausschreiben willst (sprich Speichern).. Serializable schreibt -afaik- die komplette Klassenstruktur mit und sobald du dann zB eine Methode oder Variable umbenennst, wirds schwierig alte Daten wieder zu verwenden..

Edit: soweit ich mich erinnern kann, kommt das Warning erst ab 1.5.,.. die alten Programme würd ich nicht einzeln ändern wenns viele sind - ist ja nur ein Warning und kein Fehler.. was noch ab 1.5. passieren kann ist, dass dir die Generics aufgedrängt werden.. musst aber auch nicht verwenden - kannst du aber.. vorteil: schön, effektiv, kurz - nachteil: nicht mehr möglich mit älteren compilern zu compilieren, schaut ein bissi gewöhnungsbedürftig aus am anfang..

lg, asterix

einmal ein paar Links:
http://www.galileocomputing.de/openbook/java2/kap_12.htm#t22
http://www.galileocomputing.de/openbook/…e54003f5aa2b7c6
http://www.zdnet.de/builder/print_this.h…54667-20000201c
und von den Chefs..
http://java.sun.com/javase/6/docs/api/ja…rializable.html
http://java.sun.com/javase/6/docs/api/ja…rnalizable.html
----
http://gd.tuwien.ac.at/languages/java/Go….html#ixa102890
also da müssten ein paar Beispiele drinnen sein.. zB beim letzten Link die "Famile abspeichern und wieder neu einlesen"..


ich geb dir aber gern ein konkretes - falls die Links zu umfassend sind..

Zitat

kann man etwa Objekte in java auf die Platte speichern und sein Programm beenden und beim nächsten Programmstart ihn auffordern dieses abgespeicherte Objekt wieder weiter zu verwenden?

Na klar. Die Grundidee is primitiv: Man will als Anwender was abspeichern und beim nächstenmal klarerweise wieder laden können. ZB.: Du hast in einer Textverarbeitung einen Text geschrieben --> Man will ihn ja doch abspeichern und beim nächsten Mal wiederhaben..
Angenommen du willst in einem Programm was abspeichern (ein schlechtes Beispiel wären Grafiken [da kommst mit XML oder Textdateien nicht weit - allerdings ist es bei denen ein bissi trickreicher, da bei Grafics kein Interface Serializable implementiert werden kann.. ]).. oder überhaupt eigene Objekte für die XML oder reine Textdateien nicht reichen) dann implementierst du in deiner Klasse einfach Serializable bzw. Externalizable. Bei Externalizable gibts zwei zwingend vorgeschriebene Methoden: writeExternal und readExternal.. auf deutsch in der einen wird definiert, was rausgeschrieben werden soll, in der anderen, wie denn das abgespeicherte Objekt eingelesen werden soll..
In Wirklichlichkeit steht da fast das gleiche drinnen nur einmal mit write und einmal mit read.
Ahja und das Speichern und Einlesen dann konkret: Aufgerufen wird das Abspeichern über ObjectOutputStream= new blahbla.. und genauso das Einlesen.. mit ObjectInputStream.. halt inklusive der ganzen Wrapper
dann passiert wenn du zB
kind1 = (Person)is.readObject();
(also gecastet zuerst), wenn es Externalizable gibt, genau das was in readExternal in der Klasse Person steht.. also auf deutsch, wird da drinnenstehen, dass die Variablen wieder gesetzt werden.. (im Beispiel wirds mit Serialziable gemacht, da das automatisch alles wiederherstellt.. )
.. und wennst zB an aufwendigere Objekte wie zB einen JButton denkst, da gibst dann 1000de Variablen die, wenn Serializable verwendet wird, sinnlos mitgespeichert werden, bei Externalizable kannst -einfach ausgedrückt- schön und genau festlegen, was denn genau gespeichert werden soll..

Zitat

hab immer gedacht wenn man sein programm abbricht räumt die garbage collection alles weg

Das stimmt ja auch. Außer wenn du eben absichtlich was in eine Datei, Datenbank,.. abgespeichert hast. Garbage is ja eigentlich das, was wirlich weggeworfen werden soll (zB. alte Threads, oder die Objekte, die im Konstruktor sowieso immer neu erzeugt werden). Afaik ist das Serializable dafür verantwortlich, dass das gesamte Objekt richtig abgespeichert wird - also es speichert nicht inkonsistent (zB wenn irgenwelche Threads noch am Objekt rummurksen) (also wenn zB einer eine Datei/Objekt grad bearbeitet und ein anderer will die/das gleiche zur selben Zeit speichern, dann passiert ja, wenn da nicht wer aufpasst (zB Serializable) auch ein Blödsinn,, ) .. so in etwa dürfts funktionieren - stell ich mir zumindest vor..

lg, asterix

Zitat

Original von asterix
also es speichert nicht inkonsistent (zB wenn irgenwelche Threads noch am Objekt rummurksen) (also wenn zB einer eine Datei/Objekt grad bearbeitet und ein anderer will die/das gleiche zur selben Zeit speichern, dann passiert ja, wenn da nicht wer aufpasst (zB Serializable) auch ein Blödsinn,, )

Naja, darauf sollte schon der Entwickler achten, Threadsafety lautet hier das Zauberwort, ansonsten hat man bei komplexen Programmen schnell einen Wurm drinne, den man nicht mehr mit vertretbaren Aufwand rauskriegt

Beim oben genannten Beispiel z.B. könnte man eine Kopie (keine Referenz) des Objektes (Zugriff anderer Threads ist gelockt solange die Kopierfunktion arbeitet) den Speicherthread übergeben, so könnten ein Thread mit dem Objekt arbeiten, während ein anderer eine relativ aktuelle Kopie ungestört in eine Datei schreibt.
Oder man lockt das Objekt ganz (Alle Threads müssen warten, bis das Objekt gespeichert wude, bevor sie wieder darauf zugreifen können).