getting ready for ASM 6.2

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Vicente Romero" <vicente.romero at oracle.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Samedi 28 Juillet 2018 00:04:35
> Objet: Re: getting ready for ASM 6.2

> Does anyone know when the 11 version of ASM will be released?

Hi Brian,
i may have the answer :)

Starting with ASM 6.2, we have changed the way we develop ASM to adapt to the 6 month release cycle,
so ASM 6.2 is fully compatible with JDK 11 but to enable it, users need to ask for the ASM API version ASM7_EXPERIMENTAL and not ASM6.
As usual, once the JDK 11 will be released we will release a version of ASM7 that will use the ASM7 API version.

So currently using ASM 6.2 (or the source from the master*) with the experimental features enable, ASM provides full nestmates, constant dynamic and class preview support.

Using the notion of experimental features (which are marked @Deprecated) allow us to support new JDK feature even if the JDK is not released yet.

see you soon,
Rémi

> 
> On 7/27/2018 5:54 PM, Vicente Romero wrote:
>> 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