----- Mail original ----- > De: "Jason Greene" <jason.gre...@redhat.com> > À: "Paul Benedict" <pbened...@apache.org> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "ZML-OpenJDK-Jigsaw-Developers" > <jigsaw-dev@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 <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. +1 > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat Rémi
