[foreign-memaccess] [Rev 01] RFR: JDK-8243284: Remove Foreign class

[Ty Young]

On 4/22/20 8:28 AM, Maurizio Cimadamore wrote:
> On Wed, 22 Apr 2020 09:34:58 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:
>
>>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    * simplified API to take Runnable instead of AutoCloseable
>>>    * renamed all occurrences of "unsafe" with "restricted" (e.g. as in "restricted foreign")
>>>    * cleaned up the code which performs the restricted access check
>> Marked as reviewed by sundar (Committer).
>> That's a lot of arguments. Could simplified overrides be provided too?
>> For example:
>>
>> static MemorySegment ofNativeUnsafe(MemoryAddress addr, long bytesSize,
>> AutoCloseable cleanup)
> The point of this API is to provide a very general way to construct any kind of native segments. I understand there are
> many arguments - but then you have a tradeoff between having multiple unsafe API points vs. just one, and I'm not sure
> that usability is the main concern when stepping onto the unsafe path. This is mostly to allow devs to link their own
> custom allocators with memory segments, so I don't think the extra arguments should be a big issue (but lack of
> generality could be).


That's fine. I wasn't suggesting the large static method be removed but 
rather add overrides to the big one:


static MemorySegment ofNativeUnsafe(MemoryAddress addr, long bytesSize, 
AutoCloseable cleanup)

{

     return ofNativeUnsafe(addr, byteSize, null, cleanup, null);

}


No *real* functionality here is being duplicated nor is anything being 
lost. The JDK already provides overrides like this throughout its many 
APIs. List has about a dozen.


>
> As for providing pre-baked Runnable cleanup actions, I thought about that and I also thought that we should keep in
> mind what will happen once we have the ABI work - having a call to "free" won't require writing any JNI code, so by
> putting these pieces together it should be possible to implement pretty much any behavior.
>
> In terms of usability, I think having a 'resize' method on (unchecked) MemoryAddress would probably be the most
> appealing choice. For now I think there is a certain appeal in keeping the number of unsafe entry points as low as
> possible, so that the user can reason about them.


Agreed. Especially with the way it was before with the 3 unsafe entry 
points it was fairly confusing.


It isn't just a matter of convenience but also API design though. It's 
kinda sketchy, especially with that "Object attachment" bit: Netbeans 
likes to autofill method calls with any argument it deems viable and 
since there is no type safety that'll be literally anything. If one 
isn't paying attention it could cause problems.


TL;DR: more complexity, more bugs.


>
> -------------
>
> PR: https://git.openjdk.java.net/panama-foreign/pull/122