On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré" <j...@nanthrax.net> 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" <ieme...@gmail.com> 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. <prabsma...@gmail.com> wrote: > >> +1 >> >> On 18 October 2017 at 05:16, Griselda Cuevas <g...@google.com> wrote: >> >>> >>> +1 >>> >>> On 17 October 2017 at 16:36, Robert Bradshaw <rober...@google.com> 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 <kirpic...@google.com> >>>> 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 <rdmoor...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> +1 >>>>>> >>>>>> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi <rang...@google.com> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> +1. >>>>>>> >>>>>>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill <dav...@mcpond.co.nz> >>>>>>> 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 <ieme...@gmail.com> 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). >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> >> >>
