[
https://issues.apache.org/jira/browse/FLINK-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670492#comment-15670492
]
ASF GitHub Bot commented on FLINK-5067:
---------------------------------------
Github user StephanEwen commented on a diff in the pull request:
https://github.com/apache/flink/pull/2804#discussion_r88242410
--- Diff: pom.xml ---
@@ -96,7 +96,7 @@ under the License.
<slf4j.version>1.7.7</slf4j.version>
<guava.version>18.0</guava.version>
<akka.version>2.3.7</akka.version>
- <java.version>1.7</java.version>
+ <java.minor.version>1.7</java.minor.version>
--- End diff --
Does this make a difference, or is that mainly a naming preference?
It it is only about naming, I would prefer to undo this change.
Call it "being conservative" with `pom.xml` changes - they have subtle
implication son release scripts, etc.
> Make Flink compile with 1.8 Java compiler
> -----------------------------------------
>
> Key: FLINK-5067
> URL: https://issues.apache.org/jira/browse/FLINK-5067
> Project: Flink
> Issue Type: Improvement
> Components: Build System
> Affects Versions: 1.2.0
> Environment: macOS Sierra 10.12.1, java version "1.8.0_112", Apache
> Maven 3.3.9
> Reporter: Andrey Melentyev
> Priority: Minor
>
> Flink fails to compile when using 1.8 as source and target in Maven. There
> are two types of issue that are both related to the new type inference rules:
> * Call to TypeSerializer.copy method in TupleSerializer.java:112 now resolves
> to a different overload than before causing a compilation error: [ERROR]
> /Users/andrey.melentyev/Dev/github.com/apache/flink/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
> * A number of unit tests using assertEquals fail to compile:
> [ERROR]
> /Users/andrey.melentyev/Dev/github.com/apache/flink/flink-java/src/test/java/org/apache/flink/api/common/operators/CollectionExecutionAccumulatorsTest.java:[50,25]
> reference to assertEquals is ambiguous
> [ERROR] both method assertEquals(long,long) in org.junit.Assert and method
> assertEquals(java.lang.Object,java.lang.Object) in org.junit.Assert match
> In both of the above scenarios explicitly casting one of the arguments helps
> the compiler to resolve overloaded method call correctly.
> It is possible to maintain Flink's code base in a state when it can be built
> by both 1.7 and 1.8. For this purpose we need minor code fixes and an
> automated build in Travis to keep the new good state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
