Weakness of "requires public"

[Malachi de Ælfweald]

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 <pbenedict at 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.buckley at 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
> >
>