Weakness of "requires public"

[Alex Buckley]

The developer of the main library gets to choose the strength of its 
dependence on the companion library. If the developer uses companion API 
types in the main library's API signatures, then I think it's good 
practice for the main module to say 'requires public companion' or 
'requires public static companion' (in the latter case, using Core 
Reflection to detect companion's presence). But if the developer ships 
the main library with no 'requires' clause of any kind targeting the 
companion library, then that's their choice.

Alex

On 7/26/2016 4:28 PM, Paul Benedict wrote:
> Malachi, it's not a matter of how one knows or even if one should know.
> It's not even a matter of how things should be but how things are. There
> are distributions that have a main library and companion libraries.
> Sometimes these are coded in a way such that the main library is API
> that knows about types in the supplemental API. If the supplemental API
> is available at runtime, the primary API can leverage it. This is
> typically done via testing with Class.forName() to load classes
> dynamically and reflective method calling.
>
> In today's world, I can tell Maven that I neither need to compile nor
> run with the supplemental library. I can completely exclude it from my
> build path. If for some reason, the author of such Maven module has the
> transitive dependencies incorrect, I can correct them.
>
> My point is there is no such parallel in Jigsaw to completely exclude a
> transitive module from compile and run time.
>
> Cheers,
> Paul
>
> On Tue, Jul 26, 2016 at 5:33 PM, Malachi de Ælfweald <malachid at gmail.com
> <mailto:malachid at gmail.com>> wrote:
>
>     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
>     <mailto: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 <mailto: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
>          >
>
>
>