Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <D3441C5C.1A100%uma.gangumalla@intel.com>
References: 
 <CAPm=oFCsMk-0x8Q0FmXq1kZXVajbwFZWgmJzensV+xx45M2jkg@mail.gmail.com>
	<3E657120E422654A9EB626F537B8AA9114140284@shsmsx102.ccr.corp.intel.com>
	<CAB917RLjhhYk3V_mmL-JLe+hoNd-FrRb25MKcrvD93gqRH3Crw@mail.gmail.com>
	<3E657120E422654A9EB626F537B8AA91141410AA@shsmsx102.ccr.corp.intel.com>
	<CAOGo0VYtO1QD8qn6-sxrRcOQRmhJ2UN6Tq7UO4_4sRzXC=mfxQ@mail.gmail.com>
	<D3441C5C.1A100%uma.gangumalla@intel.com>
Date: Mon, 25 Apr 2016 19:49:52 -0700
Message-ID: 
 <CACZkXPzu2zapGFWir3B5TPvP0+GjouB=53mcFO5VoD15SYXBOA@mail.gmail.com>
Subject: Re: [CRYPTO] Switch from JNI to JNA
From: Gary Gregory <garydgregory@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=089e01183138f42fe505315a58d4

--089e01183138f42fe505315a58d4
Content-Type: text/plain; charset=UTF-8

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

--089e01183138f42fe505315a58d4--