On 09.04.2019 17:38, Moritz Hoffmann wrote:
> Well, the Java scripting framework will always use a Reader, which decodes 
> the input according to
> the current Charset. I don't see a way to circumvent this, either by not 
> using a Reader instance
> or by injecting a custom, non-adapting Charset. I agree with Rick that this 
> is not a problem that
> ooRexx should solve. Instead, I'd base64-encode the scripts, and decode them 
> before passing them
> to the interpreter. Base64 will survive any reasonable Java byte decoding 
> magic.

The reason why it is a request (and not an error report ;) ) is that so far the 
representation has not caused a problem, because only Rexx would create and 
later read the
self-produced tokenized code (knowing its internal structure and the binary 
data part).

Now, that Rexx scripts get deployed in an environment that only processes text 
and not binary data
(in this case the Java scripting frameworks) and there are use-cases (whenever 
java.io.Reader gets
triggered in the scripting frameworks) that cannot be safely intercepted by 
BSF4ooRexx, which
enables ooRexx to be hosted by and deployed from Java (applications) and also 
making all of the Java
world available to ooRexx.

As this uncovered problem lies in the binary representation of the tokenized 
Rexx code produced by
rexxc which in this use case turns out to be actually (and unexpectedly) a 
quite fragile solution it
would nevertheless be solvable by having rexxc (or some postprocessing utility) 
store it in form of
a pure text rendering. Hence this request addressed to ooRexx.


Ad Rick's idea to create a utiltity in BSF4ooRexx to recode the rexxc-produced 
binary data in an
"immune" textual form (basically coding the binary data with c2x or base64) and 
change BSF4ooRexx
internal (native) code to deal with this situation has the following 

  * the 'rexxc' generated and postprocessed tokenized format is then not 
compatible with Rexx anymore,
  * hence submitting such a non-compatible text-encoded version of the 
tokenized format would not be
    processable by Rexx,

  * every Rexx programmer who wishes to use Rexx as a scripting language for 
Java applications or
    uses BSF4ooRexx to create demanding applications in pure ooRexx using Java 
classes for missing
    ooRexx features (like portable GUIs, but also IPV6-socket connections or 
ssl-connections, etc.)
    would need to know that for sheltering their Rexx code they must

      o run 'rexxc' on each script,
      o plus must not forget to run the BSF4ooRexx postprocessing script 
applied on those freshly
        produced 'rexxc' tokenized scripts,
      o deploy the postprocessed versions (*not* the original and Rexx 
compatible 'rexxc' tokenized

  * now take into account that application systems need to be maintained in a 
constant manner
    possibly by different programmers, each maintenance change causes the need 
to 'rexxc' and in
    addition to apply the non-ooRexx utility to postprocess the tokenized code 
to turn it into pure
    7-bit text; adding another step, making it more cumbersome and therefore 
over time mostlikely
    more error-prone.

If it was possible to encode the tokenized form rexxc currently produces in an 
agreed upon format as
text then ooRexx could process such a version by converting it back into its 
binary form, and
proceed with the resulting data as today. In this scenario one would not create 
a non-compatible
version of a tokenized Rexx program, but rather one that ooRexx would be able 
to execute without the
help of any other tool.

This is just thinking loud about the situation and the idea of creating a 
non-ooRexx compatible
tokenized version of Rexx programs in the file system.
(Still have to think about it.)


> On Tue, Apr 9, 2019 at 3:34 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at
> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>     On 09.04.2019 15:13, Rick McGuire wrote:
>     > And it doesn't make sense to put the onus on solving this on the 
> interpreter. If it is
>     desired to
>     > store binary code in an inherently text-based interface, then 
> BSF4ooRexx should handle this be
>     > including a utility to perform the transform and then decoding the 
> format before passing it
>     to the
>     > interpreter.
>     Well, please tell IBM, Oracle and the OpenJDK community which devised and 
> applied all of the Java
>     scripting frameworks in the past twenty years such that they expect 
> scripts to be supplied as text
>     only, not as binary data.
>     If a Java program employs e.g. the "javax.script" framework and it is 
> supplied the name of a Rexx
>     program file, the "javax.script" framework will use some "java.io.Reader" 
> to read the script from
>     the file. In the case of rexxc-tokenized Rexx code the Reader will 
> inadvertently destroy the
>     binary
>     data due to possible codepage translations well before BSF4ooRexx 
> receives the (then ruined
>     binary)
>     script data.
>     There is nothing, BSF4ooRexx could do here as it exploits/applies and 
> depends on the Java
>     scripting
>     frameworks, unfortunately.
>     Hence asking ooRexx to the rescue;  suggesting to add a single step 
> before storing the rexxc
>     produced binary data by turning the binary data into a hexadecimal string 
> and store that lossless
>     rendering;  and upon receiving a tokenized Rexx program adding a single 
> reverse step to turn the
>     hexadecimal string losslessly back into the needed binary form for 
> unflatening.
>     ---rony

Oorexx-devel mailing list

Reply via email to