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 6058A18450 for ; Mon, 6 Jul 2015 04:53:13 +0000 (UTC) Received: (qmail 6548 invoked by uid 500); 6 Jul 2015 04:53:13 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 6515 invoked by uid 500); 6 Jul 2015 04:53:13 -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 6505 invoked by uid 99); 6 Jul 2015 04:53:13 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jul 2015 04:53:13 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B6C0018291F for ; Mon, 6 Jul 2015 04:53:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.15 X-Spam-Level: **** X-Spam-Status: No, score=4.15 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id et3BD1W0DOx8 for ; Mon, 6 Jul 2015 04:53:02 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 485472122B for ; Mon, 6 Jul 2015 04:53:01 +0000 (UTC) Received: by igau2 with SMTP id u2so2802209iga.0 for ; Sun, 05 Jul 2015 21:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J6pCWcgOb6TEQkBBeBuQVLn2/1eOKbsOEbOdxF4NoJg=; b=mZZOPGd9uOHC5PZFKaCvNvQUERJrWmus6IMiidtx7tGAdbqrqGWeKcZghgAN3nNwbW b5VttWaZT13hxCl/yvcVsqb+rBRJ5N7qHmyfQo6nsPKZkhH8uJIQ98VnhdLEdKc7yyEy YAsGUQpLbPzMGeN22WmUcX2CrTNqU0oYKb5naer1YzY18/Yj2//swuRSECqF46dOY1bd dr6MMgU0q3tvBNYEBFHI7D6I1SKYvM0mlwRCYBI8p99GfsqbYh4rXHQWyaLdqKq+uZXR x1Ibwi4N+LV2tIg8Tq4LABtCLNJCc1Cs9cLkwlwnGKehjLu/E9XfkvzyOm0y4SncCR5X Wn3Q== MIME-Version: 1.0 X-Received: by 10.50.109.138 with SMTP id hs10mr39364312igb.48.1436158380153; Sun, 05 Jul 2015 21:53:00 -0700 (PDT) Received: by 10.107.146.67 with HTTP; Sun, 5 Jul 2015 21:53:00 -0700 (PDT) Date: Mon, 6 Jul 2015 10:23:00 +0530 Message-ID: Subject: Re: chdir() implementation requested in groovy, just like jruby From: Zaxebo Yaxebo To: users@groovy.incubator.apache.org Content-Type: multipart/alternative; boundary=089e0122e6aa1722e9051a2daea3 --089e0122e6aa1722e9051a2daea3 Content-Type: text/plain; charset=UTF-8 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --089e0122e6aa1722e9051a2daea3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
by the way, JNR(Java native runtime) i= s 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=C2=A0 inc= lusion of JNR in groovy-gdk should not pose any reconsideration.

Thanks
zax

On Mon, Jul 6, 2015 at 10:12 AM, Zaxebo Yaxebo <zaxebo1@gmai= l.com> wrote:
I can see your logic.
but, I have already "m= odified 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= =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

On Mon, Jul 6, 2015 at 9:37 AM, Owen= Rubel <orubel@gmail.com> wrote:
&= gt;> " From my understanding of implementations of the chdir() meth= od, this stores a common path to be used=C2=A0
>>by other methods in determ= ining path."

> no. thats^ the methodology followed by jy= thon. That is the old approach.
>
&= gt;Nowadays, the=C2=A0 new approach of JNA/JNR implementation of chdir(),ge= tcwd() accesses the "native OS functionality" itself, in a very c= ross >platform way - but still without needing to be recompiled for each= native platform .

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

And= chdir() in Ruby IS only for 'working directory' (read documentatio= n). 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, app= lication path, plugin path, etc). The list goes on and on. chdir() is a VER= Y 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 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>







--089e0122e6aa1722e9051a2daea3--