Many different people understand different things for Java 11 compatibility and probably the easiest path for us is to define exactly what we (Beam) meant with being Java 11 compatible.
The definition that Michał gave seems aligned with the current scope. Beam published artifacts compiled with Java 8 work correctly in machines that run a Java 11 VM (and we validate this with the ValidatesRunner tests + examples). By this definition, we may consider that both Direct runner and Dataflow are Java 11 compatible, but we cannot argue this for other runners like Spark or Flink because neither of those natively support Java 11 yet [1] [2]. Probably we should specify for which runners we do validate Java 11 compatibility in the CI since this will evolve once Flink 1.10 and Spark 3.0 are released. We could argue that with portability supporting Java 11 and newer versions will be easier, but the runner part is still tight with the execution system so for the moment we will have a per case approach (the exception could be portable runners not based on Java). Of course other definitions of being Java 11 compatible are interesting but probably not part of our current scope. Actions like change the codebase to use Java 11 specific APIs / idioms, publish Java 11 specific artifacts or use Java Platform Modules (JPM). All of these may be nice to have but are probably less important for end users who may just want to be able to use Beam in its current form in Java 11 VMs. What do others think? Is this enough to announce Java 11 compatibility and add the documentation to the webpage? Ismaël [1] https://issues.apache.org/jira/browse/FLINK-10725 [2] https://issues.apache.org/jira/browse/SPARK-24417 ps. Thanks Elliotte for the pointer to the best practices repo, lots of interesting info there. On Fri, Aug 9, 2019 at 1:02 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > Another useful thing to improve Java 11 support is to add > Automatic-Module-Name headers to the various JARs Beam publishes: > > > https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-20.md > > If a JAR doesn't include this, Java synthezizes one from the name of the > jar file, and things get wonky fast. This is a low risk change that has no > effect on non-modular and pre-Java-9 apps. > > > On Wed, Aug 7, 2019 at 9:41 AM Michał Walenia <michal.wale...@polidea.com> > wrote: > >> Hi everyone, >> >> I want to gather the collective knowledge here about Java 11 >> compatibility and ask about the tests needed to deem Beam compatible with >> JDK 11. >> >> Right now concerning testing JDK 11 compatibility I implemented: >> >> - Jenkins jobs for running ValidatesRunner test sets in both Direct >> and Dataflow runners, [1], [2] >> - ValidatesRunner portability API tests for Dataflow [3], >> - examples in normal and portable mode for the Dataflow runner [4], >> [5]. >> >> >> Are these tests sufficient to say that we’re java 11 compatible? What >> other aspects do we need to test to be able to say that? >> >> >> Regards, >> >> >> Michał >> >> [1] >> https://builds.apache.org/job/beam_PostCommit_Java11_ValidatesRunner_Direct/ >> [2] >> https://builds.apache.org/job/beam_PostCommit_Java11_ValidatesRunner_Dataflow/ >> [3] >> https://builds.apache.org/job/beam_PostCommit_Java11_ValidatesRunner_PortabilityApi_Dataflow/ >> [4] >> https://builds.apache.org/job/beam_PostCommit_Java11_Examples_Dataflow/ >> [5] >> https://builds.apache.org/job/beam_PostCommit_Java11_Examples_Dataflow_Portability/ >> >> -- >> >> Michał Walenia >> Polidea <https://www.polidea.com/> | Software Engineer >> >> M: +48 791 432 002 <+48791432002> >> E: michal.wale...@polidea.com >> >> Unique Tech >> Check out our projects! <https://www.polidea.com/our-work> >> > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org >
