-
Notifications
You must be signed in to change notification settings - Fork 11k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an Automatic-Module-Name manifest entry #2846
Conversation
@jodastephen, the author of that article, actually strongly suggests using |
@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. |
We do release other things under |
It's true. As long as you're willing to claim that the package root |
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. |
This is recommended for any java library which is being published to repositories like MavenCentral or JCenter to ensure that when you do eventually convert the library to a Java 9 module, it won't change names requiring all of your consumers and the projects which depend upon your consumers to update their `moudle-info.java` files to pick up the new name. We can debate whether or not `com.google.guava` is the name you want to adopt for your module. Other possible candidates are: * `guava` * `google.guava` * `com.google.commons.guava` * Something else [This article](http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html) covers a lot of the reasons you might want to use `com.google.guava`, but I have also read reasonable arguments for more concice names if you aren't worried about module name conflicts. Related (a little bit) to #2571
The Guava team has decided to take responsiblity that all modules under this namespace have unique module names. This is based largely on reccommendations in this [email thread](https://groups.google.com/forum/#!msg/guava-discuss/1I--H7xwwR8/OLvJo-FhAwAJ).
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 So, either 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 ( |
What is the process by which the guava team can get this decision made? |
@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). |
Thanks. I'll get this submitted internally and then mirror it out. |
This is recommended for any java library which is being published to
repositories like MavenCentral or JCenter to ensure that when you do
eventually convert the library to a Java 9 module, it won't change
names requiring all of your consumers and the projects which depend
upon your consumers to update their
moudle-info.java
files topick up the new name.
We can debate whether or not
com.google.guava
is the name you wantto adopt for your module. Other possible candidates are:
guava
google.guava
com.google.common.guava
This article covers
a lot of the reasons you might want to use
com.google.guava
, but I have also read reasonable arguments for more concise names if you aren't worried about module name conflicts.Related (a little bit) to #2571