On Fri, 9 Jan 2026 06:54:35 GMT, Prasanta Sadhukhan <[email protected]> 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
