Re: Issues building/running 2.25 on java 8

ill still receive the bad 3.13.0 transitively, shouldn't >> this be fixed for the next release? >> Is there a JIRA? >> >> On Mon, Nov 9, 2020 at 9:44 PM Kenneth Knowles wrote: >> > >> > The protobuf bug summarizes the issue well. It is built against Java 11 &g

Re: Issues building/running 2.25 on java 8

> > The protobuf bug summarizes the issue well. It is built against Java 11 > bootclasspath even though it targets bytecode compatibility with Java 8. > > > > It seems like we intend to be at 3.12.0 by default: > https://github.com/apache/beam/blob/550ea9fc4db38f543350350fcc0734029

Re: Issues building/running 2.25 on java 8

t targets bytecode compatibility with Java 8. > > It seems like we intend to be at 3.12.0 by default: > https://github.com/apache/beam/blob/550ea9fc4db38f543350350fcc0734029a587e81/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L430 > > Kenn > > On Fri

Re: Issues building/running 2.25 on java 8

The protobuf bug summarizes the issue well. It is built against Java 11 bootclasspath even though it targets bytecode compatibility with Java 8. It seems like we intend to be at 3.12.0 by default: https://github.com/apache/beam/blob/550ea9fc4db38f543350350fcc0734029a587e81/buildSrc/src/main

Re: Issues building/running 2.25 on java 8

I downgraded google_cloud_bigdataoss from 2.1.5 back to 2.1.3, which was recently upgraded [1], and that fixed the issue. It looks like it was transitively pulling in protobuf 3.13.0, which isn't compatible with java 8(?!??). [1] https://github.com/apache/beam/commit

Re: Issues building/running 2.25 on java 8

https://issues.apache.org/jira/browse/BEAM-11080) > > On Fri, Nov 6, 2020 at 3:13 PM Steve Niemitz wrote: > >> I'm trying out 2.25 (built from source, using java 8), and running into >> this error, both on the direct runner and dataflow: >> >>

Re: Issues building/running 2.25 on java 8

Do you have JAVA_HOME set? (possibly related: https://issues.apache.org/jira/browse/BEAM-11080) On Fri, Nov 6, 2020 at 3:13 PM Steve Niemitz wrote: > I'm trying out 2.25 (built from source, using java 8), and running into > this error, both on the direct runner and dataflow: >

Issues building/running 2.25 on java 8

I'm trying out 2.25 (built from source, using java 8), and running into this error, both on the direct runner and dataflow: Caused by: java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; at com.google.protobuf.NioByteString.copyToInternal(NioByteString.java:112

Re: [ANNOUNCE] Beam Java 8 image rename starting from 2.26.0 (to apache/beam_java8_sdk)

ses so people who are on an older release can migrate now and not have >> to remember to do it with 2.26? >> >> On Tue, Sep 29, 2020 at 5:37 PM Emily Ye wrote: >> >>> Starting with the release of 2.26.0, the Java 8 SDK container image >>> <https

Re: [ANNOUNCE] Beam Java 8 image rename starting from 2.26.0 (to apache/beam_java8_sdk)

te now and not have > to remember to do it with 2.26? > > On Tue, Sep 29, 2020 at 5:37 PM Emily Ye wrote: > >> Starting with the release of 2.26.0, the Java 8 SDK container image >> <https://beam.apache.org/documentation/runtime/environments/> (currently >> apac

Re: [ANNOUNCE] Beam Java 8 image rename starting from 2.26.0 (to apache/beam_java8_sdk)

Can we copy the beam_java_sdk image to beam_java8_sdk for a few prior releases so people who are on an older release can migrate now and not have to remember to do it with 2.26? On Tue, Sep 29, 2020 at 5:37 PM Emily Ye wrote: > Starting with the release of 2.26.0, the Java 8 SDK container im

[ANNOUNCE] Beam Java 8 image rename starting from 2.26.0 (to apache/beam_java8_sdk)

Starting with the release of 2.26.0, the Java 8 SDK container image <https://beam.apache.org/documentation/runtime/environments/> (currently apache/beam_java_sdk <https://hub.docker.com/r/apache/beam_java_sdk)>) will be released under a new name, *apache/beam_java8_sdk.* This is in

Re: Is it too late to switch to Java 8 time for the schema aware Row and Beam SQL?

We need to figure out a way to make sure we can read the data without losing precision. It will likely be case by case. -Rui On Wed, Aug 28, 2019 at 2:27 AM Alex Van Boxel wrote: > Thanks, how will ZetaSQL support higher precision as the input in general > will be Instant anyway. Will it rely

Re: Is it too late to switch to Java 8 time for the schema aware Row and Beam SQL?

Thanks, how will ZetaSQL support higher precision as the input in general will be Instant anyway. Will it rely on the "pending" standardized logical types? _/ _/ Alex Van Boxel On Mon, Aug 19, 2019 at 7:02 AM Rui Wang wrote: > However, more challengings come from: > > 1. How to read data

Is it too late to switch to Java 8 time for the schema aware Row and Beam SQL?

I know it's probably futile, but the more I'm working on features that are related to schema awareness I'm getting a bit frustrated about the lack of precision of the joda instance. As soon as we have a conversion to the DateTime I need to drop precession, this happens with the Protobuf timestamp

Re: Java > 8 support

est way to validate the compatiblity of our code base and find issues >> with some of the classpath/code generation we use or with the >> dependencies). I agree 100% with you, the real deal is to validate that we >> can use Java 8 built jars with more recent J

