> On Jul 26, 2016, at 4:50 PM, Paul Benedict <pbened...@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
