On Fri, 29 Aug 2025 19:13:27 GMT, Chen Liang <li...@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@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

Reply via email to