Re: [POLL] Dropping support for Java 7 in Beam 2.3

2018-01-07 Thread Jean-Baptiste Onofré

Agree, good one !

Thanks !
Regards
JB

On 01/08/2018 07:28 AM, Eugene Kirpichov wrote:
1 month has passed since the vote, with <5% votes on Twitter against the switch, 
and votes on this thread only in favor of the switch.


The vote is hence concluded. We can proceed with switching Beam to Java 8. Beam 
2.3 will be Java8-only. Woohoo!


On Thu, Jan 4, 2018 at 4:55 PM Ted Yu > wrote:


+1 on dropping Java 7 support.



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


Re: [POLL] Dropping support for Java 7 in Beam 2.3

2018-01-07 Thread Eugene Kirpichov
1 month has passed since the vote, with <5% votes on Twitter against the
switch, and votes on this thread only in favor of the switch.

The vote is hence concluded. We can proceed with switching Beam to Java 8.
Beam 2.3 will be Java8-only. Woohoo!

On Thu, Jan 4, 2018 at 4:55 PM Ted Yu  wrote:

> +1 on dropping Java 7 support.
>


Re: [POLL] Dropping support for Java 7 in Beam 2.3

2018-01-04 Thread Ted Yu
+1 on dropping Java 7 support.


Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-21 Thread Eugene Kirpichov
FYI the Twitter poll is over, with currently 5% "can't switch" which I
think is in the range of acceptable (particularly because AFAIK twitter
rounds the last poll option up, and others down, to get an exact 100%, so
in reality it's <5%).

I've also looked at some internal Dataflow statistics about usage of Java
versions among jobs using Beam 2.2.0+, and it is overwhelmingly in favor of
Java 8 (Java7 seems to be ~0.1% right now). Beam below 2.2.0 doesn't report
Java version, so the fraction of Java7 users among earlier versions of Beam
on Dataflow may be higher, but probably not 50x higher.

We have 2 more weeks for people to potentially chime in on this thread, and
then, barring strong objections, we can switch!

On Tue, Dec 12, 2017 at 2:50 PM Eugene Kirpichov 
wrote:

> FYI: I took a 5-minute shot at this and quickly discovered that IntelliJ
> does not support setting different language level for tests vs. main code
> of a module, which will be painful to deal with in the IDE (setting module
> level to 7 will make IntelliJ complain about tests; setting to 8 will make
> it miss usages of 8 in main code that are not yet allowed).
>
> I think this might be more trouble than worth - let's just wait for the
> rest of the vote [currently 233 votes, with 4% "can't switch"] and
> hopefully switch the entire project.
>
> On Mon, Dec 11, 2017 at 11:20 AM Jean-Baptiste Onofré 
> wrote:
>
>> Hi Eugene,
>>
>> thanks for the report.
>>
>> I would go to Java 8 language level, starting building tests.
>>
>> Regards
>> JB
>>
>> On 12/11/2017 06:00 PM, Eugene Kirpichov wrote:
>> > Intermediate update: right now it's 219 votes on Twitter (and 0 on this
>> thread:
>> > seems that people find Twitter a more convenient medium!), with 96% who
>> are
>> > either on Java 8 or can easily switch, vs. 4% who can not easily switch.
>> >
>> > Using a proportion confidence interval calculator, so far we're looking
>> at
>> > between 1.9 and 7.7% of users (at 95% confidence) needing Java 7
>> support :)
>> >
>> > Willing users can help gather more votes by RT'ing the poll or chiming
>> in on
>> > this thread!
>> >
>> > So: for now we don't yet have enough confidence that Java 7 support can
>> be
>> > dropped from the SDK (to remind, we'll conclude the vote on January
>> 7th; since
>> > people so overwhelmingly vote on Twitter, we may consider doing 3 more
>> rounds of
>> > the same poll?..), however:
>> > - It may be enough confidence to resolve to *build* the Beam SDK using
>> JDK8 (at
>> > Java 7 source language level), which is something +Ismaël Mejía
>> >  and +Daniel Oliveira
>> >  once requested as part of building
>> Java 9
>> > support. I suspect that the sets "users who need to build their own
>> Beam SDK"
>> > and "users who can not upgrade to Java 8" have a vanishingly small
>> intersection.
>> > - Then, we may consider also start building *tests* at Java 8 language
>> level,
>> > which will give the bulk of the benefit of encouraging Java8-friendly
>> APIs.
>> > Thoughts on the above?
>> >
>> > On Thu, Dec 7, 2017 at 6:22 PM Eugene Kirpichov > > > wrote:
>> >
>> > A Twitter poll has been sent out too
>> > https://twitter.com/ApacheBeam/status/938926195910905857
>> > However, due to limitations of Twitter it can only be open for 7
>> days. I
>> > encourage people who are late to the poll to comment on this thread
>> instead.
>> >
>> > On Thu, Dec 7, 2017 at 3:50 PM Eugene Kirpichov <
>> kirpic...@google.com
>> > > wrote:
>> >
>> > Followup: we would like to keep this poll open for 2 weeks,
>> however some
>> > people have expressed concern that this is too short.
>> > Let us keep this poll open for 1 month starting today. So far
>> the
>> > agreed-upon decision has been to move forward with the plan if
>> fewer
>> > than 5% of all respondents choose option 3.
>> >
>> > On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov <
>> kirpic...@google.com
>> > > wrote:
>> >
>> > This is a follow-up on a previous similar thread
>> >
>> https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
>>  in
>> > which the community consistently expressed support for
>> transitioning
>> > Beam Java to Java8-only.
>> >
>> > Now that the release of Beam 2.2.0 has completed, we are
>> considering
>> > performing this change specifically in the immediate next
>> release:
>> > Beam 2.3.0, i.e. dropping support for Java 7 without a bump
>> in the
>> > major version of Beam.
>> >
>> > The reasons for switching to Java 8 in general are
>> considered in the
>> > thread above.
>> > The reasons in favor of making the switch in Beam 2.3.0 are
>> as follows:
>>

Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-12 Thread Eugene Kirpichov
FYI: I took a 5-minute shot at this and quickly discovered that IntelliJ
does not support setting different language level for tests vs. main code
of a module, which will be painful to deal with in the IDE (setting module
level to 7 will make IntelliJ complain about tests; setting to 8 will make
it miss usages of 8 in main code that are not yet allowed).

