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