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 <blackd...@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
