Java 9 module for Guava

[Stephen Colebourne]

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.

I've written up my recommendations for naming modules here: http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html

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.io

- com.google.common.math

- com.google.common.net

- 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

[Kevin Bourrillion]

Stephen, thank you so much for explaining this all to us. I admit most of us haven't been paying the most attention to modules.

Provisionally, the name `com.google.common` seems fine. My only question is: will the fact other projects like Truth are also under our same parent package present any problems?

Unless this thread erupts in a different direction, `com.google.common` is the name we'll stick with.

--
guava-...@googlegroups.com
Project site: https://github.com/google/guava
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: https://github.com/google/guava/issues/new
To get help: http://stackoverflow.com/questions/ask?tags=guava
---
You received this message because you are subscribed to the Google Groups "guava-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/c3c1655e-ed97-40dd-ab3f-ae842ddb58d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com

[Stephen Colebourne]

Thanks for the reply, and I think choosing `com.google.common` is great.

As mentioned above, I'd recommend you consider what to do with the publicsuffix package. Your main two choices are:

- shade it to be under `com.google.common`

- move the code to be package scoped in `com.google.common.net`

I don't know the history or usage of the package, or why it lives separately, but feel free to ask questions around it.

You are perfectly able to create another module named `com.google.common.truth`. The main restriction is that no package can ever be in two modules.

Stephen

PS. todays blog on modules != artifacts may also be of interest

http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/c3c1655e-ed97-40dd-ab3f-ae842ddb58d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Bourrillion]

On Mon, Apr 24, 2017 at 8:06 AM, Stephen Colebourne <scole...@joda.org> wrote:

Thanks for the reply, and I think choosing `com.google.common` is great.

As mentioned above, I'd recommend you consider what to do with the publicsuffix package.

Knowing that this package contains only a single public class marked "do not use this", does that get us out of worrying about it at all?

Anyway, I'll see why we can't move it to c.g.c.net, since that would solve the obvious problem with that arrangement anyway.

 

To unsubscribe from this group and stop receiving emails from it, send an email to guava-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/guava-discuss/04995306-95b8-47e1-afb9-6c9b55ae8020%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stephen Colebourne]

On Monday, 24 April 2017 17:35:22 UTC+1, Kevin Bourrillion wrote:

Knowing that this package contains only a single public class marked "do not use this", does that get us out of worrying about it at all?

Anyway, I'll see why we can't move it to c.g.c.net, since that would solve the obvious problem with that arrangement anyway.

Since you own the entire `com.google` namespace, you can in theory leave it where it is. But you would be asserting that Google will not produce another module that contains the publicsuffix package  This seems like a big ask in a large organisation, so it is easiest to move the code to a better package.

Stephen