[open] module <MODULE_NAME> {
[[requires [transitive] <MODULE_NAME>;]
[exports <PACKAGE>[ to <MODULE_NAME_1>[,<MODULE_NAME_2>..,<MODULE_NAME_N>];]
[opens <PACKAGE>;]
[provides <SERVICE> with <SERVICE_IMPLEMENTATION_1>[,<SERVICE_IMPLEMENTATION_2>..,<SERVICE_IMPLEMENTATION_N>];]
[uses <SERVICE>;]]
}
Identifier |
Description |
module |
The module keyword that holds the module directives. |
<MODULE_NAME> |
The module identier. |
<PACKAGE> |
The package identifier. |
requires |
The requires directive indicates that this module depends on another module. ^1 |
transitive |
The transitive directive indicates that the user of the current module will also requite another module that the current user will also have access into. |
exports |
The exports directive indicates which public types of the module's package are accessible to other modules. ^1 |
opens |
The opens directive also indicates which public types of the module's package are accessible to other modules. The difference between that and exports is that opens is not for compile time, only during runtime, while exports is for both compile time and runtime. The opens directive can typically be used when you want to allow other modules to use reflection for the types in the specified packages, but not to use them during compile time. Let's make this more clear by means of an example. ^1 |
open |
This is like the opens directive but with this it opens the whole module. |
to <MODULE_NAME_1>[, <MODULE_NAME_2>.., <MODULE_NAME_N>] |
This indicates to target just specific module(s). |
provides...with |
The provides...with directive indicates that the module provides a service implementation.^1 |
uses |
The uses directive indicates that the module requires a service implementation. |
<SERVICE> |
The interface or abstract class that will be implemented as a service. |
<SERVICE_IMPLEMENTATION_1>[, <SERVICE_IMPLEMENTATION_2>.., <SERVICE_IMPLEMENTATION_N>] |
The implementation classes of the SERVICE_INTERFACE. |
Recent Comments