I think this might be more trouble than worth - let's just wait for the
rest of the vote [currently 233 votes, with 4% "can't switch"] and
hopefully switch the entire project.

On Mon, Dec 11, 2017 at 11:20 AM Jean-Baptiste Onofré 
wrote:

> Hi Eugene,
>
> thanks for the report.
>
> I would go to Java 8 language level, starting building tests.
>
> Regards
> JB
>
> On 12/11/2017 06:00 PM, Eugene Kirpichov wrote:
> > Intermediate update: right now it's 219 votes on Twitter (and 0 on this
> thread:
> > seems that people find Twitter a more convenient medium!), with 96% who
> are
> > either on Java 8 or can easily switch, vs. 4% who can not easily switch.
> >
> > Using a proportion confidence interval calculator, so far we're looking
> at
> > between 1.9 and 7.7% of users (at 95% confidence) needing Java 7 support
> :)
> >
> > Willing users can help gather more votes by RT'ing the poll or chiming
> in on
> > this thread!
> >
> > So: for now we don't yet have enough confidence that Java 7 support can
> be
> > dropped from the SDK (to remind, we'll conclude the vote on January 7th;
> since
> > people so overwhelmingly vote on Twitter, we may consider doing 3 more
> rounds of
> > the same poll?..), however:
> > - It may be enough confidence to resolve to *build* the Beam SDK using
> JDK8 (at
> > Java 7 source language level), which is something +Ismaël Mejía
> >  and +Daniel Oliveira
> >  once requested as part of building Java
> 9
> > support. I suspect that the sets "users who need to build their own Beam
> SDK"
> > and "users who can not upgrade to Java 8" have a vanishingly small
> intersection.
> > - Then, we may consider also start building *tests* at Java 8 language
> level,
> > which will give the bulk of the benefit of encouraging Java8-friendly
> APIs.
> > Thoughts on the above?
> >
> > On Thu, Dec 7, 2017 at 6:22 PM Eugene Kirpichov  > > wrote:
> >
> > A Twitter poll has been sent out too
> > https://twitter.com/ApacheBeam/status/938926195910905857
> > However, due to limitations of Twitter it can only be open for 7
> days. I
> > encourage people who are late to the poll to comment on this thread
> instead.
> >
> > On Thu, Dec 7, 2017 at 3:50 PM Eugene Kirpichov <
> kirpic...@google.com
> > > wrote:
> >
> > Followup: we would like to keep this poll open for 2 weeks,
> however some
> > people have expressed concern that this is too short.
> > Let us keep this poll open for 1 month starting today. So far the
> > agreed-upon decision has been to move forward with the plan if
> fewer
> > than 5% of all respondents choose option 3.
> >
> > On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov <
> kirpic...@google.com
> > > wrote:
> >
> > This is a follow-up on a previous similar thread
> >
> https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
>  in
> > which the community consistently expressed support for
> transitioning
> > Beam Java to Java8-only.
> >
> > Now that the release of Beam 2.2.0 has completed, we are
> considering
> > performing this change specifically in the immediate next
> release:
> > Beam 2.3.0, i.e. dropping support for Java 7 without a bump
> in the
> > major version of Beam.
> >
> > The reasons for switching to Java 8 in general are
> considered in the
> > thread above.
> > The reasons in favor of making the switch in Beam 2.3.0 are
> as follows:
> > - It is believed that usage of Java 7 in production is
> already
> > vanishingly small.
> > - Since Java 7 has not been receiving even security updates
> for
> > years, helping perpetuate its usage would be a bad idea
> > - A major version bump is a major step and would likely
> happen only
> > after a large number of other major changes in Beam
> accumulate -
> > i.e. many months. Maintaining Java 7 compatibility for that
> long
> > would have costs, including the awkward possibility of
> switching
> > Beam to Java 8 after Java 8's end of life (September 2018
> AFAIK)
> > - Updating to Java 8 would lead to Beam more quickly gaining
> more
> > Java8-friendly APIs, because Beam SDK authors and
> contributors would
> > have more liberty, more respon

Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-11 Thread Jean-Baptiste Onofré

