RFR: 8364544: Extract the checks of AtomicXxxFieldUpdater into a common place [v4]

[Viktor Klang]

On Tue, 25 Nov 2025 04:26:08 GMT, Steve Armstrong <duke at openjdk.org> 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