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

[David Beaumont]

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

Actually the more I think about it, the more I'm convinced it's a better API if the forwarding class knows whether to close or not. The reasoning is this:

* There is only one correct answer to "should be delegate be closed or not", *there is no safe default*.
* The existing code assumes a behaviour which could lead to hard-to-debug bugs.
* By adding a new constructor, the question of lifetime ownership becomes visible to people using the class.

While it's not a forcing function (the other constructor with original behaviour must still exist), there's more chance users encountering the class for the first time will think about the issue, compared to having to just remember that lifetime ownership is a thing and what the forwarding class does.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1810#issuecomment-3665745443