Compile time vs. runtime deps

[David Holmes]

On 12/07/2012 11:26 PM, Jaroslav Tulach wrote:
> Dne Čt 12. července 2012 10:54:27, David Holmes napsal(a):
>>>> I don't see why I need to make the distinction to the compiler. I
>>>> declare an optional dependency and at compile-time it is, or isn't
>>>> found.
>>>
>>> That could produce different result during the compilation. The
>>> compilation
>>> could either succeed or fail. Javac and IDEs need to know whether the
>>> optional (in runtime) library should or should not be on the compilation
>>> "classpath".
>> You mean the tools are going to dynamically examine my
>> module-info.java/class and use it to determine what they should set
>> modulepath/classpath to ???
>
> Hello David,
> yes, that is the jigsaw plan. module-info.java is going to be the source of
> compilation classpath for javac. It is supposed to save us for "classpath
> hell". However, unlike other tools that shield us from such "hell", the
> current design addresses just a half (at most) of the problem. Should it stay
> this way, we are going to be faced to "classpath nightmare"...
>
>> That is not something I would have expected at all.
>
> I guess you are looking at Jigsaw from VM perspective, then! That is OK, but
> the Jigsaw tries to define (a bit of) tooling story too.

Nothing to do with VM perspective. I just don't expect my compiler or 
IDE to go and find a missing module for me. If the module is needed and 
missing then I get an error at compilation time. If the dependency is 
listed in module-info.java I still get an error at compilation time. 
Unless you expect the tool to try and resolve the problem (which I 
don't) then I don't see how adding something in module-info.java makes a 
difference.

David
-----

>> If I build a project
>> and the optional, but needed at compile-time, module is not present then
>> I get a compilation error: type XXX not found. It is then up to me to
>> realize that I am missing the module that exports XXX and either install
>> it to the main library or add the library it is in to the appropriate
>> path. (Just as I would have to add the jar file today.)
>
> The vicious circle is closed by noting that the "appropriate path" is
> expressed in module-info.java. And we are back where we started: this missing
> module is required for compilation, but optional for execution - we need a way
> to express that inside of module-info.java.
> -jt
>
>>
>>>> During compilation I reference a type and a module for that type
>>>> is, or isn't, found. Whether the module was omitted or was optional it
>>>> is simply a compile-time error if the type is not found. (I don't expect
>>>> javac to know or determine that the not-found type would have been found
>>>> in the missing optional module - how could it?)
>>>
>>> The Javac and IDEs have to know. My proposal was to introduce some way of
>>> telling the system that there is a compile time only dependency. Thus for
>>> the case when you want a fully optional dependency you could say:
>>>
>>> requires optional m at 1.0;
>>>
>>> which would mean "m at 1.0" should not be present while compiling. Or one
>>> could use
>>>
>>> requires compile optional m at 1.0;
>>>
>>> which would make the "m at 1.0" optional during execution, but Javac and
>>> other
>>> source processing tools would know that it has to be present.
>>
>> Seems like an unnecessary complication to the module system to me.
>>
>> Cheers,
>> David
>>
>>> -jt
>>>
>>>>> 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"?
>>>>> -jt