[foreign-abi] [Rev 01] RFR: 8237585: Dismantle ForeignUnsafe (foreign-abi part)

[Jorn Vernee]

It is still an interim solution until we have something better. (See 
also latter part of: 
https://mail.openjdk.java.net/pipermail/panama-dev/2020-February/007644.html).

With the eventual implementation, JDK internal code would need to bypass 
the check, probably we would export an internal API for that. We can add 
another 'secrets' package for this that then gets exported in the 
module-info. So, this would mean that we need to do something different 
when generating JDK internal code. But, I think that the need to 
generate something special for JDK internal code would pop up sooner or 
later, since JDK code is more privileged. Probably we would have a 
special tool, or use the jextract API directly to do that, right?

Wrt being able to set the flag before loading the class. This would not 
be possible with the final implementation. We could have no flag at all 
right now, and wait until we have something better, but imo it's better 
to have something even if it's not as good, to show that there are some 
methods that will be restricted.

One idea that comes to mind to improve the proposed impl is to move the 
initialization of the new flag to earlier in the application lifetime, 
for instance somewhere in java.lang.invoke, to make sure it gets 
initialized before we get to user code. But, it requires going outside 
of the incubator module.

What do you think?

Jorn

On 25/02/2020 18:57, Henry Jen wrote:
> While this seems more readable then --add-export, this means JDK internal code(like nio) will need to bypass the check by cast-then-call.
>
> Which makes tool generate code need to do differently for application code or JDK internal code.
>
> Also, I suspect it is possible for application to set the property before load the class, and means end-user may not aware the application is doing something unsafe. This is different from what was discussed a while back about security.
>
> Cheers,
> Henry
>
>
>> On Feb 25, 2020, at 9:26 AM, Jorn Vernee <jvernee at openjdk.java.net> wrote:
>>
>> On Tue, 25 Feb 2020 15:47:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>>
>>>> The pull request has been updated with 1 additional commit.
>>> The code moves look fine, but I'd like to consolidate everything under a single flag instead of using two.
>>>
>>> I'd also like to see something similar to what was done for illegal access in modules, where we can specify different behavior - e.g. permit, warn, error.
>>>
>>> Let's just use a single flag `jdk.incubator.foreign.restrictedMethods=permit/deny/warn/debug`
>> Thanks for the comments.
>>
>> I've uploaded another revision that incorporates the suggested changes.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/panama-foreign/pull/31