Objekte speichern

[Kenan89]

Hallo Leute,

heute habe ich mich zum ersten mal mit Outputstream auseinander gesetzt und habe es auch geschafft, Objekte zu speichern. Meine Frage ist, inwiefern meine Methode richtig ist. Hier ist ein kleines Projekt. So würde ich es in Zukunft machen. Für Verbesserungsvorschläge bin ich offen:

public class Screen extends JFrame implements ActionListener{
	
	private Cars cars = new Cars();
	
	private AtomicInteger carId = new AtomicInteger();
	
	private JButton add = new JButton("Hinzu");
	private JButton save = new JButton("Speichern");
	private JButton load = new JButton("Laden");
	
	public Screen(){
		setSize(500,500);
		
		add.addActionListener(this);
		save.addActionListener(this);
		load.addActionListener(this);
		
		add(cars.getScrollPane(), BorderLayout.CENTER);
		add(add, BorderLayout.EAST);
		add(save, BorderLayout.WEST);
		add(load, BorderLayout.SOUTH);
		
		setVisible(true);
		setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
	}

	@Override
	public void actionPerformed(ActionEvent e) {
		JButton btn  = (JButton) e.getSource();
		
		if(btn.equals(save)){
			cars.save();
		}
		if(btn.equals(add)){
			Car c = new Car(carId.incrementAndGet());
			cars.addCarList(c);
		}
		if(btn.equals(load)){
			cars.load();
		}
	}
	public static void main(String[] args){
		new Screen();
	}
}

public class Cars extends JPanel{
	
	private JScrollPane scrollpane;
	
	private List<Car> carList = new ArrayList<Car>();
	
	public Cars(){
		scrollpane = new JScrollPane(this);
	}
	
	public void save(){
		try{
			ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("C:\\SpeicherTest\\save.save"));
			out.writeObject(carList);
			removeAll();
			scrollpane.setViewportView(this);
			System.out.println("Cars Gespeichert");
		}
		catch(Exception e){
			e.printStackTrace();
		}
	}
	
	public void load(){
		removeAll();
		scrollpane.setViewportView(this);
		try{
			ObjectInputStream in = new ObjectInputStream(new FileInputStream("C:\\SpeicherTest\\save.save"));
			
			carList = (List<Car>)in.readObject();
			for(int i= 0; i<carList.size(); i++){
				add(new JButton(carList.get(i).getId()));
			}
			scrollpane.setViewportView(this);
			System.out.println("Cars Geladen");
		}
		catch(Exception e){
			e.printStackTrace();
		}
	}
	
	public JScrollPane getScrollPane(){
		return scrollpane;
	}
	
	public void addCarList(Car car){
		carList.add(car);
		add(new JButton(car.getId()));
		scrollpane.setViewportView(this);
	}
}

public class Car implements Serializable{

	private String id;
	
	public Car(int id){
		this.id = "Car "+id;
	}
	
	public String getId(){
		return id;
	}	
}

 

[André Uhres]

Es wird empfohlen, in der Klasse, die gespeichert werden soll (hier die Klasse Car), die serialVersionUID anzugeben. Sie sollte für eine bestimmte Klasse immer gleich bleiben. Beispiel:

private static final long serialVersionUID = 1L;

Wenn wir das nicht tun, dann generiert Java eine serialVersionUID, die ändern kann, wenn wir die Klasse später ändern (zum Beispiel wenn wir eine Eigenschaft hinzufügen); in dem Fall können die bereits gespeicherten Objekte nicht mehr geladen werden: es wird eine InvalidClassException geworfen.

Gruß,
André

PS: alternativ können wir XMLEncoder/XMLDecoder verwenden, um Java Beans in Textdarstellung zu speichern/laden. Eine Bean ist eine public Klasse mit einem Default-Konstruktor (ohne Parameter) und Getter-Setter Methoden für alle Eigenschaften. Beispiel:

public class Car
{

   private String id;

   public Car()
   {
      this(0);
   }

   public Car(int id)
   {
      this.id = "Car " + id;
   }

   public String getId()
   {
      return id;
   }

   public void setId(String id)
   {
      this.id = id;
   }
}

XMLEncoder/XMLDecoder Beispiel:

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
...

   public static void save(final Object obj, final String filename)
   {
      try
      {
         XMLEncoder encoder = new XMLEncoder(new BufferedOutputStream(new FileOutputStream(filename)));
         encoder.writeObject(obj);
         encoder.close();
      } catch (IOException e)
      {
         e.printStackTrace();
      }
   }

   public static Object load(final String filename)
   {
      Object obj = null;
      try
      {
         XMLDecoder decoder = new XMLDecoder(new BufferedInputStream(new FileInputStream(filename)));
         obj = decoder.readObject();
         decoder.close();
      } catch (FileNotFoundException ex)
      {
      }
      return obj;
   }

 

[Kenan89]

In meinem richtigen Programm soll ja nicht nur eine Klasse gespeichert, sondern mehrere gespeichert werden. Bei allen Serializable Klassen die gleiche serialVersionUID verwenden oder immer variieren?

Zum Beispiel wenn Klasse Objekte noch mit gespeichert werden soll. Es ist ja dann auch Serializable. Ist die serialVersionUID dort ein anderer als die in Car.
Car: 1L
Objekte: 2L

 

[André Uhres]

Zum Beispiel wenn Klasse Objekte noch mit gespeichert werden soll. Es ist ja dann auch Serializable. Ist die serialVersionUID dort ein anderer als die in Car.
Car: 1L
Objekte: 2L

Das kann auch dieselbe sein, Hauptsache sie ändert nicht. Allerdings, bei nicht kompatiblen Änderungen (etwa eine Änderung in der Klassenhierarchie) sollte man auch die serialVersionUID ändern, da die gespeicherten Objekte dann nicht mehr verwendbar sind.

Gruß,
André

 

[Spacerat]

Eigetlich muss man sich bei Serializable nur immer darüber bewusst sein, was gespeichert wird. Voll qualifizierter Klassenname, SerialVersionUID und alle Daten die z.B. nicht statisch oder transient sind. Generiert man eine solche UID nicht, wird sie aus der Prüfsumme der ".class"-Datei erzeugt. Ändert man an Klassen ohne UID auch nur geringfügig etwas, so werden bisher serialisierte Daten sofort ungültig. Darüber hinaus lassen sich solche Daten auch nur wieder in VMs der selben Major-/Minor-Version laden, weil diese Teil des Bytecodes und damit Teil der automatisch generierten UID sind.
Deshalb macht es durchaus Sinn, stets eine SVUID zu deklarieren, ob man sie nun einmalig aus der Prüfsumme oder eine Default-ID erstellen lässt ist dabei egal (Eclipse z.B. lässt einem die Wahl). Zumindest hat man mit einer UID mehr Freiheiten, was das Ändern der Klasse sowie das Serialisieren und Deserialisieren angeht.

 

[André Uhres]

Die Alternative mit XMLEncoder/XMLDecoder ist übrigens weniger anfällig für Veränderungen in der Implementierung der zu ladenden Objekte, weil kein Bytecode gespeichert wird, sondern nur die Eigenschaften der Objekte in Textdarstellung. Das Laden eines Objekts geschieht durch Neuerzeugung über den Default-Konstruktor, mit anschließender Anpassung der Eigenschaften, sofern diese nicht den Default-Werten ensprechen.

Gruß,
André