On Wed, 17 Dec 2025 11:05:35 GMT, David Beaumont <[email protected]> wrote:
>> Allow users of ForwardingFileManager to specify if the delegate file manager >> should also be closed. >> >> This fixes a use-after-close bug in TestOriginatingElements, where the >> system file manager and wrapping memory file manager have different, nested, >> lifetimes resulting in an early call to close the system file manager when >> the wrapper is closed, causing subsequent legitimate use of the system file >> manager to fail. >> >> This wasn't noticed before now since the system file manager was using the >> singleton JRT file-system in which "close" does nothing. Now it's using a >> properly scoped instance of the JRT file-system which can be closed. >> >> This fix could also probable go straight into mainline as a clone since it >> won't break anything there. > > David Beaumont has updated the pull request incrementally with one additional > commit since the last revision: > > add @since for new method I think the standard way to change behavior for `Forwarning...` classes is to simply override the method in the subclass, and implement whatever logic needed - delegating or not. In this case, subclasses can override the `close` method to do nothing. While I agree the `close` is a little bit special, I am not convinced it is special enough to warrant a field and a new constructor. For `MemoryFileManager`, a new constructor parameter is fine I think - that's a specialized class and not an API. ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1810#issuecomment-3665408186
