#1 19. Oktober 2010 Nicht-Serializable Object speichern Hi, hat einer ne Ahnung wie ich ein Objekt in einer Datei speichern kann, welches nicht Serializable implementiert? Um direkt das Problem anzusprechen. Ich habe mehrere Areas (java.awt.geom.Area). Die möchte ich nun gerne speichern, natürlich mit zusätzlichen Daten meine Klasse class MyArea extends Area implements Serializable is ja ganz toll aber speichert nun eben alle Variablen/Objekte, ausser eben das was zu Area gehört. hab auch schon versucht den PathIterator zu speichern Mit speichern von Objekten habe ich mich bisher noch gar nicht so auseinander gesetzt und bisher auch nichts weiter gefunden. allerdings sollte es doch irgendwie die Möglich sein das Ding zu speichern. Ich nutze Area um mehrere Bereiche aus wiederum mehreren Shapes (also kreise und rechtecke) zusammen zu setzen Ich könnte jetzt zwar auch die geometrischen formen speichern... aber da habe ich irgendwann mehrere hundert formen gespeichert, anstatt einfach 10 Areas... Vielleicht kann ja jemand helfen + Multi-Zitat Zitieren
#2 20. Oktober 2010 AW: Nicht-Serializable Object speichern Die einfachste Lösung wäre eine Serialisierungs-Library zu verwenden, z.B. XStream. In diesem Fall würde das Ergebnis eine XML-Datei sein. XStream - Two Minute Tutorial + Multi-Zitat Zitieren
#3 20. Oktober 2010 AW: Nicht-Serializable Object speichern Hi, danke frisst zwar extrem viel Ressourcen aber damit muss ich dann wohl erstmal leben immerhin gehts so + Multi-Zitat Zitieren
#4 20. Oktober 2010 AW: Nicht-Serializable Object speichern Ich würde das über JDO mit entsprechenden Annotations machen: http://www.jpox.org/docs/1_2/jdo/annotations.html Da kann man sehr genau bestimmen wie viel gespeichert werden soll. Ist auch möglich, dass dich dich falsch verstanden habe. Zeig mal deinen Source. + Multi-Zitat Zitieren
#5 20. Oktober 2010 AW: Nicht-Serializable Object speichern Verfehlt glaube ich das, was er möchte. Er hat zwar eine eigene Klasse jedoch sind gerade die Member, die von java.awt.geom.Area vererbt werden sein Problem. Und dort kann er natürlich keine Annotations einfügen. Der andere Ansatz, wenn die Serialisierung, wie ich sie vorhin schon beschrieben habe, für die Anwendung zu ressourcenlastig ist, wäre eine Liste zu verwalten, die alle Objekte, die du zeichnest, beinhaltet. Diese müsste dann nur gespeichert und wieder geladen werden. + Multi-Zitat Zitieren
#6 20. Oktober 2010 AW: Nicht-Serializable Object speichern Hi, du hast das schon richtig verstanden Das mit den Objekten speichern hatte ich mir auch schon überlegt, aber wie schon im ersten Post erwähnt, würde das noch mehr Ressourcen verbrauchen als so. XStream brauch so viel Ressourcen, weils zum großen Teil auch jedes Shape speichert, was ich zeichne. Also die Lösung ist schon okay so speichern und laden funktioniert einwandfrei + Multi-Zitat Zitieren
#7 20. Oktober 2010 AW: Nicht-Serializable Object speichern Er möchte also die Vererbungen nicht mit speichern, ist das richtig? Falls das so sein sollte, sehe ich kein Problem mit der Lösung, die ich vorgeschlagen habe (Stichwort: FetchGroup(s)). JDO sind unheimlich mächtig und es würde mich wundern, wenn sie mit so einem banalem Problem nicht klar kommen. Eine andere Lösung wäre eine neue Klasse zu erstellen, bspw. AreaData. In diese Klasse speicherst du nur dann die Informationen, die du wirklich brauchst und liest diese später wieder ein - erstellst das Objekt neu. Das ist auch das, was Chillikid meinte. Am besten ist es halt, wenn ihr Code postet, das Gerede ist meistens schwer nach zu voll ziehen P.S: Dein Blog liest sich ganz gut, sind ein paar interessante Sachen dabei. Schaue mal öfter vorbei nun + Multi-Zitat Zitieren
#8 21. Oktober 2010 AW: Nicht-Serializable Object speichern Nee falsch ich will Area eben komplett miterben aber Area implementiert Serializable eben nicht. ich habe also objekte folgender klasse in einer liste und will sie speichern vielleicht kannst du dir dan vorstellen wo das problem ist natürlich sind noch ne Menge Variablen mehr drinn, aber das sollte das problem eben verdeutlichen die variablen zu speichern ist kein Problem, die teile von Area allerdings schon wie gesagt Chillikids Lösung ist da schon okay, gibt sicherlich noch was schöneres aber funktionalität ist momentan wichtiger als schönheit Code: import java.awt.geom.Area; import java.io.Serializable; public class MyArea extends Area implements Serializable { private static final long serialVersionUID = -2060452177606140005L; private String name; //hier stehen noch mehr Attribute/Variablen public MyArea() { super(); } public EventArea(Area area, String name) { super(area); this.name = name; } public void setName(String name) { this.name = name; } public String getName() { return name; } } + Multi-Zitat Zitieren
#9 21. Oktober 2010 Zuletzt von einem Moderator bearbeitet: 14. April 2017 AW: Nicht-Serializable Object speichern Ich habe nun endlich verstanden, was du willst (sehr seltsam beschrieben, man weiß erst , was du meinst, wenn mans sowieso schon weiß ). Allerdings kann ich mir keine Situation vorstellen wo man das so machen muss (und nicht sinnvoller lösen kann.) Vielleicht solltest du dein ganzes Programm Design noch mal überdenken. Wenns unbedingt sein muss kannst du dir ja die Klasse aus den Sourcen holen, umschreiben und dann bei dir einbinden. Dank Open Source sind dir da kaum Grenzen gesetzt: No File | www.xup.in So könntest du dann beispielsweise beliebige Interfaces implementieren. Achja: Code: public EventArea(Area area, String name) Der Konstruktor hat da wohl kaum was verloren (mit dem Namen) Beim Umbenennen übersehen? + Multi-Zitat Zitieren
#10 21. Oktober 2010 AW: Nicht-Serializable Object speichern jo beim Umbenennen übersehen wollte net den thread mit millionen zeilen zu knallen und hab nur das wichtigste rauskopiert da war doch MyArea sinnvoller als der Name der Klasse den ich jetzt nutze Area an sich ist genau das richtige eigentlich für die Sache die ich damit machen will nur das es so doof zu speichern ist, ist ärgerlich aber per xml gehts auch und die dateien sehn auch noch schick aus + Multi-Zitat Zitieren