+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 user or something different?
On Wed, Sep 27, 2017 at 7:59 PM, Kenneth Knowles <k...@google.com.invalid>
wrote:
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é <j...@nanthrax.net>
wrote:
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
<danolive...@google.com.invalid> wrote:
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 of AutoValue with the fix that works in Java 7. However
I
feel that slowly moving over to Java 8 is the most future-proof solution
if
it's possible.
On Tue, Sep 26, 2017 at 2:47 PM, Ismaël Mejía <ieme...@gmail.com> wrote:
The current issue is that compilation fails on master because beam's
parent pom is configured to fail if it finds warnings):
<compiler.error.flag>-Werror</compiler.error.flag>
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 tests that break and other issues because of other
plugins and dependencies (e.g. bytebuddy), but those are not part of
this discussion.
On Tue, Sep 26, 2017 at 11:38 PM, Eugene Kirpichov
<kirpic...@google.com.invalid> wrote:
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 <ieme...@gmail.com>
wrote:
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 passes mvn clean install
with pure Java 9 (and also add this to jenkins), not to rewrite
anything to use the new stuff (e.g. modules):
https://issues.apache.org/jira/browse/BEAM-2530
Eugene can you also PTAL at the AutoValue issue, more details on the
issue, this is a warning so I don't know if it is really critical in
particular because we are not using Memoization (do we?).
https://github.com/google/auto/issues/503
https://github.com/google/auto/commit/71514081f2ca6fb4ead2b7f0a25f5d
02247b8532
Wouldn't the easiest way be that you guys convince the google.auto
guys to generate that simple fix in a Java 7 compatible way and
'voila' ?
However I agree that moving to Java 8 is an excellent idea and as
Eugene mentions there is less friction now since most projects are
moving, only pending issue are existing clusters on java 7 in the
hadoop world, but those are less frequent now. Anyway this discussion
is really important (maybe even worth a vote). Because moving to Java
8 will allow us also to move some of the dependencies that we are
keeping in old versions and in general to move forward.
What do the others think ?
On Tue, Sep 26, 2017 at 11:09 PM, Eugene Kirpichov
<kirpic...@google.com.invalid> wrote:
Very excited to hear that there's work on JDK9 support - is there a
public
description of the plans for this work somewhere?
In general, Beam could probably drop Java7 support altogether at some
point
soon: Java7 has reached end-of-life (i.e. it's not receiving even
security
patches) 2 years ago, and all major players in the data processing
ecosystem have dropped Java7 support (Spark, Flink, Hadoop), so I
presume
the demand for Java7 support in the data processing industry is low.
By
the
way: would a Java8 migration be in the scope of your work in general?
However, until we say that Beam requires Java8, what would be the
implications of using a version of AutoValue that can only be
compiled
with
Java8? Are you saying that this is simply a matter of a compiler bug,
and
if we use a Java8 compiler but configured to use source and target
versions
of 1.7 and using bootclasspath of rt.jar from 1.7, then the resulting
Beam
artifacts will be usable by people who don't have Java8?
On Tue, Sep 26, 2017 at 1:53 PM Daniel Oliveira
<danolive...@google.com.invalid> wrote:
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 and execute Java 7 code from the Java 8 compiler by building
with
the correct arguments. So the fix to this bug would essentially
require
Java 8 compilers even for compiling Java 7 code.
Does anyone need to use Java 7 compilers? Because if not I would
like to
continue with this fix.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
