Here is one more case when 1.5 RI is inconsistent and contradicts the spec.
Consider the following code: Provider[] pp = Security.getProviders("Provider.id"); System.out.println((pp==null? null : pp[0])); pp = Security.getProviders("Provider.id name:SUN"); System.out.println((pp==null? null : pp[0])); Output on 1.4: null null Output on 1.5: null SUN version 1.5 >From java.security.Security 1.5 spec.: "public static Provider[] getProviders(String filter) Returns an array containing all installed providers that satisfy the specified selection criterion, or null if no such providers have been installed. … The selection criterion must be specified in one of the following two formats: <crypto_service>.<algorithm_or_type> …. A provider satisfies the specified selection criterion iff the provider implements the specified algorithm or type for the specified cryptographic service. … <crypto_service>.<algorithm_or_type> <attribute_name>:< attribute_value> ... A provider satisfies this selection criterion iff the provider implements the specified algorithm or type for the specified cryptographic service and its implementation meets the constraint expressed by the specified attribute name/value pair." So, as "Provider.id" is not <crypto_service>.<algorithm_or_type>, method should return null. (Note: According to 1.5 java.security.Provider spec., "Provider.id name" is automatically placed in each Provider object. It is reserved for use by security framework.) But in second case 1.5 RI implementation reports that provider implements algorithm 'id' for service 'Provider'. Current Harmony implementation conforms with the specification and compatible to 1.4. I think we should not be bug compatible with RI in this case. Comments? -- Best regards, Boris Kuznetsov --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]