Hi Jochen, Many CPUs come with built-in support for certain cryptographic and/or hash/checksum-related primitives. For example, modern x86 CPUs have CRC32C implemented in hardware. Currently, this must be accessed via inline assembly expressed in JNI. It is worth it... at least in the case of checksumming, you often see 5x or 10x reductions in the amount of CPU used. The gains for moving from pure Java to using the openSSL AES functions are similar. Perhaps someday Java will gain native support for these features. Until that point, though, JNI will be necessary to get reasonable performance on modern hardware.
best, Colin On Mon, Feb 22, 2016 at 10:02 AM, Jochen Wiedmann <jochen.wiedm...@gmail.com> wrote: > On Mon, Feb 22, 2016 at 6:28 PM, Colin P. McCabe <cmcc...@apache.org> wrote: > >> What is the strategy for handling JNI components? > > Wrong question, IMO. Should better be: What are the reasons for using > JNI components? Couldn't they be replaced? If so, that would very much > enhance the long term prospects of crypto|chimera|whatever. > > Jochen > > -- > The next time you hear: "Don't reinvent the wheel!" > > http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
