nio module structure
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. ...
> 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
The way to handle this situation is to define a family of modules (names
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
We'll eventually define a "ModuleNotPresentException", or some such, to
be thrown when a requested provider module is not installed.
More information about the jigsaw-dev