You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Hendrik Dev <he...@gmail.com> on 2016/04/23 12:42:40 UTC
[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
Re: [CRYPTO] Switch from JNI to JNA
Posted by "Gangumalla, Uma" <um...@intel.com>.
This is awesome. Thanks Haifeng for driving towards 1st release.
Regards,
Uma
On 4/26/16, 6:27 PM, "Chen, Haifeng" <ha...@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 <de...@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" <se...@gmail.com> wrote:
>
>>On 26 April 2016 at 02:56, Chen, Haifeng <ha...@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 <de...@commons.apache.org>
>>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>>
>>> Chen, Haifeng <ha...@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 <de...@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
RE: [CRYPTO] Switch from JNI to JNA
Posted by "Chen, Haifeng" <ha...@intel.com>.
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 <de...@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" <se...@gmail.com> wrote:
>On 26 April 2016 at 02:56, Chen, Haifeng <ha...@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 <de...@commons.apache.org>
>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>
>> Chen, Haifeng <ha...@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 <de...@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
Re: [CRYPTO] Switch from JNI to JNA
Posted by Gary Gregory <ga...@gmail.com>.
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" <se...@gmail.com> wrote:
>On 26 April 2016 at 02:56, Chen, Haifeng <ha...@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 <de...@commons.apache.org>
>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>
>> Chen, Haifeng <ha...@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 <de...@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
Re: [CRYPTO] Switch from JNI to JNA
Posted by "Gangumalla, Uma" <um...@intel.com>.
As we plan to have release sooner, marking release ALPHA tagged make sense
IMO.
Regards,
Uma
On 4/25/16, 7:02 PM, "sebb" <se...@gmail.com> wrote:
>On 26 April 2016 at 02:56, Chen, Haifeng <ha...@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 <de...@commons.apache.org>
>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>
>> Chen, Haifeng <ha...@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 <de...@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
Re: [CRYPTO] Switch from JNI to JNA
Posted by sebb <se...@gmail.com>.
On 26 April 2016 at 02:56, Chen, Haifeng <ha...@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 <de...@commons.apache.org>
> Subject: Re: [CRYPTO] Switch from JNI to JNA
>
> Chen, Haifeng <ha...@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 <de...@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
RE: [CRYPTO] Switch from JNI to JNA
Posted by "Chen, Haifeng" <ha...@intel.com>.
>> 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.
-----Original Message-----
From: Benedikt Ritter [mailto:britter@apache.org]
Sent: Tuesday, April 26, 2016 12:03 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [CRYPTO] Switch from JNI to JNA
Chen, Haifeng <ha...@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 <de...@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
>
>
Re: [CRYPTO] Switch from JNI to JNA
Posted by Benedikt Ritter <br...@apache.org>.
Chen, Haifeng <ha...@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 <de...@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
>
>
Re: [CRYPTO] Switch from JNI to JNA
Posted by sebb <se...@gmail.com>.
On 26 April 2016 at 02:51, Chen, Haifeng <ha...@intel.com> wrote:
>>> 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.
If you can define an API which works for both JNI/JNA that would be ideal.
This may need some implementation classes; ideally these should be
marked as internal and therefore subject to change between releases
without warning.
The smaller the public API, the easier it will be to update.
However of course defining a good public API is not easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [CRYPTO] Switch from JNI to JNA
Posted by "Chen, Haifeng" <ha...@intel.com>.
>> 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:garydgregory@gmail.com]
Sent: Tuesday, April 26, 2016 6:04 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [CRYPTO] Switch from JNI to JNA
On Sun, Apr 24, 2016 at 11:38 PM, Chen, Haifeng <ha...@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:hendrikdev22@gmail.com]
> Sent: Saturday, April 23, 2016 6:43 PM
> To: Commons Developers List <de...@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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CRYPTO] Switch from JNI to JNA
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Apr 24, 2016 at 11:38 PM, Chen, Haifeng <ha...@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:hendrikdev22@gmail.com]
> Sent: Saturday, April 23, 2016 6:43 PM
> To: Commons Developers List <de...@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
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@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
RE: [CRYPTO] Switch from JNI to JNA
Posted by "Chen, Haifeng" <ha...@intel.com>.
>> 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?
Thanks,
Haifeng
-----Original Message-----
From: Hendrik Dev [mailto:hendrikdev22@gmail.com]
Sent: Saturday, April 23, 2016 6:43 PM
To: Commons Developers List <de...@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
Re: [CRYPTO] Switch from JNI to JNA
Posted by sebb <se...@gmail.com>.
On 23 April 2016 at 13:42, Gary Gregory <ga...@gmail.com> wrote:
> Could this be made pluggable? Then its easy to pick flexibility vs. speed.
> I think Svn support in Eclipse lets you do this through Subclipse and
> JavaHL.
No point, except possibly in the (very) short term whilst the JNA
implementation is being developed.
Having two implementations would increase the maintenance, and would
not solve the issue of requiring C code to be maintained.
> Gary
> On Apr 23, 2016 3:42 AM, "Hendrik Dev" <he...@gmail.com> wrote:
>
>> 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
Re: [CRYPTO] Switch from JNI to JNA
Posted by Gary Gregory <ga...@gmail.com>.
Could this be made pluggable? Then its easy to pick flexibility vs. speed.
I think Svn support in Eclipse lets you do this through Subclipse and
JavaHL.
Gary
On Apr 23, 2016 3:42 AM, "Hendrik Dev" <he...@gmail.com> wrote:
> 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
>
>
Re: [CRYPTO] Switch from JNI to JNA
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 24/04/2016 11:29, Hendrik Dev a écrit :
> I have no experience (regarding performance and stability) with BridJ
> but it seems that the license per se could be an issue:
> https://github.com/nativelibs4java/BridJ/blob/master/LICENSE
Don't worry that's a BSD-3-Clause license, it's compatible with the
Apache-2.0 license:
http://www.apache.org/legal/resolved.html#category-a
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CRYPTO] Switch from JNI to JNA
Posted by Hendrik Dev <he...@gmail.com>.
I have no experience (regarding performance and stability) with BridJ
but it seems that the license per se could be an issue:
https://github.com/nativelibs4java/BridJ/blob/master/LICENSE
On Sat, Apr 23, 2016 at 8:15 PM, Damjan Jovanovic <da...@apache.org> wrote:
> There's also BridJ (https://github.com/nativelibs4java/BridJ), which
> claims to be very fast, supports C++ and COM, and JNAerator can
> autogenerate code for it from C/C++ headers.
>
> Java 9 will also have vastly enhanced access to native code
> (http://openjdk.java.net/projects/panama/).
>
> Damjan
>
> On Sat, Apr 23, 2016 at 12:42 PM, Hendrik Dev <he...@gmail.com> wrote:
>> 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
>
--
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
Re: [CRYPTO] Switch from JNI to JNA
Posted by Damjan Jovanovic <da...@apache.org>.
There's also BridJ (https://github.com/nativelibs4java/BridJ), which
claims to be very fast, supports C++ and COM, and JNAerator can
autogenerate code for it from C/C++ headers.
Java 9 will also have vastly enhanced access to native code
(http://openjdk.java.net/projects/panama/).
Damjan
On Sat, Apr 23, 2016 at 12:42 PM, Hendrik Dev <he...@gmail.com> wrote:
> 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