[foreign-abi] [Rev 01] RFR: 8241148: need a way to create MemorySegment with contents from java String and a way to read a C char* as java String
Maurizio Cimadamore
mcimadamore at openjdk.java.net
Thu Mar 19 10:59:08 UTC 2020
On Wed, 18 Mar 2020 18:00:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last
>> revision:
>> * renamed makeNativeString as toCString
>> * added Charset accepting variant for toCString
>> * fixed test to compare PATH value with System.getenv("PATH")
>
> Looks good - some minor comments on naming and test.
> However, if it were move to MemoryAddress and it's assumed the address
> is safe, the method could just basically be a copy/paste of the old
> Pointer.toString from old Panama[1], with a variant that accepts a Charset.
I think the points you raise are valid ones.
We could indeed treat these conversions as 'safe' and expect the user to do the unsafe conversion.
That said, let's not focus too much on the fact that ForeignUnsafe is outside the API, as we have another change we're
working on which will bring ForeignUnsafe inside the official API (guarded by some flag), with probably a different
name.
So I think the choice here is whether we want to "pollute" the memory access API with functionalities which pertain to
native interop or not. I think the status quo is that all the native interop stuff should go into a separate class -
and keep the memory API simple (for users who want to use it w/o need to do native interop). But the distinction is
blurry, and we can re-evaluate as needed.
-------------
PR: https://git.openjdk.java.net/panama-foreign/pull/55
More information about the panama-dev
mailing list