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

[Prasanta Sadhukhan]

On Thu, 8 Jan 2026 00:33:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Component count leakage fix
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 5965:
> 
>> 5963:         throws IOException, ClassNotFoundException
>> 5964:     {
>> 5965:         this.removeAll();
> 
> This will remove all children from the JTable, including those added by the app.

This is done before deserialization process kicks in via readFields() so JTable is not reconstructed yet from serialized object, so I think it's alright to do this at this step to remove the rogue components not cleaned up.

There doesn't seem to be good way to prevent this without this `removeAll` call and I didn't see any issue with our JTable CI tests. If a testcase be provided showing it is affecting apps, we can take a look but at the meantime this is the only fix for leakage count. 

Basically, To make the fields of GenericEditor to not participate in serialization process as was the ask earlier, it is made an Externalizable class. 
By definition, Externalizable objects are reconstructed by calling the public no-arg constructor first, followed by the readExternal method. Since GenericEditor is still a serializable class, the no-arg constructor of GenericEditor is called from readObject and since the constructor contains "new JTextField()" a new JTextField component is created every time it is reconstructed which is seen incrementing in getComponentCount()

I tried passing JTextField object to GenericEditor from JTable when editor is created but that has other issues and I did not want to jeopardise normal operation for serialization corner case fix..
If you can provide any other suggestion for a fix, I will see on that..

Alternatively, we can just fix the serialization exception issue as mentioned in the JBS report and 
handle this leakage issue separately which anyway has not been complained of since Java inception

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2675065910