A member of the JSR-51 (NIO) expert group has pointed out that we added some
new functionality to JNI in Merlin, but we didn't increment the JNI version
number.

This is inconsistent with past practice. When we extended JNI in 1.2 we
incremented the version number to 0x00010002 and defined the new version
constant JNI_VERSION_1_2 in jni.h. In Merlin we should correspondingly define
JNI_VERSION_1_4.

This oversight also makes it difficult for native code to detect which version
of JNI it's using at runtime and adjust accordingly. There is a workaround,
namely to do a FindClass on a class that's known only to exist in 1.4, but
that's pretty ugly.

The risk of incrementing the version number at this late stage might not be all
that great. Native code that never examines the version number will not be
affected. Native code that defensively checks whether the version number is
greater than or equal to a fixed value (e.g., >= JNI_VERSION_1_2) will also not
be affected. The only native code that will be affected is that which tests
for specific version numbers and otherwise fails. (Such code is arguably
poorly written, but of course that doesn't mean it doesn't exist.)

-- ###@###.### 2001/11/13