As a user and past contributor, my view of Commons Crypto is that it is a
Java wrapper around certain common features of OpenSSL, full stop. As
such, it provides near-native performance to the Java developer for
processor-intensive operations via a Java API. It is a set of tools for
developing cryptographic applications in Java only to the extent that it
exposes underlying OpenSSL functionality. The latest contribution offer
seems consistent with that scope because it relates specifically to
functionality that currently exists in the underlying native library.
I don't have a strong opinion as to whether the project should be converted
to multi-module, but I'm unclear as to whether or not it would confer any
additional benefit. The existing project structure already separates the
native source from the Java source, and the maven build process already
compiles and packages the native and Java source and binaries
appropriately. There is a Docker file currently in the repository, used
for the 1.1 release, that manages the cross-compilation for the JNI
libraries and packages them into the commons-crypto jar.
Anyway, that's my $0.02.
Alex
On Tue, Jun 14, 2022 at 9:10 AM Gilles Sadowski <gillese...@gmail.com>
wrote:
> Hello.
>
> Contradicting comments about the latest contribution offer[1] suggest
> that the scope of the [Crypto] component is ill-defined.
>
> Is it a Java wrapper around a specific library ("openssl")?
> Is it a set of tools (a.o. strong random number generators) for developing
> cryptographic applications in Java?
> Is it both? Does it intend to be more?
>
> In order to simplify maintenance (and clarify expectations), shouldn't it
> become a (maven) multi-module project, with explicit separation between
> platform-agnostic functionality and platform-specific (native) codes?
>
> Regards,
> Gilles
>
> [1] https://issues.apache.org/jira/browse/CRYPTO-162
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
