RFR 7191662: JCE providers should be located via ServiceLoader
Valerie Peng
valerie.peng at oracle.com
Thu May 28 22:10:19 UTC 2015
Please find comments in line...
On 5/27/2015 3:42 PM, Mandy Chung wrote:
> Valerie,
>
> Did you see my comment yesterday?
> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html
Yes, we exchanged emails after this above one. I will follow up your
latest one later today.
>
> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let’s remove the META-INF files in the first push and the build change.
>
> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname.
Sure, I can remove the META-INF files so the providers are loaded
through the legacyLoad().
Hmm, the ProviderLoader.load() method is used by java.security file
provider loading. Since the current list still uses class name, it
should take class name when checking for matches while iterating through
the list returned by ServiceLoader.
This way, when changes are sync'ed into Jake, no extra change required
and the providers will be loaded through ProviderLoader.load()
automatically with the current list.
> I’ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev
Ok.
Thanks,
Valerie
> .
>
> Mandy
>
>> On May 27, 2015, at 3:29 PM, Valerie Peng<valerie.peng at oracle.com> wrote:
>>
>> Hi, build experts,
>>
>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev:
>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/
>>
>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build.
>>
>> The rest of source code changes are reviewed by my team already.
>> Thanks,
>> Valerie
>> (Java Security Team)
More information about the security-dev
mailing list