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-observers
mailing list