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