On Tue, Aug 20, 2019 at 8:37 AM Elliotte Rusty Harold <[email protected]> wrote:
> > > 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. > We definitely don't meet the basic bar ourselves, unless someone has done a lot of clean up. We've had classes shuffled from jar to jar quite a lot without changing their namespace appropriately. It may be mostly limited to runner-facing pieces, but I expect for a number of runners (notably the Direct Runner) that is enough to bite users. Kenn > > -- > Elliotte Rusty Harold > [email protected] >
