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

[Phil Race]

On Fri, 9 Jan 2026 08:42:44 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.
>
>> That call simply drops all subcomponents added by the App to the JTable before serialization, right?
> 
> But JTable is not reconstructed yet so I dont think it matters if we remove the object from pre-serialized instance of JTable..It is going to be reconstructed after this call as I see..
> 
> If you see issues then please suggest some alternative..

@prsadhuk @TejeshR13 please look at the proposal.

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

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