On Fri, 9 Jan 2026 08:42:44 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. > >> 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
