modulepath and classpath mixture

[Robert Scholte]

Hi,

I've asked for some feedback and there seems to be concerns with split  
packages when there are two or more modules on the module path that export  
the same package.
Unless I misunderstand the issue, I'd say you have the same problem with  
-addmods. If you add mod1 and mod2, which both export the same package,  
you have exactly the same issue, right?

When talking about exports it made me realize there's probably another  
issue: only the exported packages of the "main"-module are accessible,  
right? Since src/test/java has no module-info, the -Xpatch is useless.
An idea that comes to my mind is something like -mainModule <arg>, where  
are either a jar or directory containing module-info. All its classes can  
be accessed by the classes on the classpath, all other modules keep their  
package access restrictions.

thanks,
Robert

On Sat, 27 Feb 2016 16:56:22 +0100, Jonathan Gibbons  
<jonathan.gibbons at oracle.com> wrote:

> At the risk of opening bikesheds, if we go that way, I would suggest  
> just  -ALL-   or just a new option -addallmods.
>
> -- Jon
>
>
> On 02/27/2016 03:25 AM, Robert Scholte wrote:
>> Hi,
>>
>> I noticed[1] that -addmods already has a special option: ALL-SYSTEM
>> What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which  
>> simply exposes all modules on the modulepath to the classpath. The set  
>> of moduleEntries on the modulePath are already chosen with care and are  
>> in the end all required to be able to compile the test-classes without  
>> the need of knowing the name of the module being used to compile with.
>>
>> thanks,
>> Robert
>>
>> [1] http://openjdk.java.net/jeps/261
>>
>>
>> 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
>>
>>
>


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