On Wed, Oct 18, 2017 at 10:59 AM, Eugene Kirpichov <[email protected]> wrote:
> So far we seem to have unanimous consensus in favor of dropping Java7, and > we seem to also be converging on declaring that this doesn't require > increasing major version - but the discussion has been going on for only a > couple of days and we might not have reached some users. > > Robert - I think it's a great idea to make 2.2 release notes mention that > Beam is considering dropping Java 7 support in 2.3. We could also link to > this thread and encourage people to chime in; and we would need to make the > release notes explain the implications: 1) that people will need to use a > Java 8 compiler 2) if they are running on an on-prem cluster such as Spark > or Flink, they'll need to make sure their cluster runs Java8; for example, > Spark supports Java8 only starting from 1.6. > > We should probably also tweet a link to this thread from the Apache Beam > account. Something like: "Apache Beam is discussing ending Java7 support in > a subsequent release; please chime in on https://lists.apache.org/ > thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@% > 3Cuser.beam.apache.org%3E" > > The Dataflow team can probably poll Dataflow customers in parallel with > this (Dataflow runner per se already supports Java8 - AFAIK the Dataflow > worker runs a Java 8 JVM). > > I'd say if ~2 weeks after 2.2 release notes are out we still have no > voices from people for whom it's a show-stopper, then we should declare > victory and start implementation, targeting 2.3. Perhaps we can already > file an umbrella JIRA for dropping Java7. > > Does this sound reasonable to people? > SGTM Kenn > > On Wed, Oct 18, 2017 at 8:21 AM Robert Bradshaw <[email protected]> > wrote: > >> On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré" <[email protected]> wrote: >> >> What happens for the users using spark 1.5 that run with Java 7 only ? >> >> >> One of the goals of this thread is to tease out such users if any. >> >> To reach a wider audience, maybe the next set of release notes could >> mention that we're considering dropping support for Java 7 in the >> subsequent release. >> >> >> On Oct 18, 2017, at 12:06, "Ismaël Mejía" <[email protected]> wrote: >>> >>> +1 >>> >>> I forgot to vote yesterday, I don't really think this is a change >>> worth requiring a major version of Beam. Just clear information in the >>> site/release notes should make it. Also I am afraid that if we wait >>> until we have enough changes to switch Beam to a new major version the >>> switch to Java 8 will happen too late, probably after Java 8's end of >>> life. And I am not exaggerating, Java 8 is planned to EOL next march >>> 2018! (of course Oracle usually changes this), in any case go go Java >>> 8 ASAP ! >>> >>> >>> On Wed, Oct 18, 2017 at 8:08 AM, Prabeesh K. <[email protected]> wrote: >>> >>>> +1 >>>> >>>> On 18 October 2017 at 05:16, Griselda Cuevas <[email protected]> wrote: >>>> >>>>> >>>>> +1 >>>>> >>>>> On 17 October 2017 at 16:36, Robert Bradshaw <[email protected]> wrote: >>>>> >>>>>> >>>>>> +1 to removing Java 7 support, pending no major user outcry to the >>>>>> contrary. >>>>>> >>>>>> In terms of versioning, I fall into the camp that this isn't >>>>>> sufficiently incompatible to warrant a major version increase. >>>>>> Semantic versioning is all about messaging, and upgrading the major >>>>>> version so soon after GA for such a minor change would IMHO cause more >>>>>> confusion that clarity. Hitting 3.0 should signal a major improvement >>>>>> to Beam itself. >>>>>> >>>>>> On Tue, Oct 17, 2017 at 3:52 PM, Eugene Kirpichov <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> +1 to removing Java 7 support. >>>>>>> >>>>>>> In terms of release 3.0, we can handle this two ways: >>>>>>> - Wait until enough other potentially incompatible changes accumulate, >>>>>>> do >>>>>>> all of them, and call it a "3.0" release, so that 3.0 will truly differ >>>>>>> in a >>>>>>> lot of incompatible and hopefully nice ways from 2.x. This might well >>>>>>> take a >>>>>>> year or so. >>>>>>> - Make a release in which Java 7 support is removed, and call it a >>>>>>> "3.0" >>>>>>> release just to signal the incompatibility, and other potentially >>>>>>> incompatible changes will wait until "4.0" etc. >>>>>>> >>>>>>> I suppose the decision depends on whether we have a lot of other >>>>>>> incompatible changes we would like to do, and whether we have any other >>>>>>> truly great features enabled by those changes, or at least truly great >>>>>>> features justifying increasing the major version number. If we go with >>>>>>> #1, >>>>>>> I'd say, among the current work happening in Beam, portability comes to >>>>>>> mind >>>>>>> as a sufficiently huge milestone, so maybe drop Java 7 in the same >>>>>>> release >>>>>>> that offers a sufficient chunk of the portability work? >>>>>>> >>>>>>> (There's also a third path: declare that dropping Java7 support is not >>>>>>> sufficiently "incompatible" to warrant a major version increase, >>>>>>> because >>>>>>> people don't have to rewrite their code but only switch their compiler >>>>>>> version, and people who already use a Java8 compiler won't even notice. >>>>>>> This >>>>>>> path could perhaps be considered if we had evidence that switching to a >>>>>>> Beam >>>>>>> release without Java7 support would require 0 work for an overwhelming >>>>>>> majority of users) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 17, 2017 at 3:34 PM Randal Moore <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> +1. >>>>>>>>> >>>>>>>>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The final version of Beam that supports Java 7 should be clearly >>>>>>>>>> stated >>>>>>>>>> in the docs, so those stuck on old production infrastructure for >>>>>>>>>> other java >>>>>>>>>> app dependencies know where to stop upgrading. >>>>>>>>>> >>>>>>>>>> David McNeill >>>>>>>>>> 021 721 015 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 18 October 2017 at 05:16, Ismaël Mejía <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We have discussed recently in the developer mailing list about the >>>>>>>>>>> idea of removing support for Java 7 on Beam. There are multiple >>>>>>>>>>> reasons for this: >>>>>>>>>>> >>>>>>>>>>> - Java 7 has not received public updates for almost two years and >>>>>>>>>>> most >>>>>>>>>>> companies are moving / have already moved to Java 8. >>>>>>>>>>> - A good amount of the systems Beam users rely on have decided to >>>>>>>>>>> drop >>>>>>>>>>> Java 7 support, e.g. Spark, Flink, Elasticsearch, even Hadoop plans >>>>>>>>>>> to >>>>>>>>>>> do it on version 3. >>>>>>>>>>> - Most Big data distributions and Cloud managed Spark/Hadoop >>>>>>>>>>> services >>>>>>>>>>> have already moved to Java 8. >>>>>>>>>>> - Recent versions of core libraries Beam uses are moving to be Java >>>>>>>>>>> 8 >>>>>>>>>>> only (or mostly), e.g. Guava, Google Auto, etc. >>>>>>>>>>> - Java 8 has some nice features that can make Beam code nicer e.g. >>>>>>>>>>> lambdas, streams. >>>>>>>>>>> >>>>>>>>>>> Considering that Beam is a ‘recent’ project we expect users to be >>>>>>>>>>> already using Java 8. However we wanted first to ask the opinion of >>>>>>>>>>> the Beam users on this subject. It could be the case that some of >>>>>>>>>>> the >>>>>>>>>>> users are still dealing with some old cluster running on Java 7 or >>>>>>>>>>> have another argument to keep the Java 7 compatibility. >>>>>>>>>>> >>>>>>>>>>> So, please vote: >>>>>>>>>>> +1 Yes, go ahead and move Beam support to Java 8. >>>>>>>>>>> 0 Do whatever you want. I don’t have a preference. >>>>>>>>>>> -1 Please keep Java 7 compatibility (if possible add your argument >>>>>>>>>>> to >>>>>>>>>>> keep supporting for Java 7). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>>> >>
