To cross build, or not to cross build Ingestion

In #451 we upgraded outright to Java 11 for master / Feast v0.5+. Subsequently in #473 we restored support for v0.3 and v0.4 maintenance branches to be tested on CI with Java 8 (thanks!). I believe that has been broken by later updates to CI scripts, I’ll consider that part of this issue.

The upgrade could pose problems for Feast’s Beam-based Ingestion component. Beam itself does not build with Java 11 yet, and the scope of that issue is only the DirectRunner. Other runners could lag further behind, as for example Spark does not build or run on Java 11 until its version 3.0, which is in preview. Thus I presume Beam’s SparkRunner will not build with Java 11 until a GM Spark release can.

Feast does not support any runners other than GC Dataflow (and DirectRunner), so there may be no immediate issue if these are working so far. But, supporting additional runners—if anticipated (#362)—could be blocked if Ingestion does not remain Java 8-compatible.

I wanted to raise the question of whether we should (cross?) build Ingestion with Java 8 to ensure it remains compatible for awhile longer.

The bug report that follows applies to current status quo, regardless of the question above.

Expected Behavior

1. Feast master gives a helpful error about Java requirement if a developer attempts to build with an older version than is supported.
2. Feast v0.3-branch and v0.4-branch can build & test on CI with Java 8. (Appears fixed by #523 🎉)

Current Behavior

$ jenv version
openjdk64-1.8.0.242 (set by /Users/cmartin/.jenv/version)
$ mvn compile
<SNIP>
[ERROR] Fatal error compiling: invalid flag: --release

This stems from:

https://github.com/gojek/feast/blob/7633912cd8209cece2a21ebe344600342ef1ff9b/pom.xml#L408

because the flag was added to javac in Java 9. Maven Enforcer will catch this, proposed below.

For the second problem, CI fails with:

.prow/scripts/test-end-to-end-batch.sh only supports Debian stretch.
Please change your operating system to use this script.

Steps to reproduce

1. As above demo
2. Submit a PR to v0.3-branch as in #516

Possible Solution

The unhelpful error from Maven would be improved by reverting 190e605, resulting in output like

[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 1.8.0-242 is not in the allowed range [11.0,).

[ERROR] Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed.

For the CI environment problem, restore compatibility of the test scripts with maven:3.6-jdk-8 Docker image. Prow always builds using master versions of scripts & config, I think? Ideally then, ensure a build is run on the maintenance branches when Prow scripts are changed, for as long as those Feast versions are supported.

For the Java 8 matter, a quick test seems to tell me that maven-compiler-plugin can compile select modules in a Reactor build with <release>8</release> while the others compile with 11. So I’m suggesting that it could be straightforward to only build Ingestion for 8, instead of cross-building for two versions and having a more complicated CI matrix. Note then that datatypes-java ought to also build with 8 to be safe.

[ches]

With #518 and #722 I think we have moved on and can close this issue. When the ecosystem appears ready for libraries to require, and for the heavy runtimes of Beam runners to fully support, an LTS Java runtime beyond 8, we can revisit.

While running on Java 11 runtimes has advantages to recommend it, we haven’t heard arguments for compelling gains from building Java 11 bytecode, so I don’t see a justification for cross-compiling two versions of components like Feast Ingestion. For Core and Serving at least, we can enjoy developer comforts like type inference, new additions to the standard library, etc. Modules may earn more merit as time goes on.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.