JEP 200: The Modular JDK

[Tim Boudreau]

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