[foreign-memaccess+abi] RFR: 8310659: The jar tool should support allowing access to restricted methods from executable jars [v4]

[Maurizio Cimadamore]

On Wed, 28 Jun 2023 09:24:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The launcher code is is java.base.  If `java -jar app.jar` is used then there shouldn't be application code running, and trying to do native access, before the application main class is loaded. In other words, there shouldn't be code in an unnamed module trying to do native access before any application or library code has been loaded. It's similar to Add-Exports and Add-Opens. They are used to reflectively export or open packages before the application code executes.
>> 
>> The same applies to an agent that may be packaged with the application and configured with Launcher-Agent-Class. We probably need to move the handling of Add-Exports, Add-Opens, and Enable-Native-Access to before Launcher-Agent-Class.
>
> The problem here is that the current command line option for native access has a rather sophisticated behavior:
> * if the option is not present, a warning is emitted
> * if the option is present, names module M, and access occurs within M, nothing is emitted
> * if the option is present, names module M, and access occurs outside M, an exception is thrown
> 
> This makes enable-native-access non-additive (unlike add-opens). That is, if `Enable-Native-Access:ALL-UNNAMED` is translated into `--enable-native-access=ALL-UNNAMED` well, that means that:
> 
> * access to restricted methods from unnamed module is granted
> * access to restricted methods from a module M that is not unnamed is denied
> 
> Now, this patch tries to implement this approach, but I do have worries: effectively, once a manifest specifies the Enable-Native-Access attribute, can the command line still add other modules in the trusted bubble? If yes, that's ok. If no, then we have a problem.

Perhaps, setting an implicit system property in the launcher with the enable-native-access policy (e.g. either warn or deny) would be cleaner. This property will be set by the launcher and read by module bootstrap (like many other properties). This is, I believe, similar to the idea you mentioned above. IMHO that's cleaner in the sense that it's more in the spirit of how already launcher and module bootstrap talk to each other via properties side-channels.

-------------

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/843#discussion_r1244950611