ByteBufferCleaner to check Unsafe access in Java 23+

[maxxedev]

In Java 23+, ByteBufferCleaner should check for access to deprecated memory-access methods in sun.misc.Unsafe

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• [] I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Not used
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[garydgregory]

Converting to draft until I can have a closer look, needs clean ups anyway.

[garydgregory]

There are several problems here:

• The build fails
• Using java.lang.management adds a new module dependency which some people will complain about. We could disallow this through Checkstyle but we currently do not.
• It's not clear to me this is the correct implementation since the JEP is just a deprecation.
• There is a bug where clearWritable() is not called.

[maxxedev]

build fails

fixed

* Using `java.lang.management` adds a new module dependency which some people will complain about. We could disallow this through Checkstyle but we currently do not.

we just disable Unsafe access on Java 23+ now

* It's not clear to me this is the correct implementation since the JEP is just a deprecation.

deprecation is for removal. Plus, most users would want the library to not trigger scary warnings.

* There is a bug where `clearWritable()` is not called.

fixed

[garydgregory]

@maxxedev The builds for this PR have been broken since last week.

[maxxedev]

@garydgregory please review again :)

[garydgregory]

Hello @maxxedev,

Thank you for updating this PR.

I don't think this is acceptable as-is because it now violates the write once, run anywhere Java principle: the behavior changes depending on which Java version the application is running on, with no way for the user to control or opt out of that change. I think that is particularly problematic for a deprecated API; the fact that an API is deprecated should not mean its behavior changes depending on the runtime version.

If you'd like to pursue this change further, I suggest making the new behavior explicitly opt-in. That would preserve the existing behavior by default while still allowing users who want the new behavior to enable it.

[maxxedev]

I don't think this is acceptable as-is because it now violates the write once, run anywhere Java principle: the behavior changes depending on which Java version the application is running on [...]. I think that is particularly problematic for a deprecated API; the fact that an API is deprecated should not mean its behavior changes depending on the runtime version.

Right now on JDK23+, this warning is shown:

WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::invokeCleaner has been called by org.apache.commons.io.input.ByteBufferCleaner$Java9Cleaner
WARNING: Please consider reporting this to the maintainers of class org.apache.commons.io.input.ByteBufferCleaner$Java9Cleaner
WARNING: sun.misc.Unsafe::invokeCleaner will be removed in a future release

That's JDK telling the library to change the behavior by not using Unsafe on JDK23+. commons-io library should be a good citizen and automatically follow the suggestion set by JDK.

 
In any case, I added an clean(boolean) flag for users to opt-in or control this behavior.