commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Eckenfels <>
Subject Re: [all] Java 9 module names
Date Mon, 24 Apr 2017 21:38:12 GMT
Hm, I don't think a bridge implementation needs to fake a (API) module.

Your client code requires the API module and no specific implementation. The implementations
(including the bridge) export their specific packages to the API module (optionally with service
provider for discovery).

This is basically the same as with OSGi (only that modules allow friends easier). The runtime
scope in maven would be for those modules which are not explicitely required but needed at

From: <> on behalf of Stephen Colebourne
Sent: Monday, April 24, 2017 1:42:33 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names

On 24 April 2017 at 11:08, Jörg Schaible <> wrote:
> Stephen Colebourne wrote:
>> Sounds like you could use --add-modules to add the module separately
>> from the command line, or add the module to the application's
>> module-info rather than the libraries.
>> In general, I suspect a library should depend only on
>> the other modules it really needs (eg. the API of slf4j), while
>> something else, such as the application, adds the implementation
>> module (eg. the SLF4J implementation).
> Which will create another chaos. Currently I can use the the xx-over-yy
> artifacts to replace a hard coded dependency of an artifact if it is
> required to embed it in a larger system.

You still can. See my latest blog for the mental model you need:

TL;DR, modules != artifacts. Depending on a module does not imply
depending on exactly the same artifact that was used at compile time.
Thus, the xx-over-yy jar files are still useful, provided they have
the same module name as the module they are faking. See for how slf4j needs tweaking.


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message