beam-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Bradshaw <rober...@google.com>
Subject Re: [VOTE] [DISCUSSION] Remove support for Java 7
Date Wed, 18 Oct 2017 15:20:50 GMT
On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré" <jb@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" <iemejia@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. <prabsmails@gmail.com> wrote:
>
>>  +1
>>
>>  On 18 October 2017 at 05:16, Griselda Cuevas <gris@google.com> wrote:
>>
>>>
>>>  +1
>>>
>>>  On 17 October 2017 at 16:36, Robert Bradshaw <robertwb@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 <kirpichov@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 <rdmoore79@gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>
>>>>>>  +1
>>>>>>
>>>>>>  On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi <rangadi@google.com>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>>  +1.
>>>>>>>
>>>>>>>  On Tue, Oct 17, 2017 at 2:11 PM, David McNeill <davemc@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 <iemejia@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).
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>
>>

Mime
View raw message