Module Views

[David M. Lloyd]

On 12/08/2011 09:53 AM, mark.reinhold at oracle.com wrote:
> 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)

You /could/ bundle the modules together in one distro package (this is 
basically no worse than views) if you really want this "feature".  But 
if you want to replace a "view" with another module, if they're in the 
same distro package you're going to have a conflict.  If they're 
separate, you can do a one-for-one substitution of distro package, which 
also makes it easy for the user to decide what to install (it might even 
be impossible to replace the view separately if you combine them).

> 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).

I don't really understand the source code argument to be honest.  It is 
relatively rare for a user to refer to a module by name within Java 
source, yet even if they do, it shouldn't make any difference which 
approach is taken.

If you're talking about the source for the module descriptor, we've not 
found it to be a problem yet.  Our re-exporting modules seem to be 
easily understandable.

>> 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.

If they're that loosely bound then you might as well just go with the 
more flexible solution.
-- 
- DML