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 <malac...@gmail.com
<mailto:malac...@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 <pbened...@apache.org
<mailto: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 <mailto: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
>
