Bug 42273 - Expose string operations of JNI in the wrappers
Summary: Expose string operations of JNI in the wrappers
Status: RESOLVED ANSWERED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: unspecified
Hardware: PC Windows
: Normal enhancement
Target Milestone: master
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2016-06-30 11:33 UTC by Dimitar Dobrev
Modified: 2017-07-13 19:46 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description Dimitar Dobrev 2016-06-30 11:33:49 UTC
String operations in JNI (https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#string_operations) can be helpful in certain cases of interoperability. A good example is GetStringUTFChars which encodes the result in modified UTF-8 for which Mono/.NET have no built-in API.
Comment 1 Jonathan Pryor 2016-06-30 14:00:49 UTC
@Dimitar: Do you have more specifics about where and when you'd need to use this? I'm having trouble thinking of the interoperability scenario...

That said, thanks to open-sourcing, the controlling line of code is:

https://github.com/xamarin/java.interop/blob/6715181/build-tools/jnienv-gen/Generator.g.cs#L1496

`GetStringUTFChars` is currently "private", which is why it isn't exposed. Change this to public, and there will be a Java.Interop.JniEnvironment.Strings.GetStringUTFChars() method (in Java.Interop.dll).

We should probably review all such "private" methods and reconsider exposing them, though certain methods such as `CallVoidMethodV` should remain private (there's no good binding for `va_list`).
Comment 2 Dimitar Dobrev 2016-06-30 17:36:22 UTC
Jonathan,

Thank you for your interest. We use https://github.com/praeclarum/sqlite-net to work with our SQLite database. Now we want to encrypt it using https://github.com/sqlcipher. It has its own .NET API which would force us to rewrite our code. This is why I have been trying to call the native code for unlocking myself. That code requires the password to be encoded to modified UTF-8, and I have seen that their JNI bridge uses GetStringUTFChars. I have so far tried many ways to do it manually to no avail. Of course, the reason might as well be elsewhere in my code but if I could directly call GetStringUTFChars, I would've been certain.
Comment 3 Jonathan Pryor 2016-06-30 17:51:11 UTC
@Dimitar: You might be overthinking it.

https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8

There are two primary difference between UTF-8 and Modified UTF-8:

1. The representation of ASCII NUL U+0000
2. The representation for characters outside the basic multilingual plane (Emoji)

https://github.com/xamarin/java.interop/blob/89e55a5/src/Xamarin.Android.Tools.Bytecode/ConstantPool.cs#L374-L405

If this is a password, it almost certainly doesn't contain an embedded (non-terminating) NUL, and Emoji is highly unlikely as well, so normal UTF-8 should be sufficient.
Comment 4 Dimitar Dobrev 2016-06-30 17:56:31 UTC
Jonathan, thank you for trying to help. However, I am aware of the above. As I said, I realise the problem I have might be unrelated to the encoding. I just think there might be isolated cases in which having these functions at one's own disposal could be helpful. Besides, they are too few to clutter the API or increase Mono's size.