Module Views

[mark.reinhold at oracle.com]

2011/12/8 7:33 -0800, david.lloyd at redhat.com:
> On 12/08/2011 12:14 AM, mark.reinhold at oracle.com wrote:
>> 2011/12/7 18:54 -0800, david.lloyd at redhat.com:
>>> ...
>>> 
>>> Making views always be subordinate to the module name is the only way to make
>>> this work reasonably IMO.  But anyway at this point you could just as easily
>>> use a general alias concept to solve the same problem.
>> 
>> No, because views are solving an additional problem, namely that of
>> exporting distinct sets of types to different clients of the same
>> module.
> 
> A module alias could be made to do this as well.  To solve this problem, we
> create modules which simply exist to reexport a subset of another module.

Sure, but that's more or less where we were before introducing views.
Content-free "filter" modules just clutter up the system, increasing the
total number of modules (and hence distro packages) while also making the
source code less comprehensible (a point I didn't mention earlier, but
which is critical to developers working on large source bases such as the
JDK).

> This is more flexible because if an API is ever changed to be implemented by
> someone else, the module basic structure can remain unchanged.  Views seem to
> be too tightly bound to their defining module; to "move" a module view from one
> module to another (or to make the view its own module) may be significantly
> more disruptive.

Whether a view is tightly or loosely bound to its defining module is an
open issue.  If they're loosely bound then converting a non-default view
into the default view of an actual module, or vice versa, would be
transparent to its original clients.

- Mark