<https://sourceforge.net/p/oorexx/code-0/11856> fixes NewRoutine(), LoadPackageFromDate() and also the Routine's class method newFile() when employed with rexxc-tokenized/compiled code, thank you very much!
--- Unfortunately, running rexxc-tokenized/compiled scripts via the Java scripting framework does not work as apprehended in my last post and causes the following runtime error: G:\test\oorexx\rexxc>rexxj test.rexx RexxDispatcher.java: Throwable of type 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx: getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9: Rexx traceback line not available from the Rexx condition object (Rexx condition may have been caused by a call or message from Java to Rexx) Error 3 running line 0: Failure during initialization. Error 3.903: Program "G:\test\oorexx\rexxc\test.rexx" cannot be run by this version of the REXX interpreter.] (The error text within the square brackets gets created in native code from the Rexx condition object. The 'getLocalizedMessage():' right before the opening square bracket seems to come from ooRexx, it is not used in the native code.) The reason for this runtime error with rexxc-tokenized/compiled code is caused by the implicitly employed Java Reader object for reading the content of a file, changing the tokenized/compiled binary data by applying codepage translations. (There are no Java based scripting frameworks that would allow using a Stream for reading binary script data, unfortunately.) ---rony On 07.04.2019 15:33, Rony G. Flatscher wrote: > ... cut ... > > --- > > *Unfortunately*, there is one principal huge problem left with > compiled/tokenized Rexx code, that > is beyond BSF4ooRexx' ability to solve for good: BSF4ooRexx uses two Java > scripting frameworks, > one originating from IBM (DeveloperWorks) which got handed over to the ASF > named "BSF" (Bean > Scripting Framework), one originating from Java itself which got introduced > later as the "Java > scripting framework" in Java 1.6/6.0 (package named "javax.script", the URL > to the package > documentation > <https://docs.oracle.com/javase/8/docs/api/javax/script/package-summary.html>). > > BSF4ooRexx implements under the name "RexxScript" the javax.script scripting > framework, which > makes it e.g. possible for JavaFX to denote the programming language "rexx" > in the FXML files that > define the GUI. The FXMLLoader class will therefore be able to create an > ooRexx interpreter with > the help of "javax.script" and execute the code in any given files or Rexx > code supplied verbaitm > in event attributes of JavaFX GUI elements. > > The Java documentation for the javax.script.Engine interface that must be > (and has been) > implemented can be found here: > <https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngine.html>. > Executing ooRexx code > from Java will be done with one of the eval() methods which either expect a > /java.lang.String/ or > a /java.io.Reader/ object that represents the code to execute. > > A Java /Reader /will expect plain text to be read/and applies codepage > translations/ if necessary! > This means that a /Reader /object if reading compiled/tokenized Rexx code > might transform the > binary data! With other words, it is quite likely that compiled/tokenized > (binary data) Rexx code > read by Java from a file with a /Reader/ gets destroyed by applying > mistakingly code-page > translations to that binary data! :-(( > > --- > > A maybe feasible solution could be to apply c2x() to the binary data that > results when applying > "rexxc" and store that data right after the eye-catcher string "/**/@REXX" > that indicates that the > remaining data represents the compiled/tokenized version of a Rexx program. > Upon loading, that > hexadecimal string representing the binary data could be changed back to the > original binary > representation with x2c() before processing it. > > This way all the Java defined String/Reader based interfaces would keep > working and there would be > no risk whatsoever, that automatically applied codepage translations could > ruin/destroy the binary > data as that data would be turned into plain text by c2x()! > > I would file a short RFE to this effect, but wanted to give "the long story" > (trying to explain > the background and why it would be very important for allowing the Java > scripting frameworks to be > applied safely to compiled/tokenized Rexx code as well) here. > > ---rony >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel