Re: [configuration] org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
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 common template for Enums
XenoAmess
From: Gary Gregory
Sent: Monday, April 27, 2020 8:50:22 AM
To: Commons Developers List
Subject: [configuration]
org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
Hi All:
I'd like to have a way to get an enum instance out of
a org.apache.commons.configuration2.ImmutableConfiguration.
I'm surprised there is nothing like a getEnum(...). Any thoughts about
adding:
default > T getEnum(String key, Class enumType) {
return Enum.valueOf(enumType, getString(key));
}
default > T getEnum(String key, Class enumType, String
defaultEnum) {
return Enum.valueOf(enumType, getString(key, defaultEnum));
}
?
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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. Looking back through the Git history it looks like it has been this way since October 2018 - https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 Whilst it is possible with some manual work to install OpenSSL on MacOS, and I could make this happen in the Travis builds if you wish... this feels a bit unfriendly to users to me, as of course most Java users just add the Jar dependency and get going without a second thought ;-) So I just wanted to check some stuff with you first. The README.md does not make it very clear that OpenSSL is required on MacOS, it says: 4. JNI-based implementation to achieve comparable performance to the native C/C++ version based on OpenSsl. 5. Portable across various operating systems (currently only Linux/MacOSX/Windows); Apache Commons Crypto loads the library according to your machine environment (it checks system properties, os.name and os.arch). 6. Simple usage. Add the commons-crypto-(version).jar file to your classpath. So I guess my question is - Does commons-crypto only support OpenSSL, and there is no plan to change that?. If so then I can make the changes on Travis for you, and I think we must improve the README.md so it is clear that Mac users have to manually install OpenSSL and override LibreSSL if they want to use the JNI part of Commons Crypto. Cheers Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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--they were skipped because commons-crypto couldn't find the native libraries for JNI. I think the issue is probably an environment variable or path that needs to be set so commons-crypto can find the native binaries. The tests may well pass if the native library is present. Even if they don't, at least we'd know. Would you be willing to troubleshoot that on Travis? If so, I'd recommend checking out the NativeCodeLoader class. Marcelo is more familiar with the application than I am, so maybe he can give some pointers. @Marcelo - Any suggestions? Alex Alex On Mon, Apr 27, 2020 at 7:10 AM Adam Retter wrote: > > 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. > Looking back through the Git history it looks like it has been this > way since October 2018 - > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > Whilst it is possible with some manual work to install OpenSSL on > MacOS, and I could make this happen in the Travis builds if you > wish... this feels a bit unfriendly to users to me, as of course most > Java users just add the Jar dependency and get going without a second > thought ;-) > So I just wanted to check some stuff with you first. > > The README.md does not make it very clear that OpenSSL is required on > MacOS, it says: > > 4. JNI-based implementation to achieve comparable performance to the > native C/C++ version based on OpenSsl. > 5. Portable across various operating systems (currently only > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > according to your machine environment (it checks system properties, > os.name and os.arch). > 6. Simple usage. Add the commons-crypto-(version).jar file to your classpath. > > So I guess my question is - Does commons-crypto only support OpenSSL, > and there is no plan to change that?. If so then I can make the > changes on Travis for you, and I think we must improve the README.md > so it is clear that Mac users have to manually install OpenSSL and > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > Cheers Adam. > > > > -- > Adam Retter > > skype: adam.retter > tweet: adamretter > http://www.adamretter.org.uk > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
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 List
> Subject: [configuration]
> org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
>
> Hi All:
>
> I'd like to have a way to get an enum instance out of
> a org.apache.commons.configuration2.ImmutableConfiguration.
>
> I'm surprised there is nothing like a getEnum(...). Any thoughts about
> adding:
>
> default > T getEnum(String key, Class enumType) {
> return Enum.valueOf(enumType, getString(key));
> }
>
> default > T getEnum(String key, Class enumType, String
> defaultEnum) {
> return Enum.valueOf(enumType, getString(key, defaultEnum));
> }
>
> ?
> Gary
>
Re: [configuration] org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
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(enumType, value) : defaultEnum);
> }
>
>
> On 27/04/2020 06:28, Xeno Amess wrote:
> > I really think we shall have a common template for Enums
> >
> > XenoAmess
> >
> >
> > From: Gary Gregory
> > Sent: Monday, April 27, 2020 8:50:22 AM
> > To: Commons Developers List
> > Subject: [configuration]
> org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
> >
> > Hi All:
> >
> > I'd like to have a way to get an enum instance out of
> > a org.apache.commons.configuration2.ImmutableConfiguration.
> >
> > I'm surprised there is nothing like a getEnum(...). Any thoughts about
> > adding:
> >
> > default > T getEnum(String key, Class enumType) {
> > return Enum.valueOf(enumType, getString(key));
> > }
> >
> > default > T getEnum(String key, Class enumType,
> String
> > defaultEnum) {
> > return Enum.valueOf(enumType, getString(key, defaultEnum));
> > }
> >
> > ?
> > Gary
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [configuration] org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
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, getString(key));
}
default > T getEnum(String key, Class enumType, T
defaultEnum) {
final String strValue = getString(key);
return strValue == null ? defaultEnum : Enum.valueOf(enumType,
strValue);
}
Gary
>
> Gary
>
>
>>
>> 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 common template for Enums
>> >
>> > XenoAmess
>> >
>> >
>> > From: Gary Gregory
>> > Sent: Monday, April 27, 2020 8:50:22 AM
>> > To: Commons Developers List
>> > Subject: [configuration]
>> org.apache.commons.configuration2.ImmutableConfiguration.getEnum()?
>> >
>> > Hi All:
>> >
>> > I'd like to have a way to get an enum instance out of
>> > a org.apache.commons.configuration2.ImmutableConfiguration.
>> >
>> > I'm surprised there is nothing like a getEnum(...). Any thoughts about
>> > adding:
>> >
>> > default > T getEnum(String key, Class enumType) {
>> > return Enum.valueOf(enumType, getString(key));
>> > }
>> >
>> > default > T getEnum(String key, Class enumType,
>> String
>> > defaultEnum) {
>> > return Enum.valueOf(enumType, getString(key, defaultEnum));
>> > }
>> >
>> > ?
>> > Gary
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
Re: [crypto] Help Releasing new Commons Crypto
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 user accessible. -Geoff On Mon, Apr 27, 2020 at 7:53 AM Alex Remily wrote: > > 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--they were skipped because commons-crypto couldn't > find the native libraries for JNI. I think the issue is probably an > environment variable or path that needs to be set so commons-crypto > can find the native binaries. The tests may well pass if the native > library is present. Even if they don't, at least we'd know. Would > you be willing to troubleshoot that on Travis? If so, I'd recommend > checking out the NativeCodeLoader class. > > Marcelo is more familiar with the application than I am, so maybe he > can give some pointers. > > @Marcelo - Any suggestions? > > Alex > > > Alex > > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter > wrote: > > > > 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. > > Looking back through the Git history it looks like it has been this > > way since October 2018 - > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > > > Whilst it is possible with some manual work to install OpenSSL on > > MacOS, and I could make this happen in the Travis builds if you > > wish... this feels a bit unfriendly to users to me, as of course most > > Java users just add the Jar dependency and get going without a second > > thought ;-) > > So I just wanted to check some stuff with you first. > > > > The README.md does not make it very clear that OpenSSL is required on > > MacOS, it says: > > > > 4. JNI-based implementation to achieve comparable performance to the > > native C/C++ version based on OpenSsl. > > 5. Portable across various operating systems (currently only > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > > according to your machine environment (it checks system properties, > > os.name and os.arch). > > 6. Simple usage. Add the commons-crypto-(version).jar file to your > > classpath. > > > > So I guess my question is - Does commons-crypto only support OpenSSL, > > and there is no plan to change that?. If so then I can make the > > changes on Travis for you, and I think we must improve the README.md > > so it is clear that Mac users have to manually install OpenSSL and > > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > > > > Cheers Adam. > > > > > > > > -- > > Adam Retter > > > > skype: adam.retter > > tweet: adamretter > > http://www.adamretter.org.uk > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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 Travis, as the Travis Mac environment is fairly standard. On Mon, 27 Apr 2020 at 14:53, Alex Remily wrote: > > 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--they were skipped because commons-crypto couldn't > find the native libraries for JNI. I think the issue is probably an > environment variable or path that needs to be set so commons-crypto > can find the native binaries. The tests may well pass if the native > library is present. Even if they don't, at least we'd know. Would > you be willing to troubleshoot that on Travis? If so, I'd recommend > checking out the NativeCodeLoader class. > > Marcelo is more familiar with the application than I am, so maybe he > can give some pointers. > > @Marcelo - Any suggestions? > > Alex > > > Alex > > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter > wrote: > > > > 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. > > Looking back through the Git history it looks like it has been this > > way since October 2018 - > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > > > Whilst it is possible with some manual work to install OpenSSL on > > MacOS, and I could make this happen in the Travis builds if you > > wish... this feels a bit unfriendly to users to me, as of course most > > Java users just add the Jar dependency and get going without a second > > thought ;-) > > So I just wanted to check some stuff with you first. > > > > The README.md does not make it very clear that OpenSSL is required on > > MacOS, it says: > > > > 4. JNI-based implementation to achieve comparable performance to the > > native C/C++ version based on OpenSsl. > > 5. Portable across various operating systems (currently only > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > > according to your machine environment (it checks system properties, > > os.name and os.arch). > > 6. Simple usage. Add the commons-crypto-(version).jar file to your > > classpath. > > > > So I guess my question is - Does commons-crypto only support OpenSSL, > > and there is no plan to change that?. If so then I can make the > > changes on Travis for you, and I think we must improve the README.md > > so it is clear that Mac users have to manually install OpenSSL and > > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > > > > Cheers Adam. > > > > > > > > -- > > Adam Retter > > > > skype: adam.retter > > tweet: adamretter > > http://www.adamretter.org.uk > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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. JNA is the library that fails to load > on macOS, but that is apparently ok as the JNA implementation is not > used by anything user accessible. > > -Geoff > > On Mon, Apr 27, 2020 at 7:53 AM Alex Remily wrote: > > > > 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--they were skipped because commons-crypto couldn't > > find the native libraries for JNI. I think the issue is probably an > > environment variable or path that needs to be set so commons-crypto > > can find the native binaries. The tests may well pass if the native > > library is present. Even if they don't, at least we'd know. Would > > you be willing to troubleshoot that on Travis? If so, I'd recommend > > checking out the NativeCodeLoader class. > > > > Marcelo is more familiar with the application than I am, so maybe he > > can give some pointers. > > > > @Marcelo - Any suggestions? > > > > Alex > > > > > > Alex > > > > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter > > wrote: > > > > > > 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. > > > Looking back through the Git history it looks like it has been this > > > way since October 2018 - > > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > > > > > Whilst it is possible with some manual work to install OpenSSL on > > > MacOS, and I could make this happen in the Travis builds if you > > > wish... this feels a bit unfriendly to users to me, as of course most > > > Java users just add the Jar dependency and get going without a second > > > thought ;-) > > > So I just wanted to check some stuff with you first. > > > > > > The README.md does not make it very clear that OpenSSL is required on > > > MacOS, it says: > > > > > > 4. JNI-based implementation to achieve comparable performance to the > > > native C/C++ version based on OpenSsl. > > > 5. Portable across various operating systems (currently only > > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > > > according to your machine environment (it checks system properties, > > > os.name and os.arch). > > > 6. Simple usage. Add the commons-crypto-(version).jar file to your > > > classpath. > > > > > > So I guess my question is - Does commons-crypto only support OpenSSL, > > > and there is no plan to change that?. If so then I can make the > > > changes on Travis for you, and I think we must improve the README.md > > > so it is clear that Mac users have to manually install OpenSSL and > > > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > > > > > > > Cheers Adam. > > > > > > > > > > > > -- > > > Adam Retter > > > > > > skype: adam.retter > > > tweet: adamretter > > > http://www.adamretter.org.uk > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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 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 Travis, as the Travis Mac environment is fairly standard. > > On Mon, 27 Apr 2020 at 14:53, Alex Remily wrote: > > > > 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--they were skipped because commons-crypto couldn't > > find the native libraries for JNI. I think the issue is probably an > > environment variable or path that needs to be set so commons-crypto > > can find the native binaries. The tests may well pass if the native > > library is present. Even if they don't, at least we'd know. Would > > you be willing to troubleshoot that on Travis? If so, I'd recommend > > checking out the NativeCodeLoader class. > > > > Marcelo is more familiar with the application than I am, so maybe he > > can give some pointers. > > > > @Marcelo - Any suggestions? > > > > Alex > > > > > > Alex > > > > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter > > wrote: > > > > > > 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. > > > Looking back through the Git history it looks like it has been this > > > way since October 2018 - > > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > > > > > Whilst it is possible with some manual work to install OpenSSL on > > > MacOS, and I could make this happen in the Travis builds if you > > > wish... this feels a bit unfriendly to users to me, as of course most > > > Java users just add the Jar dependency and get going without a second > > > thought ;-) > > > So I just wanted to check some stuff with you first. > > > > > > The README.md does not make it very clear that OpenSSL is required on > > > MacOS, it says: > > > > > > 4. JNI-based implementation to achieve comparable performance to the > > > native C/C++ version based on OpenSsl. > > > 5. Portable across various operating systems (currently only > > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > > > according to your machine environment (it checks system properties, > > > os.name and os.arch). > > > 6. Simple usage. Add the commons-crypto-(version).jar file to your > > > classpath. > > > > > > So I guess my question is - Does commons-crypto only support OpenSSL, > > > and there is no plan to change that?. If so then I can make the > > > changes on Travis for you, and I think we must improve the README.md > > > so it is clear that Mac users have to manually install OpenSSL and > > > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > > > > > > > Cheers Adam. > > > > > > > > > > > > -- > > > Adam Retter > > > > > > skype: adam.retter > > > tweet: adamretter > > > http://www.adamretter.org.uk > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- > Adam Retter > > skype: adam.retter > tweet: adamretter > http://www.adamretter.org.uk > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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 never used JNA before, but I wonder why the original developers would bother putting it in if it is unusable externally. 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. JNA is the library that fails to load > on macOS, but that is apparently ok as the JNA implementation is not > used by anything user accessible. > > -Geoff > > On Mon, Apr 27, 2020 at 7:53 AM Alex Remily wrote: > > > > 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--they were skipped because commons-crypto couldn't > > find the native libraries for JNI. I think the issue is probably an > > environment variable or path that needs to be set so commons-crypto > > can find the native binaries. The tests may well pass if the native > > library is present. Even if they don't, at least we'd know. Would > > you be willing to troubleshoot that on Travis? If so, I'd recommend > > checking out the NativeCodeLoader class. > > > > Marcelo is more familiar with the application than I am, so maybe he > > can give some pointers. > > > > @Marcelo - Any suggestions? > > > > Alex > > > > > > Alex > > > > On Mon, Apr 27, 2020 at 7:10 AM Adam Retter > > wrote: > > > > > > 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. > > > Looking back through the Git history it looks like it has been this > > > way since October 2018 - > > > https://github.com/apache/commons-crypto/commit/c5c6220c2509c4d12de3fc08d591f82b89f882a0#diff-354f30a63fb0907d4ad57269548329e3 > > > > > > Whilst it is possible with some manual work to install OpenSSL on > > > MacOS, and I could make this happen in the Travis builds if you > > > wish... this feels a bit unfriendly to users to me, as of course most > > > Java users just add the Jar dependency and get going without a second > > > thought ;-) > > > So I just wanted to check some stuff with you first. > > > > > > The README.md does not make it very clear that OpenSSL is required on > > > MacOS, it says: > > > > > > 4. JNI-based implementation to achieve comparable performance to the > > > native C/C++ version based on OpenSsl. > > > 5. Portable across various operating systems (currently only > > > Linux/MacOSX/Windows); Apache Commons Crypto loads the library > > > according to your machine environment (it checks system properties, > > > os.name and os.arch). > > > 6. Simple usage. Add the commons-crypto-(version).jar file to your > > > classpath. > > > > > > So I guess my question is - Does commons-crypto only support OpenSSL, > > > and there is no plan to change that?. If so then I can make the > > > changes on Travis for you, and I think we must improve the README.md > > > so it is clear that Mac users have to manually install OpenSSL and > > > override LibreSSL if they want to use the JNI part of Commons Crypto. > > > > > > > > > Cheers Adam. > > > > > > > > > > > > -- > > > Adam Retter > > > > > > skype: adam.retter > > > tweet: adamretter > > > http://www.adamretter.org.uk > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
> 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...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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 error, LibreSSL lacks the rdrand() function. Perhaps it was included as a path to get rid of the native binaries that have to be built for JNI? But wonder if the performance wasn't there, or the macOS failures prevented its full development? -Geoff On Mon, Apr 27, 2020 at 9:15 AM Adam Retter wrote: > > > 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...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [crypto] Help Releasing new Commons Crypto
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 successfully to completion as a stand alone
program.
I think we're back to asking the question of whether or not to support
LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
because that is my primary development environment. I also understand
the convenience argument and I know it's a PITA to install OpenSSL
manually on a Mac, especially a new one. Nevertheless, this build is
already complex in large part because of the native interface, so
adding yet another native binary to the support list is going to
exacerbate the situation. Maybe we put it on the roadmap as a future
enhancement and see how many votes it gets.
Thoughts?
Alex
public static void main(final String args[]) throws Exception {
final String cipherClass = OpenSslJna.getCipherClass().getName();
Properties props = new Properties();
props.setProperty(CryptoCipherFactory.CLASSES_KEY, cipherClass);
String transformation = "AES/CBC/NoPadding";
final byte[] key = DatatypeConverter
.parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
final byte[] iv = DatatypeConverter
.parseHexBinary("000102030405060708090a0b0c0d0e0f");
final byte[] inputBytes = DatatypeConverter
.parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
final byte[] outputBytes = DatatypeConverter
.parseHexBinary("7649abac8119b246cee98e9b12e9197d");
CryptoCipher enc = Utils.getCipherInstance(transformation, props);
enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
new IvParameterSpec(iv));
CryptoCipher dec = Utils.getCipherInstance(transformation, props);
dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
new IvParameterSpec(iv));
final int blockSize = enc.getBlockSize();
byte[] temp = new byte[inputBytes.length + blockSize];
final int n = enc.doFinal(inputBytes, 0, inputBytes.length, temp, 0);
final byte[] cipherText = new byte[n];
System.arraycopy(temp, 0, cipherText, 0, n);
Assert.assertArrayEquals("byte array encryption error.", outputBytes,
cipherText);
temp = new byte[cipherText.length + blockSize];
final int m = dec.doFinal(cipherText, 0, cipherText.length, temp, 0);
final byte[] plainText = new byte[m];
System.arraycopy(temp, 0, plainText, 0, m);
Assert.assertArrayEquals("byte array decryption error.", inputBytes,
plainText);
}
On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
wrote:
>
> 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 error, LibreSSL lacks the rdrand() function.
> Perhaps it was included as a path to get rid of the native binaries
> that have to be built for JNI? But wonder if the performance wasn't
> there, or the macOS failures prevented its full development?
>
> -Geoff
>
> On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> wrote:
> >
> > > 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...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
