modulepath and classpath mixture
Jonathan Gibbons
jonathan.gibbons at oracle.com
Thu Mar 31 00:10:29 UTC 2016
On 03/30/2016 02:45 PM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
> *De: *"Ali Ebrahimi" <ali.ebrahimi1781 at gmail.com>
> *À: *"Remi Forax" <forax at univ-mlv.fr>
> *Cc: *"Alan Bateman" <Alan.Bateman at oracle.com>, "Jonathan Gibbons"
> <jonathan.gibbons at oracle.com>, "jigsaw-dev"
> <jigsaw-dev at openjdk.java.net>
> *Envoyé: *Mercredi 30 Mars 2016 17:12:22
> *Objet: *Re: modulepath and classpath mixture
>
> So, do you suggest partial modules or module fragments?
>
>
> A kind of exploded module with sources available in more than one
> directory.
> Classes are still in one modular jar with one module-info.class (so at
> runtime, there is only one module).
>
>
> Why we make things so complex for writing single test method. I
> think testing is an essential part of development, so modular java
> should have first class support for that.
> I don't see command line options as developer friendly solution,
> even things gets worse when have dozen of modules.
>
>
> That's another question, i think we first need to agree that we just
> want to have the main code and the test code into different directory
> and then we can see if javac -Xmodule is the best syntax or if by
> example -modulesourcepath can accept to have several directories that
> describe the same module.
-modulesourcepath can accept several source directories that together
comprise the source for a single module. If nothing else, you can see
this utilized in the JDK build, where the source structure for a module
may contain subdirectories for platform-independent classes,
platform-specific classes, and dynamically generated classes.
The primary constraints are that there is only one module-info.java
file, and the mapping to a class output directory.
There is nothing to prevent you recompiling an entire module, including
test code, to create a new version of the module, including the test
code. If you so choose.
-- Jon
>
> cheers,
> Rémi
>
>
>
> On Wed, Mar 30, 2016 at 6:42 PM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
>
> 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
> <mailto:Alan.Bateman at oracle.com>>
> > À: "Russell Gold" <russell.gold at oracle.com
> <mailto:russell.gold at oracle.com>>
> > Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net
> <mailto: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
> >
> >
> >
>
>
>
>
> --
>
> Best Regards,
> Ali Ebrahimi
>
>
More information about the jigsaw-dev
mailing list