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 be important for us).
Łukasz [1] https://github.com/gradle/gradle/issues/5120 czw., 11 paź 2018 o 02:06 Pablo Estrada <pabl...@google.com> napisał(a): > 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. >>> >>
