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 binary 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 implications: * 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 version) * 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.) ---rony > > 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 Oorexxemail@example.com https://lists.sourceforge.net/lists/listinfo/oorexx-devel