groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: challenges through Java modules (aka jigsaw)
Date Sun, 15 Nov 2015 11:11:08 GMT
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:
>
> 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 <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/
> >
>

Mime
View raw message