Great that you are also working on this too Daniel and thanks for bringing this subject to the mailing list, I was waiting to my return to office next week, but you did it first :)
Eugene for reference (This is the issue on the migration to Java 9), notice that here the goal is first that beam passes mvn clean install with pure Java 9 (and also add this to jenkins), not to rewrite anything to use the new stuff (e.g. modules): https://issues.apache.org/jira/browse/BEAM-2530 Eugene can you also PTAL at the AutoValue issue, more details on the issue, this is a warning so I don't know if it is really critical in particular because we are not using Memoization (do we?). https://github.com/google/auto/issues/503 https://github.com/google/auto/commit/71514081f2ca6fb4ead2b7f0a25f5d02247b8532 Wouldn't the easiest way be that you guys convince the google.auto guys to generate that simple fix in a Java 7 compatible way and 'voila' ? However I agree that moving to Java 8 is an excellent idea and as Eugene mentions there is less friction now since most projects are moving, only pending issue are existing clusters on java 7 in the hadoop world, but those are less frequent now. Anyway this discussion is really important (maybe even worth a vote). Because moving to Java 8 will allow us also to move some of the dependencies that we are keeping in old versions and in general to move forward. What do the others think ? On Tue, Sep 26, 2017 at 11:09 PM, Eugene Kirpichov <kirpic...@google.com.invalid> wrote: > Very excited to hear that there's work on JDK9 support - is there a public > description of the plans for this work somewhere? > > In general, Beam could probably drop Java7 support altogether at some point > soon: Java7 has reached end-of-life (i.e. it's not receiving even security > patches) 2 years ago, and all major players in the data processing > ecosystem have dropped Java7 support (Spark, Flink, Hadoop), so I presume > the demand for Java7 support in the data processing industry is low. By the > way: would a Java8 migration be in the scope of your work in general? > > However, until we say that Beam requires Java8, what would be the > implications of using a version of AutoValue that can only be compiled with > Java8? Are you saying that this is simply a matter of a compiler bug, and > if we use a Java8 compiler but configured to use source and target versions > of 1.7 and using bootclasspath of rt.jar from 1.7, then the resulting Beam > artifacts will be usable by people who don't have Java8? > > On Tue, Sep 26, 2017 at 1:53 PM Daniel Oliveira > <danolive...@google.com.invalid> wrote: > >> So I've been working on JDK 9 support for Beam, and I have a bug in >> AutoValue that can be fixed by updating our AutoValue dependency to the >> latest. The problem is that AutoValue from 1.5+ seems to be banned for Beam >> due to requiring Java 8 compilers. However, it should still be possible to >> compile and execute Java 7 code from the Java 8 compiler by building with >> the correct arguments. So the fix to this bug would essentially require >> Java 8 compilers even for compiling Java 7 code. >> >> Does anyone need to use Java 7 compilers? Because if not I would like to >> continue with this fix. >>
