Thanks again Elliotte for the clear information and references. It seems that being compatible with Java 11 modules will be more elusive than expected considering the transitive dependencies. Do you (or someone else) knows if there there is a plugin or easy way to discover this?
I think that solving this for transitive dependencies will be elusive for a LONG LONG time (I had not even thought about IO modules that have dependencies and commonly live in ‘older’ stable versions). So maybe we should just announce for end users that they can run Beam pipelines in Java 11 but that for the moment Beam modules cannot be used in Java 11 module style. I know that there is already a lot of fear around Java 8 not being maintained so this will probably be perceived well even if not perfect. I filled https://issues.apache.org/jira/browse/BEAM-8021 to set explicitly the module names. We will probably need also to put some validation in place that the jars always include the module name so new modules don’t forget to do so. On Wed, Aug 21, 2019 at 3:28 AM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > > If somebody is using JPMS and they attempt to import beam, they get a > compile time error. Some other projects I work on have been getting > user reports about this. > > See > https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-19.md > for more details. > > On Tue, Aug 20, 2019 at 5:30 PM Ahmet Altay <al...@google.com> wrote: > > > > > > > > On Tue, Aug 20, 2019 at 8:37 AM Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > >> > >> > >> > >> On Tue, Aug 20, 2019 at 7:51 AM Ismaël Mejía <ieme...@gmail.com> wrote: > >>> > >>> 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? > >> > >> > >> No, it isn't, I fear. We don't have to use JPMS in Beam, but Beam really > >> does need to be compatible with JPMS-using apps. The bare minimum here is > >> avoiding split packages, and that needs to include all transitive > >> dependencies, not just Beam itself. I don't think we meet that bar now. > > > > > > For my understanding, what would be the limitations of Beam's dependencies > > having split dependencies? Would it limit Beam users from using 3rd party > > libraries that require JPMS supports? Would it be in scope for Beam to get > > its dependencies to meet a certain bar? > > > > Ismaël's definition of being able to run Beam published dependencies in > > Java 11 VM sounds enough to me "to announce Java 11 compatibility _for > > Beam_". > > > >> > >> > >> -- > >> Elliotte Rusty Harold > >> elh...@ibiblio.org > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org
