modulepath and classpath mixture

[Paul Benedict]

Russell, if you have a module with package X and a classpath jar with
package X, the module can't see package X from the classpath.

In the last several posts, there's been discussion on putting tests on the
classpath; keeping the "main" code in the module. So given what I stated
above, that's what I've been referring to.

Cheers,
Paul

On Wed, Mar 30, 2016 at 7:28 AM, Russell Gold <russell.gold at oracle.com>
wrote:

> Hi Paul,
>
> Could you explain? What kind of code do you mean cannot access it? And
> what do you mean by “a split package situation”?
>
> From a conversation I had with Alan, earlier in this thread:
>
>
> On Mar 23, 2016, at 11:42 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
> On 23/03/2016 14:15, Russell Gold wrote:
>
> Here are my assumptions, which you can correct.
>
> 1. A jar or classes directory placed on a class path are treated as part
> of the unnamed module
>
> Yes
>
>
> So if the tests and main code are both in directories, which they have
> been up to now in Maven, why would there be a problem? Both would be in the
> unnamed module and able to access one another.
>
> - Russ
>
> On Mar 29, 2016, at 10:47 PM, Paul Benedict <pbenedict at apache.org> wrote:
>
> Russell, when you drop a jar on the classpath, module code will not be
> able to access it in a split package situation. That's the big barrier
> here. Maven test projects are typically written with the same package
> shared with the "main" code.
>
> Cheers,
> Paul
>
> On Tue, Mar 29, 2016 at 11:33 AM, Russell Gold <russell.gold at oracle.com>
> wrote:
>
>> Hi Stephen,
>>
>> Why do you need any kind of friend access?
>>
>> It seems to me that this is making things harder than they need to be.
>> The tests can simply run with the production code on the class path, and
>> then there are no module issues at all.
>>
>> I think a larger problem is that you can do what I just said with the
>> jars, even a jar which has been designated as a module by virtue of having
>> a module-info.class in it. That means that, when users are up taking jars,
>> they are not prevented from accessing module internals. They can put the
>> jars on the module path, of course, but they can still use them on the
>> class path!
>>
>> - Russ
>>
>> >
>> > On 28 March 2016 at 11:13, Remi Forax <forax at univ-mlv.fr> wrote:
>> >> Hi Stephen, Hi all,
>> >> I think that delivering tests as a separated module is a bad idea.
>> >>
>> >> I see that from the point of a developer, seeing the code and the test
>> as different modules can be attractive because everything seems to be put
>> at the right place but there is a big drawback. Because modules are reified
>> at runtime, it means that the runtime environment of the tests will be
>> different from the production environment.
>> >
>> > This last sentence doesn't make sense to me - tests are not run in a
>> > production environment.
>> >
>> > Tests have all the qualities of modules - code, dependencies,
>> > compilation phase, deployment. The only special part is the need for
>> > special "friend-like" access, which Jigsaw already has for other cases
>> > (the export...to clause).
>> >
>> > Put simply, I consider that module =
>> > deployment-artifact-with-dependencies. With that mental model, putting
>> > tests inside the module is just not acceptable, because tests should
>> > not be deployed with the main application and they have different
>> > dependencies. If we disagree that module =
>> > deployment-artifact-with-dependencies, then perhaps we have bigger
>> > problems to solve here.
>> >
>> > Stephen
>> > (And to Paul Benedict, the classpath is going to die over time, so any
>> > solution that uses that is flawed IMO).
>> >
>> >
>> >> So as Alan said, from the jigsaw point of view at runtime, the tests
>> and the code should be in the same module.
>> >>
>> >> So the building tools have to come with a way to support to have 2
>> different module-info.java in two different folders and package them as one
>> module,
>> >> maybe javac should help by providing a way to merge 2 module-info at
>> compile time.
>> >>
>> >> Rémi
>> >>
>> >> ----- Mail original -----
>> >>> De: "Alan Bateman" <Alan.Bateman at oracle.com>
>> >>> À: "Stephen Colebourne" <scolebourne at joda.org>, "jigsaw-dev" <
>> jigsaw-dev at openjdk.java.net>
>> >>> Envoyé: Mercredi 23 Mars 2016 16:18:50
>> >>> Objet: Re: modulepath and classpath mixture
>> >>>
>> >>>
>> >>> On 23/03/2016 14:42, Stephen Colebourne wrote:
>> >>>> :
>> >>>>
>> >>>> I don't particularly care what the mechanism is for this, but at the
>> >>>> requirements level:
>> >>>> - there are two modules - main and test
>> >>>> - each has its own source tree
>> >>>> - each has its own dependencies
>> >>>> - each is released separately
>> >>>> - each could be hosted on a central repo
>> >>>> - the test module needs to be able to contain the same packages as
>> the
>> >>>> main module
>> >>>> - the test module needs to be able to invoke package-scoped code in
>> >>>> the same package in the main module
>> >>>>
>> >>>> To clarify further consider 4 modules, A, B, A-test and B-test where
>> B
>> >>>> depends on A. Module A-test may have a method foo() that uses package
>> >>>> scope to access something in A. Module B-test will depend on A-test
>> >>>> and rely on foo() to get access to that internal object.
>> >>> To your list, I would add the ability to make use of testing
>> frameworks
>> >>> like TestNG and JUnit.
>> >>>
>> >>> In any case, and as things currently stand, you've got most of the
>> >>> above. One differences is that the tests are not a separate module,
>> they
>> >>> are instead compiled and run in a way that patches the main module.
>> The
>> >>> second difference is that they don't have their own module
>> declaration,
>> >>> instead the compilation or run augments the dependences with any
>> >>> additional dependences that the tests have. As I said, if they tools
>> >>> makes it easy then I don't think it's too bad.
>> >>>
>> >>>>
>> >>>> (Note that I view the thread discussion of
>> >>>> references to test classes on the classpath as another hack.
>> >>>>
>> >>> Packages can't be split between modules and classpath so there is no
>> >>> support for that.
>> >>>
>> >>> -Alan
>> >>>
>>
>>
>
>