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? 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). >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>> >>> >