Hi Eugene,

thanks for the report.

I would go to Java 8 language level, starting building tests.

Regards
JB

On 12/11/2017 06:00 PM, Eugene Kirpichov wrote:
Intermediate update: right now it's 219 votes on Twitter (and 0 on this thread: 
seems that people find Twitter a more convenient medium!), with 96% who are 
either on Java 8 or can easily switch, vs. 4% who can not easily switch.


Using a proportion confidence interval calculator, so far we're looking at 
between 1.9 and 7.7% of users (at 95% confidence) needing Java 7 support :)


Willing users can help gather more votes by RT'ing the poll or chiming in on 
this thread!


So: for now we don't yet have enough confidence that Java 7 support can be 
dropped from the SDK (to remind, we'll conclude the vote on January 7th; since 
people so overwhelmingly vote on Twitter, we may consider doing 3 more rounds of 
the same poll?..), however:
- It may be enough confidence to resolve to *build* the Beam SDK using JDK8 (at 
Java 7 source language level), which is something +Ismaël Mejía 
 and +Daniel Oliveira 
 once requested as part of building Java 9 
support. I suspect that the sets "users who need to build their own Beam SDK" 
and "users who can not upgrade to Java 8" have a vanishingly small intersection.
- Then, we may consider also start building *tests* at Java 8 language level, 
which will give the bulk of the benefit of encouraging Java8-friendly APIs.

Thoughts on the above?

On Thu, Dec 7, 2017 at 6:22 PM Eugene Kirpichov > wrote:


A Twitter poll has been sent out too
https://twitter.com/ApacheBeam/status/938926195910905857
However, due to limitations of Twitter it can only be open for 7 days. I
encourage people who are late to the poll to comment on this thread instead.

On Thu, Dec 7, 2017 at 3:50 PM Eugene Kirpichov mailto:kirpic...@google.com>> wrote:

Followup: we would like to keep this poll open for 2 weeks, however some
people have expressed concern that this is too short.
Let us keep this poll open for 1 month starting today. So far the
agreed-upon decision has been to move forward with the plan if fewer
than 5% of all respondents choose option 3.

On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov mailto:kirpic...@google.com>> wrote:

This is a follow-up on a previous similar thread

https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
 in
which the community consistently expressed support for transitioning
Beam Java to Java8-only.

Now that the release of Beam 2.2.0 has completed, we are considering
performing this change specifically in the immediate next release:
Beam 2.3.0, i.e. dropping support for Java 7 without a bump in the
major version of Beam.

