The critical missing pieces and a path forward

[Michael Nascimento]

On Tue, May 9, 2017 at 10:19 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> Think of, say, an enterprise environment where different components are
> developed by different teams, and they later decide over time that each
> must use APIs from one another, for various reasons.  They should not have
> to fight over which group must refactor their module to split API and
> implementation.  Sometimes, particularly in an enterprise environment, such
> a split just doesn't make any sense.
>

Or such a split is not realistically possible in such an environment due to
corporate politics. As ridiculous as it sounds, multiple versions and
cycles must be allowed because when you have multiple open-source projects
and multiple groups/divisions in an company working to assemble one
application, while it would be theoretically possible to polish modules and
dependencies to abide to JPMS current rules, it is not politically possible
to do so. And as painful as it sounds, these corporate users is what makes
the Java ecosystem financially valuable.

So, please, don't disregard these points. If these big corporate users
cannot adopt JPMS, at some point they will adopt a different language that
works for them without so many rules.

Regards,
Michael