How to do module refactoring without rippling changes?

[Peter Kriens]

Ah, sorry, I could have figured this out. This was the same solution that Eclipse picked when they had to refactor parts of SWT. It is not a very elegant solution (it creates a lot of extra maintenance work over time) but it does satisfy the requirement.

Thanks, kind regards,

	Peter Kriens


> On 5 okt. 2015, at 20:55, mark.reinhold at oracle.com wrote:
> 
> 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