XMLEncoder: discarding statement LinkedList.add(File)

[Guest]

Hi.

Ich habe eine Klasse in sich eine LinkedList<File> befindet. Diese Klasse lässt sich nicht korrekt serialisieren.


Eclpise Fehlermeldung:

java.lang.InstantiationException: java.io.File
Continuing ...
java.lang.Exception: XMLEncoder: discarding statement LinkedList.add(File);
Continuing ...


Woran kann das liegen? Andere LinkedLists die selbstgebaute Objekte schlucken nimmt er auch. Ist "File" etwa inkompatibel? :-?


Gruß, Mia Su En

 

[André Uhres]

Dein Code funktioniert bei mir.

 

[Guest]

Ich wollte eigentlich nur allgemein fragen ob man eine LinkedList<File> XML-serialisieren kann.

// CLASS MainApp
package generaltools;

import java.io.File;
import java.io.FileNotFoundException;
import java.util.LinkedList;

public class AppMain {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		
		A a = new A();
		a.setTestlist(new LinkedList<File>());
		a.getTestlist().add(new File("/","test"));
		
		File xmlfile = new File("/","xmlfile");		
		try
		{
			XMLFactory.exportObject(a, xmlfile);
			a.getTestlist().clear();
			XMLFactory.importObject(xmlfile);
		}
		catch (FileNotFoundException e)
		{
			e.printStackTrace();
		}
		
		System.out.println(a.getTestlist().getFirst().getAbsolutePath());		
	}
}



// CLASS A
package generaltools;

import java.util.LinkedList;

public class A {
	
	LinkedList<String> testlist;

	/**
	 * constructor
	 */
	public A() {}
	
	
	/**
	 * @return the testlist
	 */
	public LinkedList<String> getTestlist() {
		return testlist;
	}

	/**
	 * @param testlist the testlist to set
	 */
	public void setTestlist(LinkedList<String> testlist) {
		this.testlist = testlist;
	}
}

// CLASS XMLFACTORY
package generaltools;

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;

public class XMLFactory {
	
	
// XML IO
	
	/**
	 * import object from xml file
	 * 
	 * @param the object xml file to import
	 */ 
	public static Object importObject(File xmlfile) throws FileNotFoundException
	{ 
		XMLDecoder decoder = new XMLDecoder(
								new BufferedInputStream(
									new FileInputStream(xmlfile)));		
		
		Object object;
		
		if(xmlfile.canRead())
		{			
			object = (Object)decoder.readObject();
			decoder.close();
			return object;
		}
		else
			return null;		
	}

	/**
	 * export object to xml file
	 * 
	 * @param the xml file to export the object into
	 */
	public static boolean exportObject(Object object, File xmlfile) throws FileNotFoundException
	{
		XMLEncoder encoder = new XMLEncoder(
                				new BufferedOutputStream(
                					new FileOutputStream(xmlfile)));

		if(xmlfile.canWrite())
		{
			encoder.writeObject(object);
			encoder.close();
			return true;
		}
		else
			return false;
	}	
}

Woran liegts? Google findet zu "XMLEncoder: discarding statement LinkedList.add(File); " leider nichts, was man bei Suchanfragen wie "XMLEncoder File" findet ist leider auch nichts sinnvolles.

Gruß, Mia

 

[André Uhres]

..Ist "File" etwa inkompatibel?..

Sry, du hast Recht, ich hatte mich vertan.
File ist keine Bean. Z.B. fehlt die Methode setPath(..) und man könnte sie nicht mal
durch Erweiterung einfügen, denn die Variable "path" ist "private"!
XMLEncoder funktioniert aber nur für Beans.

 

[Guest]

Ok, dann nehme ich die unelegante Variante LinkedList<String>. Nicht gerade durchdacht... In Visual C++ ist das kein Problem. Wieso hängt sich der XMLEncoder denn überhaupt an den Beankonventions auf??? Alternativ könnte er sich doch eigentlich seine getter, setter selbst generieren. Wieso belastet man den Programmierer damit?

 

[Wildcard]

Der XMLEncoder ist keine generelle Persistierungsmethode, sondern für Beans vorbehalten. Beans sind übrigens grafische Komponenten und keine beliebigen Datencontainer.

 

[André Uhres]

..Beans sind übrigens grafische Komponenten und keine beliebigen Datencontainer.

Beans sind nicht notwendigerweise mit graphischen Oberflächen verknüpft.
Man kann beispielsweise auch Beans für die Verarbeitung oder Zwischenspeicherung
von Daten schreiben, die keine Ein- und Ausgaben an der Benutzeroberfläche aufweisen.

 

[Wildcard]

Sehen wir uns mal die JavaBean Spezifikation an:
http://java.sun.com/products/javabeans/docs/spec.html

“A Java Bean is a reusable software component that can be manipulated visually
in a builder tool.”

So, jetzt kommst du :wink:

 

[André Uhres]

..So, jetzt kommst du :wink:

Wir wollen doch nicht alles in einen Topf werfen!
Die graphische Oberfäche eines Builder Tools ist eine Sache,
und die graphische Oberfläche der Anwendung, die wir damit bauen wollen, ist eine andere Sache.
Ich sprach von der letzteren.
"javax.swing.ButtonGroup" ist z.B. keine graphische Komponente,
kann aber sehr wohl in einem Builder Tool visuell eingesetzt werden, weil es eine Bean ist.

 

[Wildcard]

Das ist richtig, eine Bean braucht nicht unbedingt eine direkte grafische Visualisierung und die Buttongroup ist ein sehr schönes Beispiel.

