Hi all,
With Jigsaw here will be some changes affecting Groovy in some major
ways, but frankly it is still unclear to me as of how much. This is
partially to Jigsaw still being so young. This mail is mostly to write
down some thoughts for sharing.
Jigsaw means that we will not have access to all classes we have now.
Many factory methods of the JDK for example will provide such classes.
Jigsaw means we can still get a class object from it, but we cannot get
the methods or do invocations directly with the implementation class.
Things need to get through the public base class.
This is for example a problem with flow typing in static compilation:
class Base { def foo(){}; static baseImpl(){return new Hidden()}}
class Hidden extends Base {}
Hidden h = Base.baseImpl() //works
h.foo() // works not
Base b = h
b.foo() // works (in Java at least)
h.foo() fails in Java because Hidden is used as base class and protected
by the module system. Doing the same invocation using the public
available class will work though. This of course will here still invoke
Hidden#foo thanks to it being a virtual method call.
For static compilation the problem is, that the trick with Base b might
not work. b will still have the flow type Hidden. We need to ensure we
do the invocation not with the flow type, if the method is also
available in the normal static type.
But now that I think of it, the compiler might already have a problem,
since the compiler can probably not inspect Hidden by Reflection at all.
This means we need to check the code generating ClassNodes how it reacts
to exceptions being thrown due to the class object being available, but
not the members.
This also means, that if we look for a class sing reflection like
Unsafe, and assume, just because the class is there, that we can use it,
we have a code part to change. I am thinking of Unsafe hereof course,
but also about that special interface we use for callsite caching, that
bypasses verification. There is probably more.
And of course the Groovy runtime has similar problems. We have already
some checks for classes not being available through strict
SecurityManagers, but new exceptions (JDK9 specific ones) can be a
problem.. and most probably several places are involved
Next problem is with @Grab. It looks like there will be no longer a
URLClassLoader from the JDK available. Thus we can no longer add a jar
at runtime. RootLoader (used when executing Groovy from the console) can
still be used of course, but does not cover the system loader case,
which databses drivers may need. It is yet unclear to me how the module
system works at runtime with database drivers added at runtime as well.
Then I see a conceptual problem for Groovy as well. If a module is
supposed to be written in Groovy and has a private part, then the Groovy
runtime cannot really access those classes and for example cannot call
private methods in those classes. To give the runtime access I think
Groovy itself would need a module descriptor. But unless I misunderstand
the proposal, this means a random script can access those private
classes from that module written in Groovy as well. Why? Because, if it
does a method call through the runtime, and if the runtime has access,
then the script has access.
There is a concept called Layers, which I have not yet found enough
information about, which may help here... not sure yet.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
