modulepath and classpath mixture

[Jonathan Gibbons]

On 02/23/2016 01:22 PM, Robert Scholte wrote:
> On Tue, 23 Feb 2016 22:14:32 +0100, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>>
>>
>> On 02/23/2016 01:06 PM, Jonathan Gibbons wrote:
>>>
>>>
>>> On 02/23/2016 12:48 PM, Robert Scholte wrote:
>>>> On Tue, 23 Feb 2016 01:52:50 +0100, Jonathan Gibbons 
>>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 02/22/2016 12:44 PM, Robert Scholte wrote:
>>>>>> Hi,
>>>>>>
>>>>>> first of all I'd like to say that I'm very pleased with the new 
>>>>>> -mp options, these matches better with the way Apache Maven would 
>>>>>> like to work with jars and class-folders.
>>>>>>
>>>>>> Here's my use case: I noticed that if I add a module-info to 
>>>>>> src/main/java and put all compile-scoped dependencies to the 
>>>>>> module path, all compiles fines.
>>>>>> I assume that developers are less interested in adding a 
>>>>>> module-info.java file to src/test/java, so that's what I'm doing 
>>>>>> right now too.
>>>>>> Now it seems that I *must* add compile + test scoped to the 
>>>>>> *classpath* to be able to compile the test classes.
>>>>>> My first approach was to leave the compile-scoped dependencies on 
>>>>>> the modulepath and all test-scoped dependencies on the classpath, 
>>>>>> so the modules keeps their inner related structure, but it seems 
>>>>>> that the classpath classes cannot access the modulepath classes.
>>>>>>
>>>>>> I'm looking for the confirmation that putting all dependencies on 
>>>>>> the classpath is indeed the right approach in this case.
>>>>>>
>>>>>> thanks,
>>>>>> Robert
>>>>>
>>>>> Robert,
>>>>>
>>>>> We definitely need some more detailed notes on setting up javac 
>>>>> compilations (note to self!) but one thing to note is that by 
>>>>> default, the unnamed module (i.e. code on the classpath) only has 
>>>>> observability of the modules in the system image. To make modules 
>>>>> on the module path observable, you need to use the -addmods option.
>>>>>
>>>>> -- Jon
>>>>
>>>> Hi Jonathan,
>>>>
>>>> this would indeed explain what I'm facing right now. However, 
>>>> adding -addmods gives me the following exception:
>>>> Caused by: java.lang.IllegalArgumentException: -addmods requires an 
>>>> argument
>>>>         at 
>>>> com.sun.tools.javac.main.Arguments.error(jdk.compiler at 9-ea/Arguments.java:708)
>>>>
>>>> Is -addmods followed by the same entries as -modulepath or by the 
>>>> modulenames. I really hope it is not the latter, because that would 
>>>> mean that I first need to discover and read all module-info files.
>>>>
>>>> thanks,
>>>> Robert
>>>
>>> Sorry, I should have been more explicit.
>>>
>>> Both javac and java (the launcher) accept an option "-addmods 
>>> <module-name>,..." which can be used to name modules to be included 
>>> in the module graph.   Confusingly, for javac, the option is listed 
>>> under javac -X (that's a bug we will fix), but setting that aside, 
>>> here's what the command line help says:
>>>
>>>   -addmods <modulename>[,<modulename>...] Root modules to resolve in 
>>> addition to the initial modules
>>>
>>> "java -help" says effectively the same.
>>>
>>>
>>> So yes, the option takes a list of module names, not module paths.
>>>
>>> -- Jon
>>>
>>>
>>>
>>
>>
>>
>> ... but that being said, note that you don't have to list all the 
>> modules on the module path.    You only need to list root modules, 
>> and javac will determine the transitive closure of all the necessary 
>> modules.
>>
>> So, if you're writing tests in the unnamed module, to test a module 
>> M, the chances are that you only need "-addmods M".
>>
>
> This makes sense. And although I still don't like the fact that this 
> requires me to read the module-info, this should be possible for the 
> target/mods/m (since it is already compiled).
> So my response to Alan was probably a bit too fast.
> This requires some tricks on our side to stay compatible with lower 
> Java versions while adding some code to read the module-info.
>
> thanks,
> Robert


When we've had discussions about how these options might work, we've 
generally assumed you might have some a priori knowledge of the module 
name from some other context, rather than having to rely on reading 
module info.

-- Jon

>
>
>>
>> Alan wrote a separate email about different compilation scenarios. 
>> Note that in many/most of those cases, no -addmods was necessary.
>>
>>
>> -- Jon
>
>