groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject challenges through Java modules (aka jigsaw)
Date Thu, 08 Oct 2015 11:08:27 GMT
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/


Mime
View raw message