Mit deiner ursprünglichen Aussage deckt sich das allerdings nicht, denn eine ButtonGroup ist sehr wohl "mit graphischen Oberflächen verknüpft".

Man kann beispielsweise auch Beans für die Verarbeitung oder Zwischenspeicherung
von Daten schreiben, die keine Ein- und Ausgaben an der Benutzeroberfläche aufweisen

Ich will mich auch nicht an Formulierungen aufhängen, aber wenn ich richtig verstehe was du damit sagen wolltest, dann ist genau das nämlich keine Bean und nur darum geht es mir, denn 'Gast' ist sicherlich weit von einer Bean entfernt.

 

[André Uhres]

..Mit deiner ursprünglichen Aussage deckt sich das allerdings nicht, denn eine ButtonGroup ist sehr wohl "mit graphischen Oberflächen verknüpft".

Man kann beispielsweise auch Beans für die Verarbeitung oder Zwischenspeicherung
von Daten schreiben, die keine Ein- und Ausgaben an der Benutzeroberfläche aufweisen

Das deckt sich sehr wohl mit meiner Aussage, denn die ButtonGroup ist an sich unsichtbar. Die Tatsache, dass sie mit sichtbaren Beans zusammenarbeitet, ändert nix daran und ist im swing package wohl auch kaum anders zu erwarten.

Aber wenn du willst, hier ist ein anderes Beispiel:

public class MeineListe extends ArrayList{
    public MeineListe(){
        add("MeineListe");
    }
}

Das ist eine Bean (naja, nicht wirklich genial) und ich kann sie ohne Weiteres in ein Builder Tool einbinden und visuell bearbeiten.
Es ist aber genauso wenig eine graphische Komponente wie ButtonGroup!

Ich will mich auch nicht an Formulierungen aufhängen, aber wenn ich richtig verstehe was du damit sagen wolltest, dann ist genau das nämlich keine Bean und nur darum geht es mir, denn 'Gast' ist sicherlich weit von einer Bean entfernt.

Ich versteh grad nicht, was du damit sagen willst.
Was ich eigentlich sagen will: mit XMLEncoder kann man viel mehr abspeichern als nur graphische Komponenten!

 

[Wildcard]

Das ist eine Bean (naja, nicht wirklich genial) und ich kann sie ohne Weiteres in ein Builder Tool einbinden und visuell bearbeiten.
Es ist aber genauso wenig eine graphische Komponente wie ButtonGroup!
...
Ich versteh grad nicht, was du damit sagen willst.
Was ich eigentlich sagen will: mit XMLEncoder kann man viel mehr abspeichern als nur graphische Komponenten!

Entschuldigung, aber das ist nun wirklich Unsinn.
Das Beispiel alleine ist schon grober Unfug, da ArrayList natürlich keine Bean ist und MeineListe daher völlig sinnbefreit ist. Sieht man jedoch davon ab, dann versuchst du, den Leuten ein Lama für einen Apfel vorzumachen.
Was eine echte Bean ist und was ein schnöder Datencontainer der sich an die Beans Specification hält, ist (hoffe ich) uns beiden klar.
Fakt ist:
Der XMLEncoder kann Klassen speichern die sich formal an die Beans Specification halten, auch wenn sie keine sind, das ist richtig. Wenn du das sagen möchtest, gebe ich dir ja recht, aber erzähl mir bitte nicht nochmal das dein Beispiel eine Java Bean sein soll :roll:
Wer versucht seine Klasse gemäß Bean Specification umzubauen(obwohl sie keine ist), nur damit der XMLEncoder sie schluckt, der soll sich einen sinnvolleren Zeitvertreib suchen und eines der mächtigen XML Binding Frameworks ansehen.

 

[André Uhres]

Ein schnöder Datencontainer der sich an die Beans Specification hält, ist eine Bean.
Beans müssen nicht immer graphische Komponenten sein :wink:

 

[Wildcard]

Nein, ist es nicht. Das ist nur was viele Leute (fälschlicherweise) unter einer Bean verstehen.
Eine Bean dient dem computerunterstützten Application Development auf Komponentenbasis.
Eine Bean ist kein POJO mit gettern und settern.

 

[André Uhres]

..Eine Bean dient dem computerunterstützten Application Development auf Komponentenbasis...

Das sag ich ja auch die ganze Zeit. Und ein schnöder Datencontainer passt da auch hin :wink:

 

[Guest]

Au. Haut Euch doch

dann ist genau das nämlich keine Bean und nur darum geht es mir, denn 'Gast' ist sicherlich weit von einer Bean entfernt.

ganz genau. kannst du mir einen Tipp geben welcher XML Serializer/Deserialzer sich für meinen Zweck empfiehlt? Einen wo ich keine getter,setter anlegen muss. Ohne Schnickschnack und keine fliegenden Kühe. Einfach einen der ein Objekt und alle Unterobjekte "schlafen legt" z.B. als simples UTF-8 encoded flat-file, einfach in dem Zustand in dem sich das Objekt grad befindet. Ich hab jetzt schon alles mögliche in der v6 Sun-Lib ausprobiert, habe immer noch keinen (vernünftigen, einfachen, klaren) Weg gefunden... ???:L

 

[André Uhres]

Au. Haut Euch doch

:noe:
Einer bevorzugt den Ansatz des Data Bindings mit EMF oder JAXB,
ein anderer nimmt für simple Datencontainer oder Ähnliches den einfachen standard XMLEncoder.