On 23 April 2016 at 13:42, Gary Gregory <garydgreg...@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" <hendrikde...@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-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
