[
https://issues.apache.org/jira/browse/FLINK-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15671666#comment-15671666
]
ASF GitHub Bot commented on FLINK-5067:
---------------------------------------
Github user melentye commented on a diff in the pull request:
https://github.com/apache/flink/pull/2804#discussion_r88332568
--- 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 --
I actually prefer java.version for it's conciseness and I share the
conservative tune in regards to unnecessary pom.xml changes. But in this case I
did it on purpose, long explanation follows.
The java.version is passed by -Djava.version=1.8 argument to mvn which
seems to be Maven-recommended (or even the only one supported) way of
redefining the property from command-line. An inconvenient side-effect is that
this property is then propagated down until the JVM that executes the tests and
causes java.lang.RuntimeException: Unexpected version format: 1.8 at
org.apache.hadoop.hbase.util.ClassSize.<clinit>(ClassSize.java:119) starting in
org.apache.flink.addons.hbase.TableInputFormatITCase (won't bore you with the
complete stack trace). Since this is third party code, we can't really fix it
in Flink source. Therefore I thought to rename the property instead to avoid
the clash.
There's a way to keep the java.version property name as is: we can use a
maven profile to set java.version. In this case when you activate the profile
with -P argument to mvn, the java.version will not be propagated as a system
property to the JVM running the tests and won't cause problems.
I've noticed that there's an existing profile called "jdk8" which sounds
relevant. But it's currently automatically activated if you're running Maven
with Java 8 so that could turn out to be a surprise for the maintainers to
realize that they suddenly are building 1.8 target bytecode. The profile
doesn't do much though so I am questioning if it really needs to be
auto-activated. I think it'll be cleaner to stop auto-activating it and reuse
it for the above purpose. See proposal in the PR update.
> 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)