Re: Java > 8 support

use this is the > strictest way to validate the compatiblity of our code base and find issues > with some of the classpath/code generation we use or with the > dependencies). I agree 100% with you, the real deal is to validate that we > can use Java 8 built jars with more recent Java versions

Re: Java > 8 support

Yes, Kenn I was talking about building artifacts (because this is the strictest way to validate the compatiblity of our code base and find issues with some of the classpath/code generation we use or with the dependencies). I agree 100% with you, the real deal is to validate that we can use Java 8

Re: Java > 8 support

On Thu, Oct 18, 2018 at 4:55 AM Kenneth Knowles wrote: > Just to add to what Luke said: The reason we had those Java 8-only modules > was because some underlying tech (example: Gearpump) required Java 8. If an > engine requires something then it is OK for a user who chooses t

Re: Java > 8 support

Just to add to what Luke said: The reason we had those Java 8-only modules was because some underlying tech (example: Gearpump) required Java 8. If an engine requires something then it is OK for a user who chooses the runner for that engine to also be subject to that requirement. Otherwise I would

Re: Java > 8 support

When we were supporting Java 7, there were Java 8 based modules in Maven. We can follow a similar pattern where Java11 (or any other version) have their own projects and as the base Java version moves up, we can merge those modules back in to simplify the set of modules being developed. On Wed

Re: Java > 8 support

of plugins/bytebuddy and other deps to guarantee that the execution was done strictly with the latest version of Java and its generated bytecode (the origin of the docker build images was to guarantee this isolation). At the time I run the tests of most IOs and most extensions with the existing (java 8

Re: Java > 8 support

FYI: If I'm correct, migrating to Java 11 may require Migrating to Gradle 5, which to me is ok, but there are some issues on the way (such as [1] or maybe more that I'm not aware of). I did some research and it seems that Groovy 2.4.15 (the default version of Groovy for Gradle 4.10.2) is unable

Re: Java > 8 support

