NetRexx JSR199 Compiler API support
Locked
NetRexx JSR199 Compiler API support
 
|
René and all interested parties;
I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! ---------------------------------------------------------------------------------------------------------- import org.netrexx. pname="jsr199hello" -- program name nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code classlist=ArrayList() -- this requests a class loader and class files returned in memory NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator pclass=loader.loadClass(pname) -- load our class file into the jvm pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! ------------------------------------------------------------------------------------------------------------ Thanks for your attention, -- Kermit _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Kermit,
that is great news! We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. The -Dnrx.compiler stuff is all kept the same? best regards, René. > On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: > > René and all interested parties; > > I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: > > (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. > > (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. > > (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. > > If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. > > The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! > ---------------------------------------------------------------------------------------------------------- > import org.netrexx. > > pname="jsr199hello" -- program name > nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code > > classlist=ArrayList() -- this requests a class loader and class files returned in memory > NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp > loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator > pclass=loader.loadClass(pname) -- load our class file into the jvm > pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! > ------------------------------------------------------------------------------------------------------------ > Thanks for your attention, > -- Kermit > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
Hi René -
Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. -- Kermit On 5/3/2015 12:49 PM, René Jansen wrote: > Kermit, > > that is great news! > > We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. > > I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. > > The -Dnrx.compiler stuff is all kept the same? > > best regards, > > René. > > >> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >> >> René and all interested parties; >> >> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >> >> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >> >> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >> >> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >> >> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >> >> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >> ---------------------------------------------------------------------------------------------------------- >> import org.netrexx. >> >> pname="jsr199hello" -- program name >> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >> >> classlist=ArrayList() -- this requests a class loader and class files returned in memory >> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >> pclass=loader.loadClass(pname) -- load our class file into the jvm >> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >> ------------------------------------------------------------------------------------------------------------ >> Thanks for your attention, >> -- Kermit >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
Hi Kermit,
I have just built this - it seems no .class file comes out? Rene. > On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: > > Hi René - > > Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) > > I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. > > I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). > > The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. > > -- Kermit > > On 5/3/2015 12:49 PM, René Jansen wrote: >> Kermit, >> >> that is great news! >> >> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >> >> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >> >> The -Dnrx.compiler stuff is all kept the same? >> >> best regards, >> >> René. >> >> >>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>> >>> René and all interested parties; >>> >>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>> >>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>> >>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>> >>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>> >>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>> >>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>> ---------------------------------------------------------------------------------------------------------- >>> import org.netrexx. >>> >>> pname="jsr199hello" -- program name >>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>> >>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>> ------------------------------------------------------------------------------------------------------------ >>> Thanks for your attention, >>> -- Kermit >>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
Can you give me a test case? The class name handling may need to be
different than in the Java examples for packages. On 5/4/2015 2:01 AM, René Jansen wrote: > Hi Kermit, > > I have just built this - it seems no .class file comes out? > > Rene. > > >> On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: >> >> Hi René - >> >> Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) >> >> I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. >> >> I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). >> >> The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. >> >> -- Kermit >> >> On 5/3/2015 12:49 PM, René Jansen wrote: >>> Kermit, >>> >>> that is great news! >>> >>> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >>> >>> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >>> >>> The -Dnrx.compiler stuff is all kept the same? >>> >>> best regards, >>> >>> René. >>> >>> >>>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>>> >>>> René and all interested parties; >>>> >>>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>>> >>>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>>> >>>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>>> >>>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>>> >>>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>>> >>>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>>> ---------------------------------------------------------------------------------------------------------- >>>> import org.netrexx. >>>> >>>> pname="jsr199hello" -- program name >>>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>>> >>>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>>> ------------------------------------------------------------------------------------------------------------ >>>> Thanks for your attention, >>>> -- Kermit >>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
package test
say ‘hello world’ does not work. If I leave package out, it does work. René. > On 4 mei 2015, at 11:08, Kermit Kiser <[hidden email]> wrote: > > Can you give me a test case? The class name handling may need to be different than in the Java examples for packages. > > On 5/4/2015 2:01 AM, René Jansen wrote: >> Hi Kermit, >> >> I have just built this - it seems no .class file comes out? >> >> Rene. >> >> >>> On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: >>> >>> Hi René - >>> >>> Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) >>> >>> I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. >>> >>> I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). >>> >>> The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. >>> >>> -- Kermit >>> >>> On 5/3/2015 12:49 PM, René Jansen wrote: >>>> Kermit, >>>> >>>> that is great news! >>>> >>>> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >>>> >>>> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >>>> >>>> The -Dnrx.compiler stuff is all kept the same? >>>> >>>> best regards, >>>> >>>> René. >>>> >>>> >>>>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>>>> >>>>> René and all interested parties; >>>>> >>>>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>>>> >>>>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>>>> >>>>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>>>> >>>>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>>>> >>>>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>>>> >>>>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>>>> ---------------------------------------------------------------------------------------------------------- >>>>> import org.netrexx. >>>>> >>>>> pname="jsr199hello" -- program name >>>>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>>>> >>>>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>>>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>>>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>>>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>>>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>>>> ------------------------------------------------------------------------------------------------------------ >>>>> Thanks for your attention, >>>>> -- Kermit >>>>> >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
I just committed a fix for the package naming that seems to work. Can
you rebuild and try it? On 5/4/2015 2:13 AM, René Jansen wrote: > package test > say ‘hello world’ > > > does not work. If I leave package out, it does work. > > René. > > > >> On 4 mei 2015, at 11:08, Kermit Kiser <[hidden email]> wrote: >> >> Can you give me a test case? The class name handling may need to be different than in the Java examples for packages. >> >> On 5/4/2015 2:01 AM, René Jansen wrote: >>> Hi Kermit, >>> >>> I have just built this - it seems no .class file comes out? >>> >>> Rene. >>> >>> >>>> On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: >>>> >>>> Hi René - >>>> >>>> Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) >>>> >>>> I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. >>>> >>>> I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). >>>> >>>> The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. >>>> >>>> -- Kermit >>>> >>>> On 5/3/2015 12:49 PM, René Jansen wrote: >>>>> Kermit, >>>>> >>>>> that is great news! >>>>> >>>>> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >>>>> >>>>> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >>>>> >>>>> The -Dnrx.compiler stuff is all kept the same? >>>>> >>>>> best regards, >>>>> >>>>> René. >>>>> >>>>> >>>>>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>>>>> >>>>>> René and all interested parties; >>>>>> >>>>>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>>>>> >>>>>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>>>>> >>>>>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>>>>> >>>>>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>>>>> >>>>>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>>>>> >>>>>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>>>>> ---------------------------------------------------------------------------------------------------------- >>>>>> import org.netrexx. >>>>>> >>>>>> pname="jsr199hello" -- program name >>>>>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>>>>> >>>>>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>>>>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>>>>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>>>>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>>>>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>>>>> ------------------------------------------------------------------------------------------------------------ >>>>>> Thanks for your attention, >>>>>> -- Kermit >>>>>> >>>>>> _______________________________________________ >>>>>> Ibm-netrexx mailing list >>>>>> [hidden email] >>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>>> >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
Hi Kermit,
Just in case no-one other than René says this - "thank you!" Your work is greatly appreciated. Dave. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser Sent: 04 May 2015 10:33 To: IBM Netrexx Subject: Re: [Ibm-netrexx] NetRexx JSR199 Compiler API support I just committed a fix for the package naming that seems to work. Can you rebuild and try it? On 5/4/2015 2:13 AM, René Jansen wrote: > package test > say ‘hello world’ > > > does not work. If I leave package out, it does work. > > René. > > > >> On 4 mei 2015, at 11:08, Kermit Kiser <[hidden email]> wrote: >> >> Can you give me a test case? The class name handling may need to be different than in the Java examples for packages. >> >> On 5/4/2015 2:01 AM, René Jansen wrote: >>> Hi Kermit, >>> >>> I have just built this - it seems no .class file comes out? >>> >>> Rene. >>> >>> >>>> On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: >>>> >>>> Hi René - >>>> >>>> Busy grandson birthday party day here today! Stealing a few minutes >>>> for NetRexx. ;-) >>>> >>>> I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. >>>> >>>> I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). >>>> >>>> The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. >>>> >>>> -- Kermit >>>> >>>> On 5/3/2015 12:49 PM, René Jansen wrote: >>>>> Kermit, >>>>> >>>>> that is great news! >>>>> >>>>> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >>>>> >>>>> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >>>>> >>>>> The -Dnrx.compiler stuff is all kept the same? >>>>> >>>>> best regards, >>>>> >>>>> René. >>>>> >>>>> >>>>>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>>>>> >>>>>> René and all interested parties; >>>>>> >>>>>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>>>>> >>>>>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>>>>> >>>>>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>>>>> >>>>>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>>>>> >>>>>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>>>>> >>>>>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>>>>> ----------------------------------------------------------------- >>>>>> ----------------------------------------- >>>>>> import org.netrexx. >>>>>> >>>>>> pname="jsr199hello" -- program name >>>>>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>>>>> >>>>>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>>>>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>>>>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>>>>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>>>>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>>>>> ----------------------------------------------------------------- >>>>>> ------------------------------------------- >>>>>> Thanks for your attention, >>>>>> -- Kermit >>>>>> >>>>>> _______________________________________________ >>>>>> Ibm-netrexx mailing list >>>>>> [hidden email] >>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>>> >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
Thanks Dave. I kind of enjoy the work. It's like a tricky brain-teaser
puzzle. (Or just plain magic. ;-) On 5/4/2015 2:35 AM, Dave Woodman wrote: > Hi Kermit, > > Just in case no-one other than René says this - "thank you!" Your work is greatly appreciated. > > Dave. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Kermit Kiser > Sent: 04 May 2015 10:33 > To: IBM Netrexx > Subject: Re: [Ibm-netrexx] NetRexx JSR199 Compiler API support > > I just committed a fix for the package naming that seems to work. Can you rebuild and try it? > > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
|
In reply to this post by Kermit Kiser
Hi Kermit,
yes, this is good. And noticeably faster on the dreadful exported filesystem of $(LARGE BANK), so you already saved me some time today. I have an odd thing with a makefile on MacOSX, but that might be the construction of it, or that it is now too fast for my previous assumptions. But the code itself compiles and runs great. Thank you! best regards, René. > On 4 mei 2015, at 11:33, Kermit Kiser <[hidden email]> wrote: > > I just committed a fix for the package naming that seems to work. Can you rebuild and try it? > > On 5/4/2015 2:13 AM, René Jansen wrote: >> package test >> say ‘hello world’ >> >> >> does not work. If I leave package out, it does work. >> >> René. >> >> >> >>> On 4 mei 2015, at 11:08, Kermit Kiser <[hidden email]> wrote: >>> >>> Can you give me a test case? The class name handling may need to be different than in the Java examples for packages. >>> >>> On 5/4/2015 2:01 AM, René Jansen wrote: >>>> Hi Kermit, >>>> >>>> I have just built this - it seems no .class file comes out? >>>> >>>> Rene. >>>> >>>> >>>>> On 4 mei 2015, at 02:05, Kermit Kiser <[hidden email]> wrote: >>>>> >>>>> Hi René - >>>>> >>>>> Busy grandson birthday party day here today! Stealing a few minutes for NetRexx. ;-) >>>>> >>>>> I see what you mean about 1.5 in the build. NetRexx still builds and runs OK with that setting but would require JDK 1.6 in order to use the javac compiler. The ecj (Eclipse compiler) is no problem since it has had JSR199 built in since version 3.3 (There are no usage docs and it differs from javac but fortunately I finally found an example on the net). It is worth testing if we can still run with Java 1.5 while using ecj anyway. >>>>> >>>>> I am also working on the "pre-read" issue but totally eliminating the jar loading is not possible except as an option because it would break any "branch" import statements and thus not be compatible with many older NetRexx programs. Even so, I think we can do it with the caveat of not using branch type import statements (package groups == import xx. ). >>>>> >>>>> The -Dnrx.compiler specification technique still works but is hard to use so I am going to make "-javac" and "-ecj" work as command line options also. However that change goes along with a mod to use extremely aggressive compiler location logic which makes the options a "preference" rather than a hard limit. >>>>> >>>>> -- Kermit >>>>> >>>>> On 5/3/2015 12:49 PM, René Jansen wrote: >>>>>> Kermit, >>>>>> >>>>>> that is great news! >>>>>> >>>>>> We built the 3.03 distribution with 1.5 level, on 1.6. Having 1.6 as a baseline is no problem, because, as someone aptly said, we are a programming language, not a museum. >>>>>> >>>>>> I think this is very interesting, and I cannot wait to test it. Please check it in, so we can all have a look at it. I think the next speed improvement for the translator would be to skip all the jar loading and check only the actually called function signatures using reflection. >>>>>> >>>>>> The -Dnrx.compiler stuff is all kept the same? >>>>>> >>>>>> best regards, >>>>>> >>>>>> René. >>>>>> >>>>>> >>>>>>> On 3 mei 2015, at 21:36, Kermit Kiser <[hidden email]> wrote: >>>>>>> >>>>>>> René and all interested parties; >>>>>>> >>>>>>> I now have a working version of the NetRexx translator with JSR199 Java Compiler API support ready for further testing. Before that can happen, some philosophical issues need to be addressed: >>>>>>> >>>>>>> (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that requirement level? Although the 3.03 release announcement said Java 1.5 was the required level, I think 1.6 was actually required since we built the code with that version. >>>>>>> >>>>>>> (2) The translator no longer writes Java source files to disk unless specifically requested via keep or keepasjava and class files are only written once to minimize disk file IO instead of twice as before. Writing class files can be optionally bypassed - see example below. >>>>>>> >>>>>>> (3) Since the goal of this update is to reduce or eliminate unneeded disk file IO, the option "-nocrossref" is now always the default where before it was only the default when interpreting programs. Crossref files must be explicitly requested now. >>>>>>> >>>>>>> If there are no objections, I will commit the changes to the NetRexx repository for addition to NetRexx 3.04. >>>>>>> >>>>>>> The following example program shows a new API which may interest some developers as it creates a NetRexx program in memory and calls the translator to convert it to Java code, then compile it with the Java compiler and return the class file along with a classloader containing it and finally run the compiled class - all without writing anything to disk files! >>>>>>> ---------------------------------------------------------------------------------------------------------- >>>>>>> import org.netrexx. >>>>>>> >>>>>>> pname="jsr199hello" -- program name >>>>>>> nrp=' say "hello"\n say arg \n say "program complete" ' -- NetRexx program code >>>>>>> >>>>>>> classlist=ArrayList() -- this requests a class loader and class files returned in memory >>>>>>> NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC to compile from string nrp >>>>>>> loader=ClassLoader classlist.get(0) -- find class loader build by NetRexx translator >>>>>>> pclass=loader.loadClass(pname) -- load our class file into the jvm >>>>>>> pclass.getMethod("main", [Class String[0].getClass()]).invoke(null,[Object [String 'argument string']]) -- locate the main method and call it with reflection = all done! >>>>>>> ------------------------------------------------------------------------------------------------------------ >>>>>>> Thanks for your attention, >>>>>>> -- Kermit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ibm-netrexx mailing list >>>>>>> [hidden email] >>>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>>>> >>>>>> _______________________________________________ >>>>>> Ibm-netrexx mailing list >>>>>> [hidden email] >>>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>>> >>>>> _______________________________________________ >>>>> Ibm-netrexx mailing list >>>>> [hidden email] >>>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>>> >>>> _______________________________________________ >>>> Ibm-netrexx mailing list >>>> [hidden email] >>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>>> >>> _______________________________________________ >>> Ibm-netrexx mailing list >>> [hidden email] >>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >>> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] >> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ >> > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
Re: NetRexx JSR199 Compiler API support
|
|
Good to hear that René. I was hoping someone could run some speed
benchmarks. Just a suggestion: Although I have put the latest trunk build binaries in the NetRexx Plus Kenai project download area, it might be a good idea to keep the latest daily development binaries in the main project download area on Kenai or on netrexx.org with a link from netrexx.org so that excellent testers like Rony can find them without needing an SVN checkout or build environment. -- Kermit On 5/4/2015 3:22 AM, René Jansen wrote: > Hi Kermit, > > yes, this is good. And noticeably faster on the dreadful exported filesystem of $(LARGE BANK), so you already saved me some time today. > I have an odd thing with a makefile on MacOSX, but that might be the construction of it, or that it is now too fast for my previous assumptions. But the code itself compiles and runs great. Thank you! > > best regards, > > René. > >> On 4 mei 2015, at 11:33, Kermit Kiser <[hidden email]> wrote: >> >> I just committed a fix for the package naming that seems to work. Can you rebuild and try it? >> _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ |
|
In reply to this post by Kermit Kiser
Hi Kermit, thanks for this information, as well as to all
improvements/issues Rene and You are doing on NetRexx. As I see all the efforts from the Kenai reports, it's real progress going on. I hope other followers of ibm-netrexx do support my: Thank YOU both. Thomas Schneider. =============================================================================================== Am 03/05/2015 um 21:36 schrieb Kermit Kiser: > René and all interested parties; > > I now have a working version of the NetRexx translator with JSR199 > Java Compiler API support ready for further testing. Before that can > happen, some philosophical issues need to be addressed: > > (1) JSR199 requires Java 6+. Are we ready to move NetRexx to that > requirement level? Although the 3.03 release announcement said Java > 1.5 was the required level, I think 1.6 was actually required since we > built the code with that version. > > (2) The translator no longer writes Java source files to disk unless > specifically requested via keep or keepasjava and class files are only > written once to minimize disk file IO instead of twice as before. > Writing class files can be optionally bypassed - see example below. > > (3) Since the goal of this update is to reduce or eliminate unneeded > disk file IO, the option "-nocrossref" is now always the default where > before it was only the default when interpreting programs. Crossref > files must be explicitly requested now. > > If there are no objections, I will commit the changes to the NetRexx > repository for addition to NetRexx 3.04. > > The following example program shows a new API which may interest some > developers as it creates a NetRexx program in memory and calls the > translator to convert it to Java code, then compile it with the Java > compiler and return the class file along with a classloader containing > it and finally run the compiled class - all without writing anything > to disk files! > ---------------------------------------------------------------------------------------------------------- > > import org.netrexx. > > pname="jsr199hello" -- program name > nrp=' say "hello"\n say arg \n say "program complete" ' > -- NetRexx program code > > classlist=ArrayList() -- this requests a class loader and > class files returned in memory > NetRexxC.main(pname "-verbose0", nrp, null, classlist) -- ask NetRexxC > to compile from string nrp > loader=ClassLoader classlist.get(0) -- find class loader > build by NetRexx translator > pclass=loader.loadClass(pname) -- load our class file > into the jvm > pclass.getMethod("main", [Class > String[0].getClass()]).invoke(null,[Object [String 'argument > string']]) -- locate the main method and call it with > reflection = all done! > ------------------------------------------------------------------------------------------------------------ > > Thanks for your attention, > -- Kermit > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > Online Archive : http://ibm-netrexx.215625.n3.nabble.com/ > _______________________________________________ Ibm-netrexx mailing list [hidden email] Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
Thomas Schneider, Vienna, Austria (Europe) :-)
www.thsitc.com www.db-123.com |
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |