<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

Reply via email to