Talk:Java Native Interface

message: 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)
replies: text: 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)

text: Indeed, I've just done it in my code. It definitely works :) --81.97.123.218 (talk) 23:27, 26 September 2009 (UTC)
thread_title:  To call ''and be called'' ? 

message: 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 **'
If I remove (void **) cast, warning goes away. It's not quite clear to me why the cast is there. I use gcc (Debian 4.4.5-10) 4.4.5. --Sigmundur (talk) 10:58, 9 February 2011 (UTC)
thread_title:  error in example? 

message: 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. 69.54.60.34 (talk) 23:26, 9 February 2011 (UTC)
thread_title:  "modified" UTF-8? 

message: 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:
java HelloWorld
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)
thread_title:  The example won't run in Linux 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Java Native Interface. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20080330002620/http://today.java.net/pub/a/today/2006/10/19/invoking-assembly-language-from-java.html to http://today.java.net/pub/a/today/2006/10/19/invoking-assembly-language-from-java.html
*Added archive https://web.archive.org/web/20071011014140/http://today.java.net/pub/a/today/2007/10/04/launch-java-applications-from-assembly-language-programs.html to http://today.java.net/pub/a/today/2007/10/04/launch-java-applications-from-assembly-language-programs.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 23:13, 22 November 2017 (UTC)
thread_title:  External links modified