Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Jochen Theodorou]

On 16.07.2016 00:03, Alex Buckley wrote:
> On 7/15/2016 6:21 AM, Jochen Theodorou wrote:
>> I will give you an analysis of my situation so far:
>>
>> assuming the whole Groovy runtime is a module, and assuming I have other
>> modules as well, and then I want to use a Groovy script at runtime, to
>> access those modules. And let us assume those modules do not know of
>> Groovy. Let us further assume the Groovy runtime will be in a loader
>> that delegates to a loader knowing the classes of those modules, or is
>> in the same loader.
>>
>> So first problem is ... can I use the unnamed module for the scripts?
>> They read every (named) module, thus they can access the types.
>> Next are 4 types of method invocations to consider for the case of  an
>> invocation from script in the unnamed module to named module:
>> reflective, indy, direct, generated bytecode for callsites (I name this
>> one csgen in short). The method itself is looked up by reflection
>>
>> * for indy it is only a question of the lookup object, which will be
>> provided by the script and can do the call
>> * direct calls will work
>> * reflection would be done from the groovy runtime, thus the runtime
>> need to have a read on the named module. That´s the first time I will
>> need Java9 special code in this scenario
>> * csgen is more unclear. Let us assume it is in the unnamed package as
>> well, in a loader that delegates to the script loader. Basically it
>> becomes a direct call and works.
>>
>> Next step is for my Groovy runtime having to call a method from the
>> script. Since everything is exported there is no problem on this side.
>> * indy will work after adding the read
>> * reflection - same
>> * direct call - same
>> * cs gen... the call to the csgen method will be done by an
>> interface/class of the Groovy runtime, and since the csgen class is in
>> the unnamed package, it has no problem calling the script methods.
>
> With one exception, everything above is correct. (Exception: reflection
> from the Groovy module to a named module, performed on behalf of the
> script, does NOT need Java 9 code, because reflection gets readability
> for free. Also, you mean that csgen code is in the unnamed MODULE; its
> package is not so important.)

yes, my mistake, looks like I did not see it even the second or third 
time I did read through my post. Anyway, thanks for adding the part 
about reflection being able to read everything. I did forget that. This 
simplifies matters for the reflection part.

> Key point: Just because a framework is delivered as a module, does not
> mean the framework has to change its class loading behavior or require
> that its plugins/scripts/introspectees be delivered as modules. Groovy
> can continue to load scripts (or classes derived therefrom) into
> user-defined loaders. The scripts can continue to access each other
> (assuming suitable loader delegation) and Java platform APIs and Groovy
> runtime APIs (assuming the Groovy module exports some packages).

Well, that is exactly what I am wondering about. Should we even go the 
module route or not? I did for example not attempt to make the runtime 
scripts modules, as I did not found need for actually doing that so far. 
And those runtime scripts are what you are talking about mostly. But 
people are supposed to be able to use precompiled Groovy as much as Java 
as possible. Not being able to make a module for Groovy code would be 
bad then. And if you have Java code, that depends on a library written 
in Groovy, do you really want to be blocked from making this a module, 
just because of that library being in Groovy? That will be bad for 
Groovy and the library.

Groovy is not like many JVM languages, in which you basically switch 
over into a new universe and have to do conversions and special things 
to go back to Java or use something of that language in Java. With the 
effect of staying in one universe as much as possible. Instead we target 
full integration. It is very common for us to switch between Groovy and 
Java all the time in the same program. That´s why a library written in 
Groovy is supposed to be usable from Java without quirks... and that 
includes the module system.

[...]
> For creating named modules at run time, see the javadoc for
> java.lang.reflect.Layer and all the linked javadoc down to
> java.lang.module.ModuleDescriptor.Builder.

What if I have to make anamed module at runtime to realize a call that 
involves sibling layers? I do not see an answer to that in the javadoc. 
Not that I know if I would need that... but that is also information I 
do not have in the javadoc

> You're right about indy calls and direct calls following readability, so
> you can either have the script's module require another named module in
> the Configuration that you pass to the Layer, or you can have the
> script's own code add readability as you describe.

so far the named module version looks much more complicated...

> Now for a pivot. All the issues you raise in the rest of this email,
> about how named modules containing bytecode-derived-from-Groovy-source
> interact with named modules of the Groovy runtime or otherwise, are
> familiar. Why? Because Nashorn faced exactly the same issues. There will
> be a presentation at the JVM Language Summit (jvmlangsummit.com) on how
> Nashorn uses modules to encapsulate its generated bytecode. The video
> will be online at YouTube the next day. It'll make discussing the issues
> below much easier.

ah well, since I waited already for several months, I guess I can wait 
another 2 or 3 weeks.

bye Jochen