Service Providersand versioning

[Sean Mullan]

On 04/18/2012 11:07 AM, Alan Bateman wrote:
> On 18/04/2012 15:22, Sean Mullan wrote:
>> I have been starting to think about how JCE providers might be
>> deployed as jigsaw services. [1] notes that services do not have
>> version numbers.
>>
>> One of the current limitations with the JCE provider framework is that
>> it is not a good idea to add a new parameter to an
>> AlgorithmParameterSpec subclass, because existing provider
>> implementations will not be aware of that new parameter until they are
>> upgraded.
>>
>> We usually have to define a new AlgorithmParameterSpec subclass to be
>> able to identify providers that have not been upgraded (they will
>> throw an InvalidAlgorithmParameterException), or a completely new
>> algorithm type.
>>
>> It would be nice if we could find a cleaner solution to this problem
>> with jigsaw, but without a versioning mechanism I'm not sure if it is
>> possible. Any thoughts on this?
> I don't know this area too well but aren't security providers
> implementations of java.security.Provider, in which case I assume a
> starting point would be something like:
>
> module sun.ec @ 8-ea {
> provides service java.security.Provider with sun.security.ec.SunEC;
> }

But a Provider is not a Service. It is more equivalent to a ServiceLoader.

I would have expected something more like:

module sun.ec @ 8-ea {
   provides service java.security.Signature
                    with sun.security.ec.ECDSASignature;
}

So basically, the Provider API doesn't come into play at all in finding 
JCE services.

Clearly this area needs more thought but it's good to start discussing 
it some more now.

I also think that ideally we need additional algorithm attributes to 
help find the right service, if we expect this to be used for JCE - for 
example:

module sun.ec @ 8-ea {
   provides service java.security.Signature:ECDSA
                    with sun.security.ec.ECDSASignature;
}

where ":ECDSA" is the type of algorithm being requested.

> As you mention AlgorithmParameterSpec then perhaps you are thinking
> about finer grain service types rather than at the level of a
> traditional security provider?

Perhaps I should clarify.

What I'd like to do is the following:

module app {
     requires service java.security.cert.CertPathValidatorSpi:PKIX @ >= 8.0;
}

In other words, the app module would be requesting a PKIX 
CertPathValidator service that has been updated to support API changes 
to that SPI in JDK 8.

--Sean