Class loading error when looking up security providers

[Sean Mullan]

On 6/13/12 11:55 AM, Paul Sandoz wrote:
> 
> On Jun 13, 2012, at 5:10 PM, Sean Mullan wrote:
> 
>>
>> On 6/13/12 9:58 AM, Paul Sandoz wrote:
>>> Hi Sean,
>>>
>>> Looking at the code the problem is the class "com.sun.crypto.provider.SunJCE" is in the jdk.crypto module and the code to load crypto providers does:
>>>
>>>                    ClassLoader cl;
>>>                    if (Platform.isModuleMode()) {
>>>                        cl = Platform.getBaseModuleLoader();
>>>                    } else {
>>>                        cl = ClassLoader.getSystemClassLoader();
>>>                    }
>>>                    Class<?> provClass;
>>>                    if (cl != null) {
>>>                        provClass = cl.loadClass(className);
>>>                    } else {
>>>                        provClass = Class.forName(className);
>>>                    }
>>>
>>> So it is using the CL of the jdk.base module, which cannot see classes from the jdk.crypto module.
>>>
>>> As the comment in the source that occurs above the above snippet states, this area needs to start using services.
>>
>> Ok, but I need a workaround for the time-being. If you think of anything, let me
>> know.
>>
> 
> Hmm... you might be able to muck around with the platform library and copy the classes from the jdk.crypto location into the jdk.base location then refresh the library.

One workaround is to instantiate and specify the provider class directly, ex:

Cipher.getInstance("AES", new com.sun.crypto.provider.SunJCE());

and make sure you add a "requires jdk.crypto.internal" to module-info.java,
since SunJCE is now exported via the jdk.crypto.internal view:

jdk.crypto at 8-ea
   requires jdk.base.internal@=8-ea
   requires jdk.tls.internal@=8-ea
   requires synthesized java.base@>=8
   view jdk.crypto.internal
     exports
       com.sun.crypto.provider

--Sean