Weakness of "requires public"

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Jason Greene" <jason.greene at redhat.com>
> À: "Paul Benedict" <pbenedict at apache.org>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "ZML-OpenJDK-Jigsaw-Developers" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mardi 26 Juillet 2016 23:56:34
> Objet: Re: Weakness of "requires public"

>> On Jul 26, 2016, at 4:50 PM, Paul Benedict <pbenedict at apache.org> wrote:
>> 
>> Okay, I accept your scenario for what it is. You created a very nice
>> example to illustrate your point where everything must be one, but you know
>> not every project is like this. The whole discussion with Joda Time was
>> based on having additional functionality from classes which were optional
>> at runtime. I am raising the issue that transitive dependencies are also
>> sometimes optional at runtime. Where is the relief for this scenario? It
>> doesn't exist -- but it should. Just imagine M1 was a 5MB library and B's
>> only use of A was buried in some code I never trigger. Here the module
>> author is going to make me lug around 5MB just because. That's a ridiculous
>> constriction.
>> 
>> Is transitive dependencies a language concern? No.
>> Is this a build tool concern? Yes.
>> Is Java a build tool? No.
> 
> It’s definitely a runtime concern. You need class visibility and accessibility
> to have the ability to see and interact with API dependencies.
> 
> It also adds flexibility in refactoring. I can split a module into two modules
> for example, and then create a delegate in the middle that "requires public" on
> both.

+1

> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat

Rémi