Simplify waitForCloseablesToClose() to focus on waiting semantics

[peter-lawrey]

Refactor CloseableUtils.waitForCloseablesToClose(long) so its behaviour matches its name and return type more clearly: it now only waits for tracked closeables to enter the closing state within the given timeout and returns true or false accordingly.

Motivation

waitForCloseablesToClose(long) previously mixed two responsibilities:

• waiting for closeables to close within a timeout
• performing assertion-style validation and exception throwing on unreleased resources

That made the method harder to read and blurred the distinction between it and assertCloseablesClosed(), which is the method intended for strict validation and failure reporting.

This change makes the contract clearer:

• waitForCloseablesToClose(long) is a polling/wait helper
• assertCloseablesClosed() remains the diagnostic/assertion path

Change

The method has been simplified to:

• invoke pending cleanup work up front

  • CleaningThreadLocal.cleanupNonCleaningThreads()
  • BackgroundResourceReleaser.releasePendingResources()

• check whether all tracked ManagedCloseable instances are already closing

• return true once they are

• return false if the timeout expires

• pause briefly between checks rather than re-running assertion-oriented logic

The call in finalize() has also been updated to use the local method directly, improving readability.

What was removed

The previous implementation included behaviour that was more appropriate for assertion/debug flows, including:

• disabling single-threaded checks on AbstractCloseable
• calling throwExceptionIfNotReleased() on ReferenceCountedTracer
• retrying around IllegalStateException

That logic obscured the purpose of the method and overlapped with assertCloseablesClosed().

Behavioural intent

This is primarily a clarity and responsibility-separation change:

• waitForCloseablesToClose(long) now has straightforward wait semantics
• assertCloseablesClosed() remains the place for stronger verification and failure signalling

Benefits

• clearer API intent
• simpler control flow
• easier distinction between “wait and report success/failure” and “assert and diagnose”
• reduced surprise from a boolean-returning method throwing assertion-related failures during polling

Notes

A @see link has been added in both directions to make the relationship between the two methods explicit.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud