modulepath and classpath mixture

[Remi Forax]

Alan, Jon,
i think javac -Xmodule should merge the module-info.java from the existing module and the one declared in the directory,
with the current semantics of the module-info, merging of modules is easy and with no corner cases,
so for testing, the test will be able to declare their own dependencies inside their own module-info.java.

Proposed semantics for merging,
- do the union of the required modules
  - if one required module is required publicly, it will be required publicly. 
- do the union of the exported packages
  - if one exported package is restricted, do the union of the restriction
- do the union of the uses.
- do the union of the provides.

so merging two modules is symmetric and will always succeed.

Rémi

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Russell Gold" <russell.gold at oracle.com>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mercredi 30 Mars 2016 15:45:03
> Objet: Re: modulepath and classpath mixture
> 
> On 30/03/2016 13:28, Russell Gold wrote:
> > :
> >
> >
> > 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.
> >
> There shouldn't any issue there, it should just work as it has always done.
> 
> The thread here has meandered a bit but I think the scenario under
> discussion is tests for a module that need to nestmate with the module
> under test. The tests are in their own test tree. The tests are compiled
> separately from the module they test and may have additional dependences
> (such as on TestNG or JUnit for example). When compiling or running then
> the tests need to access public types in non-exported packages and maybe
> package private members too. The support for this has been in jake for a
> long time but involves command line options that many developers or
> build environments won't immediately grok. In particular the tests have
> to be compiled "as if" they augment the already compiled module - that
> is what javac -Xmodule is about. There is no need to co-locate source
> files or class files of course. When run then the -Xpatch option is what
> brings the tests and the module classes together. If we get the tools
> right then most developers won't ever see this of course.
> 
> One other thing to say that we've already been through some of this with
> the JDK tests. The jtreg test harness that we use for the JDK tests has
> been updated (thanks to Jon Gibbons) with useful support for modules
> [1]. It's enough for us to write tests that use JDK-internal APIs or
> write tests that nestmate with types in system modules so that they get
> access to package private type or public types in non-exported packages.
> It has rudimentary support for user modules too. Additional dependences
> are still an issue but our tests don't require additional dependences
> beyond TestNG. The test harness employs a bit of hackery to get things
> done, important when starting out, but I expect will go away in time.
> 
> -Alan.
> 
> [1]
> http://hg.openjdk.java.net/code-tools/jtreg/raw-file/tip/src/share/doc/javatest/regtest/tag-spec.html
> 
> 
>