nio module structure

Mark Reinhold mr at sun.com
Mon Feb 22 09:58:12 PST 2010


> Date: Fri, 19 Feb 2010 18:26:02 +0000
> From: alan.bateman at sun.com

> Mark Reinhold wrote:
>> In the module-library/repository code I need to lock files and also
>> rename files atomically.  I can do that with nio, obviously, but I've
>> avoided that so far due to footprint concerns, both static and
>> dynamic.  I'd been thinking that a I could just add a few native
>> methods to libjava.so to provide this functionality.  Another
>> possibility would be to split nio into two modules, one for the
>> filesystem APIs and another for everything else.
> 
> One idea that I've been thinking about for NIO to keep the API in the base
> module but put the provider implementations into their own modules. That would
> allow us to deploy without the SelectorProvider and AsynchronousChannelProvider
> modules. ...
>                                                                          My
> only concern with putting the providers into their own modules is that there
> wouldn't be anything in the module-info class files to require the provider
> module to be present. This would mean a module using SocketChannel would fail
> at runtime. My guess is you've thought about problems like this as we have
> similar issues with all the provider based APIs. Anyone using security or JNDI
> will need to list the specific provider as a dependency to ensure it is
> installed.

The way to handle this situation is to define a family of modules (names
strictly hypothetical):

    nio-base -- public APIs only, no providers
    nio-file requires nio-base
    nio-selector requires nio-base
    nio-async requires nio-selector
    nio requires nio-base, nio-file, nio-selector, nio-async

If you want all of nio, then just require nio.

If you want finer-grained dependences, then require only the modules
that you need.

Platform modules (e.g., security, JNDI) should always use finer-grained
dependences.

We'll eventually define a "ModuleNotPresentException", or some such, to
be thrown when a requested provider module is not installed.

- Mark



More information about the jigsaw-dev mailing list