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
