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