<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
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
