A couple of minor comments: 1. The "java." vs. "jdk." semantics are, long-term, probably doomed. That is, it's fairly inevitable that some "jdk." module will, sooner or later, grow a public API, probably starting from a "friend" API. For example, NetBeans tried a convention of "org.netbeans.api.*" for modules with public API, and "org.netbeans.modules.*" for non-api stuff, but today you'll find plenty of modules that have public APIs yet are named "org.netbeans.modules.*" because their author couldn't predict a priori that there would eventually be an API.
When you reach the point of actually declaring it to be public API, there will be existing code that already uses it under the name "jdk.foo", which will break if it is changed. Yes, you could require that there be a "java." module which contains no code but simply exports the packages of "jdk.foo", but that starts to get pretty silly. If you have a mechanism by which a module can restrict the list of things that can depend on it, then the naming convention adds nothing except a message that says "you can't depend on this" (which is already obvious by the fact that, well, you can't). That has a smidgen of value, but if there's a good chance the naming convention is going to break down, or not be ruthlessly adhered to for eternity, I'm not sure it's worth it. It's easy to carve a snapshot in time of something up into modules; doing that in a way that's going to evolve sanely is harder, and the more semantics are put into things, the more ways there are for it to go wrong. 2. "java.base" smells like an antipattern - but it's not clear to me if it's just an aggregator of some other dependencies, or contains stuff of its own as well, and if so, what. If it's an aggregator, what is gained by not having the things that need what it aggregates just have direct dependencies? My guess is that those things only export APIs to java.base, and then it re-exports those. Maybe I'm misunderstanding what it is, but my experience is that sooner or later someone wants just one of the things you're exporting, but is forced to take all of them (example: org.openide.util in NetBeans is a module most other modules wind up depending on; it contains localization-related stuff, plus a grab bag of other things from fiddling with Swing Actions to thread pools to utilities for identifying the OS; it is common to need maybe one of these things, usually localization; it would be better to have that factored as a separate module). Usually I've seen this pattern when a module has been split apart into smaller things, as a way of providing backward compatibility for code that was written when it was monolithic - i.e. you wind up with this pattern not because it's particularly good, but because it was impossible to predict the future when it was created. Starting out in that place seems odd. Basically what I'm saying is, given the choice of more or less granular dependencies, more granular causes fewer headaches, long-term. But as I said, it's not clear to me precisely what java.base is, so I might just be misunderstanding that. 3. XML, really? Most of our industry has gotten over the, er, unhealthy fetish for XML that was common some years ago. If it's just as placeholder documents, okay, but it's not the cheapest thing in the world to parse, and there's nothing in the example documents that has, or even has the potential to have, a deep tree-like substructure that might justify it. -Tim -- http://timboudreau.com
