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

[Martin Buchholz]

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.

Java Historian recalls many years ago suffering from duplicate maintenance of "atomic mechanics" in these core classes, but never trying to "fix" it because the risk and effort were too high.  At the very least the code duplication makes optimization very easy for the JVM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28464#issuecomment-3579752573