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

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: 
Executing ooRexx code from Java will be done with one of the eval() methods 
which either expect a
/java.lang.String/ or a / object that represents the code to 

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.


Oorexx-devel mailing list

Reply via email to