• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SWING and Serialisation

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Morning All,

Just a quick question.

I'm learning to use SWING at the moment and going through Head 1st. While doing this I noticed from the API docs that at least some of the SWING classes are marked with a couple of warnings viz:

for JFrame;

Warning: Swing is not thread safe......



and

Warning: Serialized objects of this class will not be compatible with future Swing releases.......



This rang alarm bells with me because you don't want to be designing something that won't be forward compatible do you now?

So what does this all mean?

I'm not overly concerned about the thread safe warning at the moment as I've not really learnt enough about that topic yet to comment but the warning about serialisation worries me a bit as JFrame is a class I would use a lot I would think.

Does this mean that at some time in the future there will be some other way of serialising these types of classes or is it that it's just not appropriate to serialise them anyway?

If anyone can throw some light onto the implications of these warnings I would be grateful.

Thanks and regards,
Phil.
 
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think this topic will sit better in the Swing forum, so I shall move it . . .

Those warnings are actually found on the API for every Swing class I have ever used, so I think it is there for them all. What it means is that serialisation should only be used for sending them across a network or short-term storage. But how often do you want to store a Frame or send it across a network? You often store objects representing the data to go with a Swing GUI, but that is something different. There is the Beans framework which can also be used to store objects, which is what you are supposed to use for Swing, but I know little about it myself. So you don't need to worry that your objects will somehow become obsolete; in fact Sun have taken great pains to maintain backward compatibility for older versions of Java.

The warning about thread-safety is more serious; it means that everything which affects any of your GUI components must be coded on the same thread. If you just code it in the classes as usual and don't do anything like creating a new Thread, or a new Runnable, then it will all be on the same thread.
So as to ensure you are on the event despatch thread (EDT) there is a special invocation, whereby your entire GUI is inside a single Runnable. There are two examples on the API; where you found the warning there is a link marked "Swing Threading Policy" or similar, where you will find two examples of starting GUIs with invokeLater() and also the correct spelling of EDT.

Hope that helps for a start, and that you get more answers on the other forum.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Campbell is right on the mark on both counts; I'll just add a little more perspective.

The serialization message is about the binary serialization (using ObjectOutputStream and its related classes); the message actually says that the text-based serialization (using javax.beans.XMLEncoder) is good for the long term. But, serializing Swing components either short term or long term is not something one needs to do frequently, and quite possibly not at all.

As an aside, the binary serialization format is generally not compatible between JDK versions, and that's true for many Java classes, not just the Swing classes. That means serializing something using JDK 1.5.0_13 and trying to deserialize with anything other than that exact version may cause problems.

As to multi-threading: yes, you need to take care not to update a Swing GUI from several threads in parallel, but that's true for just about all GUI frameworks, be they Java-based or native. Attempts at creating truly multi-threaded GUI frameworks have been made, but run into serious problems, and then abandoned.
 
Phil Hopgood
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Campbell, Ulf,

Really interesting stuff - how sad!

Especially about serialising/de-serialising using different versions. One to watch out for.

Thanks and regards,
Phil.
 
Campbell Ritchie
Marshal
Posts: 79153
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Phil Hopgood:
Thanks Campbell, Ulf,

Really interesting stuff - how sad!

Especially about serialising/de-serialising using different versions. One to watch out for.

You're welcome.

Have a look around for details of the serial version unique identifier (SUID); there is a bit about it (and its correct name) in the Serializable documentation. It is a number put into the class when it is created, such that a different version of a class can (or can't) deserialise objects.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic