RFR: 6441373: Editing JTable is not Serializable [v3]

Sergey Bylokhov serb at openjdk.org
Thu Dec 11 07:47:24 UTC 2025


On Thu, 11 Dec 2025 04:42:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> 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


More information about the client-libs-dev mailing list