RFR: 6441373: Editing JTable is not Serializable [v7]
Sergey Bylokhov
serb at openjdk.org
Fri Jan 9 08:33:22 UTC 2026
On Fri, 9 Jan 2026 06:54:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:
>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.
That call simply drops all subcomponents added by the App to the JTable before serialization, right?
>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
This is not just a memory leak caused by objects being referenced from uncleaned or suspicious places. It is the accumulation of subcomponents in the JTable after deserialization, so JTable just becomes broken.
>I did not want to jeopardise normal operation for serialization corner case fix..
The patch attempts to fix the serialization of the "Editing JTable", but the current version produces a broken object. This is not just a corner case, it is a primary case. Leaving all subcomponents to accumulate is not correct, and deleting all of them is also wrong.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28627#discussion_r2675298095
More information about the client-libs-dev
mailing list