groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Schalk Cronjé <>
Subject Java NIO2 and the Groovy ClassLoader conundrum
Date Thu, 31 May 2018 06:53:12 GMT
HI all,

Java NIO2 providers 
works by providing filesystems via SPI. Ideally one would just write the 
appropriate classes and drop them on the classpath . This allows 
somebody does to write something like:


This all works fine when done within a normal application but it fails 
when used within GroovyConsole or just running a normal Groovy script. 
ONe would expect the following just to work


    import java.nio.file.*


However the following workaround is required


    import java.nio.file.*

    FileSystem fs

    try {
         fs = FileSystems.getFileSystem(gzURI)
    } catch(FileSystemNotFoundException) {
         fs =

    Path gzPath = fs.provider().getPath(gzURI)

NOTE: Using 
@GrabConfig(initContextClassLoader=true,systemClassLoader=true) does not 
solve the problem in this case

At Gr8Conf I sat with with Andres, Jochen and Guillaume to work through 
this. The issue that that providers are loaded via the system class 
loader, whereas with GroovyConsole and command-line Groovy it will be 
loaded via an instance of RootLoader. This leads to one having to 
manually loading the filesystem.

 From the point of view of someone using NIO2 providers this is 
surprising behaviour. One would expect it just to work out of the box 
(as per the Javadoc for FileSystemProvider).

My question is now. Is there something that can be done to way 
GroovyConsole and Groovy scripts are started so that the expectd 
behaviour of NIO2 providers can be obtained? (Maybe adding an additional 
method to GrabConfig?).

Groovy luck.

Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

View raw message