On Thu, 8 Jan 2026 00:33:39 GMT, Sergey Bylokhov <[email protected]> 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
