3 finalizers in RMI code can be removed, as they do not perform meaningful cleanup.
**`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`** `RegistryContext.finalize()` just calls `close()`. The `close()` method does not perform any cleanup per se, but rather "helps the garbage collector" by setting `environment` and `registry` to `null`. **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.BindingEnumeration`** `BindingEnumeration.finalize()` simply calls `close()` on the `ctx` field, itself a `RegistryContext` (and `close()` just "helps the GC.") **`src/java.rmi/share/classes/sun/rmi/log/LogInputStream`** `LogInputStream` tracks its length with an int field, `length`. If `length` ever becomes == 0, `LogInputStream`'s methods will return without doing anything. The finalizer calls `close()`, which just sets length = 0. By the time a `LogInputStream` becomes unreachable and is finalized, it's a moot point whether length == 0, as no more methods can be called. If anything, this finalizer could cause a bug. If a `LogInputStream` were to became unreachable while a method were still running, the finalizer could set the length to 0 while method code is still running and expecting a length != 0. It's possible that there is a very long standing bug that `close()` should be calling `in.close()`, in which case this evaluation will need to be revisited. ------------- Commit messages: - Remove finalizer from RMI LogInputStream - Remove finalizer from RMI RegistryContext.BindingEnumeration - Remove finalizer from RMI RegistryContext Changes: https://git.openjdk.org/jdk/pull/23406/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8349107 Stats: 20 lines in 2 files changed: 0 ins; 19 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23406/head:pull/23406 PR: https://git.openjdk.org/jdk/pull/23406
