Problem bei Umstellung von (default package) auf Packages

[Soren]

Moin, moin!

Ich habe ein kleines Problem und weiß nicht wo ich es anpacken soll. Vor Zeiten schreib ich ein Programm und war mir nicht im Klaren, dass es eines Tages sehr unübersichtlich würde: nun möchte ich es gerne auf eine vernünftige Packagestruktur umstellen. Problematisch ist nun Folgendes:

Das Programm speichert per Object In- und OutputStream ArrayListen von Transaktionen, Schlüsseln und Konten. Sagliche Klassen befinden sich in (default package). Wenn ich sie nun in ein normales Packages stecke, ist die JVM beim Auslesen der Dateien einer Vorgängerversnio der Meinung, das zu lesende Objekt gäbe es gar nicht und wirft eine ClassNotFoundException, wenn ich eine der ArrayLists lesen möchte. Warum er das tut ist klar, das einst gespeicherte Objekt kennt seine Identität und die JVM weiß nicht, dass ich im Programm dessen Namen geändert habe. Nur was mache ich nun?

Leider bin ich auf Abwärtskompatibilität zu alten Versionen meines Programms angewiesen. Kennt vielleicht jemand die Patentlösung zu meinem Problem ;-) greez


Soren

 

[mic_checker]

Dann poste das ganze doch bitte mal konkreter. WIr wissen ja nicht wie deine Sources aussehen, welche Verzeichnisse du auf deiner Festplatte dafür erstellt hast etc.

 

[Soren]

Der gesamte Quelltext befindet sich jetzt im Arbeitsverzeichnis, das ich für das Programm angelegt habe, in

d:\E3W\Buchhaltung\

Wenn ich packages anlege, sieht das ungefähr so aus:

d:\E3W\Buchhaltung\buchhaltung

mit den speziellen Unterverzeichnissen für Funktionkomponenten, Interaktionskomponenten, Geschäftsobjekte, Hilfsklassen, usw., die dann in buchhaltung\iak, buchhaltung\fk, buchhaltung\go liegen. Im letzten liegen die Klassen, die vorher in d:\E3W\Buchhaltung\ lagen und die ich nun lesen möchte, und zwar mit dem Programm, dass die neue Verzeichnis und somit Paketstruktur kennt. Konkret sind das ArrayLists mit Transaktionen. Transaktionen sind nichts weiter als Datenbehälter mit get und set Methoden (eine Art JavaBean also).

Zu beachten ist hier, dass ich die Geschäftsobjekte nicht etwa im (default package) in d:\E3W\Buchhaltung\ belassen kann, weil sie dort von den anderen Klassen, die natürlich auf den Geschäftsobjekten arbeiten, nicht gefunden werden. Wenn ich sie allerdings nach buchhaltung.go verschiebe, dann findet die JVM die in der ArrayList enthaltenen Objekte vom Typ "Transaktion" usw. nicht mehr, da ich ihren qualifizierten Namen geändert habe, nämlich von "Transaktion" auf "buchhaltung.go.Transaktion". Das Quelltextfragment sieht so aus:

file = new File(filename);
			FileInputStream fos = new FileInputStream(filename);
			ObjectInputStream oos = new ObjectInputStream(fos);
			try
			{
                 // hier kommt eine ArrayList mit Transaktionen an
				_transaktionen = (ArrayList) oos.readObject(); 
			}
			catch (ClassNotFoundException e)
			{
				JOptionPane.showMessageDialog(
					null,
					"Dateifehler. Fehlerursache: Datei ist nicht kompatibel oder keine Buchhaltungsdatei.\n"
						+ "Das System kann die Datenbasis (Transaktionen) nicht laden.\n" +
								"\n"+e.getMessage());
			}

Die Wurzel des Übels habe ich gefunden, nur wie bringe ich der JVM bei, dass Transaktion und buchhaltung.go.Transaktion die selben Objekte sind?

 

[Bert Brenner]

Über einen ObjectOutputStream sollte man generell keine Daten länger speichern, da ich diese ja schon nicht mehr laden kann wenn ich änderungen an meiner Klasse mache.

Da würde ich zusehen das du die Daten künftig anders speicherst. Vielleicht kannst du die alte Klasse ja noch mal verwenden um eine art Konverter zu schreiben.

 

[Soren]

Mh, ja. Konverter schreiben wäre dann natürlich die Haudrauf-Lösung. Das Programm speichert auch jetzt schon die Daten in eine DB, leider nicht in der Version, die im Einsatz ist. Am Einsatzort ist nämlich keine DB vorhanden und wird dort auch nicht gewünscht ;-) Für die Benutzer zählt im Moment nur die Abwärtskompatibilität.

Da ich damals davon ausging, dass sich die Geschäftsobjekte nie ändern, hab ich die ObjectOutputStreams gewählt, weil es schön einfach ist. War scheinbar keine gute Wahl, denn auch wenn ich keine Änderungen an der Klasse vornehme, sondern diese nur verschiebe, ist schon alles im Dutt. Ganz offensichtlich gibt's dafür auch keinen einfachen Workaround, wie ich gehofft hatte. Naja, wenn noch jemandem was einfällt ...

 

