Compile for Java 1.8

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Compile for Java 1.8

Alberto Ramón
bash> git Clone
POM> <java.version>1.8</java.version>
bash> java -version ==> java version "1.8.0_111"

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project flink-core: Compilation failure
[ERROR] . . . /flink1.2 _10_Nov/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java:[112,63] incompatible types: void cannot be converted to java.lang.Object


is this Normal ?
(If I put 1.7, there isn't any problem)
Reply | Threaded
Open this post in threaded view
|

Re: Compile for Java 1.8

Andrey Melentyev
Hi Alberto,

it seems that this class is not compatible with Java 8 new type inference rules, more specifically the 1.8 compiler picks a different overloaded method than 1.7.

In TupleSerializer.java:112 the call to TypeSerializer.copy method in Java 7 resolves to 
public abstract T copy(T from, T reuse);
while with Java 8 following the new inference rules (which basically selects the most specific matching method)  the compiler prefers 
public abstract void copy(DataInputView source, DataOutputView target) throws IOException;
and the compilation fails. It's the only place in the production code where this change in the compilation logic seems to cause compile-time errors. There are a few unit tests that fail to pick the correct overloaded method alternative as well.

Since Java 7 is end of life, I think it makes sense to be able to build Flink with Java 8 source/target. If you create a Jira for the compilation issue, I can suggest a PR fixing the compile-time errors and the tests.

Note that you can still use JDK8 to compile Flink without changing the java.version in pom.xml, in this scenario the compiler will not try to use 1.8 language features and the compilation will succeed. You can also run your Flink cluster using the Java 8 runtime.

Andrey

On Sun, Nov 13, 2016 at 12:29 AM, Alberto Ramón <[hidden email]> wrote:
bash> git Clone
POM> <java.version>1.8</java.version>
bash> java -version ==> java version "1.8.0_111"

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project flink-core: Compilation failure
[ERROR] . . . /flink1.2 _10_Nov/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java:[112,63] incompatible types: void cannot be converted to java.lang.Object


is this Normal ?
(If I put 1.7, there isn't any problem)

Reply | Threaded
Open this post in threaded view
|

Re: Compile for Java 1.8

Alberto Ramón
Thanks.
Sounds weird I imagine the Flink team have a road-map to migrate to Java 1.8

 
On "Build From source":
"Flink requires at least Java 7 to build. We recommend using Java 8."


2016-11-13 17:48 GMT+01:00 Andrey Melentyev <[hidden email]>:
Hi Alberto,

it seems that this class is not compatible with Java 8 new type inference rules, more specifically the 1.8 compiler picks a different overloaded method than 1.7.

In TupleSerializer.java:112 the call to TypeSerializer.copy method in Java 7 resolves to 
public abstract T copy(T from, T reuse);
while with Java 8 following the new inference rules (which basically selects the most specific matching method)  the compiler prefers 
public abstract void copy(DataInputView source, DataOutputView target) throws IOException;
and the compilation fails. It's the only place in the production code where this change in the compilation logic seems to cause compile-time errors. There are a few unit tests that fail to pick the correct overloaded method alternative as well.

Since Java 7 is end of life, I think it makes sense to be able to build Flink with Java 8 source/target. If you create a Jira for the compilation issue, I can suggest a PR fixing the compile-time errors and the tests.

Note that you can still use JDK8 to compile Flink without changing the java.version in pom.xml, in this scenario the compiler will not try to use 1.8 language features and the compilation will succeed. You can also run your Flink cluster using the Java 8 runtime.

Andrey

On Sun, Nov 13, 2016 at 12:29 AM, Alberto Ramón <[hidden email]> wrote:
bash> git Clone
POM> <java.version>1.8</java.version>
bash> java -version ==> java version "1.8.0_111"

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project flink-core: Compilation failure
[ERROR] . . . /flink1.2 _10_Nov/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java:[112,63] incompatible types: void cannot be converted to java.lang.Object


is this Normal ?
(If I put 1.7, there isn't any problem)


Reply | Threaded
Open this post in threaded view
|

Re: Compile for Java 1.8

Ufuk Celebi
As far as I know, there were no concrete discussions about this yet. I would not expect it to happen this year, but maybe/probably in the course of next year. We would have to have a release where we explicitly say that this will be the last major release with 1.7 support, so users running old version have some time to prepare for a 1.8 only release.

– Ufuk

On 13 November 2016 at 21:52:17, Alberto Ramón ([hidden email]) wrote:

> Thanks.
> Sounds weird I imagine the Flink team have a road-map to migrate to Java 1.8
>  
>  
> On "Build From source
> ":  
>  
> "Flink requires *at least Java 7* to build. We recommend using Java 8."
>  
>  
> 2016-11-13 17:48 GMT+01:00 Andrey Melentyev :
>  
> > Hi Alberto,
> >
> > it seems that this class is not compatible with Java 8 new type inference
> > rules, more specifically the 1.8 compiler picks a different overloaded
> > method than 1.7.
> >
> > In TupleSerializer.java:112 the call to TypeSerializer.copy method in Java
> > 7 resolves to
> >
> > public abstract T copy(T from, T reuse);
> >
> > while with Java 8 following the new inference rules (which basically
> > selects the most specific matching method) the compiler prefers
> >
> > public abstract void copy(DataInputView source, DataOutputView target) throws  
> IOException;
> >
> > and the compilation fails. It's the only place in the production code
> > where this change in the compilation logic seems to cause compile-time
> > errors. There are a few unit tests that fail to pick the correct overloaded
> > method alternative as well.
> >
> > Since Java 7 is end of life, I think it makes sense to be able to build
> > Flink with Java 8 source/target. If you create a Jira for the compilation
> > issue, I can suggest a PR fixing the compile-time errors and the tests.
> >
> > Note that you can still use JDK8 to compile Flink without changing the
> > java.version in pom.xml, in this scenario the compiler will not try to use
> > 1.8 language features and the compilation will succeed. You can also run
> > your Flink cluster using the Java 8 runtime.
> >
> > Andrey
> >
> > On Sun, Nov 13, 2016 at 12:29 AM, Alberto Ramón > > > wrote:
> >
> >> bash> git Clone
> >> POM> 1.8
> >> bash> java -version ==> java version "1.8.0_111"
> >>
> >>
> >> *Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> >> (default-compile) on project flink-core: Compilation failure[ERROR] . . .
> >> /flink1.2
> >> _10_Nov/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java:[112,63]  
> >> incompatible types: void cannot be converted to java.lang.Object*
> >>
> >> is this Normal ?
> >> (If I put 1.7, there isn't any problem)
> >>
> >
> >
>  

Reply | Threaded
Open this post in threaded view
|

Re: Compile for Java 1.8

Andrey Melentyev
Ufuk, 

do you think it's still worth fixing the build errors and maybe adding a Travis configuration to build and test against 1.8? Or do you think that would introduce too much additional overheads? I mean without deprecating 1.7 support of course.

Andrey

On Mon, Nov 14, 2016 at 10:51 AM, Ufuk Celebi <[hidden email]> wrote:
As far as I know, there were no concrete discussions about this yet. I would not expect it to happen this year, but maybe/probably in the course of next year. We would have to have a release where we explicitly say that this will be the last major release with 1.7 support, so users running old version have some time to prepare for a 1.8 only release.

– Ufuk

On 13 November 2016 at 21:52:17, Alberto Ramón ([hidden email]) wrote:
> Thanks.
> Sounds weird I imagine the Flink team have a road-map to migrate to Java 1.8
>
>
> On "Build From source
> ":
>
> "Flink requires *at least Java 7* to build. We recommend using Java 8."
>
>
> 2016-11-13 17:48 GMT+01:00 Andrey Melentyev :
>
> > Hi Alberto,
> >
> > it seems that this class is not compatible with Java 8 new type inference
> > rules, more specifically the 1.8 compiler picks a different overloaded
> > method than 1.7.
> >
> > In TupleSerializer.java:112 the call to TypeSerializer.copy method in Java
> > 7 resolves to
> >
> > public abstract T copy(T from, T reuse);
> >
> > while with Java 8 following the new inference rules (which basically
> > selects the most specific matching method) the compiler prefers
> >
> > public abstract void copy(DataInputView source, DataOutputView target) throws
> IOException;
> >
> > and the compilation fails. It's the only place in the production code
> > where this change in the compilation logic seems to cause compile-time
> > errors. There are a few unit tests that fail to pick the correct overloaded
> > method alternative as well.
> >
> > Since Java 7 is end of life, I think it makes sense to be able to build
> > Flink with Java 8 source/target. If you create a Jira for the compilation
> > issue, I can suggest a PR fixing the compile-time errors and the tests.
> >
> > Note that you can still use JDK8 to compile Flink without changing the
> > java.version in pom.xml, in this scenario the compiler will not try to use
> > 1.8 language features and the compilation will succeed. You can also run
> > your Flink cluster using the Java 8 runtime.
> >
> > Andrey
> >
> > On Sun, Nov 13, 2016 at 12:29 AM, Alberto Ramón > > > wrote:
> >
> >> bash> git Clone
> >> POM> 1.8
> >> bash> java -version ==> java version "1.8.0_111"
> >>
> >>
> >> *Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> >> (default-compile) on project flink-core: Compilation failure[ERROR] . . .
> >> /flink1.2
> >> _10_Nov/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java:[112,63]
> >> incompatible types: void cannot be converted to java.lang.Object*
> >>
> >> is this Normal ?
> >> (If I put 1.7, there isn't any problem)
> >>
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: Compile for Java 1.8

Ufuk Celebi
Sounds good to me if possible without breaking anything :-)

On 14 November 2016 at 10:57:26, Andrey Melentyev ([hidden email]) wrote:

> Ufuk,
>  
> do you think it's still worth fixing the build errors and maybe adding a
> Travis configuration to build and test against 1.8? Or do you think that
> would introduce too much additional overheads? I mean without deprecating
> 1.7 support of course.
>  
> Andrey
>  
> On Mon, Nov 14, 2016 at 10:51 AM, Ufuk Celebi wrote:
>  
> > As far as I know, there were no concrete discussions about this yet. I
> > would not expect it to happen this year, but maybe/probably in the course
> > of next year. We would have to have a release where we explicitly say that
> > this will be the last major release with 1.7 support, so users running old
> > version have some time to prepare for a 1.8 only release.
> >
> > – Ufuk
> >
> > On 13 November 2016 at 21:52:17, Alberto Ramón ([hidden email])
> > wrote:
> > > Thanks.
> > > Sounds weird I imagine the Flink team have a road-map to migrate to Java
> > 1.8
> > >
> > >
> > > On "Build From source
> > > ":
> > >
> > > "Flink requires *at least Java 7* to build. We recommend using Java 8."
> > >
> > >
> > > 2016-11-13 17:48 GMT+01:00 Andrey Melentyev :
> > >
> > > > Hi Alberto,
> > > >
> > > > it seems that this class is not compatible with Java 8 new type
> > inference
> > > > rules, more specifically the 1.8 compiler picks a different overloaded
> > > > method than 1.7.
> > > >
> > > > In TupleSerializer.java:112 the call to TypeSerializer.copy method in
> > Java
> > > > 7 resolves to
> > > >
> > > > public abstract T copy(T from, T reuse);
> > > >
> > > > while with Java 8 following the new inference rules (which basically
> > > > selects the most specific matching method) the compiler prefers
> > > >
> > > > public abstract void copy(DataInputView source, DataOutputView target)
> > throws
> > > IOException;
> > > >
> > > > and the compilation fails. It's the only place in the production code
> > > > where this change in the compilation logic seems to cause compile-time
> > > > errors. There are a few unit tests that fail to pick the correct
> > overloaded
> > > > method alternative as well.
> > > >
> > > > Since Java 7 is end of life, I think it makes sense to be able to build
> > > > Flink with Java 8 source/target. If you create a Jira for the
> > compilation
> > > > issue, I can suggest a PR fixing the compile-time errors and the tests.
> > > >
> > > > Note that you can still use JDK8 to compile Flink without changing the
> > > > java.version in pom.xml, in this scenario the compiler will not try to
> > use
> > > > 1.8 language features and the compilation will succeed. You can also
> > run
> > > > your Flink cluster using the Java 8 runtime.
> > > >
> > > > Andrey
> > > >
> > > > On Sun, Nov 13, 2016 at 12:29 AM, Alberto Ramón > > > wrote:
> > > >
> > > >> bash> git Clone
> > > >> POM> 1.8
> > > >> bash> java -version ==> java version "1.8.0_111"
> > > >>
> > > >>
> > > >> *Failed to execute goal
> > > >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> > > >> (default-compile) on project flink-core: Compilation failure[ERROR] .
> > . .
> > > >> /flink1.2
> > > >> _10_Nov/flink-core/src/main/java/org/apache/flink/api/
> > java/typeutils/runtime/TupleSerializer.java:[112,63]
> > > >> incompatible types: void cannot be converted to java.lang.Object*
> > > >>
> > > >> is this Normal ?
> > > >> (If I put 1.7, there isn't any problem)
> > > >>
> > > >
> > > >
> > >
> >
> >
>