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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >> >> <[email protected]> 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 >> >> > <[email protected]> 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. >> >> >> >> >> >>
