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] [Comment Edited] (CRYPTO-74) Full class names make code more difficult to update
Date Wed, 22 Jun 2016 05:40: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 edited comment on CRYPTO-74 at 6/22/16 5:40 AM:
-----------------------------------------------------------

Thank Sebb for your comments.

{quote}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.
{quote}
This patch also support using externally provided classes. the value could be the full class
name of externally provided classes.

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

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

{quote}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){quote}

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?


was (Author: dapengsun):
Thank Sebb for your comments.

{quote}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.
{quote}
This patch also support using externally provided classes. the value could be the full class
name of externally provided classes.

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

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

{quote}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){quote}

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