JSR223 support in NetRexx 3.03
Locked
 
|
Let me tell you about one of the good things introduced in NetRexx 3.03 through the integration of the JSR223 package that Kermit Kiser has put together for us some time ago. JSR223 is an interface between Java and scripting languages, introduced in JVM level 1.6. It enables Java programs to interpret NetRexx source in the same way as it would call other scripting languages, like Javascript (Rhino and Nashorn), Clojure, and a host of other languages - even ANT scripts can now execute NetRexx. It can accept and return variables, including object references. An invocation of interpreted NetRexx, in NetRexx, looks like this:
import javax.script. nrEngine = ScriptEngineManager().getEngineByName("NetRexx") /* simple script invocation */ nrEngine.eval('numeric digits 17; say 111111111 * 111111111') /* script invocation with bindings */ answer = 42 nrEngine.put("answer", answer) nrEngine.eval('say ''the answer is ''answer') one = 1 nrEngine.put("onemore",one) nrEngine.eval('say ''one more is ''answer+onemore') Note that this is still beyond the numeric capacity of most scripting languages. Also note that in the second example, I have shown that for the variable bindings, any name can be used (the onemore refers to one). Another exciting way of calling any NetRexx program, for interpretation, is to use the standard jrunscript executable that is included in Java 1.6 and beyond. For example, in the examples/rosettacode directory, one could specify: jrunscript -l netrexx -cp $CLASSPATH -f RCSortingHeapsort.nrx The -l option instructs the jrunscript handler to choose NetRexx as its standard scripting language. For NetRexx to be eligible as a scripting language, NetRexxC.jar must be on the jrunscript classpath, which is a separate classpath from the standard one. I gave it my standard one by just specifying $CLASSPATH, which on Windows would be %CLASSPATH%. The -f option specifies an input file to be interpreted. The nrc and netrexxc scripts are not needed this way. But the real reason for this email is, that in this way, also a REPL ('toplevel') for NetRexx has become available, analogous to RexxTry. This can be done by just specifying: jrunscript -l netrexx -cp $CLASSPATH NetRexx> jrunscript replies with a prompt to indicate that NetRexx is the current scripting language. Any clause can be typed in and will be evaluated. Some time will be spent to bullet-proof this in the sense that we will suppress some of the generated code when errors occur, but in principle it is ready for testing. Also, this opens up ways in which user interfaces can be built using Javascript and then accessed by NetRexx programs, which is something to be explored later. Also, we are working on calling Rexx programs this way, using a new generation of JSR223 compatible BSF; this will take somewhat longer; a way to use BSF4ooRexx in a transparent manner should be feasible before NetRexx 3.03 is released. The daily build on the download page has a version for testing and experimenting; all stated examples do run with it. It would be good if problems are registered in the JIRA at Kenai. Today's daily build is Java 6 compatible - most are Java 7 or 8 nowadays, so grab it while you can if you only have Java 6 - only release candidates will be explicitly compiled for Java 6 bytecode level. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: JSR223 support in NetRexx 3.03
|
|
*Congratulations*, that is really *very* cool and great news, which
opens up a lot of new doors and makes it truely possible to expose
NetRexx to the whole Java world!
It seems that Kermit has done an excellent job, so big kudos to Kermit (and to you for picking it up and incorporating it into NetRexx)! ---rony On 8/15/2013 3:18 PM, René Jansen wrote: Let me tell you about one of the good things introduced in NetRexx 3.03 through the integration of the JSR223 package that Kermit Kiser has put together for us some time ago. JSR223 is an interface between Java and scripting languages, introduced in JVM level 1.6. It enables Java programs to interpret NetRexx source in the same way as it would call other scripting languages, like Javascript (Rhino and Nashorn), Clojure, and a host of other languages - even ANT scripts can now execute NetRexx. It can accept and return variables, including object references. An invocation of interpreted NetRexx, in NetRexx, looks like this: _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: JSR223 support in NetRexx 3.03
|
|
In reply to this post by rvjansen
That is truly amazing, René! It works exactly as advertised (even the compilation “errors”). It’s not as if you don’t already have more on your plate than most folks could tolerate (including me!), but – certainly after a bit of housekeeping as you suggest – this really needs a more formal announcement to the world. The academic world would certainly benefit from exposure, where advances like this are paid their proper due. Perhaps RexxLA should consider a membership in the ACM and send you (or MFC!) to their Conference. NetRexx (and indeed the entire Rexx Family) certainly deserve representation in their SIGPLAN. Congratulations to Kermit, and to you, for getting the ball rolling. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: JSR223 support in NetRexx 3.03
|
|
In reply to this post by rvjansen
To add my voice in support, this is splendid! Dave. From: [hidden email] [mailto:[hidden email]] On Behalf Of René Jansen Let me tell you about one of the good things introduced in NetRexx 3.03 through the integration of the JSR223 package that Kermit Kiser has put together for us some time ago. JSR223 is an interface between Java and scripting languages, introduced in JVM level 1.6. It enables Java programs to interpret NetRexx source in the same way as it would call other scripting languages, like Javascript (Rhino and Nashorn), Clojure, and a host of other languages - even ANT scripts can now execute NetRexx. It can accept and return variables, including object references. An invocation of interpreted NetRexx, in NetRexx, looks like this: import javax.script. nrEngine = ScriptEngineManager().getEngineByName("NetRexx") /* simple script invocation */ nrEngine.eval('numeric digits 17; say 111111111 * 111111111') /* script invocation with bindings */ answer = 42 nrEngine.put("answer", answer) nrEngine.eval('say ''the answer is ''answer') one = 1 nrEngine.put("onemore",one) nrEngine.eval('say ''one more is ''answer+onemore') Note that this is still beyond the numeric capacity of most scripting languages. Also note that in the second example, I have shown that for the variable bindings, any name can be used (the onemore refers to one). Another exciting way of calling any NetRexx program, for interpretation, is to use the standard jrunscript executable that is included in Java 1.6 and beyond. For example, in the examples/rosettacode directory, one could specify: jrunscript -l netrexx -cp $CLASSPATH -f RCSortingHeapsort.nrx The -l option instructs the jrunscript handler to choose NetRexx as its standard scripting language. For NetRexx to be eligible as a scripting language, NetRexxC.jar must be on the jrunscript classpath, which is a separate classpath from the standard one. I gave it my standard one by just specifying $CLASSPATH, which on Windows would be %CLASSPATH%. The -f option specifies an input file to be interpreted. The nrc and netrexxc scripts are not needed this way. But the real reason for this email is, that in this way, also a REPL ('toplevel') for NetRexx has become available, analogous to RexxTry. This can be done by just specifying: jrunscript -l netrexx -cp $CLASSPATH NetRexx> jrunscript replies with a prompt to indicate that NetRexx is the current scripting language. Any clause can be typed in and will be evaluated. Some time will be spent to bullet-proof this in the sense that we will suppress some of the generated code when errors occur, but in principle it is ready for testing. Also, this opens up ways in which user interfaces can be built using Javascript and then accessed by NetRexx programs, which is something to be explored later. Also, we are working on calling Rexx programs this way, using a new generation of JSR223 compatible BSF; this will take somewhat longer; a way to use BSF4ooRexx in a transparent manner should be feasible before NetRexx 3.03 is released. The daily build on the download page has a version for testing and experimenting; all stated examples do run with it. It would be good if problems are registered in the JIRA at Kenai. Today's daily build is Java 6 compatible - most are Java 7 or 8 nowadays, so grab it while you can if you only have Java 6 - only release candidates will be explicitly compiled for Java 6 bytecode level. best regards, René Jansen. _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
| Free forum by Nabble | Edit this page |