Thanks folks. An alpha release is a good suggestion! I am checking with the Spark guys as to the Spark 2.0 code freeze timeline and check whether we can meet it with an alpha release While at Commons, we try move fast to make everything clean. Try best stabilize the API.
If folks in community has different ideas, please free feel to raise up. Regards, Haifeng -----Original Message----- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Tuesday, April 26, 2016 10:50 AM To: Commons Developers List <dev@commons.apache.org> Subject: Re: [CRYPTO] Switch from JNI to JNA I like it. RERO! As we plan to have release sooner, marking release ALPHA tagged make sense IMO. Regards, Uma On 4/25/16, 7:02 PM, "sebb" <seb...@gmail.com> wrote: >On 26 April 2016 at 02:56, Chen, Haifeng <haifeng.c...@intel.com> wrote: >>>> Sounds like a tough time schedule. It's only one week until May. >> Yeah, it's a tough time schedule. We will just try moving fast and >>see what we can reach at that time. Maybe it's not realistic in one week. > >It's expensive to change the public API once released. > >Given the timescale, maybe it would work to release an ALPHA version on >the understanding that the API may change incompatibly. > >> -----Original Message----- >> From: Benedikt Ritter [mailto:brit...@apache.org] >> Sent: Tuesday, April 26, 2016 12:03 AM >> To: Commons Developers List <dev@commons.apache.org> >> Subject: Re: [CRYPTO] Switch from JNI to JNA >> >> Chen, Haifeng <haifeng.c...@intel.com> schrieb am Mo., 25. Apr. 2016 >> um >> 08:38 Uhr: >> >>> >> 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. >>> >> >> Sounds like a tough time schedule. It's only one week until May. >> >> >>> Any idea to put JNA evaluation in the second release? >> >> >> Yes, why not. >> >> >>> >>> 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 >>> >>> > >--------------------------------------------------------------------- >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
