Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[Remi Forax]

About multiple versions or true hiding of non exported packages, I do not believe that someone is against those features.

But they both requires to change the VM in an extensive way and to my knowledge nobody has ever done a prototype of those features.

The good news is that both these features can be introduced later in a compatible way.

I would love to see Oracle or RedHat to put engineering ressources on these features, but until that, the reality is that those features are not blockers to the release of JPMS*

Rémi 
* given the tumultuous past of the modules in Java, being able to release something even if not perfect, is already a victory.







On April 25, 2017 3:16:54 PM GMT+02:00, Michael Nascimento <misterm at gmail.com> wrote:
>On Tue, Apr 25, 2017 at 10:10 AM, David M. Lloyd
><david.lloyd at redhat.com>
>wrote:
>
>> Just the fact that there is the *very idea* of a "fit"/"non-fit" for
>JPMS
>> is sad though.  It should have been the ubiquitous thing that
>everyone was
>> expecting.  But denying multiple versions?  Blowing up on run time
>cycles?
>> Reneging on the idea of being the basis of Java EE 9? These are
>things that
>> people will not be expecting.
>
>
>Some extra feedback: I delivered a talk yesterday at QCon SP and people
>were very much disappointed with these limitations, and also the fact
>packages must be defined by a single module even if they are not
>exported,
>because it was considered nearly impossible to track in real world
>scenarios.
>
>Regards,
>Michael

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.