If your M3 depends on M2, how do you know what the current implementation of M2 does behind the scenes? How do you know it isn't depending on M1?
To give a concrete example, if an app depends on GSON, why should they know about all the internals of how the GSON library is written to know which method calls will call which other modules/libraries? If you want optional things at compile time, that seems more like a plugin approach (a'la ServiceLoader) where you are controlling which items get loaded - but that's different than what some black box does internally. Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 26, 2016 at 3:12 PM, Paul Benedict <pbened...@apache.org> wrote: > Alex, that's one half of the puzzle. The other half would be excluding it > at compile time too. In the scenario I was giving Remi, I do not even need > M1 at compile time. It can be completely eliminated from my project. > > Cheers, > Paul > > On Tue, Jul 26, 2016 at 4:58 PM, Alex Buckley <alex.buck...@oracle.com> > wrote: > > > On 7/26/2016 2:50 PM, Paul Benedict 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. > >> > > > > The #CompileTimeDependences proposal allows transitive dependencies to > > be optional at run time. It's the 'requires public static ...' use case. > > > > Alex > > >
