<AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module [v2]
gziemski at openjdk.java.net
Mon Feb 1 18:33:44 UTC 2021
On Fri, 29 Jan 2021 19:53:32 GMT, Phil Race <prr at openjdk.org> wrote:
>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:
>>> 81: stringWithFileSystemRepresentation:chs length:len];
>>> 82: return result;
>>> 83: }
>> Why are we doing:
>> `java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
>> Why not just get the raw characters form JNI and feed them directly into `[NSFileManager stringWithFileSystemRepresentation]`, ie:
>> `java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
>> and skip the `JavaStringToNSString` step altogether?
> I tried to explain the odd-ness of this in the comments preceding the function definition.
> Near as I could figure out that intermediate call is needed to do the decomposition since the NSFileManager won't do that.
> But this is not exactly my area of expertise and there may be a better way. Who is an expert on the intricacies of the macOS file system naming ?
How about a comment like:
Returns an NSString in decomposed UTF16 format that is compatible with HFS's
expectation of the UTF16 format for file system paths.
Example string: "/Users/Amélie/"
Java's UTF16 string is "/ U s e r s / A m \351 l i e /"
macOS UTF16 string suitable for HFS is "/ U s e r s / A m e \314 \201 l i e /"
There is no direct API that takes in NSString UTF16 encoded by Java
and produces NSString UTF16 for HFS, so we first need to decompose it
into chars (suitable for low level C file APIs), and only then
create NSString representation of this decomposition back into UTF16 string.
I borrowed the API description from Apple's original `JNFNormalizedNSStringForPath` API, but added an example and different description.
More information about the awt-dev