[code-reflection] RFR: Make Quotable a marker interface [v4]

[Paul Sandoz]

On Wed, 8 Jan 2025 22:22:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Right, so i think we need to create an interface in `java.base` in a package exported to `jdk.incubator.code` e.g., create a package in `java.base` called `jdk.internal.code` and add:
>> 
>> // Implementations of this interface also implement jdk.incubator.code.Quotable
>> interface QuotableWithQuotedAccess { // or whatever we call it
>>     // Implementations return instances of jdk.incubator.code.Quoted
>>     Object quoted();
>> }
>> 
>> then modify `module-info.java` in `java.base` to export package `jdk.internal.code` to module `jdk.incubator.code`.
>> 
>> 
>> More generally either this or the current approach will fail if the quotable functional interface is explicitly proxied via `Proxy.newProxyInstance` or `MethodHandleProxies.asInterfaceInstance`. And, regardless if we have `Quotable::quoted` proxying would fail for instances of the following:  
>> 
>> Runnable r = (Runnable & Quotable) () -> { ... };
>> 
>> 
>> I think we have to specify that such proxying results in inaccessible models. Not great a great answer, but not terrible.
>
> There's actually three modules:
> 1. the module in which capture occurs (e.g. where the quotable lambda is)
> 2. `java.base` which is where the lambda metafactory is
> 3. `jdk.incubator.code` which is where the code reflection code is
> 
> I'm not sure if the problem @mabbay is describing has to do with `Quotable2` not being accessible from (1) or (2). Putting the new interface in `java.base` will obviously address accessibility from (2). But I think there's still issues with respect to (1) ?
> 
> E.g. `InnerClassLambdaMetafactory`, at the end of the day, will call `defineClass` on the _caller_ lookup (e.g. the one in (1)). If the class being defined contains a symbolic reference to a non-exported interface, wouldn't that be an issue, regardless of whether the non-exported interface is in `java.base` or `jdk.incubator.code` ?

Ah yes, that will likely throw an `IllegalAccessError`. (I seem to recall we ran into this before when trying to add internal marker interfaces to FI implementations?)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/302#discussion_r1907951811