I would support this as well, however we probably should first poll current users of the Beam API to see if any of them rely on Java 7.
Reuven On Wed, Sep 27, 2017 at 9:00 AM, Robert Bradshaw < rober...@google.com.invalid> wrote: > I also think that it's time to seriously consider dropping support for > Java 7. > > On Tue, Sep 26, 2017 at 9:14 PM, Daniel Oliveira > <danolive...@google.com.invalid> wrote: > > Yes, just as Ismaël said it's a compilation blocker right now despite > that > > (I believe) we don't use the extension that's breaking. > > > > As for other ways to solve this, if there is a way to avoid compiling the > > advanced features of AutoValue that might be worth a try. We could also > try > > to get a release of AutoValue with the fix that works in Java 7. However > I > > feel that slowly moving over to Java 8 is the most future-proof solution > if > > it's possible. > > > > On Tue, Sep 26, 2017 at 2:47 PM, Ismaël Mejía <ieme...@gmail.com> wrote: > > > >> The current issue is that compilation fails on master because beam's > >> parent pom is configured to fail if it finds warnings): > >> > >> <compiler.error.flag>-Werror</compiler.error.flag> > >> > >> However if you remove that line from the parent pom the compilation > passes. > >> > >> Of course this does not mean that everything is solved for Java 9, > >> there are some tests that break and other issues because of other > >> plugins and dependencies (e.g. bytebuddy), but those are not part of > >> this discussion. > >> > >> On Tue, Sep 26, 2017 at 11:38 PM, Eugene Kirpichov > >> <kirpic...@google.com.invalid> wrote: > >> > AFAIK we don't use any advanced capabilities of AutoValue. Does that > mean > >> > this issue is moot? I didn't quite understand from your email whether > it > >> is > >> > a compilation blocker for Beam or not. > >> > > >> > On Tue, Sep 26, 2017 at 2:32 PM Ismaël Mejía <ieme...@gmail.com> > wrote: > >> > > >> >> 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/71514081f2ca6fb4ead2b7f0a25f5d > >> 02247b8532 > >> >> > >> >> 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. > >> >> >> > >> >> > >> >
