Yes. My current thinking is that I'd simply expose the existing relevant
OpenSSL functions via JNI and JNA by mapping them to the JCE API for the
Mac class to the extent possible. Essentially, I'd follow the established
pattern for the cipher and random functionality currently exposed.
On Fri,
I don't have any algorithm-specific quantitative analysis to reference
specifically regarding native vs JCE performance, but my intuition is that
a performance boost from dropping into native code comes from eliminating
the overhead from the JVM abstraction layer more than anything else, with
perha
SukantPal commented on issue #38: Cleaned up PNG component.
URL: https://github.com/apache/commons-imaging/pull/38#issuecomment-466596775
Kinow that was relieving. As you know, this was my first OSS attempt. It
kinda discouraged me that nobody was doing anything.
Please tell me if yo
aherbert opened a new pull request #22: RNG-72: Add new JMH benchmark
ConstructionPerformance
URL: https://github.com/apache/commons-rng/pull/22
Initial benchmark version.
Results posted in
[RNG-72](https://issues.apache.org/jira/browse/RNG-72?focusedCommentId=16775619&page=com.atla
Thank you very much for taking care of this!
Am 22.02.2019 um 18:49 schrieb Marcelo Vanzin:
Jira link: https://issues.apache.org/jira/browse/INFRA-17892
On Fri, Feb 22, 2019 at 9:44 AM Marcelo Vanzin wrote:
Thanks all, vote passes with 11 +1s, no -1s.
I'll file the INFRA ticket and link it b
Jira link: https://issues.apache.org/jira/browse/INFRA-17892
On Fri, Feb 22, 2019 at 9:44 AM Marcelo Vanzin wrote:
>
> Thanks all, vote passes with 11 +1s, no -1s.
>
> I'll file the INFRA ticket and link it back here soon.
>
> On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin wrote:
> >
> > I'm ope
Thanks all, vote passes with 11 +1s, no -1s.
I'll file the INFRA ticket and link it back here soon.
On Tue, Feb 19, 2019 at 1:35 PM Marcelo Vanzin wrote:
>
> I'm opening a vote based on recent discussions about the extra noise
> generated by github updates going to dev@. So please vote:
>
> - +1
Hello,
I think crypto is rather special for native - not sure if you can get the same
speedup from a native HMAC compared to the JCE Version. So a HMAC utility is
mostly about convenience, and that already exists in commons-codec in HmacUtils.
The only thing which would be a good fit as it does
Hello Alex,
welcome to the Apache Commons Developers list!
Am Fr., 22. Feb. 2019 um 03:01 Uhr schrieb Alex Remily <
alex.rem...@gmail.com>:
> Team,
>
> What do you think about adding HMAC and CMAC functionality to commons
> crypto? I have a project I'd like to use it for, so I don't mind workin
kinow commented on issue #102: TEXT-104: deprecate JaroWinkler methods for 2.0,
and fix clirr report
URL: https://github.com/apache/commons-text/pull/102#issuecomment-466327585
Tested on Oracle Java 8, and Open JDK 11 with `mvn
-Dcheckstyle.failOnViolation=false`, all tests, reports (exce
10 matches
Mail list logo