Requires optional permits <was> Re: Service provider module resolution

[David Holmes]

On 11/07/2012 7:19 PM, Neil Bartlett wrote:
> You don't have to interact with the optional dependency purely with
> reflection. You could check for the availability of the class first
> with ClassLoader.loadClass() or Class.forName(), and if that doesn't
> throw an exception then you can proceed and use the class in the
> normal way. Of course this has to be done before calling any code that
> has the dependency, whether directly or indirectly e.g. via a
> supertype.
>
> I have sometimes seen this done in OSGi, alhough optionality at the
> level of static class/package dependencies is widely considered to be
> a bad practice.
>
> If you do this then you clearly need the dependency at compile time
> but it is not needed at runtime. This is one of several reasons why
> compile dependencies differ from runtime dependencies.

Sure. If you need it at compile time you need it at compile time. But if 
you don't you don't. My issue is with the apparent requirement that you 
_must_ be able to resolve the optional dependency at compile-time, 
whether you _need_ it or not. And I don't see that I should have to 
pre-declare whether I have a compile-time dependency or only a runtime 
one, as that will become self-evident at compile-time.

Cheers,
David


> Neil
>
>
> On Wed, Jul 11, 2012 at 7:28 AM, David Holmes<david.holmes at oracle.com>  wrote:
>> On 11/07/2012 4:12 PM, Paul Sandoz wrote:
>>>
>>> On Jul 11, 2012, at 3:53 AM, David Holmes wrote:
>>>>>
>>>>>
>>>>> IIUC from reading the Jigsaw Big Picture document an optional dependency
>>>>> must resolve at compile time, if such a dependency is not resolvable due to
>>>>> permits or otherwise no module being present then resolution should fail.
>>>>
>>>>
>>>> Are you only referring to an optional dependency on a module which in
>>>> turns has a permits clause?
>>>
>>>
>>> An optional dependency in general. From the Jigsaw Big Picture document:
>>>
>>> "
>>> Optional dependences
>>> A dependence from one module to another can be declared optional:
>>>
>>> module bar {
>>>       requires optional foo;
>>> }
>>>
>>> If no foo module is available then bar can still be installed and invoked.
>>> Code in bar that uses types from foo must be written defensively so that it
>>> operates properly when foo is not available.
>>>
>>> A foo module must still be available when compiling bar since code in bar
>>> can depend upon types declared in foo.
>>> "
>>>
>>>> I would not in general expect to have to resolve an optional dependency
>>>> at compile time.
>>>
>>>
>>> I was of the same opinion but then changed my mind.
>>>
>>> If there is an optional dependency then presumably code in the depending
>>> module must be using types exported by the optional dependent module.
>>> Reflection is one way to use those types, another is a little bit of
>>> indirection (static or via reflection) to static usage of those types.
>>
>>
>> I think this is wrong. I can use the optional module reflectively so that
>> there is no direct type dependency (else the dependency would not be
>> optional!). There is no reason that it needs to be present at compile time
>> if I don't use those types directly. I would think the above statement from
>> the Big Picture should read:
>>
>> "A foo module must still be available when compiling bar _if_ code in bar
>> depends upon types declared in foo."
>>
>> Cheers,
>> David
>> -----
>>
>>> Paul.