[Bert Brenner]

Ok, es gibt noch einen anderen weg.

Ergänze deine Klasse um folgende eigenschaft:

static final long serialVersionUID = 12345L;

Den Wert der serialVersionUID setzt du auf den der alten Klasse, um diesen rauszufinden gibt es das Tool "serialver" im bin Verzeichniss vom jdk.

Dann versuch noch mal via ObjectInputStream zu lesen.

 

[Soren]

Super Idee! Das sah echt richtig aus, leider tritt der Fehler immer noch auf. Nen weiteren Handgriff kennst du da nicht, oder?

Ich habe probiert, die Klassen einfach im (default package) zu belassen und eine Kopie in der Paketstruktur anzulegen, damit er meinetwegen die (default package).Transaktion liest und dann auf buchhaltung.go.Transaktion casted, aber selbst da gibt es eine ClassCastException, obwohl der Quelltext identisch ist ... bis auf die "package" Passage. Schade

 

[Soren]

Natürlich habe ich die serialVersionID beibelassen, aber die CCException tritt trotzdem auf.

 

[Soren]

Noch ein Nachtrag zum Fehler: komischerweise scheint die JVM die Kopie der Transaktion im (default package) tatsächlich zu finden, auch wenn alles bereits im buchhaltung-Package ist. Die Datei wird nun geladen und der Fehler tritt erst dann auf, wenn die erste Transaktion aus der ArrayList "rausgecastet" wird. Zu dem Zeitpunkt wird nämlich die neue buchhaltung.go.Transaktion benutzt.
Die serialVersionID ist bei beiden gleich, hab ich sogar noch mal nachgeschaut...

 

[Soren]

Ganz offensichtlich betrachtet die JVM zwei von unterschiedlichen ClassLoadern geladene Klassen als unterschiedlich, auch wenn sie gleich sind: aber sogar das stimmt bei mir. Ich hab mir mal die classLoader und den qualifizierten Namen ausgeben lassen:

sun.misc.Launcher$AppClassLoader@169e11 buchhaltung.Transaktion
sun.misc.Launcher$AppClassLoader@169e11 Transaktion
Exception in thread "Thread-0" java.lang.ClassCastException: Transaktion
	at buchhaltung.DBSeitenStapel.fuege_Transaktionen_ein(DBSeitenStapel.java:59)
	at buchhaltung.Verwaltung.<init>(Verwaltung.java:56)
	at buchhaltung.Verwaltung.getInstance(Verwaltung.java:68)
	at buchhaltung.BuchHaltung.run(BuchHaltung.java:44)

[/code]

Scheinbar unterscheiden sie sich wirklich nur in ihrem Namen.

 

[Soren]

Ich habe das Problem gelöst. Ich caste nun per Hand, indem ich die Reflection Methoden des "unbekannten" Objektes aufrufe. So komme ich an dessen Methoden und auch an die Werte des Objektes! Super. Hier ist der Quellcode:

/**
     * @param object
     * @return
     */
    private Transaktion casteAufNeueTA(Object object) {

        Method get_schluessel = null;
        Method get_haben = null;
        Method get_soll = null;
        Method get_kategorie = null;
        Method get_name_lang = null;
        Method get_zweck_lang = null;
        Method get_datum = null;

        try {
            get_schluessel = object.getClass().getMethod("get_schluessel",
                    new Class[0]);
            get_haben = object.getClass().getMethod("get_haben", new Class[0]);
            get_soll = object.getClass().getMethod("get_soll", new Class[0]);
            get_kategorie = object.getClass().getMethod("get_kategorie",
                    new Class[0]);
            get_name_lang = object.getClass().getMethod("get_name_lang",
                    new Class[0]);
            get_zweck_lang = object.getClass().getMethod("get_zweck_lang",
                    new Class[0]);
            get_datum = object.getClass().getMethod("get_datum", new Class[0]);
        } catch (SecurityException e) {
            // sollte nicht passieren
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            // sollte nicht passieren
            e.printStackTrace();
        }
        Transaktion ta;
        try {
            ta = new Transaktion((String) get_name_lang.invoke(object,
                    new Object[0]), casteAufNeuenSchluessel(get_schluessel
                    .invoke(object, new Object[0])), (String) get_zweck_lang
                    .invoke(object, new Object[0]), (String) get_kategorie
                    .invoke(object, new Object[0]), ((Float) get_soll.invoke(
                    object, new Object[0])).floatValue(), ((Float) get_haben
                    .invoke(object, new Object[0])).floatValue(),
                    (Date) get_datum.invoke(object, new Object[0]));
            return ta;
        } catch (IllegalArgumentException e1) {
            // sollte nicht passieren
            e1.printStackTrace();
        } catch (IllegalAccessException e1) {
            // sollte nicht passieren
            e1.printStackTrace();
        } catch (InvocationTargetException e1) {
            // sollte nicht passieren
            e1.printStackTrace();
        }

        return new Transaktion("fehler", new Schluessel(0, "fehler"), "fehler",
                "fehler", 0, 0, new Date());

    }