JDK support for VM to read classes from modules in a module library

[Alan Bateman]

On 16/05/2012 22:48, Jesse Glick wrote:
> On 05/16/2012 04:39 PM, Mandy Chung wrote:
>> JAXP provided by other vendor would not provide the XMLUtils service 
>> unless it's part of the specification.
>
> No need to touch JAXP itself:
>
> module jdk.base {
>   ...
>   view sun.jaxp.bridge {
>     permits sun.jaxp.bridge.impl; // <--
>     exports sun.misc;
>   }
>   requires optional service sun.misc.XMLUtils;
> }
> // jdk.base classes as in first message
> module jdk.jaxp {
>   // unmodified
> }
> module sun.jaxp.bridge.impl {
>   requires jdk.jaxp; // or its vendor substitute
>   requires sun.jaxp.bridge;
>   provides service sun.misc.XMLUtils with sun.misc.XMLUtilsImpl;
> }
> package sun.misc;
> public class XMLUtilsImpl implements XMLUtils {
>   // call javax.xml.** methods
> }
>
> As Yarda's message pointed out, the same bridge module could deal with 
> XML-format Preferences, and you could supply a fallback implementation 
> based on something like NanoXML for use in small environments where 
> JAXP would be overkill.
This is nice in that it eliminates this optional dependency but it means 
we have another module to deal with. But there is more work required to 
make JAXP really replaceable. The main issue (I think) is that JAX-WS, 
its tools, and XML-DSIG rely on internal interfaces that JAXP currently 
exports via an internal view. I often wonder how this actually works 
today and whether people are dropping in completely different 
implementations of JAXP or just newer/older versions that just happen to 
have the same com.sun.org.** classes.

-Alan