Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Why does the wrapper exists and why doesn't it override close()? Apparently, this wrapper was introduced to "Attempt to fix memory leak in JarFile class". The memory leak issue was caused by a cha...
Answer
#1: Initial revision
by
Miss Skooter
·
2024-02-05T18:23:50Z (10 months ago)
#### Why does the wrapper exists and why doesn't it override `close()`? Apparently, [this wrapper was introduced](https://github.com/spring-projects/spring-boot/commit/aac367e9c5e40733421716f2edfb3522f3480119) to "Attempt to fix memory leak in JarFile class". The memory leak issue was caused by a change in java 11 that introduced `FinalizableResource` which made it so that [any JarFile implementation that override close() will end up with finalizer based cleanup](https://github.com/spring-projects/spring-boot/issues/22991#issuecomment-675202657). Ultimately, too many JarFile instances are being created, especially given they [used to wrap the `JarFile` in a `JarFile`](https://github.com/spring-projects/spring-boot/commit/aac367e9c5e40733421716f2edfb3522f3480119#diff-4fb8fa007e8483410daf8be17b0b3c21ade3396eba622254f79c6060fef13a1eL269), without ever being cleaned by the garbage collector since `FinalizableResource` doesn't deference it. The simplest way to tackle this was to create a wrapper class that doesn't override `close()` which would be created/returned instead of `JarFile`, essentially working around the problem. #### Why was the `JarFile` wrapped in itself before the wrapper was added? In the question I said the `close()` method in JarFile is never called which made sense since it was never returned. However, it seems `JarFile` is actually exposed through `JarURLConnection.getJarFile()` and therefore may get closed and [run you into trouble](https://github.com/spring-projects/spring-boot/issues/17796). I assume the exposure is intentional since that's not what was changed. My testing missed it, but the point here is that situations definitely exist where it *could* be called. #### Java got rid of problematic code? Well, apparently Java didn't like the change any more than Spring did and `FinalizableResource` [was removed](https://github.com/openjdk/jdk/commit/a655e6b52b3819092c0e874d95e39c124d681381#diff-b6128c3608aaf04e0802af64a2df5bb981e33bf873d41017df2c9ca4e187a545L847) in literally the first java 12 tag: `jdk-12-ga`. I currently use Java 17 and it still does not exist. #### Is the wrapper still necessary? Unclear... It may still be necessary for the same reason `JarFile` was wrapped in itself before. It may not since the language has changed a lot since. Either way, I've learned to be happy with the wrapper and coexist :)