also additionally note that this "new approach" of JNR (library being used by jruby for native access) is already a JEP 191.
see this url ==>

I proposed that JNR (or JNA) is quite useful to be included in groovy-gdk , This will extend the reach to all the native functionality in groovy in a single shot, even without providing the implementation for each individual functionality.
Even if chdir() functionality is not provided, but still inclusion of JNR or JNA into groovy-gdk will lead to easy individual implementation of chdir() and lots of other native functionality in a single shot.
Those who needed to use JNI for this and carry .so/.dll of their own library for each platform, is now thing of past with new approach of JNR/ JNA.
If groovy allows us to access all the functionality of JDK in easy way, in the same way it inbuilt allowed all the native functionality of OS in easy way (by inclusion of JNR/JNA), then that will be really a dream come true for us.


On Mon, Jul 6, 2015 at 7:45 AM, Zaxebo Yaxebo <> wrote:
owen>> " From my understanding of implementations of the chdir() method, this stores a common path to be used by other methods in determining path."

my feedback>> no. thats^ the methodology followed by jython. That is the old approach.

Nowadays, the  new approach of JNA/JNR implementation of chdir(),getcwd() accesses the "native OS functionality" itself, in a very cross platform way - but still without needing to be recompiled for each native platform .


On Mon, Jul 6, 2015 at 7:26 AM, Owen Rubel <> wrote:
You missed the whole point of wherein I stated 'which environment I am in'. From my understanding of implementations of the chdir() method, this stores a common path to be used by other methods in determining path. Path can not only be a PROPERTY read from config, but it can be ENV based.

You are actually overthinking the problem in alot of ways.

Owen Rubel

On Sun, Jul 5, 2015 at 5:47 PM, Zaxebo Yaxebo <> wrote:
Thanks for the feedback.

Those users like me, who want to use groovy for scripting for Operating system domain, and replace shellscript/ruby/python scripts with the one "groovy" language script there. We obviously need changeDirectory(chdir()) function. This is the case of missing of "only one very core filesystem manipulation function (chdir) from groovy-gdk".

As you said, why - "it will depend upon env. framework and alot of variables that need to be set by a developer creating a required config over convention functionality".???
if JNA method for chdir() is finalised, then it only requires almost the following code:

import com.sun.jna.NativeLibrary;

import com.sun.jna.Platform;


  • Call native low level Posix functions.
    public class Posix
    private static final int MAX_PATH = 1024;
    private NativeLibrary cLib = null;
    public void chdir(String dirName)
    Unknown macro: { int error = getCLib().getFunction(getOsDependentFuntionName("chdir")).invokeInt( new Object[] { dirName }); if (error != 0) throw new Error("Could not change working directory to}

    private NativeLibrary getCLib()

    { if (cLib == null) cLib = NativeLibrary.getInstance(null); // Will load or msvcrt.dll return cLib; }

    public String getcwd()

    Unknown macro: { String cwd = getCLib().getFunction(getOsDependentFuntionName("getcwd")).invokeString( new Object[] { new String(new byte[MAX_PATH]), MAX_PATH }, false); return cwd; }

    private String getOsDependentFuntionName(String fname)

    { if (Platform.isWindows()) return "_" + fname; return fname; }


In single threaded environments like shell scripting, it is really very stable and rocks solid.

alternative proposal:
Though i would pray that this feature of chdir() is implemented.
But, Just in case, this chdir() function is not implemented , i would still suggest/request that atleast JNA or JNR .jar to be bundled with groovy, so that user can access large native functionality without writing JNI code. The entire JNA/JNR end-user's source code will always be in java/groovy. It will replace lot of C/C++ coding of JNI. Say,It will enable user to access extended file system attributes (say for XFS,/proc type file systems) directly from native functions, for those file systems for which java driver is not there. It will let us access other Posix API or native Win32 API functions etc , directly from java/groovy code without writing glue C/C++ JNI code. 
This native accessing  functionality without writing glue C/C++ code, will let groovy core  reach extend to lots of native functionality.

Probably, those who are into Web development etc may not need it. But those like us who want to communicate to other native accessing functionality without compiling any .so on their own,  we want to use groovy for scripting these cases also. Groovy can atleast provide JNA/JNR functionality out of the box, to enable large native functionality access out of the box, for which there is no inbuilt functionality in jdk.


On Mon, Jul 6, 2015 at 2:28 AM, Owen Rubel <> wrote:

Well... The only thing really competing with JRuby is Ruby.

Groovy isn't a bridge for another language which is why it's approx 4x faster than JRuby. 

It's purpose isn't to mock every other language but to implement convention over config concepts, provide a scripting language for Java,  simplified functions.

The chdir() function really really depends on env, framework and alot of variables that need to be set by a developer creating a required config over convention functionality. You CAN automate it but you lose speed when running over simplicity.

I think thats why it won't be implemented IMHO.

On Sun, Jul 5, 2015 at 11:26 AM, Zaxebo Yaxebo <> wrote:
jvm has no chdir() function to change current working directory.

As groovy positions itself as competitor to jruby and other scripting language, and jruby implements chdir() using JNR (not using JNI)

jython also implements chdir() on its own, but its implementation has some limtation. And jruby's implementation of chdir() function is best and stable.

I have filed an enhancement request of adding a chdir() function to groovy using JNA or JNR.
I have given sample code to achieve this using JNA.

please give your feedback at
for this enhancement feature request.