Weakness of "requires public"

[Jason Greene]

> 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.

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