FWIW, the issue regarding java 11 support to gradle might be helpful here [1]. Quoting: "there are only some minor corner cases that don't work. Overall Java 11 support is pretty solid already" but some users reported problems in comments with Checkstyle plugin and MacOS + Gradle4.10.2 (this might

Re: Java > 8 support

Hello all, If I understand you correctly Ismael, a good amount of 'beam-sdks-java-core' tests are already passing with Java 11, so the amount of work necessary on the core module should be relatively small. Is this correct? Are there improvements that may be missing in terms of modularization?

Re: Java > 8 support

Thanks for the clarification Ismaël. * • **Arif Kasim* * • * Strategic Cloud Engineer * • *Google, Inc. • arifka...@google.com On Wed, Oct 10, 2018 at 9:41 AM Ismaël Mejía wrote: > Just wanted to clarify, there is already a JIRA for ongoing work on > Java 11 support. >

Re: Java > 8 support

Just wanted to clarify, there is already a JIRA for ongoing work on Java 11 support. https://issues.apache.org/jira/browse/BEAM-2530 I led the initial work on supporting what at the time was Java 9/10, so far the biggest blockers were around the ApiSurface tests (not at all compatible with these

Re: Java > 8 support

@Reuven: bytebuddy by itself no but the way beam tries to inject the proxy class is. There are other strategies you can use in bytebuddy which work. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: Java > 8 support

Hi, I mean that some IO dependency, especially for the tests should be updated for the build with J9. The runtime should work with J9, but not the build. Regards JB On 06/10/2018 17:45, Romain Manni-Bucau wrote: > I dont think so JB - until you want to use jlink but it is out of scope > of

Re: Java > 8 support

Romain, do you have any more details on the ByteBuddy incompatibility? Is ByteBuddy incompatible with the Java 11 JRE, or just with new language features? On Fri, Oct 5, 2018 at 10:20 AM Romain Manni-Bucau wrote: > Hi Arif, > > AFAIK bytebuddy code is not java 11 friendly otherwise it runs (but

Re: Java > 8 support

I dont think so JB - until you want to use jlink but it is out of scope of beam - and since j9 didnt break unsafe it should work. Le sam. 6 oct. 2018 17:23, Jean-Baptiste Onofré a écrit : > Same thing, it requires some change in the dependency, especially for > the Jigsaw modules. > > Regards >

Re: Java > 8 support

Same thing, it requires some change in the dependency, especially for the Jigsaw modules. Regards JB On 06/10/2018 15:01, Arif Kasim wrote: > Thanks all. What about Java 9 support? > > > > > > > > > > *  •  **Arif Kasim** > **  • * Strategic Cloud

Re: Java > 8 support

Thanks all. What about Java 9 support? * • **Arif Kasim* * • * Strategic Cloud Engineer * • *Google, Inc. • arifka...@google.com On Fri, Oct 5, 2018 at 7:20 PM Romain Manni-Bucau wrote: > Hi Arif, > > AFAIK bytebuddy code is not java 11 friendly otherwise it runs (but it > means

Re: Java > 8 support

Hi Arif, AFAIK bytebuddy code is not java 11 friendly otherwise it runs (but it means your pipeline is very very simple since it does not have a dofn ;)) if your engine supports it. Also note that the modules not being named you can have to use some weird import names or even unstable ones if you

Re: Java > 8 support

Hi Arif, Java 8 is supported but we also plan some update in the core (like removing joda-time to use "native" Java 8 lib). I guess you are mostly asking for Java 11, I just try a rough build and indeed, we have lot of changes/updates to do. I did the update to Java 11 in Ap

Java > 8 support

Hello, What's the status of java version > 8 support for beam? Thanks. -Arif.

Re: Euphoria Java 8 DSL - proposal

aware of. We >> welcome DSLs. >> > >> > Technically, the >> code >> > would start >> > in a >> > feature branc

Re: Euphoria Java 8 DSL - proposal

o have you! Hope > > this > >helps, and please > reach > > out if > > anybody on > > our end can help, &g

Re: Euphoria Java 8 DSL - proposal

g, > having >         different >                                      fluent DSL on top of the >                                      Beam >                                        SDK is great. > >                                        I w

Re: Euphoria Java 8 DSL - proposal

Welcome to the ASF and >> Beam -- we are >> thrilled to have you! Hope >> this >>helps, and please reach >>

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

>> >> >> On Thu, Feb 1, 2018 at 9:07 PM, Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> +1 >>> >>> Regards >>> JB >>> >>> On 02/01/2018 07:54 PM, Kenneth Knowles wrote: >>> > Hi all, >

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

s wrote: >> > Hi all, >> > >> > Luke, Thomas, and I had some in-person discussions about the use of >> Java 8 >> > futures and Guava futures in the portability support code. I wanted to >> bring our >> > thoughts to the dev list fo

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

gt; JB > > On 02/01/2018 07:54 PM, Kenneth Knowles wrote: > > Hi all, > > > > Luke, Thomas, and I had some in-person discussions about the use of Java 8 > > futures and Guava futures in the portability support code. I wanted to > > bring our > > thoughts to

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

+1 On Thu, Feb 1, 2018 at 9:07 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > +1 > > Regards > JB > > On 02/01/2018 07:54 PM, Kenneth Knowles wrote: > > Hi all, > > > > Luke, Thomas, and I had some in-person discussions about the use

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

+1 Regards JB On 02/01/2018 07:54 PM, Kenneth Knowles wrote: > Hi all, > > Luke, Thomas, and I had some in-person discussions about the use of Java 8 > futures and Guava futures in the portability support code. I wanted to bring > our > thoughts to the dev list for feedback.

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

nds >> great, +1. >> >> On Thu, Feb 1, 2018 at 11:53 AM Reuven Lax <re...@google.com> wrote: >>> >>> Unless there's something that doesn't work in Java 8 future, +1 to >>> migrating. >>> >>> On Thu, Feb 1, 2018 at 10:54 AM, Kenneth

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

Unless there's something that doesn't work in Java 8 future, +1 to >> migrating. >> >> On Thu, Feb 1, 2018 at 10:54 AM, Kenneth Knowles <k...@google.com> wrote: >> >>> Hi all, >>> >>> Luke, Thomas, and I had some in-person discussions about th

Re: [PROPOSAL] Switch from Guava futures vs Java 8 futures

Unless there's something that doesn't work in Java 8 future, +1 to migrating. On Thu, Feb 1, 2018 at 10:54 AM, Kenneth Knowles <k...@google.com> wrote: > Hi all, > > Luke, Thomas, and I had some in-person discussions about the use of Java 8 > futures and Guava futures in the p

[PROPOSAL] Switch from Guava futures vs Java 8 futures

Hi all, Luke, Thomas, and I had some in-person discussions about the use of Java 8 futures and Guava futures in the portability support code. I wanted to bring our thoughts to the dev list for feedback. As background: - Java 5+ "Future" lacks the main purpose of future, which is asyn

Re: Switching to Java 8

gt; Regards > JB > > On 01/09/2018 11:46 AM, Etienne Chauchot wrote: > > Hi, > > > > +1 as well, excellent news ! > > > &

Re: Switching to Java 8

x.net> >>> wrote: >>> >>>> Actually, it's part of the build and I will "expand" the java version >>>> in the >>>> enforcer. >>>> >>>> Regards >>>> JB >>>> >>>> On 01/09/2018 1

Re: Switching to Java 8

he java version in >>> the >>> enforcer. >>> >>> Regards >>> JB >>> >>> On 01/09/2018 11:46 AM, Etienne Chauchot wrote: >>> > Hi, >>> > >>> > +1 as well, excellent news ! &g

Re: Switching to Java 8

tienne Chauchot wrote: >> > Hi, >> > >> > +1 as well, excellent news ! >> > >> > I would add also: remove (AFAIK in some IOs) the enforcer >configuration >> (like >> > [1]) that were put when java 8 was needed in a java 7 build. >>

Re: Switching to Java 8

auchot wrote: > > Hi, > > > > +1 as well, excellent news ! > > > > I would add also: remove (AFAIK in some IOs) the enforcer configuration > (like > > [1]) that were put when java 8 was needed in a java 7 build. > > > > [1] > > > > > >

Re: Switching to Java 8

Hi, +1 as well, excellent news ! I would add also: remove (AFAIK in some IOs) the enforcer configuration (like [1]) that were put when java 8 was needed in a java 7 build. [1]    [1.8,) Etienne Le 08/01/2018 à 14:02, Jean-Baptiste Onofré a écrit : I created https://issues.apache.org

Re: Switching to Java 8

Hi Romain, Good point. However, AFAIR, AutoValue supports Java 8 (not Java 8 "style" but it compiles without problem using Java 8). Regards JB On 01/08/2018 11:36 AM, Romain Manni-Bucau wrote: +1000 also requires to upgrade @Auto* processor which was not supporting j8 in curr

Re: Switching to Java 8

e build update: Maven/Gradle with enforcer + merge of the examples all together. Regards JB On 01/08/2018 07:34 AM, Eugene Kirpichov wrote: > The vote on user@ about switching to Java 8 has concluded, affirmatively. > > What needs to be done to co

Re: Switching to Java 8

ether. Regards JB On 01/08/2018 07:34 AM, Eugene Kirpichov wrote: > The vote on user@ about switching to Java 8 has concluded, affirmatively. > > What needs to be done to complete the switch? I can see at least the following: > - Change maven and gra

Re: Switching to Java 8

Good point Romain, this is also another (same) point: - Update dependencies pinned into older version because of the lack of java 8 support (guava, auto, etc). On Mon, Jan 8, 2018 at 11:36 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > +1000 > > also requires to upgrade @

Re: Switching to Java 8

ptiste Onofré <j...@nanthrax.net > >> <mailto:j...@nanthrax.net>> wrote: > >> > >> Hi Eugene, > >> > >> I'm taking the build update: Maven/Gradle with enforcer + merge of > the > >> examples > >> all together. >

Re: Switching to Java 8

at 10:38 PM Jean-Baptiste Onofré <j...@nanthrax.net >> <mailto:j...@nanthrax.net>> wrote: >> >> Hi Eugene, >> >> I'm taking the build update: Maven/Gradle with enforcer + merge of the >> examples >> all together. >> >> Regards >&

Re: Switching to Java 8

; The vote on user@ about switching to Java 8 has concluded, affirmatively. > > What needs to be done to complete the switch? I can see at least the following: > - Change maven and gradle scripts to use 1.8 source and target version > - Fix resulting compil

Re: Switching to Java 8

e with enforcer + merge of the > examples > all together. > > Regards > JB > > On 01/08/2018 07:34 AM, Eugene Kirpichov wrote: > > The vote on user@ about switching to Java 8 has concluded, > affirmatively. > > > > What needs to be done to complete the switc

Re: Switching to Java 8

Hi Eugene, I'm taking the build update: Maven/Gradle with enforcer + merge of the examples all together. Regards JB On 01/08/2018 07:34 AM, Eugene Kirpichov wrote: The vote on user@ about switching to Java 8 has concluded, affirmatively. What needs to be done to complete the switch? I can

Switching to Java 8

The vote on user@ about switching to Java 8 has concluded, affirmatively. What needs to be done to complete the switch? I can see at least the following: - Change maven and gradle scripts to use 1.8 source and target version - Fix resulting compilation/test errors (Java8 has slightly different

Re: Euphoria Java 8 DSL - proposal

                      On 12/17/2017 07:00 PM, David Morávek                             wrote:                               Hello,                               First of all, thanks for the                             amazing work the Apache Beam        

Re: Euphoria Java 8 DSL - proposal

this >> helps, and please reach out if >> anybody on >> our end can help, >> including JB >> or myself. >> >>

Re: Euphoria Java 8 DSL - proposal

Hello, First of all, thanks for the amazing work the Apache Beam community is doing!      In 20

Re: Euphoria Java 8 DSL - proposal

gt;>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>

Re: Euphoria Java 8 DSL - proposal

gt;>>>> >>>>>>>> Hi guys >>>>>>>> >>>>>>>> A DSL would be very welcomed, in particular if fluent. >>>>>>>> >>>>>>>> Open question: did you study to implement Stre

Re: Euphoria Java 8 DSL - proposal

eamStream and a few more features like sides etc)? >>>>>>> Would be >>>>>>> very >>>>>>> natural and integrable easily anywhere and avoid a new API >>>>>>> discovery. >>>>>>> >>>>>>> Hazelcast jet

Re: Euphoria Java 8 DSL - proposal

  community is doing! In 2014, we've started development of the runtime independent Java 8 API, that helps us to create unified big-data processing flows. It has been used as a core building block of Seznam.cz web crawler data infrastructu

Re: Euphoria Java 8 DSL - proposal

! Regards JB On 12/17/2017 07:00 PM, David Morávek wrote: Hello, First of all, thanks for the amazing work the Apache Beam community is doing!      In 2014, we've started development of the runt

Re: Euphoria Java 8 DSL - proposal

    Thanks ! Regards JB On 12/17/2017 07:00 PM, David Morávek wrote: Hello, First of all, thanks for the amazing work the Apache Beam community is doing!      In 2014, we've started development o

Re: Euphoria Java 8 DSL - proposal

Thanks ! Regards JB On 12/17/2017 07:00 PM, David Morávek wrote: Hello, First of all, thanks for the amazing work the Apache Beam community is doing! In 2014, we've started devel

Re: Euphoria Java 8 DSL - proposal

eaking, having different fluent DSL on top of the >> Beam >> SDK is great. >> >> I would like to take a look on your wordcount examples to give >> you a >> complete feedback. I like the idea and a fluent Java DSL is >> valuable. >> >&g

Re: Euphoria Java 8 DSL - proposal

e amazing work the Apache Beam community is doing! In 2014, we've started development of the runtime independent Java 8 API, that helps us to create unified big-data processing flows. It has been used as a core building block of Seznam.

Re: Euphoria Java 8 DSL - proposal

(I worked on the Camel Java >>> DSL while ago, so I have some experience here). >>> >>> Thanks ! >>> Regards >>> JB >>> >>> On 12/17/2017 07:00 PM, David Morávek wrote: >>> >>>> Hello, >>>> >&g

Re: Euphoria Java 8 DSL - proposal

happy to help you for the donation (I worked on the Camel Java >> DSL while ago, so I have some experience here). >> >> Thanks ! >> Regards >> JB >> >> On 12/17/2017 07:00 PM, David Morávek wrote: >> >>> Hello, >>> >>> >&

Re: Euphoria Java 8 DSL - proposal

amazing work the Apache Beam community is >> doing! >> >> >> In 2014, we've started development of the runtime independent Java 8 API, >> that helps us to create unified big-data processing flows. It has been used >> as a core building block of Seznam.cz web

Re: Euphoria Java 8 DSL - proposal

, we've started development of the runtime independent Java 8 API, that helps us to create unified big-data processing flows. It has been used as a core building block of Seznam.cz web crawler data infrastructure every since. Its design principles and execution model are very similar to Apache

Euphoria Java 8 DSL - proposal

Hello, First of all, thanks for the amazing work the Apache Beam community is doing! In 2014, we've started development of the runtime independent Java 8 API, that helps us to create unified big-data processing flows. It has been used as a core building block of Seznam.cz web crawler data

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

sers 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 PM Reuven Lax <

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

:21 PM Reuven Lax <re...@google.com.invalid> > >> wrote: > >> > >> > 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 > >> > conce

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

at 11:21 PM Reuven Lax <re...@google.com.invalid> >> wrote: >> >> > 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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

e: > > > 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 i

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

7 at 11:21 PM Reuven Lax <re...@google.com.invalid> wrote: > 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 >

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

er 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 warning

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

>>> > >>>> 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 i

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

hat >>>> (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 >>>

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

>> (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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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 fi

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

t'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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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 becau

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

n'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

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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 exis

Re: Possibility of requiring Java 8 compiler for building Java 7 sources?

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

  1   2   >