Hi guys,

After spending some days at Devoxx, I had a few chats about Jigsaw and the implications on Groovy. I will send an email summarizing them and I think we need to come up with a plan. I'm not sure JIRA is the best way to track this, but in short, we have serious issues coming, and breaking changes. Maybe it's a chance for us to make all the breaking changes we thought for so long.

2015-10-09 22:48 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
So you mention 3 potential problem areas, reflection on flow types,
Grapes and the URLClassloader, and module descriptors.

Would it be more resonable to open JIRA issues on those to collect
ideas and resources?

Regarding mthe URLClassloader, all I found was this:

On Thu, Oct 8, 2015 at 1:08 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:
> 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/