RFR: 8366455: Move VarHandles.GuardMethodGenerator to execute on build

[Erik Joelsson]

On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, java.lang.invoke.VarHandles$GuardMethodGenerator is in a weird state: when VarHandleGuards needs to be updated, we uncomment it, build JDK, run it as a main class, and paste the generated VarHandleGuards class.
> 
> This process is complex and error-prone, and having a huge chunk of commented out code is not good for maintenance and verification too.
> 
> Looking at how i18n and charsets generate, we can move this generator to the build system, and have VarHandleGuards completely automatically generated like the other VarHandle implementation classes or CharacterData.
> 
> <details>
> <summary>
> Diff from new to old (backwards):
> </summary>
> 
> 
> liach at liach-Precision-5690:~$ git diff --no-index /home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java /home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> diff --git a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> index 13ef65b..49408a2 100644
> --- a/home/liach/java/jdk-5/build/linux-x64/support/gensrc/java.base/java/lang/invoke/VarHandleGuards.java
> +++ b/home/liach/java/jdk/open/src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java
> @@ -28,8 +28,7 @@ import jdk.internal.vm.annotation.AOTSafeClassInitializer;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.Hidden;
>  
> -// This file is generated by build.tools.methodhandle.VarHandleGuardMethodGenerator.
> -// Do not edit!
> +// This class is auto-generated by java.lang.invoke.VarHandles$GuardMethodGenerator. Do not edit.
>  @AOTSafeClassInitializer
>  final class VarHandleGuards {
>  
> 
> 
> </details>
> 
> Testing: java/lang/invoke.

I'm not familiar with this code generation step, but I could imagine that it was done the way it was because it needed to run in the just built JDK rather than the boot JDK. If that is the case, then this patch won't work as it will run the code generator in the boot JDK. So my question is, does this generator rely in any way on current JDK N classes to do the work correctly?

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

PR Review: https://git.openjdk.org/jdk/pull/27009#pullrequestreview-3169876731