Hi, all.
Recently there was a issue COMPRESS-565 about the Zip64. And I have pushed a
fix PR #169 for it. The fix introduces a new option in Zip64Mode, which is a
compromise solution for 7z, Expand-Archive and likely Excel.
I named the new option `AlwaysWithCompatibility`, which may not be a goo
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 per
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 assemble
On Sun, 28 Feb 2021 at 20:14, Matt Sicker 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
+1
Site reports look good, signatures look good too. Inspected maven archives &
dist binaries and sources. Found nothing out of the ordinary.
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_282, ven
For those who are unfamiliar with the Blake family of hash functions,
Blake3 is essentially an updated version of Blake2s that unifies the
other Blake2* variants into a single API to make things easier for
developers and users. Blake2 has several variants, 2b and 2s being the
most commonly used (bl
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 implemen
+1
Tested with:
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3_1/libexec
Java version: 15.0.1, vendor: N/A, runtime:
/usr/local/Cellar/openjdk/15.0.1/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name:
... 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
Gesendet: Sunday, February 28, 2021 2:45:26 PM
An: Commons Developers List
Bet
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 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
>
10 matches
Mail list logo
