So maybe what we should do now is deprecate Java 7 support but not drop it
yet. I believe this is also what Spark has done.
On Tue, Oct 17, 2017 at 9:46 AM, Jean-Baptiste Onofré
wrote:
> Agree, I would target this for Beam 3.0.0.
>
> Regards
> JB
>
> On 10/17/2017 06:43 PM,
Should this be considered a backwards-incompatible change? If so, do we
need to wait until Beam 3.0.0 is released?
On Tue, Oct 17, 2017 at 9:11 AM, Ismaël Mejía wrote:
> I am bringing the subject to the user mailing list to get some
> feedback because it makes sense anyway to
I am bringing the subject to the user mailing list to get some
feedback because it makes sense anyway to discuss this there. But I
also agree with Kenneth about the fact that runner authors must weight
in on this subject.
On Tue, Oct 17, 2017 at 5:24 PM, Kenneth Knowles
+1 to having runner maintainers weigh in as proxies. Added a few in case
they haven't followed this thread.
On Mon, Oct 16, 2017 at 11:38 PM, Eugene Kirpichov <
kirpic...@google.com.invalid> wrote:
> Agreed that polling Dataflow users makes sense, though I think they are
> very unlikely to have
Agreed that polling Dataflow users makes sense, though I think they are
very unlikely to have concerns, because unlike Spark/Flink users they
wouldn't have a "cluster" that they need to migrate to a new JVM: they'd
only need to recompile their pipelines with JDK 8.
On Mon, Oct 16, 2017 at 11:21
I think the Flink and Spark runner maintainers can weigh in here; given
that both of those systems are moving to Java 8, I doubt they will have
concerns. Same is true for the Dataflow runner - we should probably poll
Dataflow users to make sure this is not a problem for any of them.
On Mon, Oct
Reuven - do you mean e.g. a poll on the Flink mailing list asking whether
there are Flink users who use Beam with Java 7? Or just people who use
Flink with Java 7? (the latter question I'd assume was settled by the poll
about making Flink itself Java8-only?)
On Mon, Oct 16, 2017 at 10:32 PM
+1 to vote on @user.
Not sure anyway it requires a formal vote. As Java 7 is deprecated, it should be
an implicit "decision".
Regards
JB
On 10/16/2017 04:35 PM, Ismaël Mejía wrote:
Any progress on this? What is the proposed way to validate if users
are still interested on Java 7? A vote on
Yeah, a vote on user@ sounds like a good idea. Ismaël, would you be
interested in driving this process, since you're already working on Java9
support and hence you have a good understanding of what's involved in a JDK
version migration for a large project?
As due diligence, we can look at how the
Any progress on this? What is the proposed way to validate if users
are still interested on Java 7? A vote on user or something different?
On Wed, Sep 27, 2017 at 7:59 PM, Kenneth Knowles
wrote:
> Agree with polling Beam users as well as each runner's community in
>
Agree with polling Beam users as well as each runner's community in
aggregate.
On Wed, Sep 27, 2017 at 9:44 AM, Jean-Baptiste Onofré
wrote:
> Definitely agree
>
>
> On 09/27/2017 06:00 PM, Robert Bradshaw wrote:
>
>> I also think that it's time to seriously consider dropping
Definitely agree
On 09/27/2017 06:00 PM, Robert Bradshaw wrote:
I also think that it's time to seriously consider dropping support for Java 7.
On Tue, Sep 26, 2017 at 9:14 PM, Daniel Oliveira
wrote:
Yes, just as Ismaël said it's a compilation blocker right now
+1
Regards
JB
On 09/27/2017 06:04 PM, Reuven Lax wrote:
I would support this as well, however we probably should first poll current
users of the Beam API to see if any of them rely on Java 7.
Reuven
On Wed, Sep 27, 2017 at 9:00 AM, Robert Bradshaw <
rober...@google.com.invalid> wrote:
I
I would support this as well, however we probably should first poll current
users of the Beam API to see if any of them rely on Java 7.
Reuven
On Wed, Sep 27, 2017 at 9:00 AM, Robert Bradshaw <
rober...@google.com.invalid> wrote:
> I also think that it's time to seriously consider dropping
Yes, just as Ismaël said it's a compilation blocker right now despite that
(I believe) we don't use the extension that's breaking.
As for other ways to solve this, if there is a way to avoid compiling the
advanced features of AutoValue that might be worth a try. We could also try
to get a release
The current issue is that compilation fails on master because beam's
parent pom is configured to fail if it finds warnings):
-Werror
However if you remove that line from the parent pom the compilation passes.
Of course this does not mean that everything is solved for Java 9,
there are some
AFAIK we don't use any advanced capabilities of AutoValue. Does that mean
this issue is moot? I didn't quite understand from your email whether it is
a compilation blocker for Beam or not.
On Tue, Sep 26, 2017 at 2:32 PM Ismaël Mejía wrote:
> Great that you are also working
Great that you are also working on this too Daniel and thanks for
bringing this subject to the mailing list, I was waiting to my return
to office next week, but you did it first :)
Eugene for reference (This is the issue on the migration to Java 9),
notice that here the goal is first that beam
So I've been working on JDK 9 support for Beam, and I have a bug in
AutoValue that can be fixed by updating our AutoValue dependency to the
latest. The problem is that AutoValue from 1.5+ seems to be banned for Beam
due to requiring Java 8 compilers. However, it should still be possible to
compile
19 matches
Mail list logo