Remove SuppressWarnings from NoopLock.java

[damondouglas]

This PR addresses #20507 by removing the @SuppressWarnings annotation from sdks/java/core/src/main/java/org/apache/beam/sdk/util/NoopLock.java.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

[github-actions]

Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment assign set of reviewers

[damondouglas]

assign set of reviewers

[github-actions]

Assigning reviewers. If you would like to opt out of this review, comment assign to next reviewer:

R: @bvolpato for label java.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

[damondouglas]

Run Java PreCommit

[damondouglas]

@kennknowles related to #27416 (comment) and #27416 (comment), I'm thinking we are going to run into a lot of these issues as we clean up a lot of the SupressWarnings. I'm wondering if we should just maintain a like-for-like as much as the original author's intent unless we observe something breaking. What do you think?

[kennknowles]

To your global comment: actually the issue with the repo is that the classes that exist are wrong and the process of fixing the nullness discipline is to make them right. Sometimes that just involves putting on a few annotations. Sometimes it involves refactors or redesigns because the original code cannot be made right.

If we just wanted "like for like" then suppressing warnings on the places where we see warnings would do the trick. But then of course we still have all the same errors in the codebase.

[kennknowles]

In other words, running into these issues and fixing them is the whole point.

[damondouglas]

@kennknowles I chose @MonotonicNonNull here as per the JavaDoc it "Indicates that once the field (or variable) becomes non-null, it never becomes null again." I preferred this over the original @Nullable as the static get method along with the private constructor satisfies this condition.

[damondouglas]

The @NonNull annotation seemed appropriate here given that the returned instance, if null, will always be instantiated.

[kennknowles]

run java precommit

[kennknowles]

I didn't see why it was red but it also has be GC'd

[kennknowles]

The tests were not green. Please do not merge when tests are failing.

[kennknowles]

Even though the failures at https://ci-beam.apache.org/job/beam_PreCommit_Java_Phrase/6182/ are probably not related, please file tickets about the failures and kick the tests to get them green. Merging on red embraces the flakey lifestyle, which we don't want to do.