Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Before we get too deep into our discussion, I'd like to provide some background on how native methods worked prior to the release of the JNI. In short, before JDK 1.1 native methods were difficult to use because:
With the introduction of the JNI in JDK 1.1, native methods have become much easier to use. To help you better understand the JNI, we'll review portions of the actual JNI spec to explain why you need to use it and what it allows you to do. The italicized items are direct quotes from the JNI specification, and the regular text is the annotation I've supplied for clarity. Once you know the "why" and "what" of using the JNI, we'll focus on the "how." Note that for brevity's sake I make no attempt to fully explain the JNI specification. If you feel you need a primer on the JNI, be sure to review the complete specification (and also the tutorial), which is listed in the Resources section of this article.
Why do I need to use the JNI?
You might need to set some device-specific properties under program control, or access a device-specific API.
You may want to rewrite the necessary application in Java, but this is not possible in all cases. Many application libraries on the 'Net have taken an enormous amount of time to perfect (we're talking hundreds of thousands of hours); rewriting them in Java is not likely in the short term.
Unfortunately, using native methods may not be the best solution. When you use native methods in computation-intensive tasks like tight loops, which occur when you repeatedly call a function, you may find that the process of setting up parameters, calling the method, and getting the return values for each iteration of the loop takes longer than the time it takes to execute the function.