I echo all sentiments regarding benchmarking. The deck at the link is a bit dated, but it contains some benchmarking of the existing commons crypto implementation against the JCE on JDK 8 and 9 that provides reason for optimism. Even if more recent versions of the JCE significantly narrow the performance gap, which remains to be seen, I think commons crypto will endure for the foreseeable future for users who need the performance and can't or won't upgrade.
https://events.static.linuxfound.org/sites/events/files/slides/apache-commons-crypto-another-wheel.pdf Regarding portability, the JNI libraries for each supported OS distribution are bundled with the JAR and transparent to the caller of the commons crypto api. Yes, that makes it a hassle to build a release, but users need only have libcrypto installed locally. On Sun, Feb 28, 2021 at 6:21 PM Matt Sicker <boa...@gmail.com> wrote: > That's why I'm interested in proper benchmarks before supporting a > release of something with platform-specific code. The CPU extensions > are ostensibly for optimizing the code where possible (the Blake3 code > has a dynamic dispatch mechanism for checking CPU features at runtime > to select the assembler-optimized variants), but if JNI overhead > negates the gains there, then I'd agree that sticking to pure Java > code here would be optimal. > > On Sun, 28 Feb 2021 at 17:18, sebb <seb...@gmail.com> wrote: > > > > On Sun, 28 Feb 2021 at 20:14, Matt Sicker <boa...@gmail.com> wrote: > > > > > > I'd also be interested in benchmarking comparisons as I've been > > > working on a proof of concept using Blake3 to do similarly (I have a > > > pure Java implementation and a JNI version that ultimately invokes the > > > reference C implementation, though I've also wondered about linking > > > the reference Rust implementation). The potential advantage to linking > > > in the native implementations here would be in taking advantage of > > > CPU-specific extensions like SSE, AVX, NEON, etc., which aren't > > > accessible from the JVM without JNI or other patches to the JDK > > > itself. If the overhead turns out to be non-negligible, then we should > > > probably keep the native code bindings to commons-crypto while porting > > > pure Java implementations to commons-codec. > > > > Of course the disadvantage is that the code is not portable. > > Also each OS version will need separate testing and makes releasing > > binaries harder. > > This is an issue we have already faced with Crypto. > > And there will be versions of Java for which it will not work. > > > > So unless the is a great performance improvement, I don't think it's > > worth the extra overheads. > > > > > On Sun, 28 Feb 2021 at 09:25, Bernd Eckenfels <e...@zusammenkunft.net> > wrote: > > > > > > > > ... and also do benchmarking early, the native interface overhead > might be a problem so that pure java (intrinsic) code is much faster > > > > > > > > > > > > -- > > > > http://bernd.eckenfels.net > > > > ________________________________ > > > > Von: Gary Gregory <garydgreg...@gmail.com> > > > > Gesendet: Sunday, February 28, 2021 2:45:26 PM > > > > An: Commons Developers List <dev@commons.apache.org> > > > > Betreff: Re: [crypto] Interest in adding support for cryptographic > hash function? > > > > > > > > That sounds reasonable to me. I think once we see a PR, we'll get a > better > > > > idea. Start small IMO. > > > > > > > > Gary > > > > > > > > > > > > On Sat, Feb 27, 2021, 13:51 Alex Remily <alex.rem...@gmail.com> > wrote: > > > > > > > > > I'd be exposing additional elements of the OpenSSL API via > additions to the > > > > > commons crypto API. Since I wouldn't be adding any additional > > > > > dependencies, I would expect that licensing and portability would > remain > > > > > unchanged. Would it not? > > > > > > > > > > Thanks, > > > > > > > > > > Alex > > > > > > > > > > On Sat, Feb 27, 2021 at 1:08 PM Gilles Sadowski < > gillese...@gmail.com> > > > > > wrote: > > > > > > > > > > > Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels > > > > > > <e...@zusammenkunft.net> a écrit : > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > I don’t think it’s a Good idea to introduce native > dependencies to > > > > > > formerly pure Java projects. > > > > > > > > > > > > +1 > > > > > > [I thought that the idea was a (pure) Java implementation.] > > > > > > > > > > > > > So i think native optimized hash implementations would fit > better in > > > > > > commons-crypto. So I would say go for it, keep in mind license > clearance > > > > > > and portability. > > > > > > > > > > > > > > Gruß > > > > > > > Bernd > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > >
