JAXP default implementation and JDK-8152063

[Alan Bateman]

On 28/03/2016 23:46, huizhe wang wrote:
> Thanks David.  So I understand the dynamic nature of the server 
> configuration. There maybe two options to solve it:
>
> 1) Add a system property to point to a Layer in order to find an 
> alternative-system-default. This will add a new step to the JAXP 
> process after the current ServiceLoader process.  I saw that you had 
> concern over the performance of searching a provider among all modules 
> in a Layer.
I'm not sure that it would be feasible to statically configure the VM to 
use a module in a layer of modules that will get created sometime later 
in the lifetime of the VM. Also this amounts to changing the default 
implementation on the fly and something we should avoid without deep 
consideration.

On the performance issue, this is a temporary issue with a new API where 
we had to remove indexing in order to make progress. It shouldn't impact 
anything and will sort it out once we get further on a number of topics.

>
>
>
> 2) Add a new type FinderDelegate for processes such as the "proxy" in 
> your case to implement. If the FinderDelegate process fails to locate 
> a provider, it would signal the jaxp process (by returning null) to 
> fall back to the JDK-default implementation. In other words, when the 
> system property points to a FinderDelegate, the 4-step JAXP process is 
> reduced to two: delegate the process to the FinderDelegate, and fall 
> back to the system default implementation.
The devil is in the detail of course. You haven't said if the 
FinderDelegate implementation has to be visible via the system class loader.

I think the main thing is to tread carefully and it would be very easy 
to introduce a troublesome mis-feature here.

-Alan.