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 Fri, 21 Apr 2017 20:37:42 GMT
Around what? there is no problem to have multiple packages in multiple modules depending on
each other (if you decide to ship modules at all). Only split packages is a problem (but this
is also a problem for OSGi or code signing so nobody should really use that anyway)

From: Ralph Goers <>
Sent: Friday, April 21, 2017 10:34:36 PM
To: Commons Developers List
Subject: Re: [all] Java 9 module names

I am having a hard time figuring out how Log4j is going to be able to support this.  The API
itself is in org.apache.logging.log4j and some packages under that.  All the main implementation
is under org.apache.logging.log4j.core.  These obviously overlap.  Most of our other jars
have packages that are in where xxx matches the jar name.  We
aren’t going to change the API to support modules.

Is there some reasonable way around this?


> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <> wrote:
> On 21 April 2017 at 13:59, sebb <> wrote:
>> What happens when there is a API break which necessitates a package name change?
>> I assume that the module name will also need to change to the new super-package.
>> e.g.
>> Commons-Lang4
>> -> super-package org.apache.commons.lang4
>> -> module org.apache.commons.lang4
> Yes, thats right.
>> AFAICT Commons generally has obvious and unique super-packages for
>> each component.
>> This should make it easier than for larger projects with lots of jars
>> and potentially overlapping package names.
>> However even Commons has some code that uses a different package structure.
>> e.g. NET uses examples as the super-package.
>> This includes working examples that are included in the release.
>> I guess that will have to change (which is probably a good idea anyway).
> Yes, as it stands, [net] would be a bad modular citizen, because it
> exposes the "examples" package, and thus prevents any other module
> from using that package. Just move it to
> Stephen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

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