commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CRYPTO-74) Full class names make code more difficult to update
Date Tue, 28 Jun 2016 23:40:10 GMT

    [ https://issues.apache.org/jira/browse/CRYPTO-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15353934#comment-15353934
] 

Sebb commented on CRYPTO-74:
----------------------------

I think we can combine this with some of the ideas in CRYPTO-81:

Create an enum like the following:
{code}
public enum CipherProvider {
    OPENSSL(OpensslCipher.class),
    JCE(JceCipher.class),
    etc;
    ...
    public String getClassName() {return className; }
{code}

This can then be used as follows:

{code}
properties.setProperty(CIPHER_CLASSES_KEY, CipherProvider.JCE.getClassName());
{code}

This approach does expose the full class name, but since the name is not stored in a constant,
it can easily be changed.
The String constant is replaced by a constant enum instance name; there is then no need to
convert from alias to full class name.

If necessary, there could be Utils methods to create Properties instances that take the appropriate
enum and set the relevant KEY value:

{code}
Utils.getCipherProperties(CipherProvider); // e.g. getCipherProperties(CipherProvider.JCE)
Utils.getRandomProperties(RandomProvider);
{code}

There should probably also be versions that accept String/Class params for use with 3rd party
implementations.
The Utils methods could allow for muliple params to support generating a list of class names.

Note: I have tried this out locally and it works well.

> Full class names make code more difficult to update
> ---------------------------------------------------
>
>                 Key: CRYPTO-74
>                 URL: https://issues.apache.org/jira/browse/CRYPTO-74
>             Project: Commons Crypto
>          Issue Type: Improvement
>            Reporter: Sebb
>
> The method CryptoRandomFactory.getCryptoRandom uses the value of a property as the full
name of the CryptoRandom class to be instantiated.
> This is inherently non-portable if the code package names should ever be changed in future.
> One way round this is to add a constant alias for the embedded implementations.
> For example:
> CryptoRandomFactory.java
> public static final String OPENSSL_RANDOM = "OpensslCryptoRandom";
> public static final String JAVA_RANDOM = "JavaCryptoRandom";
> ...
> If the COMMONS_CRYPTO_SECURE_RANDOM_CLASSES_KEY string does not contain a full class
name, then the code would preprend the appropriate package name (or there could be a lookup
table).
> This would also work for the case where the class is provided as a system property value.
> Another advantage of this method is that it simplifies the user code.
> Similar considerations apply to all other factories which use class name strings.
> [Note: the constants must not contain the full package names as that would result in
a binary incompatibility if the names changed.]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message