On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <[email protected]> wrote:
>> The three AtomicXxxFieldUpdater classes (AtomicIntegerFieldUpdater, >> AtomicLongFieldUpdater, and AtomicReferenceFieldUpdater) contain duplicate >> field validation and access checking logic in their constructors and helper >> methods. >> >> This change extracts the common validation and utility methods into a new >> package-private class FieldUpdaterUtil to eliminate code duplication and >> improve maintainability. >> >> Changes: >> - Added new FieldUpdaterUtil class with static utility methods: >> * validateField() - validates field type, volatile, and static checks >> * computeAccessClass() - determines correct class for access checks >> * isSamePackage() - checks if two classes are in same package >> * isAncestor() - checks classloader delegation chain >> >> - Updated AtomicIntegerFieldUpdater to use FieldUpdaterUtil >> * Simplified constructor to use validateField() and computeAccessClass() >> * Removed duplicate isAncestor() and isSamePackage() methods >> >> - Updated AtomicLongFieldUpdater to use FieldUpdaterUtil >> * Simplified constructor to use validateField() and computeAccessClass() >> * Removed duplicate isAncestor() and isSamePackage() methods >> >> - Updated AtomicReferenceFieldUpdater to use FieldUpdaterUtil >> * Simplified constructor to use validateField() and computeAccessClass() >> * Removed duplicate isAncestor() and isSamePackage() methods >> >> Existing tests in test/jdk/java/util/concurrent/tck and >> test/jdk/java/util/concurrent/atomic verify that the refactoring preserves >> the original behavior. > > Steve Armstrong has updated the pull request incrementally with one > additional commit since the last revision: > > Fix try-catch block to not wrap IllegalArgumentException > > The validation exceptions should be thrown directly to the caller, > not wrapped in RuntimeException. Only the field lookup and access > checking code should be in the try-catch block. (Adding this comment here as well as the linked JBS issue) Personally I think this isn't worth the effort—there's little-to-no updates to these classes/APIs and there's no clear benefit in terms of safety and/or performance. My preference here would be to move to deprecate these classes and make sure that it is clearly documented that VarHandle is the intended successor API. Tagging @DougLea and Dr Deprecator @stuart-marks for their input. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3574932660
