[lworld] RFR: 8373825: [lworld] ForwardingFileManager always closes its delegate leading to ClosedFileSystemException in TestOriginatingElements [v4]

[Jan Lahoda]

On Wed, 17 Dec 2025 11:05:35 GMT, David Beaumont <duke at openjdk.org> 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