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. >
