We run spark in AWS EMR and it overrides the classpath, so we don't have control over it:
Sparks will pull guava 14.0.1: https://github.com/apache/spark/blob/master/dev/deps/spark-deps-hadoop-3-hive-2.3#L68 That's why we need to shade guava. On Fri, Nov 24, 2023 at 4:31 PM Julian Hyde <[email protected]> wrote: > The version of Guava we compile against is relevant. In 1.35 we > compiled against Guava 19.0; in 1.36 we compiled against Guava > 32.1.3-jre. The effect would be the same if we compiled against any > version of Guava 20.0 or higher, due to the addition of > Preconditions.checkArgument methods that in earlier Guava versions > would be handled by varargs method. > > See https://issues.apache.org/jira/browse/CALCITE-5477 (which was > fixed in 1.35) and https://issues.apache.org/jira/browse/CALCITE-5763 > (which was fixed in 1.36 and essentially reverted 5477). > > Julian > > On Fri, Nov 24, 2023 at 10:20 AM Guillaume Masse > <[email protected]> wrote: > > > > 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 > > > >
