tag:blogger.com,1999:blog-741750605858169835.post6137288254702776502..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java SE 9 - JPMS module namingStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-741750605858169835.post-29861136399277139612018-08-30T11:24:08.320+01:002018-08-30T11:24:08.320+01:00Carry on using the Maven standard. The JPMS module...Carry on using the Maven standard. The JPMS module naming convention is just for using the java compiler on the command line, something which no one really does.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43834940708565158642018-06-17T00:03:18.035+01:002018-06-17T00:03:18.035+01:00Hi Stephen,
Do you also have a recommendation for...Hi Stephen,<br /><br />Do you also have a recommendation for the module directory names?<br /><br />In multi-module Maven projects the module directories often have the same name as the artifactId.<br />AFAIK the convention with JPMS seems to be to name the JPMS module directories after the module name.<br />Should we get used to read our code as JPMS modules and follow this JPMS convention? On the other hand, sticking with the current Maven convention seems more readable to me.<br /><br />I know the impact of the decision is not very big and only limited to the project, but it's still good to have such conventions/ recommendations, especially in large companies.Florian Brunnerhttps://www.blogger.com/profile/10094773112480994318noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-91171142259036531472017-05-09T14:16:09.137+01:002017-05-09T14:16:09.137+01:00I think using the jar name (artifact id) for autom...I think using the jar name (artifact id) for automatic naming is not a bad idea, because it does not use reverse DNS notation; chances of it conflicting with an actual module is low. tbeehttps://www.blogger.com/profile/02676132703267756531noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-40985599553170565212017-04-25T20:40:45.585+01:002017-04-25T20:40:45.585+01:00Stephen, thank you for this very timely and well-w...Stephen, thank you for this very timely and well-written post. The jsr-340 example in the comments is compelling as well.<br /><br />Unless I missed some crucial information, you seem to be offering criticism but no alternative solution regarding auto-module naming. What can Oracle do better?Cekihttps://www.blogger.com/profile/06948108407442025539noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-53239115828667265542017-04-25T07:58:40.466+01:002017-04-25T07:58:40.466+01:00See the next blog in the series, modules != artifa...See the next blog in the series, modules != artifacts - http://blog.joda.org/2017/04/java-se-9-jpms-modules-are-not-artifacts.html . As for package names, I tend to agree that it isn't that clear what is obtained by depending on a module name rather than depending on a package name. In theory, it is an extra abstraction level, but I'm struggling to see what I'd do with it.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10388106751985195542017-04-24T21:20:09.462+01:002017-04-24T21:20:09.462+01:00Ignoring groupIds in module naming ignores relevan...Ignoring groupIds in module naming ignores relevant details about the providers of the module and their licensing regimes. It is not enough to just depend upon 'javax.servlet' since there won't be only one provider of that package with universally acceptable licensing. This is why you often see these API jars from Apache since people re-author the interfaces under Apache license to avoid the license on the originally published API jar. This same problem wont go away with modules. This is exactly why depending upon module names is a bad idea. Depending upon package names is what really matters. (Full disclosure, I am the OSGi CTO.)BJ Hargravehttps://www.blogger.com/profile/05791451307210957698noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-1691093552041819132017-04-23T23:03:50.760+01:002017-04-23T23:03:50.760+01:00Good question, and one I should write another blog...Good question, and one I should write another blog about. The answer is essentially not that much for many applications.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-38106349755534921802017-04-23T08:10:46.750+01:002017-04-23T08:10:46.750+01:00So much rules to follow and restrictions to obey, ...So much rules to follow and restrictions to obey, but what do we get in reward for this from Jigsaw?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-83679714765641386842017-04-20T23:57:21.403+01:002017-04-20T23:57:21.403+01:00Minor/awkward typo in article: "We so of cour...Minor/awkward typo in article: "We so of course have project-style names today in Maven"Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-27425356859579222672017-04-20T18:35:01.338+01:002017-04-20T18:35:01.338+01:00In your example, you're describing the differe...In your example, you're describing the difference between the interface vs the implementation. This of course makes sense, but how many of the legacy automodules does this really apply to? I surmise it's really an edge case.<br /><br />Since Mark has removed the Module Name mechanism for authors to provide a sensible default, we're back to the original problems.Brianhttps://www.blogger.com/profile/12398498751546867188noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-28875585505137545392017-04-20T18:03:43.042+01:002017-04-20T18:03:43.042+01:00Guava is indeed weird, but the thirdparty packge i...Guava is indeed weird, but the thirdparty packge is intended to be private if you read the docs. Thats why I suggested that case should be sharded. That said, in theory Google takes ownership of `com.google` in general, and can do anything it likes within that namespace providing it is consistent and sensible.<br /><br />Using groupId and artifactId to generate a module name is appealing, yet IMO a bad idea. A lot of the time it will result in the super-package name, so appear to work. But as I've tried to emphasise, artifacts and modules are different things. And because JPMS modules are built of packages, it is the package name that must be used. Let me try to clarify the distinction.<br /><br />JSRs are released as specifications, and it is often the case that different teams produce their own jar file artifact containing the specification. So, for example there might be an `apache-jsr-340.jar` and a `jboss-jsr-340.jar`. But both of these jar file artifacts contain the same package and the same code. If you get a conflict today with Maven you can exclude one of the artifacts (although in most cases it won't matter, as both jar files are functionally identical, the first on the classpath is fine). However, with JPMS modules, that conflict cannot be resolved.<br /><br />But there shouldn't be a conflict in the first place. The correct module name is the super-package of the JSR code, `javax.servlet`, not something referring to apache or jboss. ie. there are two different artifacts supplying one conceptual module (both artifacts have equivalent functionality). Taking this approach, other modules that depend on the jar will use the module name `javax.servlet` in their module-info.java files.<br /><br />When assembling this using Maven, the pom.xml will still use the groupId and artifactId to reference one of the two artifacts. But there is not a 1:1 mapping from artifact to module.<br /><br />This also answers your question about changing the module name when patching it to fix a bug. Again, this is two different artifacts but one module name. Tooling like Maven is going to have to resolve this many-to-one problem.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-73918384908625175692017-04-20T17:31:07.208+01:002017-04-20T17:31:07.208+01:00Agh, the indentation of the package tree was remov...Agh, the indentation of the package tree was removed during posting. There are "com.google.common.annotations", "com.google.common.base", "com.google.common. ..." and "com.google.thirdparty.publicsuffix".Anonymoushttps://www.blogger.com/profile/16910067065508493885noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-72817744500888180152017-04-20T17:29:31.703+01:002017-04-20T17:29:31.703+01:00Hi, it appears to be a good strategy in general, b...Hi, it appears to be a good strategy in general, but it won't work in each and every case, i.e. it's not something which can be applied in an automated fashion. E.g. take Guava which you mentioned. It actually contains these packages:<br /><br />com.google<br /> - common<br /> - annotations<br /> - base<br /> - ...<br /> - thirdparty<br /> - publicsuffix<br /><br />I.e. the "common super-package" would be "com.google" which doesn't seem like a good module name as it's too generic.<br /><br />But even when pretending everything in Guava's JAR was under com.google.common, there'd be an issue when also using Guava's test lib. This also has com.google.common as it's common super-package. Now you'd have two modules with the same name.<br /><br />Or consider the case where someone publishes a patched version of a module, e.g. to fix a bug in a library not under their direct control. Wouldn't it make sense to keep the original package names but use another module name, allowing to tell the two apart?<br /><br />Doing large style package renamings in order to arrive at unique super-package names seems not appropriate to me.<br /><br />An important thing you mention is taking ownership of a namespace. I think that's key, but not by claiming packages but by claiming group ids. Together with the artifact id (and perhaps classifier if needed) it seems one can arrive at reasonably unique names.<br /><br />I made good experiences by combining group and artifact id, omitting any redundant middle part. E.g. in the case of com.google.guava:guava and com.google.guava:guava-testlib one would arrive at com.google.guava and com.google.guava.testlib, respectively. And the good thing is that Maven Central already prevents conflicts by assigning group ids to individual parties. E.g. I as a non-Guava contributor couldn't publish a module with an automatically derived module name of com.google.guava as I'm not allowed to publish to this group id (unlike any approach based on package names).<br />Anonymoushttps://www.blogger.com/profile/16910067065508493885noreply@blogger.com