RFR 7191662: JCE providers should be located via ServiceLoader,

[Valerie Peng]

But you are correct that the content which uses jdk.crypto.ec seems 
inconsistent to the file name.
I will fix those and re-test.
Thanks,
Valerie

On 5/21/2015 3:03 PM, Valerie Peng wrote:
> Mandy,
>
> Please find comments in line.
>
> On 5/20/2015 10:39 PM, Mandy Chung wrote:
>>
>> A quick comment on the META-INF/services config files and the 
>> makefile. Merging the service config files is temporary until the 
>> module system is moving further along.
>>
>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html 
>>
>> and other os-specific service configuration:
>>    1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider
>>
>> - why is this commented out?  Does the makefile uncomment it?  It 
>> should be simple
>> concatenation with
>
> In an example that I found through another makefile, it would 
> uncomment the entry start with "#[OS]" (and process/remove this 
> prefix) when the OS matches. We need OS-specific file processing when 
> concatenate these files.
>
>> The makefile doesn’t seem right though.
>>
>> make/gensrc/Gensrc-java.naming.gmk.html
>>
>>   96 jdk.crypto.ec: $(GENSRC_PROVIDER)
>>   98 all: jdk.crypto.ec
>>
>> java.naming doesn’t seem an appropriate module to be the main module 
>> for containing all service provider config files.  I initially 
>> propose to use jdk.crypto.ec as the gensrc module as indicated in 
>> line 96,98.
>
> What decides if it's appropriate or not? These are not just crypto 
> providers that we are defining here, but all classes which extend from 
> java.security.Provider. I recall using jdk.crypto.ec as the gensrc 
> module as you suggested initially. But when testing it, it doesn't 
> seem to work as expected. I ended up using java.naming as that's the 
> one ended up in the final image instead of the concatenated one under 
> jdk.crypto.ec. Could there be some alphabetic ordering when 
> processing/building these modules?
>
> Well, since this is really a hack and only temporary, does it really 
> matter whether it's under java.naming or jdk.crypto.ec? Both contains 
> providers for the java.security provider list. The key thing is that 
> the resulting image works.
> Valerie
>>
>> You can rename the file to Gensrc-jdk.crypto.ec and update the content..
>>
>> GENSRC_PROVIDER := 
>> $(SUPPORT_OUTPUTDIR)/gensrc/java.naming/META-INF/services/java.security.Provider
>>
>> GENSRC_PROVIDER is the output file.  line 79-89 is building the 
>> target list.   I think you need another variable to build up the 
>> target list but not GENSRC_PROVIDER.
>>
>> You can reference how Gensrc-jdk.jdi.gmk concatenates the service 
>> config for jdk.jdi and dk.hotspot.agent module.
>>
>> # Filter com.sun.jdi.connect.Connector
>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector: 
>> \
>>     
>> $(JDK_TOPDIR)/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector 
>> \
>>     $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services
>>         $(process-provider)
>>
>> # Copy the same service file into jdk.hotspot.agent so that they are 
>> kept the same.
>> $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector: 
>> \
>>     
>> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector
>>         $(install-file)
>>
>> Mandy