I'd like to add persistence to my Swing-based application; and this is the first time that I'm doing something like that.
I know how to use Java serialization APIs (though I'm using xstream instead), I know that JComponent's are serializable, but I'm interested in more architectural considerations: how an application should be designed so that making it persistent becomes easy; etc.
I'd be happy to see any sources with in-depth consideration of these issues, though I'd be also happy to hear some best practices explicitly :)
Hint: Oracle has developed JavaFX to replace both Swing and AWT. Since Java SE 7, update 6 it is bundled with Java SE. "JavaFX is a set of graphics and media packages that enables developers to (...) deploy rich client applications that operate consistently across diverse platforms" [1].
JavaFX new fixes will continue to be supported on Java SE 8 through March 2022 and removed from Java SE 11. Swing and AWT will continue to be supported on Java SE 8 through at least March 2025, and on Java SE 11 (18.9 LTS) through at least September 2026.
No, Java Swing components are not thread-safe in Java.
You should use a model-view-controller approach. You only serialize the model, not the view. The view should be populated from the model. Serializing Swing components is anyways not recommended at all:
While Swing components do implement the Serializable interface, they are not portable between different versions of the Java Virtual Machine
Looking at what you have, you should have some classes that are your model and have only data. These classes will be serialized using XStream somewhere. Your Swing Classes then have methods to receive these model classes and populate the fields and editors. You can then extend the UI, for example, without having to change the class, adding more funcionality, or provide different views for the same data set.
To make it fancier, the Swing Component should not store and load the model, but you should have a controller interface that you pass to the swing component to perform these operations. This way, you can unit test better and you decouple the storage logic from the view logic.
If XStream is correctly configured, and if you are careful about the model and the fields, it should be possible to add more fields to your model classes without breaking backwards compatibility.
I don't recommend using Java Serialization anyways, as it is not a good practice to use it for storage. Java Serialization excels at Remote Method Invocation. It is relatively fragile when the model classes change..
And the javadoc says (for instance on JComponent): As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.
So see XMLEncoder.
From architectural point of vue, this serialization work best with beans, collections, and the notion of default value. On beans, it save only properties beans with a different value than default value. (sorry for my english)
You can configure that as you want.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With