Talk:Java Native Interface

Java Low‑importance

	This article is within the scope of WikiProject Java, a collaborative effort to improve the coverage of Java on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaWikipedia:WikiProject JavaTemplate:WikiProject JavaJava articles
Low	This article has been rated as Low-importance on the project's importance scale.

Computing: Software / Java Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by WikiProject Java (assessed as Low-importance).

noncompliant - Article is a tutorial, violates WP:NOT[edit]

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.

(my emphasis).

Suggest reverting to 5 December 2005 edit by 212.85.24.83, which is the most recent edit before the tutorial content was added. LVC 12:16, 25 July 2006 (UTC)[reply]

One week has passed with no challenge on this - reverting. LVC 03:40, 2 August 2006 (UTC)[reply]

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)[reply]

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

Thanks for the valuable info! Unfortunately wikipedia admins are too rigorous. I don't know either why this guideline is needed. I wouldn't mind if Wikipedia would contain practical information as well. --80.98.75.217 (talk) 11:56, 14 January 2008 (UTC)[reply]

Is JNI an API or no?[edit]

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 ?[edit]

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)[reply]

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)[reply]

Indeed, I've just done it in my code. It definitely works :) --81.97.123.218 (talk) 23:27, 26 September 2009 (UTC)[reply]

Examples falls into the pit[edit]

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?[edit]

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)[reply]

"modified" UTF-8?[edit]

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.[1]

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.[2]

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.[3] 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)[reply]

The example won't run in Linux[edit]

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)[reply]

External links modified[edit]

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:13, 22 November 2017 (UTC)[reply]