Compile time vs. runtime deps was: Requires optional permits

[Paul Sandoz]

On Jul 11, 2012, at 9:22 AM, Jaroslav Tulach wrote:

> Dne St 11. července 2012 08:59:20, Paul Sandoz napsal(a):
>> On Jul 11, 2012, at 8:28 AM, David Holmes wrote:
>>>> 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!).
>> Yes, but the dependency can also be direct at compile time and optional at
>> install time, it's just that "requires optional" does not differentiate
>> between the two cases.
>>> 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."
>> That's seems reasonable to me. I will try and get some clarification on
>> this.
>> 
>> Perhaps the resolver should output warnings at compile time for optional
>> modules that are not present to augment any "cannot find symbol" compiler
>> errors?
> 
> I believe both cases are possible. I can have optional dependency I need to 
> compile against and I can as well have another optional dependency I don't 
> need to compile against.
> 

Yes


> There needs to be a way to express that properly to Jigsaw runtime as well as 
> Javac.
> 

I was wondering the same.


> This is another example when runtime and compile time dependencies may  
> differ. The first one I know is the list of annotation processor providing 
> modules to be present when compiling, but not during execution.
> 
> Time to introduce "requires compile m at 1.0"?

Scopes!

Just to be clear: the annotation processor case is different from the two cases previously discussed with "requires optional", where defensive coding is used to deal with absence of the optional dependency at runtime.

I suspect modular annotation processor support will require container support to isolate dependencies of compiling the application from the dependencies of the annotation processors. I can imagine something similar is required for test dependencies.

Paul.