Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Kenneth Knowles]

On Wed, Oct 18, 2017 at 10:59 AM, Eugene Kirpichov 
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 
> wrote:
>
>> On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré"  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"  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.  wrote:
>>>
  +1

  On 18 October 2017 at 05:16, Griselda Cuevas  wrote:

>
>  +1
>
>  On 17 October 2017 at 16:36, Robert Bradshaw  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 
>>  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 

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Eugene Kirpichov]

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  wrote:

> On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré"  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"  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.  wrote:
>>
>>>  +1
>>>
>>>  On 18 October 2017 at 05:16, Griselda Cuevas  wrote:
>>>

  +1

  On 17 October 2017 at 16:36, Robert Bradshaw  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 
>  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 

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Robert Bradshaw]

On Oct 18, 2017 3:25 AM, "Jean-Baptiste Onofré"  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"  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.  wrote:
>
>>  +1
>>
>>  On 18 October 2017 at 05:16, Griselda Cuevas  wrote:
>>
>>>
>>>  +1
>>>
>>>  On 17 October 2017 at 16:36, Robert Bradshaw  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 
  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 
>  wrote:
>
>>
>>  +1
>>
>>  On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi 
>>  wrote:
>>
>>>
>>>  +1.
>>>
>>>  On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
>>>  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  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
>  

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Neville Dipale]

+1

On 18 October 2017 at 16:00, Ismaël Mejía  wrote:

> Small correction EOL of Java 8 is Sep. 2018 not Mar. 2018.
> http://www.oracle.com/technetwork/java/eol-135779.html
>
> JB the goal of this thread is to get an opinion from the users of all
> the runners on their opinions/constraints, but we have to reach some
> consensus and deal with the tradeoffs of existing users vs the future
> of the project. So far we don't have many reports from users on Spark
> 1.5 or more important from people constrained by the need of Java 7
> support, but we need to wait and see before taking a decision.
>
>
> On Wed, Oct 18, 2017 at 12:59 PM, Srinivas Reddy
>  wrote:
> > +1
> >
> > -
> > Srinivas
> >
> > - Typed on tiny keys. pls ignore typos.{mobile app}
> >
> > On 17-Oct-2017 9:47 PM, "Ismaël Mejía"  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).
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Ismaël Mejía]

Small correction EOL of Java 8 is Sep. 2018 not Mar. 2018.
http://www.oracle.com/technetwork/java/eol-135779.html

JB the goal of this thread is to get an opinion from the users of all
the runners on their opinions/constraints, but we have to reach some
consensus and deal with the tradeoffs of existing users vs the future
of the project. So far we don't have many reports from users on Spark
1.5 or more important from people constrained by the need of Java 7
support, but we need to wait and see before taking a decision.


On Wed, Oct 18, 2017 at 12:59 PM, Srinivas Reddy
 wrote:
> +1
>
> -
> Srinivas
>
> - Typed on tiny keys. pls ignore typos.{mobile app}
>
> On 17-Oct-2017 9:47 PM, "Ismaël Mejía"  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).

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Srinivas Reddy]

+1

-
Srinivas

- Typed on tiny keys. pls ignore typos.{mobile app}

On 17-Oct-2017 9:47 PM, "Ismaël Mejía"  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).
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Jean-Baptiste Onofré]

What happens for the users using spark 1.5 that run with Java 7 only ?

On Oct 18, 2017, 12:06, at 12:06, "Ismaël Mejía"  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. 
>wrote:
>> +1
>>
>> On 18 October 2017 at 05:16, Griselda Cuevas  wrote:
>>>
>>> +1
>>>
>>> On 17 October 2017 at 16:36, Robert Bradshaw 
>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
>
 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
>
 > wrote:
 >>
 >> +1
 >>
 >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi
>
 >> wrote:
 >>>
 >>> +1.
 >>>
 >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill
>
 >>> 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 
>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.
 >
 > 

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Ismaël Mejía]