The reasons for switching to Java 8 in general are considered in the
thread above.
The reasons in favor of making the switch in Beam 2.3.0 are as 
follows:
- It is believed that usage of Java 7 in production is already
vanishingly small.
- Since Java 7 has not been receiving even security updates for
years, helping perpetuate its usage would be a bad idea
- A major version bump is a major step and would likely happen only
after a large number of other major changes in Beam accumulate -
i.e. many months. Maintaining Java 7 compatibility for that long
would have costs, including the awkward possibility of switching
Beam to Java 8 after Java 8's end of life (September 2018 AFAIK)
- Updating to Java 8 would lead to Beam more quickly gaining more
Java8-friendly APIs, because Beam SDK authors and contributors would
have more liberty, more responsibility and more experience with
working in the context of Java8. Delaying until Beam 3.0 would delay
this as well.

With that in mind, we'd like to poll the Beam community to gather
information about usage of Java 7 and Java 8 in production. Please 
vote:

Option 1. I am already using only Java 8+ for building my production
Beam code.

Option 2. I am using Java 7 for building my production Beam code,
but I would have no trouble with the switch to Java 8 [e.g. my
transition to Java 8 would be easy and/or I don't expect that I'll
have strong reasons to upgrade to Beam 2.3 anyway].

Option 3. I am using Java 7 for building my production Beam code,
and dropping Java 7 would be a blocker or hindrance to adopting the
new release for me [e.g. I expect that I'll have strong reasons to
update to Beam 2.3, b

Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-11 Thread Eugene Kirpichov
Intermediate update: right now it's 219 votes on Twitter (and 0 on this
thread: seems that people find Twitter a more convenient medium!), with 96%
who are either on Java 8 or can easily switch, vs. 4% who can not easily
switch.

Using a proportion confidence interval calculator, so far we're looking at
between 1.9 and 7.7% of users (at 95% confidence) needing Java 7 support :)

Willing users can help gather more votes by RT'ing the poll or chiming in
on this thread!

So: for now we don't yet have enough confidence that Java 7 support can be
dropped from the SDK (to remind, we'll conclude the vote on January 7th;
since people so overwhelmingly vote on Twitter, we may consider doing 3
more rounds of the same poll?..), however:
- It may be enough confidence to resolve to *build* the Beam SDK using JDK8
(at Java 7 source language level), which is something +Ismaël Mejía
 and +Daniel Oliveira  once
requested as part of building Java 9 support. I suspect that the sets
"users who need to build their own Beam SDK" and "users who can not upgrade
to Java 8" have a vanishingly small intersection.
- Then, we may consider also start building *tests* at Java 8 language
level, which will give the bulk of the benefit of encouraging
Java8-friendly APIs.
Thoughts on the above?

On Thu, Dec 7, 2017 at 6:22 PM Eugene Kirpichov 
wrote:

> A Twitter poll has been sent out too
> https://twitter.com/ApacheBeam/status/938926195910905857
> However, due to limitations of Twitter it can only be open for 7 days. I
> encourage people who are late to the poll to comment on this thread instead.
>
> On Thu, Dec 7, 2017 at 3:50 PM Eugene Kirpichov 
> wrote:
>
>> Followup: we would like to keep this poll open for 2 weeks, however some
>> people have expressed concern that this is too short.
>> Let us keep this poll open for 1 month starting today. So far the
>> agreed-upon decision has been to move forward with the plan if fewer than
>> 5% of all respondents choose option 3.
>>
>> On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov 
>> wrote:
>>
>>> This is a follow-up on a previous similar thread
>>> https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
>>>  in
>>> which the community consistently expressed support for transitioning Beam
>>> Java to Java8-only.
>>>
>>> Now that the release of Beam 2.2.0 has completed, we are considering
>>> performing this change specifically in the immediate next release: Beam
>>> 2.3.0, i.e. dropping support for Java 7 without a bump in the major version
>>> of Beam.
>>>
>>> The reasons for switching to Java 8 in general are considered in the
>>> thread above.
>>> The reasons in favor of making the switch in Beam 2.3.0 are as follows:
>>> - It is believed that usage of Java 7 in production is already
>>> vanishingly small.
>>> - Since Java 7 has not been receiving even security updates for years,
>>> helping perpetuate its usage would be a bad idea
>>> - A major version bump is a major step and would likely happen only
>>> after a large number of other major changes in Beam accumulate - i.e. many
>>> months. Maintaining Java 7 compatibility for that long would have costs,
>>> including the awkward possibility of switching Beam to Java 8 after Java
>>> 8's end of life (September 2018 AFAIK)
>>> - Updating to Java 8 would lead to Beam more quickly gaining more
>>> Java8-friendly APIs, because Beam SDK authors and contributors would have
>>> more liberty, more responsibility and more experience with working in the
>>> context of Java8. Delaying until Beam 3.0 would delay this as well.
>>>
>>> With that in mind, we'd like to poll the Beam community to gather
>>> information about usage of Java 7 and Java 8 in production. Please vote:
>>>
>>> Option 1. I am already using only Java 8+ for building my production
>>> Beam code.
>>>
>>> Option 2. I am using Java 7 for building my production Beam code, but I
>>> would have no trouble with the switch to Java 8 [e.g. my transition to Java
>>> 8 would be easy and/or I don't expect that I'll have strong reasons to
>>> upgrade to Beam 2.3 anyway].
>>>
>>> Option 3. I am using Java 7 for building my production Beam code, and
>>> dropping Java 7 would be a blocker or hindrance to adopting the new release
>>> for me [e.g. I expect that I'll have strong reasons to update to Beam 2.3,
>>> but I expect that it will be difficult because of lack of Java 7 support]
>>>
>>>


Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-07 Thread Eugene Kirpichov
A Twitter poll has been sent out too
https://twitter.com/ApacheBeam/status/938926195910905857
However, due to limitations of Twitter it can only be open for 7 days. I
encourage people who are late to the poll to comment on this thread instead.

