>> I am a RERO guy so that is fine with me... BUT... keep in mind that we need >> to be BC within major releases. Now, me, I do not mind evolving the API >> right away in a 2.0, but hey that's just me. In the first release, we would need to think more on API. Would try best to provide a stable API and keep BC among the releases. JNA should be kept as implementation approach towards calling the native, it should not impact the API.
>> Also, since we can fiddle the code all we want in the repo (in a branch or >> not) without releasing we can still do the JNA experiment and not release it. Make sense. Regards, Haifeng -----Original Message----- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Tuesday, April 26, 2016 6:04 AM To: Commons Developers List <dev@commons.apache.org> Subject: Re: [CRYPTO] Switch from JNI to JNA On Sun, Apr 24, 2016 at 11:38 PM, Chen, Haifeng <haifeng.c...@intel.com> wrote: > >> Maybe its an option to replace JNI by JNA [1]. This would have IHMO > several advantages like > >> * No C code needs to be written, compiled, tested and maintained > >> * Its easier compared to JNI (this could help attracting more > >> people to > contribute) > >> * Many supported platforms [2], precompiled native binaries > >> available > Agree on these advantages. > > >> Disadvantages: > >> * Introduce a dependency to JNA > >> * Performance decrease compared to JNI (direct buffers and direct > mapping helps minimizing this) [3] > The major concern will be on the performance. Because the major value > for Crypto is to utilize the performance optimization OpenSSL provided. > Need to have an evaluation on how much performance penalty will occur > when using JNA comparing JNI. > > The Spark community are eager to utilize this library. If we can have > the first release before May, there is a possibility to include it in Spark > 2.0. > Any idea to put JNA evaluation in the second release? > I am a RERO guy so that is fine with me... BUT... keep in mind that we need to be BC within major releases. Now, me, I do not mind evolving the API right away in a 2.0, but hey that's just me. Also, since we can fiddle the code all we want in the repo (in a branch or not) without releasing we can still do the JNA experiment and not release it. 2c, Gary > > Thanks, > Haifeng > > -----Original Message----- > From: Hendrik Dev [mailto:hendrikde...@gmail.com] > Sent: Saturday, April 23, 2016 6:43 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: [CRYPTO] Switch from JNI to JNA > > Hi, > > i just had a brief look into commons crypto today. > Maybe its an option to replace JNI by JNA [1]. This would have IHMO > several advantages like > > * No C code needs to be written, compiled, tested and maintained > * Its easier compared to JNI (this could help attracting more people > to > contribute) > * Many supported platforms [2], precompiled native binaries available > > Disadvantages: > > * Introduce a dependency to JNA > * Performance decrease compared to JNI (direct buffers and direct > mapping helps minimizing this) [3] > > I prepared a demo [4] to show thats its generally working and how a > implementation could like (although tests are not working and error > handling is missing). > > [1] https://github.com/java-native-access/jna > [2] https://github.com/java-native-access/jna/tree/master/lib/native > [3] https://s.apache.org/q5Tl > [4] https://s.apache.org/DQeD > > Wdyt? > > Thanks > Hendrik > > -- > Hendrik Saly (salyh, hendrikdev22) > @hendrikdev22 > PGP: 0x22D7F6EC > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
