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 <[email protected]>: > 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: > > https://discuss.gradle.org/t/gradle-is-broken-by-jdk9-application-class-loader/9206 > http://comments.gmane.org/gmane.comp.java.openjdk.jigsaw/969 > > On Thu, Oct 8, 2015 at 1:08 PM, Jochen Theodorou <[email protected]> > 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/ > > >