On Thu, Dec 7, 2017 at 3:50 PM Eugene Kirpichov 
wrote:

> Followup: we would like to keep this poll open for 2 weeks, however some
> people have expressed concern that this is too short.
> Let us keep this poll open for 1 month starting today. So far the
> agreed-upon decision has been to move forward with the plan if fewer than
> 5% of all respondents choose option 3.
>
> On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov 
> wrote:
>
>> This is a follow-up on a previous similar thread
>> https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
>>  in
>> which the community consistently expressed support for transitioning Beam
>> Java to Java8-only.
>>
>> Now that the release of Beam 2.2.0 has completed, we are considering
>> performing this change specifically in the immediate next release: Beam
>> 2.3.0, i.e. dropping support for Java 7 without a bump in the major version
>> of Beam.
>>
>> The reasons for switching to Java 8 in general are considered in the
>> thread above.
>> The reasons in favor of making the switch in Beam 2.3.0 are as follows:
>> - It is believed that usage of Java 7 in production is already
>> vanishingly small.
>> - Since Java 7 has not been receiving even security updates for years,
>> helping perpetuate its usage would be a bad idea
>> - A major version bump is a major step and would likely happen only after
>> a large number of other major changes in Beam accumulate - i.e. many
>> months. Maintaining Java 7 compatibility for that long would have costs,
>> including the awkward possibility of switching Beam to Java 8 after Java
>> 8's end of life (September 2018 AFAIK)
>> - Updating to Java 8 would lead to Beam more quickly gaining more
>> Java8-friendly APIs, because Beam SDK authors and contributors would have
>> more liberty, more responsibility and more experience with working in the
>> context of Java8. Delaying until Beam 3.0 would delay this as well.
>>
>> With that in mind, we'd like to poll the Beam community to gather
>> information about usage of Java 7 and Java 8 in production. Please vote:
>>
>> Option 1. I am already using only Java 8+ for building my production Beam
>> code.
>>
>> Option 2. I am using Java 7 for building my production Beam code, but I
>> would have no trouble with the switch to Java 8 [e.g. my transition to Java
>> 8 would be easy and/or I don't expect that I'll have strong reasons to
>> upgrade to Beam 2.3 anyway].
>>
>> Option 3. I am using Java 7 for building my production Beam code, and
>> dropping Java 7 would be a blocker or hindrance to adopting the new release
>> for me [e.g. I expect that I'll have strong reasons to update to Beam 2.3,
>> but I expect that it will be difficult because of lack of Java 7 support]
>>
>>


Re: [POLL] Dropping support for Java 7 in Beam 2.3

2017-12-07 Thread Eugene Kirpichov
Followup: we would like to keep this poll open for 2 weeks, however some
people have expressed concern that this is too short.
Let us keep this poll open for 1 month starting today. So far the
agreed-upon decision has been to move forward with the plan if fewer than
5% of all respondents choose option 3.

