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
