JEP 200: The Modular JDK

[Alan Bateman]

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