That's an open question. I think we could use the same approach we used to
support 1.0 and 1.1 for cipher and random. Of course, as you noted, the
workload would increase to support additional versions, but I don't think
implementing MAC would otherwise hamstring the overall effort.
Fair poi
kinow merged pull request #102: TEXT-104: deprecate JaroWinkler methods for
2.0, and fix clirr report
URL: https://github.com/apache/commons-text/pull/102
This is an automated message from the Apache Git Service.
To respond
coveralls commented on issue #23: Update readme using commons-build-plugin
URL: https://github.com/apache/commons-rng/pull/23#issuecomment-466699664
[](https://coveralls.io/builds/21811319)
Coverage remained the same a
aherbert opened a new pull request #23: Update readme using commons-build-plugin
URL: https://github.com/apache/commons-rng/pull/23
All Javadoc links are now valid where appropriate.
Manual edits were made on the build plugin output to support the sub-modules.
---
Go!
On Sat, Feb 23, 2019 at 2:16 PM Gary Gregory wrote:
>
> Hi All:
>
> I plan on updating Commons CSV from Java 7 to 8.
>
> Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-
Hi All:
I plan on updating Commons CSV from Java 7 to 8.
Gary
On Sat, 23 Feb 2019 at 02:33, Alex Remily wrote:
>
> more performant implementation to Java developers? If so I think it can we
> added to crypto.>
>
> 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
