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. I wouldn't expect to see usages of AtomicXxxFieldUpdater in new code. Maybe we should include some examples in the class descriptions to create awareness of VarHandles. It may indeed be time to look at deprecating them too. As regards this PR then it should be very rare to need to touch these classes. Looking at the history, they have rarely need to be touched since they were introduced in JDK 5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3582102370
