So I did a little homework and JNA appears to be a first class citizen
in Commons Crypto. One instantiates a JNA-backed CryptoCipher just as
one does JNI or JCE. The OpenSslJna class is exposed for that
purpose. I hacked together the below from some JNA test classes to
demonstrate and it runs su
JNA is the middle ground between JNI and JCE in terms of performance
is my understanding without needing any .c files to create linkage.
The problem appears to be that there is no conditional loading and
stubbing of functions like can be done easily in the JNI code and is
why macOS throws that erro
> I think Geoff just answered this question for us.
Yup he was quicker with his reply than me! Thanks :-)
--
Adam Retter
skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk
-
To unsubscribe, e-mail: dev-unsubscr
My apologies. It is only the JNA. I wasn't paying attention and got
crossed with some errors I dealt with while troubleshooting another
issue.
** WARN: JNA could not be enabled: Error looking up function
'ENGINE_load_rdrand': dlsym(0x7f859c4b6db0, ENGINE_load_rdrand):
symbol not found.
I've nev
Adam,
I think Geoff just answered this question for us. I'll go back and
check the Travis logs to see which tests were actually skipped. If
they were just the JNA tests then it's probably not much of a problem.
On Mon, Apr 27, 2020 at 9:44 AM Adam Retter
wrote:
>
> Thanks Alex,
>
> I don't hav
I assumed it was JNI. I'll have to go back and check.
On Mon, Apr 27, 2020 at 9:41 AM Geoffrey Blake
wrote:
>
> Hi Alex,
>
> Just a sanity check, are you sure it was the JNI failing to load or
> was it the JNA? At least on my Mojave MacOS install, libreSSL is
> found and links fine with JNI. J
Thanks Alex,
I don't have a great deal of time available to look into this. If
someone could assure me that this compiles, and all the tests run
correctly on their MacOS with LibreSSL first, then I could then figure
out the difference on Travis. I suspect it is a more general Mac issue
than just T
Hi Alex,
Just a sanity check, are you sure it was the JNI failing to load or
was it the JNA? At least on my Mojave MacOS install, libreSSL is
found and links fine with JNI. JNA is the library that fails to load
on macOS, but that is apparently ok as the JNA implementation is not
used by anything
On Mon, Apr 27, 2020 at 9:11 AM Gary Gregory wrote:
> On Mon, Apr 27, 2020 at 6:39 AM Rob Spoor wrote:
>
>> Why use a String as default and not a T?
>>
>
> Yes of course you are correct.
>
Like this:
default > T getEnum(String key, Class enumType) {
return Enum.valueOf(enumType, ge
On Mon, Apr 27, 2020 at 12:28 AM Xeno Amess wrote:
> I really think we shall have a common template for Enums
>
Please expand, I do not understand.
Gary
>
> XenoAmess
>
>
> From: Gary Gregory
> Sent: Monday, April 27, 2020 8:50:22 AM
> To: Commons Developers
On Mon, Apr 27, 2020 at 6:39 AM Rob Spoor wrote:
> Why use a String as default and not a T?
>
Yes of course you are correct.
Gary
>
> default > T getEnum(String key, Class enumType, T
> defaultEnum) {
> String value = getString(key, null);
> return value != null ? Enum.valueOf(enumT
Adam,
Fair points. I don't know if commons-crypto "officially" supports
LibreSSL, but now that I think about it, it may be a moot point. As
long as LibreSSL complies with the OpenSSL 1.0 or 1.1 API, it *should*
run. It did compile and build against LibreSSL on the Mac, and the
tests didn't fail
Hi Alex,
> Just submitted a PR to increase the coverage in the streams package.
> While prepping the PR I noticed the Travis Mac build is testing
> against LibreSSL
I recently improved the Travis builds for a few platforms, however
libressl on Mac OS has been the case since before I was involved.
Why use a String as default and not a T?
default > T getEnum(String key, Class enumType, T
defaultEnum) {
String value = getString(key, null);
return value != null ? Enum.valueOf(enumType, value) : defaultEnum);
}
On 27/04/2020 06:28, Xeno Amess wrote:
I really think we shall have a
14 matches
Mail list logo
