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 Tue, 28 Jun 2016 05:18:57 GMT

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

Dapeng Sun edited comment on CRYPTO-74 at 6/28/16 5:18 AM:
-----------------------------------------------------------

I don't think using SPI is much better than factory for CRYPTO, it still have many limitations,

{quote}
The ServiceLoader API is useful, but it has limitations. For example, it is impossible to
derive a class from the ServiceLoader class, so you cannot modify its behavior. You can use
custom ClassLoader subclasses to change how classes are found, but ServiceLoader itself cannot
be extended. Also, the current ServiceLoader class cannot tell your application when new providers
are available at runtime. Additionally, you cannot add change-listeners to the loader to find
out whether a new provider was placed into an application-specific extension directory.

>From "Limitations of the ServiceLoader API" at https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
{quote}

{quote}
It's not an error to install more than one provider for the same service. For example, two
different service providers might supply support for reading the same type of sound file.
In such a case, the system arbitrarily chooses one of the providers. Users who care which
provider is chosen should install only the desired one.

>From "How Users Install New Services" at https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html
{quote}

And user may confuse with installing and selecting an active implementation. And we also want
to hidden the implementation. I think although SPI may be a good mechanism, but it may not
suitable for CRYPTO.


was (Author: dapengsun):
I don't think using SPI is much better than factory for CRYPTO, it still have many limitations,

{quote}
The ServiceLoader API is useful, but it has limitations. For example, it is impossible to
derive a class from the ServiceLoader class, so you cannot modify its behavior. You can use
custom ClassLoader subclasses to change how classes are found, but ServiceLoader itself cannot
be extended. Also, the current ServiceLoader class cannot tell your application when new providers
are available at runtime. Additionally, you cannot add change-listeners to the loader to find
out whether a new provider was placed into an application-specific extension directory.

>From "Limitations of the ServiceLoader API" at https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
{quote}

{quote}
It's not an error to install more than one provider for the same service. For example, two
different service providers might supply support for reading the same type of sound file.
In such a case, the system arbitrarily chooses one of the providers. Users who care which
provider is chosen should install only the desired one.

>From "How Users Install New Services" at https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html
{quote}

And user may confuse with installing and selecting an active implementation. And we also want
to hidden the implementation. I think although SPI may is good mechanism, but it may not suitable
for CRYPTO.

> 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