JDK-6190713 : Reg: Subclasses of swing components are not serializable
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 5.0,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-11-04
  • Updated: 2010-04-02
  • Resolved: 2004-12-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u2Fixed 6 b14Fixed
Related Reports
Duplicate :  
JDK-6189117 - REGRESSION: JScrollBar does NOT serialize if overridden in JDK 5.0
Relates :  
JDK-4864304 - Improve memory consumption of Swing apps
Description
A subclass of JTextArea or JTextField is not serializable. It is throwing the following exception:

java.io.NotSerializableException: javax.swing.plaf.basic.BasicTextUI$UpdateHandler
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
        at java.io.ObjectOutputStream.access$100(ObjectOutputStream.java:135)
        at java.io.ObjectOutputStream$PutFieldImpl.writeFields(ObjectOutputStream.java:1512)
        at java.io.ObjectOutputStream.writeFields(ObjectOutputStream.java:418)
        at java.awt.Container.writeObject(Container.java:3461)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:890)
        at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1333)
        at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284)
        at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073)
        at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291)
        at SerializeTest.doTest(SerializeTest.java:16)
        at SerializeTest.main(SerializeTest.java:8)

This is a regression in tiger. Reproducible with tiger fcs and mustang builds. It works fine with 1.4.2.

To reproduce:

Run the attached testcase.
###@###.### 11/4/04 13:52 GMT
Comments
EVALUATION java.awt.Component 1.362.1.1 private void doSwingSerialization() { 1.362.1.1 Package swingPackage = Package.getPackage("javax.swing"); 1.362.1.1 // Find the first Swing class. Swing classes MUST be loaded by 1.362.1.1 // the bootstrap class loader, otherwise we don't consider them. 1.362.1.1 Class klass = Component.this.getClass(); 1.362.1.1 while (klass != null && klass.getPackage() != swingPackage && 1.382 klass.getClassLoader() == null) { 1.362.1.1 klass = klass.getSuperclass(); 1.362.1.1 } This method supposed to do something with first parent class from javax.swing package of the component to write. Becuase of klass.getClassLoader() == null check (introduced in delta 1.382 among with more than 400 other changes) it fails to do so. This effectively breaks serialisation for swing component subclasses. Suggested fix: *** /tmp/geta6039 Mon Nov 8 18:16:27 2004 --- Component.java Mon Nov 8 18:16:26 2004 *************** *** 7357,7363 **** // the bootstrap class loader, otherwise we don't consider them. Class klass = Component.this.getClass(); while (klass != null && klass.getPackage() != swingPackage && ! klass.getClassLoader() == null) { klass = klass.getSuperclass(); } while (klass != null && klass.getClassLoader() == null) { --- 7357,7363 ---- // the bootstrap class loader, otherwise we don't consider them. Class klass = Component.this.getClass(); while (klass != null && klass.getPackage() != swingPackage && ! klass.getClassLoader() != null) { klass = klass.getSuperclass(); } while (klass != null && klass.getClassLoader() == null) { ---- Major functionality is broken thus changing priority to 2-High. Reassigning to awt team ###@###.### 2004-11-08 23:22:30 GMT Putback was made in 1.357.2.1. Unfortunately there is no bug id mentioned. ###@###.### 2004-11-09 17:35:52 GMT This was fixed as part of the performance work for Swing: 4864304. The code is trying to find the first class in the swing package, and the second check handles the class loader check. We shouldn't need a class loader check in the first chunk of code. ###@###.### 2004-11-10 00:22:00 GMT The code has been streamlined to loop through classes, looking for first Swing class with a null class loader that overrides compWriteObjectNotify. ###@###.### 2004-11-11 15:12:41 GMT
08-11-2004