# XMLEncoder: discarding statement LinkedList.add(File)



## Guest (16. Feb 2008)

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 (18. Feb 2008)

Dein Code funktioniert bei mir.


----------



## Guest (18. Feb 2008)

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 (19. Feb 2008)

Anonymous hat gesagt.:
			
		

> ..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 (19. Feb 2008)

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 (19. Feb 2008)

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


----------



## André Uhres (19. Feb 2008)

Wildcard hat gesagt.:
			
		

> ..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 (19. Feb 2008)

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 (20. Feb 2008)

Wildcard hat gesagt.:
			
		

> ..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 (20. Feb 2008)

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 (20. Feb 2008)

Wildcard hat gesagt.:
			
		

> ..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!



			
				Wildcard hat gesagt.:
			
		

> 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 (20. Feb 2008)

André Uhres hat gesagt.:
			
		

> 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 (20. Feb 2008)

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 (20. Feb 2008)

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 (20. Feb 2008)

Wildcard hat gesagt.:
			
		

> ..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 (21. Feb 2008)

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 (21. Feb 2008)

Anonymous hat gesagt.:
			
		

> 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.


----------

