On Wed, 17 Dec 2025 09:50:04 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:
>
> tidy and restore eagerly removed not-actually-dead code
test/langtools/tools/javac/classfiles/InnerClasses/T8068517.java line 110:
> 108: try (JavaFileManager fm =
> ToolProvider.getSystemJavaCompiler().getStandardFileManager(null, null,
> null)) {
> 109: ToolBox tb = new ToolBox();
> 110: try (var memoryFM1 = new ToolBox.MemoryFileManager(fm,
> false);
I could leave this alone, but it seemed nicer to actually acknowledge that the
file managers are closeable.
test/langtools/tools/lib/toolbox/ToolBox.java line 858:
> 856: * and delegates to a default file manager for input files.
> 857: */
> 858: public MemoryFileManager() {
This is the vast majority of users, they don't care about the delegated
instance and want it closed.
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1810#discussion_r2626408506
PR Review Comment:
https://git.openjdk.org/valhalla/pull/1810#discussion_r2626419184
