Any progress on this? What is the proposed way to validate if users are still interested on Java 7? A vote on user or something different?
On Wed, Sep 27, 2017 at 7:59 PM, Kenneth Knowles <k...@google.com.invalid> wrote: > 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 >>
