Exporting things (Was: Re: Module-system requirements)

[mark.reinhold at oracle.com]

2015/3/16 2:43 -0700, david.lloyd at redhat.com:
> On 03/16/2015 03:47 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> We'll encapsulate types by default, and also have a way to export them to
>> other modules on a per-package basis.  We seemed to agree earlier that a
>> similar style of export control for resources would be overkill, and my
>> suggested requirement to ensure access to a module artifact's resources
>> by suitably-privileged code, when such an artifact exists, appears to
>> cover the use cases so far discussed (as you note later in your message,
>> quoted below).
> 
> I agree that export control for resources adds complexity, however, 
> without it we're definitely going to be looking at a potentially much 
> more onerous conversion process for a broad category of existing code 
> which wants to take advantage of the benefits of Java modularity but 
> presently relies on using class loaders to access resources for the 
> purposes of self-configuration, which does not (in my experience or 
> opinion) violate encapsulation any more than exporting a public class 
> does.  My agreement, such as it is, is based purely on the ensuing 
> simplification of the module linkage algorithm, as well as the relative 
> simplicity of *new* code (free of any legacy encumbrances) which isn't 
> really the best of motives.
> 
> I guess what I'm getting at is, I'd like to be able to see some 
> realistic mechanism to allow such code to work *unchanged* as modules 
> (even if a customized dynamic configuration were required to do so). 
> Whether or not your previously-proposed method of going through the 
> class loader is a practical approach requires a bit more consideration, 
> I guess.  It may depend on how difficult it is to control the 
> relationship between modules and class loaders, assuming that we don't 
> end up with a 1:1 relationship, or it may depend on making resource 
> export control a feature of the module architecture which is not 
> utilized by the default platform module configuration but can be used by 
> higher layers.

I agree that we should try to reduce the migration effort for such cases.
To capture this, I'll revise the proposed "resource encapsulation"
requirement as follows:

  - _Resource encapsulation_ --- The run-time system must ensure that the
    static resource files within a module are directly accessible only by
    code within that module.  ADD: The existing resource-access APIs
    should continue to work as they do today when used to access a
    module's own resources.

>>>> ...
>>>> 
>>>> So a JBoss module can specify that it depends upon service providers from
>>>> one or more specific modules rather than whichever modules happen to
>>>> provide implementations of that service?  That seems contrary to the
>>>> nature of services, if I understand you correctly.
>>> 
>>> Right; this is however functionally similar to having the configuration
>>> determine the service bindings without any sub-configurations being able
>>> to override it, though at a whole-module granularity rather than a
>>> per-module-service granularity.
>> 
>> I can understand having a build system or a run-time framework control
>> service bindings in this way, but it seems odd for a module itself to
>> declare that it requires a specific provider of a service.
> 
> It's not too odd in practice.  Many projects (especially OSS frameworks 
> which we consume) split their code into API and implementation aspects 
> for encapsulation reasons (both at run time and at build time), where 
> there are typically a small constant number of implementations (maybe 1, 
> but sometimes one primary and one or two less common/specialized, whose 
> usage is based on run time circumstances).  Then the implementations are 
> simply imported into the API in order, the API uses its own class loader 
> to spin up the service loader, and everything is fine.
> 
> This seems preferable to putting API and implementations into the same 
> module (which is the only practical alternative that we provide), and 
> also frees the user from having to create "obvious" bindings between 
> service and provider (though if there could be a way for modules to 
> influence the binding process by specifying a default or "preferred" set 
> of provider modules for a given service, that could be a 
> practical/satisfactory alternative I think).

Interesting.  That would essentially be the dual of the provider-declared
order we discussed in the "Enhanced ServiceLoader" thread.  As with that
feature, I think this is more of a design issue than something we need to
capture in the requirements.

- Mark