Unfortunately for him, the relevant datatypes are completely opaque,
i.e. they are not publicly defined in the header files that come with
Suns JDK, and I suspect the same is true of other common JDKs.

/gordon

I made many tests before asking.
The use case are short vs long strings (5 vs ~100) and strings that need
escaping vs strings that do not need escaping (reserved chars are quotes,  
CR, LF, TAB, BS, \, \z: you can guess that looks like sql escaping....
But don't get me side tracked on prepared statement! that is another
game!)

The encoder scans the strings first to find reserved chars (and counts
the extra space it would require). If none, return the original jstring.
Super fast. Otherwise, it malloc a new jchar* of the extended dimension
and loops again to copy & escape the input chars.

Here are the results. JNI call overhead is below 10% with ~100 char
strings (and most of our strings are long usually above 100 chars) Note:
the java version uses StringBuffer.append(char) on every char, tested in
a switch case to find if it is reserved. So the java version doesn't
return the original string. This is because I would have needed about 8
calls to String.indexOf(reservedchar) just to figure out if it needs
escaping. Pulling the char[] out of the String (to iterate the same ways
I do in C) is not an option (similar prohibitive cost to GetStringChars).

(for 1'000'000 calls)

Short string that do not require escaping: "hello"
       java: avg 2.99 us
       jni:  avg 7.56 us (2.53x slower)

Short string that requires escaping: "hel'lo"
       java: avg  3.69 us
       jni:  avg 21.9 us (5.9x slower)

(from here, 100'000 calls)

Long string no escaping:
"aaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccccccc
ccddddddddddddddddddeeeeeeeeeeeeeeeeeeeee"
       Java: avg 44.9 us
       JNI:  avg 17.2 us (2.61x FASTER)

Long string + escaping:
"aaaaa'aaaaaaaa'aaaaaaaa'bbbbbbbb'bbbbbbbbbb'bbbbbbbbb'ccccccccc'cccccccc
cc'ccccccc'ddddddd'dddd'ddddddd'eeeee'eeeeeeeeee'eeeeee"

       Java: avg 54.0 us
       JNI:  avg 59.0 us (1.09x slower)

So, the benefit of JNI lies in the fact that it scale better that java
for long strings, which compensate for it base call cost. That cost is
the jni overhead, and the GetStringChars() of original jstring which I'm
trying to eliminate. That encoding is the hotspot of our app, invoked
about a minimum of 3000 times per second).

I have the jvm source. That's what I searched for the 'jstring' text.
It's too much to read of course so I'm asking for those who might already
know.

Thanks.

On Fri, 28 Oct 2005 11:45:25 +0100, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly
quoted someone who said :

if there were a generic, safe way to do that, surely Sun would have
used it.  Even if you figure out a way, it will surely have a major
catch.