>> 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

Reply via email to