Änderungen in der JAR speichern

[BaqFish]

Nabend zusammen,

ich bin im Moment dabei ein kleines Programm zu schreiben. Nun habe ich das Projekt als JAR exportiert und es lässt sich auch ohne Probleme starten.
Jetzt habe ich allerdings das Problem, dass ich, wenn ich TextFields oder CheckBox' ändere, deren Wert beim schließen nicht gespeichert wird.
Da ich nicht genau wusste, nach was ich suchen sollte, erstelle ich ein eigenes Thema und hoffe auf eure Hilfe.


Mit freundlichem Gruß

BaqFish

 

[Helgon]

Du speicherst den wert auch nirgends.

Dein Java Programm speichert nicht von selbst.

Für etwas kleines wie deine Sache bietet es sich an die Klasse zu serialisieren.

Java ist auch eine Insel – 12.14 Persistente Objekte und Serialisierung

 

[troll]

man kommt zwar auch während der runtime an einen stream des aktuellen JAR-files ran ... sinnvoller ist aber eine config-datei daneben

File dir=new File(this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI()).getParentFile();

liefert dir ein File-objekt auf das aktuelle verzeichnis in dem die JAR liegt ...

dann kannst du mit

File config=new File(dir, "config.properties");

ein File-objekt auf deine config-datei holen und darin mit Properties (standard-format für java) deine daten speichern ... laden funktioniert analog

wenns nur ein kleines projekt ist kann man auch eine klasse nehmen und in deren variablen alles speichern und dann serialisieren ... ist aber für große projekte und long-time unbrauchbar

 

[Gastredner]

man kommt zwar auch während der runtime an einen stream des aktuellen JAR-files ran ... sinnvoller ist aber eine config-datei daneben

File dir=new File(this.getClass().getProtectionDomain().getCodeSource().getLocation().toURI()).getParentFile();

Ich würde die Konfigurationsdateien nicht bei der Executable speichern - unter Umständen liegt diese an einem Ort, wo der Nutzer keine Schreibrechte hat, was das Speichern erfahrungsgemäß dann eher schwierig gestaltet.
Besser ist es, den Benutzerordner dazu zu verwenden:

String userFolder = System.getProperty("user.home");
File saveFile = new File(userFolder, ".yourapp/config.cfg");

Damit erzeugst du im Benutzerordner einen Ordner namens ".yourapp" (der Punkt, damit dieser unter unixoiden Systemen nicht direkt sichtbar ist), der eine Datei "config.cfg" enthält, in die du deine Daten schreiben kannst. Wenn du den Ordner deines Nutzers unter Windows nicht sinnlos "zumüllen" möchtest, kannst du auch erst testen, ob dein Programm unter Windows läuft und dir im Falle einer positiven Antwort den Wert der Systemvariable APPDATA besorgen, die den Pfad zu dem Ordner enthält, den Windows zum Speichern von Applikationsdaten vorsieht.

 

[BaqFish]

Danke schonmal für die Hilfe. Ich bin jetzt soweit, dass ich folgenden Code habe:

public class Testi extends javax.swing.JFrame implements java.io.Serializable {

    public static Testi getJFrame() {
        ObjectInputStream o;
        try {
            o = new ObjectInputStream(new FileInputStream("C:/Users/****/Documents/NetBeansProjects/Testi/dist/"));
            Testi myFrame = (Testi) o.readObject();
            return myFrame;
        } catch (IOException | ClassNotFoundException e) {

            Testi my = new Testi();
            serialize(my);
            return my;
        }
    }

    public static void serialize(Testi myFrame) {
        try {
            File f = new File("C:/Users/****/Documents/NetBeansProjects/Testi/dist/testi.bn");
            try (ObjectOutputStream o = new ObjectOutputStream(new FileOutputStream("C:/Users/****/Documents/NetBeansProjects/Testi/dist/", true))) {
                o.writeObject(myFrame);
            }
        } catch (IOException e) {
            JOptionPane.showMessageDialog(null,
                    "Fehler beim anlegen der Konfigurationsdatei!", "Fehler",
                    JOptionPane.ERROR_MESSAGE);
        }
    }

Es wird eine nun durch Testi.getJFrame(); eine Datei erstellt, dennoch erscheint die Fehlermeldung die im unteren Exception Block abgefangen wird. Laut Debugger handelt es sich um eine NotSerializableException.

Ich hoffe ihr könnt mir erneut helfen.

 

[kaetzacoatl]

1. Prüfe ob dein Frame nicht serialisierbare Felder enthält und mache diese transient.
2. Füge eine id eine [JAPI]java.io.Serializable[/JAPI]
3. wtf?

try (ObjectOutputStream o = new ObjectOutputStream(new FileOutputStream("C:/Users/****/Documents/NetBeansProjects/Testi/dist/", true))) {

sowas hab ich noch nie gesehen,
geht das?

 

[789456123]

Ich würde die Konfigurationsdateien nicht bei der Executable speichern - unter Umständen liegt diese an einem Ort, wo der Nutzer keine Schreibrechte hat, was das Speichern erfahrungsgemäß dann eher schwierig gestaltet.
Besser ist es, den Benutzerordner dazu zu verwenden:

String userFolder = System.getProperty("user.home");
File saveFile = new File(userFolder, ".yourapp/config.cfg");

Damit erzeugst du im Benutzerordner einen Ordner namens ".yourapp" (der Punkt, damit dieser unter unixoiden Systemen nicht direkt sichtbar ist), der eine Datei "config.cfg" enthält, in die du deine Daten schreiben kannst. Wenn du den Ordner deines Nutzers unter Windows nicht sinnlos "zumüllen" möchtest, kannst du auch erst testen, ob dein Programm unter Windows läuft und dir im Falle einer positiven Antwort den Wert der Systemvariable APPDATA besorgen, die den Pfad zu dem Ordner enthält, den Windows zum Speichern von Applikationsdaten vorsieht.

ist mir bewusst ... jedoch gehe ich davon aus (oder besser prüfe es direkt in meiner software) dass das jar bereits innerhalb von user.home liegt und somit rechte vorhanden sind ...
wird festgestellt dass das jar außerhalb user.home ist wird es dort hin kopiert (in einen seperaten unterordner) und von dort aus noch mal neu gestartet sowie die aktuelle VM terminiert ...

3. wtf?

try (ObjectOutputStream o = new ObjectOutputStream(new FileOutputStream("C:/Users/****/Documents/NetBeansProjects/Testi/dist/", true))) {

sowas hab ich noch nie gesehen,
geht das?

das nennt sich try-with-resources und macht im zusammenhang mit AutoCloseable sinn
beides gibt es ab Java7 sowie den fakt das Closeable nun auch von AutoCloseable erbt, genau wie viele Channel klassen
der sinn dahinter ist das man sich nun nicht mehr explizit in einem finally-block um das closen kümmern muss ...