Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A3D43188B2 for ; Mon, 6 Jul 2015 15:01:08 +0000 (UTC) Received: (qmail 92117 invoked by uid 500); 6 Jul 2015 15:01:08 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 92090 invoked by uid 500); 6 Jul 2015 15:01:08 -0000 Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.incubator.apache.org Delivered-To: mailing list users@groovy.incubator.apache.org Received: (qmail 92079 invoked by uid 99); 6 Jul 2015 15:01:08 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2015 15:01:08 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of keeganwitt@gmail.com designates 209.85.160.173 as permitted sender) Received: from [209.85.160.173] (HELO mail-yk0-f173.google.com) (209.85.160.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2015 14:58:54 +0000 Received: by ykfy125 with SMTP id y125so150864457ykf.1 for ; Mon, 06 Jul 2015 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=TBaAtIL+Zk5R3ptQcMyqERId3ck2ZDdh615WgHSpU+Y=; b=YwED1YRDRzRtoqbG6cBuk80G8bVoq6GpJclk2id5nJzZlTqiXyNIN6nDc6IRz1W4sb GujxjbXchpBEPqkIboOFM1lDJjZHgr8eTIqYzWSQ0GWRqCnxeIgFOAigMzAGloEUAX2V zMCBKpTHn5QgRep8leLcVvejFnTGm75DuLttJiKvpLiuaX6jOn+bU9aM5mZJ+/Hl4kke ObGPCdJrZSqTrojzEPYSIgcfMGn3tVBFinddQYuHXwFMBbPcItCcpHIIRBJPya9oF11N rO2FyTtDMUKBSl1RyWW9EXU+0i0XpTHvuBhEwsR0V0abLAHq24ZOrNQAXZ7bc48oHjKM MliA== X-Received: by 10.170.126.214 with SMTP id s205mr60255879ykb.67.1436194840198; Mon, 06 Jul 2015 08:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.226.210 with HTTP; Mon, 6 Jul 2015 08:00:20 -0700 (PDT) In-Reply-To: References: From: Keegan Witt Date: Mon, 6 Jul 2015 11:00:20 -0400 Message-ID: Subject: Re: chdir() implementation requested in groovy, just like jruby To: users@groovy.incubator.apache.org Content-Type: multipart/alternative; boundary=001a1139720a475462051a362bba X-Virus-Checked: Checked by ClamAV on apache.org --001a1139720a475462051a362bba Content-Type: text/plain; charset=UTF-8 Treating JNR/JNA as a separate issue, what would you want to see Groovy do to implement? Are you proposing adding a JNR/JNA DSL? If not, why wouldn't it work to just pull in JNR or JNA with @Grab? Sorry if that's a dumb question, I've not used either. -Keegan On Mon, Jul 6, 2015 at 12:53 AM, Zaxebo Yaxebo wrote: > by the way, *JNR*(Java native runtime) *is Apache 2.0 Licensed ( see > https://github.com/jnr/jnr-ffi/blob/master/LICENSE > )* > I mentioned this - because this may be a point of consideration as groovy > is now part of Apache. So, "license wise" the inclusion of JNR in > groovy-gdk should not pose any reconsideration. > > Thanks > zax > > > On Mon, Jul 6, 2015 at 10:12 AM, Zaxebo Yaxebo wrote: > >> I can see your logic. >> but, I have already *"modified my proposal*" as Proposal Version 2.0: >> >> Now, *I do not request for chdir()* implementation,as mandatory >> requirement. >> *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 and lots >> of other native functionality in a single shot. >> >> *RATIONALE:* >> a) Groovy allows us to to acess all the funcionality of *JDK* (java >> development kit) in easy way >> b) groovy provides its own convenience methods in* GDK* (groovy >> development kit) >> c) but whole lot of native OS functionalities or other functionalities >> in .so/.dll still require JNI implementation. If JNR is included as inbuilt >> into GDK , then if somebody wants to roll out his own chdir() he can do >> easily, if somebody wants to access POSIX/win32 API extended >> functionalities, XFS etc extended functionalities , Device programming >> through a native dll - then that end-user can implement his own methods >> using this JNR in one shot. Groovy will not implement these functionalities >> on its own, it will just provide base functionality to access native >> functionality - by inclusion of JNR. So a single inclusion of a .jar of JNR >> will enable the groovy programmers to access all the native platform >> functionalities in extended way. *We can think of JNR as NDK (native >> development kit).* >> >> This will bring NDK (native functionalities , ie JNR), >> GDK functionalities, JDK functionalities on one par. >> >> >> >> >> *Spring,grails etc are just one type of users of groovy - which is >> Enterprise usage. But, We another type of users - who are using groovy to >> script native platform (device programming, file system programming with >> extended attributes etc) are also a user domain of groovy. * >> >> *Even if chdir() is not implement , no problem. But whether the inclusion >> of JNR , in form of thinking it as NDK(native development kit) , in groovy >> - so that end-user can just write his own small script with native >> functionalities - does this Proposal version 2.0 make it to you.* >> >> Again, >> >> * saying my Proposal Version 2.0 is that: if chdir() via JNR is >> implemented ..well and good.* >> >> * but, even If chdir() is not implemented, but still JNR >> becomes part of groovy-jdk , then that still will be a heaven's boon for >> all of us scripters. * >> >> Thanks >> zax >> >> On Mon, Jul 6, 2015 at 9:37 AM, Owen Rubel wrote: >> >>> >> " From my understanding of implementations of the chdir() method, >>> this stores a common path to be used >>> >>by other methods in determining path." >>> >>> > 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 . >>> >>> You seem to be missing the point. I'm not talking about 'native OS >>> functionality'. I'm still talking env. >>> >>> And chdir() in Ruby IS only for 'working directory' (read >>> documentation). It does not affect changing directory for other contexts. >>> And thus this variable IS stored so that the applicaton is aware of >>> 'current working directory' >>> >>> In Java/Groovy applications such as Spring/Grails, you will have a >>> variety of paths(ie jar,war,catalina, application path, plugin path, etc). >>> The list goes on and on. chdir() is a VERY LIMITED method and IMHO, not >>> worth the time and effort for what little it provides. >>> >>> Owen Rubel >>> 415-971-0976 >>> orubel@gmail.com >>> >>> On Sun, Jul 5, 2015 at 7:15 PM, 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 . >>>> >>>> zax >>>> >>>> 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 >>>>> 415-971-0976 >>>>> orubel@gmail.com >>>>> >>>>> 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; >>>>>> import java.io.*; >>>>>> >>>>>> /** >>>>>> >>>>>> - 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 libcxxx.so 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. >>>>>> >>>>>> zax >>>>>> >>>>>> >>>>>> 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. >>>>>>> >>>>>>> >>>>>>> Owen Rubel >>>>>>> 415-971-0976 >>>>>>> orubel@gmail.com >>>>>>> >>>>>>> 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 >>>>>>>> https://issues.apache.org/jira/browse/GROOVY-7493 >>>>>>>> for this enhancement feature request. >>>>>>>> >>>>>>>> zaxebo1 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --001a1139720a475462051a362bba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Treating JNR/JNA as a separate issue, what would you = want to see Groovy do to implement?=C2=A0 Are you proposing adding a JNR/JN= A DSL?=C2=A0 If not, why wouldn't it work to just pull in JNR or JNA wi= th @Grab?=C2=A0 Sorry if that's a dumb question, I've not used eith= er.

-Keegan

On Mon, Jul 6, 2015 at 12:53 AM, Zaxebo Yaxebo <zaxebo1= @gmail.com> wrote:
by the way, JNR(Java native runtime) is Apache= 2.0 Licensed ( see https://github.com/jnr/jnr-ffi/blob/master/LICENS= E )
I mentioned this - because this may be a point of cons= ideration as groovy is now part of Apache. So, "license wise" the= =C2=A0 inclusion of JNR in groovy-gdk should not pose any reconsideration.<= br>
Thanks
zax


On Mon, Jul 6, 2015 at 10:1= 2 AM, Zaxebo Yaxebo <zaxebo1@gmail.com> wrote:
I can see your logic.
but, I have already "modified my proposal" as Proposal= Version 2.0:

Now, I do not request for chdir() impleme= ntation,as mandatory requirement.
I proposed that JNR (or JNA)= is quite useful to be=20 included in groovy-gdk , This will extend the reach to all the native= =20 functionality in groovy in a single shot, even without providing the=20 implementation for each individual functionality.
Even if=20 chdir() functionality is not provided, but still inclusion of JNR or JNA into groovy-gdk will lead to easy individual implementation and lots of ot= her native functionality in a single shot.

RATIONAL= E:
=C2=A0a) Groovy allows us to to acess all the funcionality of= JDK (java development kit) in easy way
=C2=A0b= ) groovy provides its own convenience methods in GDK (groovy = development kit)
=C2=A0c) but whole lot of native OS function= alities or other functionalities in .so/.dll still require JNI implementati= on. If JNR is included as inbuilt into GDK , then if somebody wants to roll= out his own chdir() he can do easily, if somebody wants to access POSIX/wi= n32 API extended functionalities, XFS etc extended functionalities , Device= programming through a native dll - then that end-user can implement his ow= n methods using this JNR in one shot. Groovy will not implement these funct= ionalities on its own, it will just provide base functionality to access na= tive functionality - by inclusion of JNR. So a single inclusion of a .jar o= f JNR will enable the groovy programmers to access all the native platform = functionalities in extended way.=C2=A0 We can think of JNR as NDK (na= tive development kit).

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 This will bring NDK (native functionalities , ie JNR), GDK functionalit= ies, JDK functionalities on one par.


Spring,grails= etc are just one type of users of groovy - which is Enterprise usag= e.
But, We another type of users - who are using groovy to scrip= t native platform (device programming, file system programming with extende= d attributes etc) are also a user domain of groovy.

= Even if chdir() is not implement , no problem. But whether the inclusion= of JNR , in form of thinking it as NDK(native development kit) , in groovy= - so that end-user can just write his own small script with native functio= nalities - does this Proposal version 2.0 make it to you.

Again, saying my Proposal Version 2.0 is that:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 if chdir() via JNR is implemented= ..well and good.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 but, even =C2=A0 If chdir() is not implemented, but s= till JNR becomes part of groovy-jdk , then that still will be a heaven&= #39;s boon for all of us scripters.

Thanks
=C2=A0zax

<= div class=3D"gmail_quote">On Mon, Jul 6, 2015 at 9:37 AM, Owen Rubel <orube= l@gmail.com> wrote:
>> "= ; From my understanding of implementations of the chdir() method, this stor= es a common path to be used=C2=A0
>>by other methods in determining path.&q= uot;

> no. thats^ the methodology followed by jython. That is= the old approach.
>
>Nowadays, = the=C2=A0 new approach of JNA/JNR implementation of chdir(),getcwd() access= es the "native OS functionality" itself, in a very cross >plat= form way - but still without needing to be recompiled for each native platf= orm .

=
You seem to be missing the point= .=C2=A0 I'm not talking about 'native OS functionality'. I'= m still talking env.=C2=A0

And chdir() in R= uby IS only for 'working directory' (read documentation). It does n= ot affect changing directory for other contexts. And thus this variable IS = stored so that the applicaton is aware of 'current working directory= 9;

In Java/Groovy applications such as Spring/Gra= ils, you will have a variety of paths(ie jar,war,catalina, application path= , plugin path, etc). The list goes on and on. chdir() is a VERY LIMITED met= hod and IMHO, not worth the time and effort for what little it provides.
<= /span>

On Sun, Jul 5, 2015 at 7:15 PM, Zaxebo Yaxeb= o <zaxebo1@gmail.com> wrote:
owen>> " From my understanding of implementa= tions of the chdir() method, this=20 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 app= roach.

Nowadays, the=C2=A0 new appr= oach of JNA/JNR implementation of chdir(),getcwd() accesses the "nativ= e OS functionality" itself, in a very cross platform way - but still w= ithout needing to be recompiled for each native platform .

zax

On Mon, Jul 6, 2015 at 7:26 AM, Owen Rubel <orubel@gmai= l.com> 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 w= ays.

=

=

On Sun, Jul 5, 2015 at 5:47 PM, Zaxebo Yaxeb= o <zaxebo1@gmail.com> wrote:
Thanks for the feedback.

Those us= ers like me, who want to use groovy for scripting for Operating system doma= in, and replace shellscript/ruby/python scripts with the one "groovy&q= uot; language script there. We obviously need changeDirectory(chdir()) func= tion. This is the case of missing of "only one very core filesystem ma= nipulation function (chdir) from groovy-gdk".

As yo= u said, why - "it will depend upon env. framework and alot of variable= s that need to be set by a developer creating a required config over conven= tion functionality".???
if JNA method for chdir() is fin= alised, then it only requires almost the following code:

import com.= sun.jna.NativeLibrary;

import com.sun.jna.Platform;
import java.io.*;

/**

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

    private NativeLibrary getCLib()

    { if (cLib =3D=3D null) cLib =3D NativeLibrary.getInstance(null); // Will load libcxxx.so or msv= crt.dll return cLib; }

    public String getcwd()

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

    private String getOsDependentFuntionName(String fname)

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

    }


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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
alternative proposal:
Though i would pray t= hat this feature of chdir() is implemented.
But, Just in case, thi= s chdir() function is not implemented , i would still suggest/request th= at 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 repla= ce lot of C/C++ coding of JNI. Say,It will enable user to access extended f= ile system attributes (say for XFS,/proc type file systems) directly from n= ative 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.=C2=A0 <= br>This native accessing=C2=A0 functionality without writing glue C/C++ cod= e, will let groovy core=C2=A0 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 fu= nctionality without compiling any .so on their own,=C2=A0 we want to use gr= oovy for scripting these cases also. Groovy can atleast provide JNA/JNR fun= ctionality out of the box, to enable large native functionality access out = of the box, for which there is no inbuilt functionality in jdk.

zax


On Mon, Jul 6, 2015 at 2:28 AM,= Owen Rubel <orubel@gmail.com> wrote:

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

Groovy isn't a bridge for another language which is why it's appr= ox 4x faster than JRuby.=C2=A0

It's purpos= e isn't to mock every other language but to implement convention over c= onfig concepts, provide a scripting language for Java, =C2=A0simplified fun= ctions.

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.


Owen Rubel
<= a href=3D"tel:415-971-0976" value=3D"+14159710976" target=3D"_blank">415-97= 1-0976
orubel@= gmail.com

On Sun, Jul 5, 2015 at 11:26 AM, Zaxebo Yaxe= bo <zaxebo1@gmail.com> wrote:
jvm has no chdi= r() function to change current working directory.

As groovy position= s itself as competitor to jruby and other scripting language, and jruby imp= lements chdir() using JNR (not using JNI)

jython also implemen= ts 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 us= ing JNA.

please give your feedback at https://= issues.apache.org/jira/browse/GROOVY-7493
for this enhancement= feature request.

zaxebo1
<= /div>








--001a1139720a475462051a362bba--