File handle in SpringBootJoranConfigurator should be closed

[dlwldn30]

What Problem This Solves

SpringBootJoranConfigurator.RequireNewOrMatchingContentFileHandler compares
the logging resources it is about to write against what is already there:

InputStreamSource content = file.getContent();
Assert.state(content != null, "Unable to get file content");
byte[] existingContent = content.getInputStream().readAllBytes();

InputStream.readAllBytes() is documented as "This method does not close the
input stream", and the stream is never assigned to anything, so nothing can
close it afterwards.

During AOT processing the handler is a FileSystemGeneratedFiles.FileSystemFileHandler,
whose content supplier returns new FileSystemResource(path), so this is a real
file handle rather than an in-memory resource. The handler is used for both
generated files (MODEL_RESOURCE_LOCATION and RESOURCE_LOCATION), and
file.exists() is true whenever more than one application context contributes
the same resource.

FileSystemGeneratedFiles itself already uses try-with-resources when it
consumes an InputStreamSource, so this is inconsistent with the code on the
other side of the same interface.

Evidence

Red — fix reverted, test present:

./gradlew :core:spring-boot:test --tests '*SpringBootJoranConfiguratorTests'

SpringBootJoranConfiguratorTests > aotContributionClosesExistingFileContent() FAILED
23 tests completed, 1 failed

java.lang.AssertionError:
Expecting all elements of:
  [AtomicBoolean(false)]
to match given predicate but this element did not:
  AtomicBoolean(false)

The failure is on the close assertion only. The IllegalStateException and
non-empty assertions before it pass, so the handler was invoked and the
comparison ran; only the stream was left open.

Green — same command with the fix applied:

BUILD SUCCESSFUL

Summary

Read the existing content inside a try-with-resources block. InputStream was
already imported, so the production change is three lines.

The test supplies its own GeneratedFiles and a FileHandler whose content
records when its stream is closed, then drives the AOT contribution through
applyTo.

Related

Same leak class as prior cleanups, all merged:

• JarFile is not closed when finding main class from archive #50949 JarFile is not closed when finding main class from archive
• Close FileOutputStream delegate in InspectingOutputStream #50639 Close FileOutputStream delegate in InspectingOutputStream
• Close URLClassLoader in ArchitectureCheck #50626 Close URLClassLoader in ArchitectureCheck

No open PR touches SpringBootJoranConfigurator, no closed PR in the last 200
has, and I found no existing issue for this. The only commits to this file are
the Spring Framework 7.0.6 snapshot upgrade, the nullability annotations and
the directory restructure, none of which touched this method.

Test plan

• Red: aotContributionClosesExistingFileContent fails without the
  production change
• Green: it passes with the fix
• :core:spring-boot:test — 3829 tests, 0 failures, 0 errors, 14 skipped
• checkFormatMain, checkFormatTest, checkstyleMain, checkstyleTest

---

Contributed on behalf of Goatshave.

[snicoll]

Thanks for this PR. I checked out your branch locally to push a few minor tweaks and help get this over the finish line, but my push was rejected with a 403 error.

It looks like the "Allow edits from maintainers" option might be unchecked. You need to enable that. You can find the checkbox on the right-hand sidebar of this PR page, right at the bottom. Let me know once it's checked so I can push those updates. Also, please do not unched it going forward and enable it on the other PR you've submitted.