On 27/08/2014 08:35, Tim Boudreau wrote:
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.
jdk.* modules can export APIs too. In the tabular summary (linked from
the module-graph definition section, might not be obvious), then you'll
see several examples where JDK-specific APIs are exported.
Clearly anyone looking to promote a JDK-specific API to a Java SE API
would need to take compatibility and migration into account. The Java
Debug Interface (com.sun.jdi.** ) is a good example of a supported API
used by debuggers and tools but where it never seem to be worth the
disruption to define a JCP/standard API.
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.
The java.base module is where the core APIs live, it's not an aggregator
and does not depend on anything. It is close to the smallest set of API
packages without breaking things by omitting classes or sub-setting
packages. The tabular summary page has the details.
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.
As the JEP says, the document is just temporary until a module system is
in place. For now it is checked into the top-level repo in the jdk9
forest and used to check module boundaries at JDK build time. You won't
see it in the JDK/JRE images.
-Alan