On Thu, Dec 7, 2017 at 3:48 PM Eugene Kirpichov 
wrote:

> This is a follow-up on a previous similar thread
> https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
>  in
> which the community consistently expressed support for transitioning Beam
> Java to Java8-only.
>
> Now that the release of Beam 2.2.0 has completed, we are considering
> performing this change specifically in the immediate next release: Beam
> 2.3.0, i.e. dropping support for Java 7 without a bump in the major version
> of Beam.
>
> The reasons for switching to Java 8 in general are considered in the
> thread above.
> The reasons in favor of making the switch in Beam 2.3.0 are as follows:
> - It is believed that usage of Java 7 in production is already vanishingly
> small.
> - Since Java 7 has not been receiving even security updates for years,
> helping perpetuate its usage would be a bad idea
> - A major version bump is a major step and would likely happen only after
> a large number of other major changes in Beam accumulate - i.e. many
> months. Maintaining Java 7 compatibility for that long would have costs,
> including the awkward possibility of switching Beam to Java 8 after Java
> 8's end of life (September 2018 AFAIK)
> - Updating to Java 8 would lead to Beam more quickly gaining more
> Java8-friendly APIs, because Beam SDK authors and contributors would have
> more liberty, more responsibility and more experience with working in the
> context of Java8. Delaying until Beam 3.0 would delay this as well.
>
> With that in mind, we'd like to poll the Beam community to gather
> information about usage of Java 7 and Java 8 in production. Please vote:
>
> Option 1. I am already using only Java 8+ for building my production Beam
> code.
>
> Option 2. I am using Java 7 for building my production Beam code, but I
> would have no trouble with the switch to Java 8 [e.g. my transition to Java
> 8 would be easy and/or I don't expect that I'll have strong reasons to
> upgrade to Beam 2.3 anyway].
>
> Option 3. I am using Java 7 for building my production Beam code, and
> dropping Java 7 would be a blocker or hindrance to adopting the new release
> for me [e.g. I expect that I'll have strong reasons to update to Beam 2.3,
> but I expect that it will be difficult because of lack of Java 7 support]
>
>


[POLL] Dropping support for Java 7 in Beam 2.3

2017-12-07 Thread Eugene Kirpichov
This is a follow-up on a previous similar thread
https://lists.apache.org/thread.html/2e1890c62d9f022f09b20e9f12f130fe9f1042e391979087f725d2e0@%3Cuser.beam.apache.org%3E
in
which the community consistently expressed support for transitioning Beam
Java to Java8-only.

Now that the release of Beam 2.2.0 has completed, we are considering
performing this change specifically in the immediate next release: Beam
2.3.0, i.e. dropping support for Java 7 without a bump in the major version
of Beam.

The reasons for switching to Java 8 in general are considered in the thread
above.
The reasons in favor of making the switch in Beam 2.3.0 are as follows:
- It is believed that usage of Java 7 in production is already vanishingly
small.
- Since Java 7 has not been receiving even security updates for years,
helping perpetuate its usage would be a bad idea
- A major version bump is a major step and would likely happen only after a
large number of other major changes in Beam accumulate - i.e. many months.
Maintaining Java 7 compatibility for that long would have costs, including
the awkward possibility of switching Beam to Java 8 after Java 8's end of
life (September 2018 AFAIK)
- Updating to Java 8 would lead to Beam more quickly gaining more
Java8-friendly APIs, because Beam SDK authors and contributors would have
more liberty, more responsibility and more experience with working in the
context of Java8. Delaying until Beam 3.0 would delay this as well.

With that in mind, we'd like to poll the Beam community to gather
information about usage of Java 7 and Java 8 in production. Please vote:

Option 1. I am already using only Java 8+ for building my production Beam
code.

Option 2. I am using Java 7 for building my production Beam code, but I
would have no trouble with the switch to Java 8 [e.g. my transition to Java
8 would be easy and/or I don't expect that I'll have strong reasons to
upgrade to Beam 2.3 anyway].

Option 3. I am using Java 7 for building my production Beam code, and
dropping Java 7 would be a blocker or hindrance to adopting the new release
for me [e.g. I expect that I'll have strong reasons to update to Beam 2.3,
but I expect that it will be difficult because of lack of Java 7 support]