Module Views

[mark.reinhold at oracle.com]

2011/12/7 14:32 -0800, jesse.glick at oracle.com:
> On 12/07/2011 04:17 PM, mark.reinhold at oracle.com wrote:
>> A series of `exports` and `permits` clauses at the top syntactic level of
>> a module declaration defines the module's _default view_.  Further views
>> of a module's content can be defined using the new `view` construct,
>> which specifies a view name together with a bracketed list of exports and
>> permits declarations.
> 
> This feels confusing. A class may either have an implicit no-arg
> constructor or an explicit list of constructors, but not both. I think
> the same should be true of views - either you do not use the view
> keyword, or all exports in the module must be defined in explicit views
> (one of which may have the same name as the module).

That would be another way to do it.  We'll be in a good position to
evaluate alternatives like that after we have some experience using
views in anger.

(Oh, and for what it's worth I'm not sure I'd rank default no-arg
 constructors as one of the better design choices in Java.)

>> It also exports all public types in the `foo` package because the
>> non-default views of a module inherit the exports clauses of that
>> module's default view.
> 
> This also seems needlessly confusing, especially in light of the fact
> that permits are _not_ inherited. Clearer to have each view list its
> complete contents.

Implicit export-declaration inheritance is motivated by the observation
that non-default views, at least in the modular JDK itself, always export
everything that's in the default view.  Having to repeat all those export
declarations is tedious and error-prone:

    module jdk.tls @ 8-ea {

        requires local jdk.boot @ 8-ea;

        // Default view (available to all)
        exports com.sun.net.ssl.*;
        exports java.net.*;
        exports javax.net.*;
        exports javax.net.ssl.*;
        exports javax.security.cert.*;

        // Internal view (available only to permitted modules)
        view jdk.tls.internal {
            permits jdk.crypto, jdk.sunpkcs11, sun.compat,
                    sun.jndi, sun.kerberos, sun.management, sun.rmi;
            exports com.sun.net.ssl.*;
            exports java.net.*;
            exports javax.net.*;
            exports javax.net.ssl.*;
            exports javax.security.cert.*;
            exports sun.security.internal.interfaces.*;
            exports sun.security.internal.spec.*;
            exports sun.security.pkcs.*;
            exports sun.security.ssl.*;
            exports sun.security.util.*;
            exports sun.security.x509.*;
        }

    }

An alternative would be to require clients of jdk.tls.internal to import
jdk.tls explicitly if they actually need types from that view, but then
that gets tedious on the client side.

Another alternative would be to make export-declaration inheritance
explicit ("view foo extends bar"), but that seems like overkill.

Again, after some actual experience I'm sure we'll come back and consider
such variations.  For now we needed a plausible initial design so that we
could start working it through the rest of the system.

> Entry points as currently in Jigsaw strike me as very limited; they seem to
> only apply to main(String[]) classes, meaning they are only useful for
> command-line programs. A more general approach would be to define
> 
> package java.lang; // ?
> public interface Application {
>     void /* or int? */ main(String... arguments) throws Exception;
> }
> 
> and permit a module to register it using the 'service' declaration. The
> command-line launcher in module mode would just look for one (and only
> one) instance of the Application service and run it, whereas an applet
> container would look for an Applet, etc. Legacy main classes could
> trivially be retrofitted. This would eliminate the need for a special
> 'class' declaration in module metadata.

Hmm, interesting idea.  We'd still want a simple way to support legacy
main methods, but that could be done in tools.  Worth exploring further.

>> ...
>> 
>> Another possibility is to structure the names of non-default views so
>> that they always include the names of their containing modules, but
>> that turns views into second-class entities.
> 
> I suppose you mean that in the above example, the compiled jdk.crypto
> module's metadata would refer to the name "jdk.tls" only, so that when
> packaged natively, jdk.crypto.deb would simply depend on
> jdk.tls.deb. This seems natural enough; the view just controls what is
> exposed to whom, but does not change the nature of the module-to-module
> dependency.

Yes, that's what I mean.

>             Virtual dependencies introduce a lot more complexity and
> points of failure, ...

Do you mean module aliases ("provides") here, or something else?

- Mark