modulepath and classpath mixture

[Robert Scholte]

On Wed, 24 Feb 2016 00:15:26 +0100, Jonathan Gibbons  
<jonathan.gibbons at oracle.com> wrote:

>
>
> 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
>

Hmm, would have been nice if I had known about these discussions, because  
I don't think that this is a valid assumption from a Maven perspective.  
Ideally developers simply add module-info.java files to the source-roots  
of their choice and Maven should be able to construct the correct set of  
javac arguments.
I don't expect developers to open a jar to see if there's a module-info  
available. Actually, how can he figure out the module name, since the  
module-info is a compiled file?
Anyhow, Maven is capable to discover the module name when required, but it  
is not that efficient. Maybe it is time to work on some feedback to  
describe the issues I'm facing regarding some of the javac options.

thanks,
Robert

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


-- 
Using Opera's mail client: http://www.opera.com/mail/