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
>

Reply via email to