Agree with polling Beam users as well as each runner's community in aggregate.
On Wed, Sep 27, 2017 at 9:44 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Definitely agree > > > On 09/27/2017 06:00 PM, Robert Bradshaw 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. >>>>>>>> >>>>>>>> >>>>>> >>>> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
