On Tue, Aug 20, 2019 at 7:51 AM Ismaël Mejía <[email protected]> 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. -- Elliotte Rusty Harold [email protected]