+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.  wrote:
> +1
>
> On 18 October 2017 at 05:16, Griselda Cuevas  wrote:
>>
>> +1
>>
>> On 17 October 2017 at 16:36, Robert Bradshaw  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 
>>> 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 
>>> > wrote:
>>> >>
>>> >> +1
>>> >>
>>> >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi 
>>> >> wrote:
>>> >>>
>>> >>> +1.
>>> >>>
>>> >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
>>> >>> 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  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 

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Prabeesh K.]

+1

On 18 October 2017 at 05:16, Griselda Cuevas  wrote:

> +1
>
> On 17 October 2017 at 16:36, Robert Bradshaw  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 
>> 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 
>> wrote:
>> >>
>> >> +1
>> >>
>> >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi 
>> wrote:
>> >>>
>> >>> +1.
>> >>>
>> >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
>> >>> 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  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).
>> 
>> 
>> >>>
>> >
>>
>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Griselda Cuevas]

+1

On 17 October 2017 at 16:36, Robert Bradshaw  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 
> 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 
> wrote:
> >>
> >> +1
> >>
> >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi 
> wrote:
> >>>
> >>> +1.
> >>>
> >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
> >>> 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  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).
> 
> 
> >>>
> >
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Eugene Kirpichov]

+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  wrote:

> +1
>
> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi  wrote:
>
>> +1.
>>
>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
>> 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  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).

>>>
>>>
>>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Randal Moore]

+1

On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi  wrote:

> +1.
>
> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill 
> 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  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).
>>>
>>
>>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Raghu Angadi]

+1.

On Tue, Oct 17, 2017 at 2:11 PM, David McNeill  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  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).
>>
>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[David McNeill]

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

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Wayne Collins]

+1

(snip):

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

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Vilhelm von Ehrenheim]

+1

On Tue, Oct 17, 2017 at 8:22 PM, Thomas Groh  wrote:

> I'm pretty strongly in favor of phasing out Java7 support, especially
> given that it was EoL'd more than two years ago. However, I'm not sure how
> this interacts with the repository's backwards-compatibility guarantees
> (given that this *is* an immediately breaking change for any Java 7
> user).
>
> On Tue, Oct 17, 2017 at 9:52 AM, Henning Rohde  wrote:
>
>> +1
>>
>> On Tue, Oct 17, 2017 at 9:47 AM, Jean-Baptiste Onofré 
>> wrote:
>>
>>> However, it's good to target this for Beam 3.0.0 as it can have an
>>> impact especially for runners.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 10/17/2017 06:45 PM, Jean-Baptiste Onofré wrote:
>>>
 +1 from a general purpose.

 +0 from a runner perspective (as it depends of the execution engine).

 Regards
 JB

 On 10/17/2017 06:16 PM, Ismaël Mejía 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).
>
>

>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Rune Fevang]

+1

On Tue, Oct 17, 2017 at 6:52 PM, Henning Rohde  wrote:

> +1
>
> On Tue, Oct 17, 2017 at 9:47 AM, Jean-Baptiste Onofré 
> wrote:
>
>> However, it's good to target this for Beam 3.0.0 as it can have an impact
>> especially for runners.
>>
>> Regards
>> JB
>>
>>
>> On 10/17/2017 06:45 PM, Jean-Baptiste Onofré wrote:
>>
>>> +1 from a general purpose.
>>>
>>> +0 from a runner perspective (as it depends of the execution engine).
>>>
>>> Regards
>>> JB
>>>
>>> On 10/17/2017 06:16 PM, Ismaël Mejía 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).


>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Yihua Fang]

+1
On Tue, Oct 17, 2017 at 9:38 AM Steve Anderson  wrote:

> +1
>
> Sent from my iPhone
>
> On Oct 17, 2017, at 09:31, Aleksandr  wrote:
>
> +1
>
> 17. okt 2017 7:17 PM kirjutas kuupäeval "Ismaël Mejía"  >:
>
> 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).
>
>
>

Re: [VOTE] [DISCUSSION] Remove support for Java 7

[Aleksandr]

+1

17. okt 2017 7:17 PM kirjutas kuupäeval "Ismaël Mejía" :

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