commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dapeng Sun (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CRYPTO-74) Full class names make code more difficult to update
Date Wed, 22 Jun 2016 05:38:57 GMT

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

Dapeng Sun commented on CRYPTO-74:
----------------------------------

>>However the patch means that it is no longer possible to use externally provided classes.
I don't know whether that is the intention or not.

This patch also support using externally provided classes. the value could be the full class
name of externally provided classes.

>>If Crypto is only intended to be used with its own implementations, then an enum would
be a better choice than constant strings.

We should not limit the ability of using externally provided classes. I think constant strings
would be a good choice.

>>If it is intended to support outside classes, then the line where it prefixes the
Crypto class name [1] needs to be changed to check for a "." in the class name and only append
the standard prefix if no dot is present (as per my original description)

In this pr, it already supporting outside classes. Firstly, it will load the class at default
package{{default package + '.' + className}}, if the class is not existed, it will stand for
full class name and load the name dicectly (className stands for fullClass,like {{org.apache.otherProvider}}).
Do you think it is okay?

> 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