This is difficult to do since you cannot have multiple jdk activations
for a single profile in maven, and duplicating the entire profile for
all jdk versions isn't an option.
We _maybe_ could invert the behavior such that the Java 11 behavior is
the default, with a JDK 8 profile, but there may be some areas where
this wouldn't work (e.g., adding dependencies in JDK 11), and it may
catch developers off-guard.
On 30/06/2020 17:57, Niels Basjes wrote:
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
<mailto: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
