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.
Cheers, Moritz On Tue, Apr 9, 2019 at 3:34 PM Rony G. Flatscher <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 > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Moritz Hoffmann; http://antiguru.de/
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
