Issue: The JAXP+modules story is still a bit of a mess

[mark.reinhold at oracle.com]

2016/3/4 15:06 -0800, david.lloyd at redhat.com:
> I'm not sure if this is just something that has not yet been gotten 
> 'round to, but the way JAXP loading works has become somewhat less 
> convenient.
> 
> If you are a container author, and you need to supply your own global 
> default JAXP implementation classes, your options are highly limited: 
> you can rely on TCCL being set on every call to Xxxx.newFactory() (never 
> going to happen 100% of the time in reality), or you can set the 
> appropriate system properties and make your implementation visible from 
> every class loader (something of the opposite of the kind of 
> encapsulation that we have modules for).
> 
> Today we do the latter, along with some "redirect" implementations of 
> all the major JAXP classes which allow the global default factory to be 
> established or changed by suitably privileged code.  However, this 
> solution is untenable when the JDK implementation classes cannot be 
> accessed: the global default which is established by the JDK is now 
> extremely difficult to reach through any other means!
> 
> The system property approach - really any approach to locating anything 
> which involves a class name without some kind of context for locating 
> that class (be it a module name or whatever) - is pretty outdated; it 
> seems like it could be a good idea at this time to add methods to allow 
> setting (maybe even on a one-time-only basis) a global 
> Supplier<XxxFactory> for each JAXP type.  Is there any way this could be 
> accomplished?

This is an issue for Java SE 9, and its forthcoming Umbrella JSR, rather
than for the module system itself.

- Mark