Compile time vs. runtime deps

[David Holmes]

This is somewhat digressing but ...

On 13/07/2012 7:49 PM, Paul Sandoz wrote:
> On Jul 13, 2012, at 11:38 AM, David Holmes wrote:
>> On 13/07/2012 6:23 PM, Paul Sandoz wrote:
>>> On Jul 13, 2012, at 6:12 AM, David Holmes wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Do you expect that every developer, when checking out and building a project with such dependencies, deal with compile time errors?
>>
>> In general I don't expect users of a module to have to build it in the first place.
>
> Users no, developers yes.
>
>
>> I don't see why a developer of a module shouldn't have to deal with their own issues - they presumably understood that to use foo.bar they need to download and install foo.
>
> It is not just the developer of the module, but a developer in general who is interested in building that module.
>
> The expectation of many open source projects is that they should be easy to check out and build, otherwise it is a barrier to adoption.

That is true for projects involving native code because of the problems 
in getting binaries that will run on a thousand different flavours of 
system. But for Java surely this will be much rarer and limited again to 
modules that include native libraries.

I consider needing to get and build the source for a project as a 
barrier to adoption.

YMMV.

David

> Paul.