commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gangumalla, Uma" <uma.ganguma...@intel.com>
Subject Re: [CRYPTO] Switch from JNI to JNA
Date Fri, 29 Apr 2016 00:08:09 GMT
This is awesome. Thanks Haifeng for driving towards 1st release.

Regards,
Uma

On 4/26/16, 6:27 PM, "Chen, Haifeng" <haifeng.chen@intel.com> wrote:

>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:garydgregory@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" <sebbaz@gmail.com> wrote:
>
>>On 26 April 2016 at 02:56, Chen, Haifeng <haifeng.chen@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:britter@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.chen@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:hendrikdev22@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message