On Thu, 11 Dec 2025 04:42:34 GMT, Prasanta Sadhukhan <[email protected]>
wrote:
> GenericEditor serialization fixed
I guess that empty writeObject/readObject methods will behave the same as
making all fields transient: the reference that triggered the serialization
will point to a newly deserialized object, but all fields will be null.
Does calling super.stopCellEditing() affect the behavior in any way? It
bypasses the stopCellEditing implementation in GenericEditor, and the text
entered in the editor will be lost.
I tried modifying the test to check whether the JTable remains functional, and
it appears to be broken:
Object[][] data = new Object[][]{ new Object[]{ 1,2,3,4,5}};
Object[] names = new Object[]{ 1,2,3,4,5};
JTable jt = new JTable(data, names);
while(true) {
jt.editCellAt(0,3);
JTable newjt = serialize(jt);
// another bug:
// the editorRemover from the original jt is leaked in
KeyboardFocusManager
// so clean it here to avoid memory leak during the loop
// otherwise the OOm is occur, we should clear that somehow
jt.removeEditor();
jt = newjt;
// leak of the GenericEditor/JTextField, the number will grow over time
and will cause OOM
// and it is not possible to clean it after deserialisation we do not
have a refs to it
System.out.println("Count: " + jt.getComponentCount());
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28627#issuecomment-3640656855
