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
