[
https://issues.apache.org/jira/browse/CRYPTO-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352076#comment-15352076
]
Sebb commented on CRYPTO-81:
----------------------------
Another approach is to use public methods to return the class names of the
built-in implementations.
It might also be possible to use an enum for the built-in classes and extend it
with a mixin interface for the external classes [1]
[1] https://blogs.oracle.com/darcy/entry/enums_and_mixins
> improve factory api for constructing Random & Cipher
> ----------------------------------------------------
>
> Key: CRYPTO-81
> URL: https://issues.apache.org/jira/browse/CRYPTO-81
> Project: Commons Crypto
> Issue Type: Bug
> Reporter: Xianda Ke
> Assignee: Xianda Ke
>
> currently, the client code to construct a CryptoRandom or CryptoCipher looks
> like this:
> {code}
> // code snippet (a)
> Properties props = new Properties();
> props.setProperty(
> ConfigurationKeys.COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY,
> OpensslCryptoRandom.class.getName());
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
> {code}
> or using configuration file, it looks like :
> {code}
> # config file
> secure.random.classes="org.apache.commons.crypto.random.OpensslCryptoRandom"
> {code}
> {code}
> // code snippet (b)
> {
> Properties props = loadMyApplicationConfig();
> // ...
> }
>
> {
> // bussiness logic ...
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(props);
> // ...
> CryptoCipher cipher = CryptoCipherFactory.getInstance(transform, props);
> }
> {code}
> disadvantages:
> 1. if client user just want use openssl engine, trivial stuff in code
> snippet (a). it looks annoying.
> 2. Client user has to use the long long config key string such as
> "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY" or full name of classes
> Client user has to read source to learn how to config the properties.
> 3. the implementation classes such as JavaCryptoRandom, OsCryptoRandom and
> JavaCryptoRandom are public.
> it would be hard to change library implementation in future.
> if we just *use a enum (RandomProvider or CryptCipherProvider)*
> {code}
> // code snippet (c)
> // client code looks simple and elegant now:
> //RandomProvider.OS or RandomProvider.JAVA
> CryptoRandom random =
> CryptoRandomFactory.getCryptoRandom(RandomProvider.OPENSSL);
> {code}
> still, client user can use configuration file
> {code}
> # config file
> RandomProvider="OPENSSL"
> CryptCipherProvider="JCE"
> {code}
> {code}
> // code snippet
> {
> Properties props = loadMyApplicationConfig();
> RandomProvider randProvider =
> RandomProvider.valueOf(props.getProperty(p1));
> CryptoProvider cryptoRrovider
> =RandomProvider.valueOf(props.getProperty(p1));
> }
> {
> // bussiness logic ...
> CryptoRandom random = CryptoRandomFactory.getCryptoRandom(randProvider);
> // ...
> CryptoCipher cipher = CryptoCipherFactory.getInstance(transform,
> cryptoRrovider);
> }
> {code}
> advantages:
> 1. Simpler API. snippet (c) is simpler than snippet (a).
> 2. Modern IDE will hint that CryptoRandomFactory.getCryptoRandom() need a
> enum type (RandomProvider). client user do NOT have to search the long key
> string such as "COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY". Modern IDE will
> tell client user how to config
> 3. we don't have to expose the implementation classes as public
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
