Talk:Java Native Interface
|WikiProject Java||(Rated Start-class, Low-importance)|
noncompliant - Article is a tutorial, violates WP:NOT
This 'article' is a tutorial on the use of JNI. WP:NOT prohibits tutorials:
Instruction manuals - while Wikipedia has descriptions of people, places, and things, Wikipedia articles should not include instruction - advice ( legal, medical, or otherwise), suggestions, or contain "how-to"s. This includes tutorials, walk-throughs, instruction manuals, video game guides, and recipes.
- One week has passed with no challenge on this - reverting. LVC 03:40, 2 August 2006 (UTC)
- You removed too much useful information. I think reverting was a bad idea. It was probably better to just remove the walkthrought --Felipe Monteiro de Carvalho 19:03, 5 August 2006 (UTC)
- As writer of the expansion of the article (stub), I was not aware of this Wikipedia policy at the time I wrote it. I have written it this way because JNI is hard to understand, even for advanced programmers who have never done something like this before. By providing an example, the programmer have a concrete example to work with. There is a ton of useful information on that article that I think will help others master JNI. I will rewrite the article that will not follow a sort of a "tutorial" style format, I will instead just provide a straight-up example, explains the inner mechanisms and provide a link to a proper tutorial if the reader needs to be. - User:AverageAmerican 12 August 2006
- I have gotten rid of the walkthrough. I will see if I can write a more appropriate example that will conform to Wikipedia standards. In the meantime I have provided a link to CodeProject.com and Java.sun.com discussing how JNI is used. - User:AverageAmerican 12 August 2006
Is JNI an API or no?
The article reads at the first line, "The Java Native Interface (JNI) is a programming framework..." Then later on it states, "as mentioned before, the JNI is not an easy API to learn." Is JNI properly referred to as an API? I realize that API stands for "application program interface" which fairly describes JNI, but my understanding is that the term API usually refers to a hardware or operating system hook rather than a generic application-to-application communication pathway. Just curious. Thx.
To call and be called ?
The first sentence says JNI allows java code "to call and be called by native applications". Is there and example/tutorial anywhere on the web, showing java code being called by a native application? All the JNI examples I've been reading just show things happening the other way round (java invokes native). -- Harry Wood 17:00, 6 March 2007 (UTC)
- Yes, native applications can invoke the java side - it can even create java objects and pass them on to java. It's more difficult of course, but it's most definately possible. You can take a look at http://www.iam.ubc.ca/guides/javatut99/native1.1/implementing/method.html hope this helps --AverageAmerican 00:49, 8 May 2007 (UTC)
- Indeed, I've just done it in my code. It definitely works :) --188.8.131.52 (talk) 23:27, 26 September 2009 (UTC)
Examples falls into the pit
The last "pitfall" listed warns against using GetStringUTFChars since it results in "modified UTF-8" (a link to into the the UTF-8 article would be nice). Then a number of examples are presented, and several falls right into this "pit". Shouldn't the examples be rewritten?
error in example?
This puzzles me:
JNIEnv *env; (*g_vm)->AttachCurrentThread (g_vm, (void **) &env, NULL);
It's clearly from legitimate source but I get warning
warning: passing argument 2 of '(*g_javaVM)->AttachCurrentThread' from incompatible pointer type note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
From the official Unicode FAQ: Q: How do I convert an unpaired UTF-16 surrogate to UTF-8?
A: The definition of UTF-8 requires that supplementary characters (those using surrogate pairs in UTF-16) be encoded with a single four byte sequence. However, there is a widespread practice of generating pairs of three byte sequences in older software, especially software which pre-dates the introduction of UTF-16 or that is interoperating with UTF-16 environments under particular constraints. Such an encoding is not conformant to UTF-8 as defined. See UTR #26: Compatability Encoding Scheme for UTF-16: 8-bit (CESU) for a formal description of such a non-UTF-8 data format. When using CESU-8, great care must be taken that data is not accidentally treated as if it was UTF-8, due to the similarity of the formats.
And the Java docs: There are two differences between this format and the "standard" UTF-8 format. First, the null byte (byte)0 is encoded using the 2-byte format rather than the 1-byte format, so that Java virtual machine UTF-8 strings never have embedded nulls. Second, only the 1-byte, 2-byte, and 3-byte formats are used. The Java virtual machine does not recognize the longer UTF-8 formats.
This is not "modified" UTF-8, it's invalid and malformed UTF-8. Java not only produces invalid output, it doesn't recognize longer formats, meaning it requires invalid INPUT as well (so other programs must deliberately produce malformed data to interact with Java). In real UTF-8, '\0' is an actual NUL character. Perl has the decency of calling their "modified" format utf8 and explicitly saying that it's NOT UTF-8 (it's UTF-8 extended to 7 bytes (up to 0xFFFFFFFF), but is valid over the 0-0x10FFFF area, except for unpaired surrogates, which are invalid anyway). And other people agree with me. To make it worse, it uses a 2-byte length in front of the string, meaning you can't have more than 65535 bytes in a string (which is a different complaint, but it's not 80's PASCAL or QBASIC, it's "modern" Java). In contrast, a null-terminated C-string (which you think would be possible considering how they made NUL a nonzero code on purpose) could be infinite in length, or a string with a 32-bit or 64-bit length could be as long as your machine can fit in RAM. 184.108.40.206 (talk) 23:26, 9 February 2011 (UTC)
The example won't run in Linux
The example presented doesn't run on Linux.
The problem is this line in make.sh:
gcc -shared -fPIC libHelloWorld.c -o libHelloWorld.so
The library is loaded when the program is run in the next line:
But the compiler will not be able to find the jni.h, used in the created header, as the include paths (-I) did not include this java header.
The solution is to add them to the line like so:
gcc -shared -fPIC -I $JAVA_HOME/include -I $JAVA_HOME/include/linux libHelloWorld.c -o libHelloWorld.so
This assumes also that the $JAVA_HOME environment variable has been set to the appropriate path, for example in the case of jdk 7 (openjdk in the example): /usr/lib/jvm/java-7-openjdk/
I suggest adding the set up of the JAVA_HOME environment variable and the include directories to the make.sh — Preceding unsigned comment added by Chibby0ne (talk • contribs) 00:53, 6 October 2016 (UTC)