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?
There is also the work necessary to build/run tests with Gradle.... I am also curious... how much work do you estimate is necessary to support Java 11 with some of the existing sources? I understand that we have many, many sources, but perhaps some of the more popular ones (e.g. TextIO)? Thanks! -P. On Wed, Oct 10, 2018 at 12:59 AM Arif Kasim <arifka...@google.com> wrote: > 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 <ieme...@gmail.com> wrote: > >> 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 versions) but at the time we were at 5 tests >> from getting sdks/core passing. Notice also that the scope of this >> JIRA evolved to support only the LTS version (Java 11), and >> specifically to support only sdks/core + direct runner. Supporting all >> IOs or runners really is more a question of the dependencies working >> nicely with Java 11 so this will probably take long time. Also the >> idea so far does NOT include supporting the Java module system at all. >> >> I stopped working on this during the move to gradle because it was too >> hard to tackle both Java evolving and all the ongoing changes in the >> build system. If somebody in the community wants to contribute in this >> area it will be greatly appreciated, notice that all the work we did >> on the build system for this needs to be implemented now in gradle >> too. >> On Sat, Oct 6, 2018 at 5:55 PM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> > >> > @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 | Github | LinkedIn | Book >> > >> > >> > Le sam. 6 oct. 2018 à 17:51, Reuven Lax <re...@google.com> a écrit : >> >> >> >> 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 < >> rmannibu...@gmail.com> wrote: >> >>> >> >>> 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 >> want to use modules (but there is no real reason to do that yet in java). >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >> >>> >> >>> >> >>> Le ven. 5 oct. 2018 à 19:10, Arif Kasim <arifka...@google.com> a >> écrit : >> >>>> >> >>>> Hello, >> >>>> What's the status of java version > 8 support for beam? Thanks. >> >>>> >> >>>> -Arif. >> >
