modulepath and classpath mixture

[David M. Lloyd]

On 03/22/2016 07:06 AM, Peter Levart wrote:
>
>
> On 02/24/2016 08:30 PM, Robert Scholte wrote:
>> On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman
>> <Alan.Bateman at oracle.com> wrote:
>>
>>>
>>> On 23/02/2016 21:10, Robert Scholte wrote:
>>>> :
>>>>
>>>> If I understand this correctly I need to know the module name.
>>> Has there been any discussion around having the module name in the
>>> POM?  From the mails then it sounds like the project is mostly
>>> "unaware" that it is creating a module. The other thing that comes to
>>> mind is the source layout and whether it will get to the point where
>>> the module name is in the file path. I'm mostly thinking of multi
>>> module projects where one might have the source to multiple modules
>>> in the same source tree.
>>>
>>> -Alan
>>
>> The name of the module with not end up in pom-4.0.0, it'll simply
>> break the xsd and would have effect on all other tools/IDEs/etc
>> depending on the pom.
>> The only place where one might specify the module name is in the
>> configuration of the maven-compiler-plugin.
>> In Brussels we talked about multimodules, but it makes more sense that
>> 1 Maven project contains zero or one module-info[1].
>> And yes, I think a MavenProject will probably be unaware of its own
>> module name. It knows its source roots and outputdirectories (for both
>> main/java and test/java) and the packaged jar. Based on the
>> availability of the module-info in one of these locations it knows how
>> to construct the commandline arguments.
>> At least, this is what I'm hoping to achieve.
>>
>> thanks,
>> Robert
>>
>> [1] https://twitter.com/rfscholte/status/694599731515899904
>
> Hi Robert,
>
> Why do you want to support tests that "inject" classes into packages of
> main artifact? Is this mainly because that's how it is done today? With
> modules I would rather create tests in its own module and use qualified
> exports from otherwise concealed packages of main module to give tests
> access to types that are not accessible otherwise. This however means
> that main module would have to use public qualifier on types and members
> to allow test module to access them. In effect substituting the
> package-private-nes with partly concealed packages to enable testability.
>
> Perhaps jigsaw should realize that testabililty is an important aspect
> to support. Forcing tools to compile a suitable set of javac and java
> options to compile or inject new classes into an existing module and
> augment it's dependencies is not very pleasant. Maybe this could be
> supported with a little twist to the accessibility rules. Let me borrow
> a rough idea that already circulated this list a while ago and modify it
> to fit on the top of jigsaw accessibility rules.
>
> Suppose that a qualified export of a package to the specific module(s)
> could be augmented with say a "private" keyword:
>
> module my.mod {
>      requires ...;
>      export private my.mod.internal to my.mod.test;
> }
>
> module my.mod.test {
>      requires my.mod;
>      requires junit;
> }
>
> ...which would not only export the package to the specific module(s),
> but also enable access to package-private types/members of that package
> from the target module(s) as though those types/members were public for
> them and for them only.

FWIW This is something I've been asking for in the JPMS EG.  I think 
this would be an incredibly powerful and useful security tool... and 
could also potentially eliminate lots of "shared secrets" from the JDK 
code base (and a few others as well).  Not just for tests but also for 
other existing code bases which today have to rely on 
privacy-by-convention/documentation for this kind of sharing.

> It would only be possible to specify "private" keyword with qualified
> exports - not with unqualified.
>
> Would that be against any jigsaw goals?
>
> Regards, Peter
>

-- 
- DML