getting ready for ASM 6.2

[Remi Forax]

Hi Vicente,
nice to see the integration of ASM to be fully automated.

I've nothing to add :)

Rémi

----- Mail original -----
> De: "Vicente Romero" <vicente.romero at oracle.com>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Vendredi 27 Juillet 2018 23:54:53
> Objet: getting ready for ASM 6.2

> Hi all,
> 
> Now that the integration of the, still experimental, ASM 6.2 version
> into the JDK seems to be closer; I decided to give it a try to see what
> it would take to do it for real when the time comes. Below some notes
> about the process I followed.
> 
> Some commands to warm-up:
> 
> # creating a dir to hold all what we need:
> mkdir asm-to-jdk
> cd asm-to-jdk
> 
> #cloning ASM:
> git clone http://gitlab.ow2.org/asm/asm.git asm
> cd asm
> cd ..
> 
> #cloning the jdk
> hg clone http://hg.openjdk.java.net/jdk/jdk jdk_open
> cd jdk_open
> # I nuked the current copy of ASM
> rm -rf src/java.base/share/classes/jdk/internal/org/objectweb/asm
> cd ..
> 
> # now cloning some tools to adapt the copyright and package names from
> the ASM format to JDK
> hg clone http://closedjdk.us.oracle.com/code-tools/langtools code-tools
> cd code-tools
> hg pull -u
> cd AsmToJdk/
> export JAVA_HOME=/path/to/jdk1.11.0
> /path/to/apache-ant/bin/ant clean all
> bash ./do-asm.sh ../../asm/ ../../jdk_open/src/
> 
> now it started the interesting path, the asm version I obtained after
> invoking the do-asm.sh tool still had many differences, apart from the
> expected ones of course, when compared with the expected format. So I
> started modifying the tool to improve the copyright and to obtain a four
> spaces indentation instead of the two spaces one used by ASM. I redid
> the last step several times till I obtained sources that won't need a
> manual merge to match the JDK format.
> 
> That allowed me to obtain a patch to apply on top of JDK. Now with this
> patch I went on and try to obtain a full build of JDK. I realized that
> all the new features are marked deprecated. So I had to go again to
> generated sources, removing whatever deprecated annotation or javadoc
> comment the build was complaining about. After that it was the turn for
> the nasgen tool to complain. After some debug rounds I realized that the
> issue was due to an UnsupportedOperationException due a nasgen not
> setting the ASM_VERSION that understand the experimental features. This
> patch fixed that:
> 
> diff -r be7b04898a1c -r 07c9fb188386
> make/nashorn/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java
> ---
> a/make/nashorn/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java
> Fri Jul 27 10:06:35 2018 -0700
> +++
> b/make/nashorn/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java
> Fri Jul 27 13:57:16 2018 -0700
> @@ -43,7 +43,7 @@
>      /**
>       * ASM version to be used by nasgen tool.
>       */
> -    public static final int ASM_VERSION = Opcodes.ASM5;
> +    public static final int ASM_VERSION = Opcodes.ASM7_EXPERIMENTAL;
> 
>      private static final boolean DEBUG =
> Boolean.getBoolean("nasgen.debug");
> 
> after this the build finished smoothly :) It was a lot of fun, fancy a try?
> 
> Thanks,
> Vicente