[
https://issues.apache.org/jira/browse/CRYPTO-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15368636#comment-15368636
]
Sebb commented on CRYPTO-103:
-----------------------------
Looking into it further, I don't think the NativeCodeLoader.getVersion() method
is actually needed.
It's only used as part of the name of a temporary file which is deleted on exit.
The file name also contains a random UUID.
The version does not appear to offer any benefit at all.
It does not help make the name unique (since it will be constant for a given
version of Crypto) and there is no need to identify the file by its version
(tests still work if the version is 'unknown'). And the file is deleted after
use.
I think the code should be removed along with Crypto.getVersion().
At some later stage new version methods can be added as per CRYPTO-104, but
this implementation is not needed.
> NativeCodeLoader.getVersion() seems badly named
> -----------------------------------------------
>
> Key: CRYPTO-103
> URL: https://issues.apache.org/jira/browse/CRYPTO-103
> Project: Commons Crypto
> Issue Type: Bug
> Reporter: Sebb
>
> The NativeCodeLoader.getVersion() method seems badly named, as it has nothing
> to do with the native code that has been loaded.
> It only relates to the version of the Java code in the jar.
> I would expect the method to return the version details from the library
> itself.
> If there is a need to return the Java code version, it should be done from a
> method in another class, e.g. Utils or Crypto. Note: also the extraction
> should be done once, e.g. using IODH or using a synchronised/volatile lock.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
