Re: opinions about @NotNull and @Nullable ?

Good question. IntelliJ specifies Runtime retention so they can interact with IntelliJ's internal JRE, which adds additional assertions into the code to enforce the annotations. So even though they have Runtime retention, they're still a development-phase tool. In production, they don't need to be

Re: opinions about @NotNull and @Nullable ?

I find them to be useful in two ways. 1) The document which parameters and return values may be null, and which can't. 2) I use them in conjunction with IntelliJ's Constant Conditions and Exceptions inspection. (This inspection lets me specify what annotations to use for Nullable and NotNull, so I

Re: [Crypto] requesting help testing native binaries

For a library with as many vulnerabilities as OpenSSL, I’m surprised macOS keeps such an ancient version! It’s not like they ship a trimmed down and audited version of LibreSSL, either. On Thu, Aug 27, 2020 at 20:19 Gary Gregory wrote: > The issue for me is that it was a PITA to override macos'

Re: [Crypto] requesting help testing native binaries

The issue for me is that it was a PITA to override macos' baked in (ancient) LibreSSL. Gary On Thu, Aug 27, 2020, 20:03 Alex Remily wrote: > Interesting. If I understand correctly, you did get it to run > successfully to completion, but only after placing a compatible > libcrypto in the direct

Re: [Crypto] requesting help testing native binaries

Interesting. If I understand correctly, you did get it to run successfully to completion, but only after placing a compatible libcrypto in the directory of execution, probably the first place dlopen looks for it. Would you agree then that the error was caused by loading an incompatible libcrypto?

Re: [Crypto] requesting help testing native binaries

Thanks Alex, updating tally: Here is what community testing we have so far for the Crypto.main() smoke test: - darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily - debian-amd64; OpenSSL 1.0.1f; Gary Gregory - debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita - Linux x86_64; OpenSSL 1.1.

Re: [Crypto] requesting help testing native binaries

Gary, You can add the Windows 64 build. Unit tests passed as expected and main function output is: Apache Commons Crypto 1.1.0-SNAPSHOT Native code loaded OK: 1.1.0-SNAPSHOT Native name: Apache Commons Crypto Native built: Aug 16 2020 OpenSSL library loaded OK, version: 0x1010104f OpenSSL librar

Re: [Crypto] requesting help testing native binaries

Here is what community testing we have so far for the Crypto.main() smoke test: - darwin64-x86_64-cc; OpenSSL 1.1.1g; Gary Gregory, Alex Remily - debian-amd64; OpenSSL 1.0.1f; Gary Gregory - debian-amd64; OpenSSL 1.1.1g; Bruno P. Kinoshita - Linux x86_64; OpenSSL 1.1.1; Alex Remily Gary On Sat,

Re: [Crypto] requesting help testing native binaries

On Mon, Aug 24, 2020 at 7:28 PM Alex Remily wrote: > Gary, > > Can you check that your libcrypto.dylib is symlinked to the libcrypto > for OpenSSL 1.1.1.g? Mine wasn't, and I was getting different output > from the main function than from the unit test output. I'm not > confident that this is t

Re: [All] Jenkins going haywire ?

Le jeu. 27 août 2020 à 10:06, Mark Thomas a écrit : > > On 27/08/2020 00:21, Gilles Sadowski wrote: > > Hi. > > > > Something happening recently (apparently unrelated to changes > > in the repository): > > https://ci-builds.apache.org/job/Commons/job/commons-statistics/3/console > > https://ci

Re: [All] Jenkins going haywire ?

On 27/08/2020 00:21, Gilles Sadowski wrote: > Hi. > > Something happening recently (apparently unrelated to changes > in the repository): > https://ci-builds.apache.org/job/Commons/job/commons-statistics/3/console > https://ci-builds.apache.org/job/Commons/job/commons-numbers/2/console > htt