Join GitHub today
Add an Automatic-Module-Name manifest entry #2846
This is recommended for any java library which is being published to
We can debate whether or not
This article covers
Related (a little bit) to #2571
@Stephan202 you are right. I am happy to change the module name in the pull request to
But, first I would like someone to be able to confidently confirm, "No other jar files inside or outside Google contribute classes to the
If that's the case, I'll update the pull request on getting that confirmation.
Hmm, after re-reading this conversation, I understand now that only the
On the assumption that my new understanding is correct, I'll rephrase my previous questions:
I think I may be introducing more confusion than clarity here, but it's worth writing about in a bit more detail because we really only want to make this decision once.
First of all, I think that Stephen makes a well-reasoned argument in his JPMS module naming post.
The point about
There is are 3 separate and mostly-independent teams inside Google each of which maintains a module which exports some packages in the
Guava Team publishes a module which exports packages (reduced for space):
Blue Team publishes a module which exports packages:
Red Team publishes a module which exports packages:
Only one of those teams can call their module
There isn't really a great answer here. Personally, I think that
I actually think it might be better to separate the module names from the packages they contain because those concepts evolve through separate development lifecycles.
But, ultimately, I care less about the name you choose, than that you choose it before the 23.0 release, so we can get it published with this new manifest attribute. The choice is your's.
Lets start by observing that Google (the company) owns everything under
(The observation is however that ALL Google modules should start with
The next observation is that the standard (Java-wide) rule for module names should be that the module name is the super-package name of the project. While this rule handles many cases, it does not of course handle the Guava case, as each package is a sibling.
In my blog, I describe this case, and argue that the implied super-package in a case like this is the next level up. Thus, I arrive at my view of
Looking to the future, there is another way to view the whole problem space however. Each package in Guava is pretty isolated. There are dependencies between the packages, but they form a DAG as far as I can tell. As such, it would be perfectly possible for each package to be a separate module (where the module name is then obviously the package name).
Now, today this would be a pain to do, because it would mean publishing a separate artifact to Maven Central for each package, something that nobody would really want. However, there is a fair chance that Oracle will consider having multi-module jar files in a future release of Java (ie. one jar file containing many modules). Were this to happen, having a module for each package is suddenly not such a bad idea, as users could then depend on the subset of Guava they care about, or the whole of it, and not suffer any clashes.
In this scenario, the Guava module would then be an aggregating module that contains no bytecode of its own:
This is similar to the JDK, where the
Given this world view,
One final note however, if
Ultimately, the Guava team must decide as to which of the two world-views of the project describes it best - a single project formed of a coherent set of packages (
@jodastephen's recommendation was simply to declare which module name we choose. (And I think we're all happy with
Now that JDK 9 looks like passing the official processes with no further changes, it is safe (and recommended) to add
You'll keep declaring that until you write a proper module-info file, which won't be too hard to do once JDK 9 is finally released. (Maven has support for compiling module-info.java on JDK 9 and merging the .class file with the rest of the code so it all works on JDK 8).