Hi Benchao Li, thanks for giving me more details like the java version,
I compiled with 1.8.0_371-b11 on macos x64 (emulated) and I was still able to transform the classfile. The bug must come from something else. Was this compiled on your personal machine? Was it on windows/linux/mac? What's the processor architecture? 1.35.0 also pases the transformation and the same piece of code is there. How was 1.35.0 released? Thanks! On Thu, Nov 23, 2023 at 9:59 PM Benchao Li <[email protected]> wrote: > Guillaume, > > The binary release are always compiled with JDK8, this is a required > procedure[1]. > > For 1.36.0, the JDK version I'm using is: > $ java -version > java version "1.8.0_371" > Java(TM) SE Runtime Environment (build 1.8.0_371-b11) > Java HotSpot(TM) 64-Bit Server VM (build 25.371-b11, mixed mode) > > [1] https://calcite.apache.org/docs/howto.html#making-a-release-candidate > > Guillaume Masse <[email protected]> 于2023年11月24日周五 > 07:22写道： > > > > Hi all, > > > > We recently upgraded to calcite 1.36.0 and it broke our deployment > process. > > We are using java asm <https://asm.ow2.io/> to shade (rename packages > from > > the bytecode) since there are multiple dependencies clash when using with > > Apache Spark. For example, Apache Spark is using a much older version of > > guava. If I build calcite locally with Java Correto 17.0.7-amzn I can > > transform calcite's bytecode without any problem. Where can I find the > java > > version used to compiled calcite? Is there a process in place to have a > > consistent java version? > > > > https://gitlab.ow2.org/asm/asm/-/issues/318008 > > > > > > -- > > Guillaume Massé > > [Gee-OHM] > > (马赛卫) > > > > -- > > Best, > Benchao Li >
