How to do module refactoring without rippling changes?

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Oct 5 18:55:23 UTC 2015


2015/9/28 9:58 -0700, peter.kriens at aqute.biz:
> According to the requirements specification it should be possible to
> split a module into two modules and this should not require changing
> all modules that are dependent on this module. How will this work in
> the current proposal?

Suppose you start with:

  module foo {
      exports foo.bar;
      exports foo.baz;
  }

Then you split it into two:

  module foo.bar {
      exports foo.bar;
  }

  module foo.baz {
      exports foo.bar;
  }

To keep old clients of the original "foo" module working, define a new
version of "foo":

  module foo {
      requires public foo.bar;
      requires public foo.baz;
  }

This is a so-called "aggregator" module: It has no actual content of its
own, but it brings together the content of two or more other modules and
uses implied readability to ensure that any module that reads this module
will, in turn, read the other modules.

- Mark


More information about the jpms-spec-experts mailing list