Hi all, I want to contribute more actively to this and push Beam as close as currently possible towards Java11 both in terms of running and compiling the project with it.
I needed a bigger picture so I created a spreadsheet to have a clear roadmap for the whole process. It starts with testing existing java 8 artifacts (part of this is already done) and continues with providing compile support and later JPMS support for the project. I figured that before I storm JIRA with some new subtasks of BEAM-2530 it's good to have something like this thought through. I hope this is also helpful for others if they want to help to migrate the project to Java 11. Here's the spreadsheet: https://s.apache.org/java11-support-roadmap Any comments highly appreciated. :) FWIW, grpc devs ’’will be looking into options" for resolving the above-mentioned gprc issue "this quarter": https://github.com/grpc/grpc-java/issues/3522 Thanks! Łukasz śr., 21 sie 2019 o 20:46 Kenneth Knowles <k...@apache.org> napisał(a): > > > 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. >> > > 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 >> elh...@ibiblio.org >> >
