-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
6
-
x86
-
solaris_10
A DESCRIPTION OF THE REQUEST :
After reading bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4337898
where the evaluator makes the excellent observation:
'Ideally serialization would behave like other object oriented methods, you could override and specialize. Lacking this ability leads to ugly hacks like this.'
and running into a multitude of bugs in Swing regarding Serialization, it appears that Swing serialization:
1. Is hard to control.
2. Is easy to break.
One problem that I have noticed is that every swing component has its own writeObject method that essentially is the same:
s.writeObject(values);
if (getUIClassID().equals(uiClassID)) {
byte count = JComponent.getWriteObjCounter(this);
JComponent.setWriteObjCounter(this, --count);
if (count == 0 && ui != null) {
ui.installUI(this);
}
}
Not implementing this code results in swing objects that do not serialize correctly and in some cases will break the running object. Would it not be better to improve this mechanism so that it is only implemented in one place? And would it not be better to allow the user to take control of the process for a particular object?
A simple idea would be to have JComponent implement writeObject and have it delegate to a public method in the JComponent interface:
public void serialize(ObjectOutputStream s);
conversely, they could have readObject delegate to a
public void deserialize(ObjectInputStream s)
method.
A different approach then this would be to allow pluggable serializers. This is the initial approach I have taken for this submission:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=11421
public static abstract class ListSerializer implements Serializable{
/**
* Serialize the <code>List</code>.
*
* @param data the <code>List</code>
* @param s the <code>ObjectOutputStream</code>
* @throw IOException
*/
public abstract void serializeList(List<?> data, ObjectOutputStream s) throws IOException;
/**
* Deserialize the <code>List</code>
*
* @param s the <code>ObjectInputStream</code>
* @return the <code>List</code>
* @throw IOException
* @throw ClassNotFoundException
*/
public abstract List<?> deserializeList(ObjectInputStream s) throws IOException, ClassNotFoundException;
}
It may make sense to make this pluggable in that there will be cases where subclassing is not an option.
JUSTIFICATION :
swing serialization is too tricky and not overridable
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
swing serialization should be simpler
ACTUAL -
its tricky
---------- BEGIN SOURCE ----------
read the source, notice the patterns. Look at the bug database, see the bugs.
---------- END SOURCE ----------
After reading bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4337898
where the evaluator makes the excellent observation:
'Ideally serialization would behave like other object oriented methods, you could override and specialize. Lacking this ability leads to ugly hacks like this.'
and running into a multitude of bugs in Swing regarding Serialization, it appears that Swing serialization:
1. Is hard to control.
2. Is easy to break.
One problem that I have noticed is that every swing component has its own writeObject method that essentially is the same:
s.writeObject(values);
if (getUIClassID().equals(uiClassID)) {
byte count = JComponent.getWriteObjCounter(this);
JComponent.setWriteObjCounter(this, --count);
if (count == 0 && ui != null) {
ui.installUI(this);
}
}
Not implementing this code results in swing objects that do not serialize correctly and in some cases will break the running object. Would it not be better to improve this mechanism so that it is only implemented in one place? And would it not be better to allow the user to take control of the process for a particular object?
A simple idea would be to have JComponent implement writeObject and have it delegate to a public method in the JComponent interface:
public void serialize(ObjectOutputStream s);
conversely, they could have readObject delegate to a
public void deserialize(ObjectInputStream s)
method.
A different approach then this would be to allow pluggable serializers. This is the initial approach I have taken for this submission:
https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=11421
public static abstract class ListSerializer implements Serializable{
/**
* Serialize the <code>List</code>.
*
* @param data the <code>List</code>
* @param s the <code>ObjectOutputStream</code>
* @throw IOException
*/
public abstract void serializeList(List<?> data, ObjectOutputStream s) throws IOException;
/**
* Deserialize the <code>List</code>
*
* @param s the <code>ObjectInputStream</code>
* @return the <code>List</code>
* @throw IOException
* @throw ClassNotFoundException
*/
public abstract List<?> deserializeList(ObjectInputStream s) throws IOException, ClassNotFoundException;
}
It may make sense to make this pluggable in that there will be cases where subclassing is not an option.
JUSTIFICATION :
swing serialization is too tricky and not overridable
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
swing serialization should be simpler
ACTUAL -
its tricky
---------- BEGIN SOURCE ----------
read the source, notice the patterns. Look at the bug database, see the bugs.
---------- END SOURCE ----------