Skip to main content

Components, listeners, serializable ... best practices?

20 replies [Last post]
Anonymous

Sorry for the vague subject ... but I'm lost in serializable djungle: as
a relax task I thought I would quickly tackle

JXTable not serializable
https://swingx.dev.java.net/issues/show_bug.cgi?id=349

As it turns out, many parts of swingx (most probably not only
table-related, but didn't dig into) are not serializable: as a naive
approach I added a Serializable tag to whatever blows the example that
comes with the issue .. but it looks endless: IconBorder,
tableHeader.headerListener, columnModel.visibilityListener,
xtable.tableAdapter.

So I'm wondering if that's the best solution (last time I really used
Serialization is eons ago...) An alternative might be to tag the
offending field as transient - but then the readObject might be
responsible for re-wiring?

Any hints?

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mikaelgrev
Offline
Joined: 2006-09-27

Richard,

I'm not sure I'm getting through with the article linked at the top. ;)

If you do as the article suggests you WILL be supporting Serializable just by copy-paste a few (under ten) lines that are just about exactly the same for every class (simple transfer code).

You CAN "la la la" and still support the legacy Serializable/Externalizable. You can change the internals of a serialized object just as you can with XMLEncoder/decoder (since it is actually XMLEncoder that does the serialization).

Wouldn't this be a great solution to without pain move from Serializable to XMLEncoder/decoder?

Or am I way off on this one? We have been using this in production for quite a while now and it is working flawlessly (except for an early bug..).

Cheers,
Mikael

rbair
Offline
Joined: 2003-07-08

> I'm not sure I'm getting through with the article
> linked at the top. ;)

Nah, I just saw the subject and my knee jerked. I haven't had a chance to read the article yet.

mikaelgrev
Offline
Joined: 2006-09-27

I need to run my subject lines through the JavaLobby quality crew i guess..

rbair
Offline
Joined: 2003-07-08

No, not the subject of the article, but of this thread.

mikaelgrev
Offline
Joined: 2006-09-27

Ah...

Well, since I know you read that last proposal by Tor on the JSR-273 expert panel list you might want to bump the priority on that reading.. PersistenceDelegates is the future and we need a way to bridge the gap from Serializable...

tackline
Offline
Joined: 2003-06-19

> There are quite a few of us who think Serializable is
> fundementally flawed by exposing internal state.
> Personally, I'd rather hide my head in the sand
> shouting "la la la" until the problem goes away.

And quite a few with the exact opposite opinion. Persistence is an orthogonal issue to the normal API, and should be treated accordingly. The trouble with most serialisable Java classes is that persistence wasn't thought about, it just sort of happened. Java Beans are evil. (That's not to say that Java serialisation is not fundamentally flawed.)

It's not as if it is an important issue for Swing. Yeah, all the buzz in 1997 was GUI builders creating serialised GUIs. I don't think anyone seriously did even back then. Swing decided to be incompatible every release. 1.5 completely broke (default PL&F) Swing serialisation for untrusted code and nobody noticed for two years. And even then it was the awkward squad who reported it.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6466058

(Fixed in 1.7, to be fixed in 1.5 but not 1.6?)

Vetoing Serializable: You could throw an exception from readObject and writeObject, but that wouldn't be proof against hackers. It may be possible to add a poison pill to serialPersistentFields. I guess you could implement Externalizable and insert a base class without a no-arg constructor, but that would alter the public interface.

Kleopatra

Mikael,

really interesting approach. Not sure if we should go for it in SwingX,
though, don't oversee all the implications, don't like the c&p code
(okay, that's a minor point), you are warning against possible
performance issues yourself.

Anyway, it's an implementation - so I think we can take our time to
understand it (read: I want to understand it completely, you already do
), decide later. We can switch over any time.

Looks like it moves all the dirty details (persisting non-public state
and non-bean "properties" like addXX) into PersistanceDelegates? The
beans package has quite a list of delegates - good place to see what can
go wrong (and the removeProperty in MetaClass reminded me that I had to
reside to a similar trick in a former project ...)

Just curious - you mentioned in the other thread that beans spec will be
enhanced to cover modifications like addXX/removeXX. Would that imply
that most of the speical collection-related PersistanceDelegates are no
longer needed?

Thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

mikaelgrev
Offline
Joined: 2006-09-27

Kleopatra,

The JSR-273 enhancements will only result in getting things like addXxx/removeXxx to be specified in the Bean Spec. This will mean better IDE support for collection properties. Exactly how is debated now in the expert group.

What it will mean (JSR-273) is (probably) that the emphasis on PersistenceDelegates (note that the typical bean doesn't need one at all) for just about everything is raised to a point that if you create beans and properties for beans you WILL also provide PersistenceDelegates. This fact means that a simple C&P (not really, see below) can also make your beans/property objects Serializable without drawbacks.

Serializable is much disliked by everyone and I think this approach is the natural (and only?) way to go.

Also note that it's not really C&P. It's using a utility class to do the persisting. C&P would be pasting all of that utility code into every class..

When it comes to performance there should be no problem. It is normally slower that the default implementation for serializable, but it's like Java is slower than Machine Code. XMLEncoder is a better and more flexible solution that solves a lot more use-cases in a reasonable way. I also think that XMLEncoder has been sped up for 6.0.

If one want to use Serialization for say fast comm between applications you might still go for a custom solution. I which way you wouldn't go with Serializable anyway..

Btw, are you with Sun working for SwingLabs?

Cheers,
Mikael

Kleopatra

Mikael,

actually, I do like your approach - are (should?) there plans to push it
into core jdk? Or more generally: are there plans to drop Serializable
in the long run?

My point is that it doesn't automagically solve the problems we have
with Serializable right now - I (unsuccessfully) tried to use it with
BoundAction which still (but now silently by not writing) barks on
EventHandler which is not Serializable. Probably need a
PersistanceDelegate to solve that. Your approach replaces one bag of
problems with a (possibly smaller) bag of similar problems. There's a
good probability that both bags are due to my ignorance ;-)

A question we (SwingLabs) need to answer is which priority to give to
fix swingx failure to honor Serializable? It's a major flaw of nearly
all JX** - on the other hand: not being Accessible is a major flaw as
well, which we are ignoring, steadily looking into a direction where we
don't see it

> Also note that it's not really C&P. It's using a utility class to do the persisting. C&P would be pasting all of that utility code into every class..
>

Probably wasn't too clear: the c&p I meant was the code in the
serializable which is needed to route the write/readObject via the IOUtil.

> Btw, are you with Sun working for SwingLabs?
>

contracted, working from Europe (mostly Berlin)

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

mikaelgrev
Offline
Joined: 2006-09-27

Kleopatra,

> are (should?) there plans to push it into core jdk? Or more generally: are there plans to drop Serializable in the long run?

I have no idea. Everybody loves to hate Serializable so I guess that something should be done? Even Joshua Bloch think that Serializable should be shunted to some other mechanism and Effective Java is the bible right? ;)

I guess this Serializable thing is for the big guys within Sun to decide how to handle. I'm just providing a possible solution to a known problem.

> Probably wasn't too clear: the c&p I meant was the code in the serializable which is needed to route the write/readObject via the IOUtil.

I understood you. I just don't consider one/two statements in a mandatory method Copy&Paste..

Cheers,
Mikael

coxcu
Offline
Joined: 2003-06-11

Mikael,

That's a great article and a really useful technique.

I've got a few random notes to add to this topic.

- The only really good discussion of java.io.Serialization that I know of is in "Component Development for the Java Platform" by Halloway. Everyone who needs to make a class Serializable should read it.

- XMLEncoder/XMLDecoder are pretty good for their intended purpose. They are based on the assumption that the combination of API and default state will be stable over time. java.io.Serialization is based on persisting internal data representation, which can sometimes be more stable, but rarely is with published supported APIs.

- With java.io.Serialization, it is often a better plan to drop back to data streams and design a format that isn't tied to either the object graph or the classes involved.

- I have some reservations about XMLEncoder/XMLDecoder. There are many outstanding bugs and enhancements. Support for transients isn't adequate. When something goes wrong, the error messages and debugging support are inadequate. A DebuggingXMLDecoder would be really welcome for that. Finally, after looking at the code, there are parts that are really hard to trust. All of these can be fixed, however.

- I have one reservation about the implementation of the technique. It lacks information in the stream about the class version and the XML protocol being used. Perhaps, those things would be wasted space, but we're talking about a tiny amount of space. If they are omitted, then future changes that would be relatively easy become much harder.

- Curt

Kleopatra

note to myself: first read then post

interesting article - need to think about.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

evickroy
Offline
Joined: 2004-07-23

Wow! Very nice article!

Erik

jplemieux
Offline
Joined: 2004-11-05

In a general sense, Serialization and XMLEncoder/XMLDecoder cannot be treated as equivalents.

XMLEncoder/XMLDecoder is only capable of reading/writing the state of an object accessible through the [i][b]public[/b][/i] API.

Serialization, on the other hand, is capable of reading/writing any and all of the [b][i]private[/i][/b] state of an object.

If you choose to ignore this difference you are tacitly affirming that either:

a) it is not necessary to serialize any private state in my objects (i.e. my object can always recreate private state on demand)

b) I will always and forever design my objects without private data (i.e. every piece of state will be publicly accessible)

In the past I have used the Serializable Memento pattern
(http://www.churchillobjects.com/c/14024.html) to maintain a happy balance between

1. preserving the ability to serialize private object state
2. ease of implementation
3. ability to handle future arbitrary changes to the serializable state/public interface of an object

Kleopatra

a quick follow-up: most SwingX components are not serializable (as such
violating super's contract). Filed an issue

https://swingx.dev.java.net/issues/show_bug.cgi?id=423

with CCs to all component owners plus Scott - I think we need help from
core. They must have a good strategy to solve which they might be
willing to share, please :-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

mikaelgrev
Offline
Joined: 2006-09-27

Kleopatra,

When it comes to persisting beans there is a problem. One want to support Serializable yet use XMLEncoder/Decoder (1.4+ long term persistence).

I have a solution that I have written an article about. Basically it is using the XMLEncoder/Decoder as the persistence mechanism for Serializable/Externalizable.

This means that you only need to provide a PersistenceDelegate (or use the default one for JavaBeans) and you have both long term persistence AND legacy support.

You can read the article here:
http://www.javalobby.org/articles/serialization/?source=archives

(I have since enhanced it slightly)

I think that it would be good if this was used in SwingLabs with an option to use for Swing's JComponents in the long term.

We have been using it in the MiG Calendar JavaBean to persist our classes in all major IDEs since the start and we have no problems at all modifying our beans as they grow.

Cheers,
Mikael Grev

Kleopatra

Mikael,

thanks for the pointer. Actually, XMLEncoder/decoder is the reason I
didn't use Serialization for years :-)

But seems like I expressed myself rather poorly: I think that most
(all?) JComponents, at least JTable guarantees to be serializable.
JXTable is not, due to quite a bunch of listeners, helpers, whatever not
being serializable. Now my question is: what's to best approach to make
JXTable satisfy super's contract. Listeners in particular are tricky (as
I seem to faintly remember without hard fact). Core Swing components are
not so much effected, because a) listener are registered by the
uidelegate and the uidelegate is uninstalled during writeObject or b)
they often implement xlistener themselves.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13

Don't have anything useful to add, sorry, does look tricky. I was just wondering if all else fails how you would go about vetoing Serializable on a subclass of JComponent/Serializable ?

- Richard

rbair
Offline
Joined: 2003-07-08

> Don't have anything useful to add, sorry, does look
> tricky. I was just wondering if all else fails how
> you would go about vetoing Serializable on a subclass
> of JComponent/Serializable ?

There are quite a few of us who think Serializable is fundementally flawed by exposing internal state. Personally, I'd rather hide my head in the sand shouting "la la la" until the problem goes away.

Richard

kleopatra
Offline
Joined: 2003-06-11

>
> There are quite a few of us who think Serializable is
> fundementally flawed by exposing internal state.
> Personally, I'd rather hide my head in the sand
> shouting "la la la" until the problem goes away.
>

I deeply regret to have touched that f... bug this morning - there seems to be more to it than I expected. Probably will join you soonj in sand and singing

Jeanette