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

[Henry Jen]

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