In the past days I got problem reports from a professional developer who exclusively uses ooRexx and for his rather complex GUIs he uses the portable JavaFX libraries via BSF4ooRexx. Everything has worked out fine it seems, using ooRexx 5.0beta and BSF4ooRexx.
However, since he started to use "rexxc" to compile/tokenize all of the Rexx source files that comprise his elaborate application to shelter his code, he has started to run into abends/errors 13.1. This was the kick-off to analyze the code paths of BSF4ooRexx and getting to the ooRexx native APIs NewRoutine() and LoadPackageFromData() that currently cause that error. Once these native APIs become able to process compiled/tokenized Rexx code like LoadPackage(), these errors will go away. --- *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
