JDK9 and the problem of @Grab

[Jochen Theodorou <bl...@gmx.org>]

Hi all,

with the oncoming of JDK9 we are facing a problem with @Grab, which is 
that there is no URLClassLoader to hook into anymore by default. 
Actually that was never a guarantee, just worked in almost all of the 
scenarios of interest.

>  @Grab(group='commons-lang', module='commons-lang', version='2.4')
>  import org.apache.commons.lang.WordUtils
>  println "Hello ${WordUtils.capitalize('world')}"


There are two basic flavors to @Grab, which is using it with a source 
file and using it with a precompiled file. In both cases the @Grab would 
download dependencies and try to give the executing environment those 
dependencies.

In case of a source file, we hook into the compiler to do the downloads 
as well as change the static constructor of the class. So we ensure we 
can compile the file and since we have full control over the execution 
environment in this case we can also ensure all the libraries are 
available before the class is loaded by the JVM.

In the precompiled case, for example as a testcase, we do not have full 
control over the environment and with JDK9 there might not be a single 
URLClassloader we can use anymore. Furthermore here is a limitation of 
@Grab, which is that the grabbed classes cannot be used in any of the 
signatures of the class.

So now the question is what we want to do. The most simple version would 
be to ditch the precompiled version. If we want to keep it like is, we 
will have to add JDK9 specific code handling layers and modules.

What do you think?

bye Jochen

Re: JDK9 and the problem of @Grab

[Jochen Theodorou <bl...@gmx.org>]

On 27.08.2016 12:28, Paul King wrote:
> I guess I haven't looked into that part of JDK9 just yet. My first
> reaction would be to try to see what work would be involved with the
> "special handling". Keeping the existing behaviour (or close to it
> with perhaps a few caveats) would be ideal but has to be weighed up
> with the amount of work required to do that.

from what I understood so far you have to make a Layer containing all 
the dependencies, including the program itself (means the class will be 
loaded a second time) and then it is supposed to work. Of course you 
have to solve the problem of calling the new class instead of the old 
one then. And maybe this would be no problem to do, if I was feeling 
safe with this API. The problem being though, we will need jsk9 specific 
code for this, thus jdk9 will becomes the defacto build version for 
Groovy. I mean, we probably will have to make that step some-when, So 
maybe now is better than later. On the other hand I feel bad about 
requiring jdk9 to build Groovy and not being able to completely build 
Groovy on JDK9 at the same time

bye Jochen

Re: JDK9 and the problem of @Grab

[Paul King <pa...@asert.com.au>]

I guess I haven't looked into that part of JDK9 just yet. My first
reaction would be to try to see what work would be involved with the
"special handling". Keeping the existing behaviour (or close to it
with perhaps a few caveats) would be ideal but has to be weighed up
with the amount of work required to do that.

Cheers, Paul.

On Fri, Aug 26, 2016 at 8:28 PM, Jochen Theodorou <bl...@gmx.org> wrote:
> Hi all,
>
> with the oncoming of JDK9 we are facing a problem with @Grab, which is that
> there is no URLClassLoader to hook into anymore by default. Actually that
> was never a guarantee, just worked in almost all of the scenarios of
> interest.
>
>>  @Grab(group='commons-lang', module='commons-lang', version='2.4')
>>  import org.apache.commons.lang.WordUtils
>>  println "Hello ${WordUtils.capitalize('world')}"
>
>
>
> There are two basic flavors to @Grab, which is using it with a source file
> and using it with a precompiled file. In both cases the @Grab would download
> dependencies and try to give the executing environment those dependencies.
>
> In case of a source file, we hook into the compiler to do the downloads as
> well as change the static constructor of the class. So we ensure we can
> compile the file and since we have full control over the execution
> environment in this case we can also ensure all the libraries are available
> before the class is loaded by the JVM.
>
> In the precompiled case, for example as a testcase, we do not have full
> control over the environment and with JDK9 there might not be a single
> URLClassloader we can use anymore. Furthermore here is a limitation of
> @Grab, which is that the grabbed classes cannot be used in any of the
> signatures of the class.
>
> So now the question is what we want to do. The most simple version would be
> to ditch the precompiled version. If we want to keep it like is, we will
> have to add JDK9 specific code handling layers and modules.
>
> What do you think?
>
> bye Jochen