Java 9 is coming soon (unless it is delayed again, but that seems unlikely). The major feature is JPMS, the Java Platform Module System. While JPMS is far from ideal, projects like Guava and mine Joda-* are going to be key to getting some adoption. This is particularly true as Guava is at the base of the dependency tree, and it is awkward to name.
Basically, it strongly recommends reverse-DNS naming based on the super-package of a project.
So, how to apply this to Guava?
Well these are Guava's packages:
- com.google.common.annotations
- com.google.common.base
- com.google.common.base.internal
- com.google.common.cache
- com.google.common.collect
- com.google.common.escape
- com.google.common.eventbus
- com.google.common.graph
- com.google.common.hash
- com.google.common.html
- com.google.common.math
- com.google.common.primitives
- com.google.common.reflect
- com.google.common.util.concurrent
- com.google.common.xml
- com.google.thirdparty.publicsuffix
There is no single super-package, but there is an implied super-package of `com.google.common`. As such, this is my recommended module name for Guava.
I note that there are other projects, such as Truth, built under `com.google.common`, however based on the package name recommendations, Truth should use the module name `com.google.common.truth`, which is fine.
I'd also recommend making `com.google.common.base.internal` hidden (not exported) and either sharding `com.google.thirdparty.publicsuffix` to `com.google.common.thirdparty.publicsuffix` or releasing it separately. (Packages cannot be in two modules in JPMS, ignoring this and releasing `com.google.thirdparty.publicsuffix` would cause unresolvable clashes if Google released another module with that package in it, even if the package is hidden).
Clearly though, my recommendation of `com.google.common` does not include "guava"! But this is a feature of the basic naming strategy - JPMS modules are based on packages, and since Guava's packages don't include "guava" this is what you get.
You could use `com.google.guava`. Doing so would set a bad precedent for getting others to modularize using a sensible naming strategy. However, since you "own" "com.google" you can technically do anything you like within that namespace, so long as you consistently allocate one package to one module.
I recommend against using google.guava. Modules are not artifacts. Modules are strongly linked to packages, thus it is the package name that guides the module name.
In summary, because Guava is depended on by many projects, it needs to pick a module name and say it publicly (such as on the home page of the project). This does not require you to write a module-info.java file, nor make other code changes for Java 9. I'd argue that because Guava doesn't have an obvious module name (as discussed above), that this is particularly critical.
Stephen