Hi Chesnay, Ok, so if someone uses a non-LTS version of Java (like 14) then how about simply "pinning" it to the Java 11 compatibility? I'm assuming no one uses Java 9 and/or 10 anymore so I'm ignoring those. Then building with Java 8 will result in Java 8 code. Building with Java 11, 12, 13, 14, ... will result in Java 11 code.
That way the code generated using Java 14 will fail immediately on Java 8 because of a completely incompatible binary format. To me this error would make a lot more sense (I would immediately know what I was doing should not work) than the strange error about the non-existent method. Do you agree? Niels On Tue, Jun 30, 2020 at 1:15 PM Chesnay Schepler <ches...@apache.org> wrote: > > What is the Java version Apache Flink is supposed to work with? > > 8 and 11. Non-LTS Java11+ releases _should work_, but we don't put in > effort to make it as convenient as for LTS releases. As such you have to > manually enable the java11 profile when compiling Flink. > > I set the target version to 11 since IIRC we ran into more errors that > way, ensuring a smoother transition once Java 11 is the default. > > On 30/06/2020 13:01, Niels Basjes wrote: > > Hi, > > > > I have both JDK 8 and 14 on my system and yesterday I ran into this > > exception (I put the info I have in this ticket > > https://issues.apache.org/jira/browse/FLINK-18455 ) : > > > > java.lang.NoSuchMethodError: > > java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; > > > > >From digging around ( > > > https://stackoverflow.com/questions/61267495/exception-in-thread-main-java-lang-nosuchmethoderror-java-nio-bytebuffer-flip > > ) > > it seems this is caused when using JDK 9+ without setting '-release 8' > and > > then running with JDK 8. > > > > Essentially there are two solutions I see a lot: > > 1) Add the -release 8 flag to the compiler > > 2) Use the flaky workaround to cast all problem cases to the superclass > > implementing the method (i.e. cast to java.nio.Buffer) > > > > Looking at the actual Flink code I found that > > > > In a JDK 8 build both source and target are set to Java 8 > > > https://github.com/apache/flink/blob/d735d8cd8e5d9fae5322001099097581822453ae/pom.xml#L109 > > <java.version>1.8</java.version> > > > https://github.com/apache/flink/blob/d735d8cd8e5d9fae5322001099097581822453ae/pom.xml#L115 > > <maven.compiler.source>${java.version}</maven.compiler.source> > > <maven.compiler.target>${java.version}</maven.compiler.target> > > > > In a JDK 11 build a profile is activated that overrides it to Java 11 > > > https://github.com/apache/flink/blob/d735d8cd8e5d9fae5322001099097581822453ae/pom.xml#L938 > > <profile> > > <id>java11</id> > > <activation> > > <jdk>11</jdk> > > > https://github.com/apache/flink/blob/d735d8cd8e5d9fae5322001099097581822453ae/pom.xml#L1004 > > <artifactId>maven-compiler-plugin</artifactId> > > <configuration> > > <source>11</source> > > <target>11</target> > > > > So when building with Java 11 the output classes are Java 11 compatible > > binaries. > > > > However I have Java 14 (and the 'java11' profile is only activated at the > > EXACT version of java 11) so it stays at source and target 1.8 but does > not > > specify the "release 8" setting. ... which causes the problems I see. > > > > Looking at the current build settings I was puzzled a bit and I have this > > main question: > > > > What is the Java version Apache Flink is supposed to work with? > > > > Currently I would expect Java 8. > > > > So what I propose for this problem as a fix is to set source, target and > > release to Java 8 for all compiler versions (i.e. also Java 9, 11, 14, > ...). > > That way you can use any compiler and get the correct results. > > > > I also am curious if that would fix the tests that seem to fail under > Java > > 11. > > > > What do you think is the correct approach for this? > > > > -- Best regards / Met vriendelijke groeten, Niels Basjes
