RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader (original) (raw)

Joe Wang huizhe.wang at oracle.com
Wed Aug 29 23:33:20 UTC 2012

Paul, Alan,

Confusion was what jaxp meant to give :) I was told that the factory/object finders, security support classes were duplicated, and needed to be kept in sync. But they are not even in their original form, unfortunately.

Both of you mentioned that it's desirable to make SCE the cause for the configuration exception. DatatypeConfigurationException is different from all others in that, it's an Exception while others Error, it takes Throwable as cause while others Exception. I did not want to change the signatures of the other configuration error classes, that is, the constructors would need to take Throwable instead of Exception (as they should have already done).

As a comprise, I've wrapped the error message in a confguration error.
Would you think it's sufficient to add to the message what you did below (e.g. " could not be loaded or instantiated using java.util.ServiceLoader"?

Or are you into making signature changes? (sth. I thought we didn't want to for this patch)

--Joe

On 8/29/2012 8:56 AM, Paul Sandoz wrote:

On Aug 29, 2012, at 10:56 AM, Paul Sandoz<Paul.Sandoz at oracle.com> wrote:

Hi Joe,

I would urge you to reconsider errors using SL, since SL is being explicitly called out as part of the specification. You can make any such SL-related errors more meaningful (yes, i want the stack trace telling what bits of SL code were called!) and remove any potential for CCEs, due to linkage errors [*], by passing the SCE instance to the constructor of DatatypeConfigurationException or the FactoryConfigurationError variants e.g. 244 } catch (ServiceConfigurationError e) { 245 throw new DatatypeConfigurationException(""Provider " + className + " could not be loaded or instantiated using java.util.ServiceLoader", e); Doh, please shoot me now, i was labouring under the misapprehension that SCE was extending from Exception and not Error. Apologies for the confusion. Paul.

More information about the core-libs-dev mailing list