Two things, I forgot:
* one use-case with a lot of callbacks from Java to Rexx is parsing a 10MB
XML-file using the
Java-SAX parser, but processing in Rexx; in this use-case there are approx.
680,000 callbacks
from Java to Rexx, quite a few where the arguments need to be marshalled
for Rexx; with the
memory leak fix this task can now be conducted without any problems,
* forgot to point out that the javax.script RexxScriptEngine for making
ooRexx available to Java
was presented at this year's Rexx symposium as well, such as there are
slides that among other
things also explain the "javax.script.ScriptContext", which plays an
important role in the
ooRexx JavaFX support:
<http://rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-06-RexxScript.pdf>.
---rony
On 18.05.2017 12:30, Rony G. Flatscher wrote:
> On 18.05.2017 11:55, Rick McGuire wrote:
>>
>>
>> On Thu, May 18, 2017 at 5:00 AM, Rony G. Flatscher <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> rexxpg.pdf states in "8.5 Garbage Collection Considerations": ... "The
>> global reference can
>> be used with any API context valid for /the same/ interpreter instance."
>> ...
>>
>> * Question 1: does that mean that a "global" reference obtained with
>> RequestGlobalReference() can only be used within a single Rexx
>> interpreter instance safely?
>>
>>
>> There's really only one global reference table shared between all instances,
>> so they can be used
>> safely across instances.
> Thank you for this clarification!
>
>>
>>
>> *
>>
>>
>> If so, how could one create Rexx objects via native code in one Rexx
>> interpreter instance
>> and use them in another Rexx interpreter instance, like Rexx objects
>> that are stored in
>> .environment, which are accessible from any Rexx interpreter
>> instance?
>>
>> * Question 2: does the ReleaseGlobalReference() have to be called via
>> the Rexx interpreter
>> instance that was used to create the global reference in the first
>> place, or is it
>> possible to use any Rexx interpreter instance for this purpose?
>>
>> You can do it from any instance, but since that behavior is not part of the
>> documentation,
>> there's no guarantee it will always be that way. I really don't understand
>> why you are
>> complicating things by creating so many instances. You're gaining nothing
>> but a bunch of
>> overhead. I would really only expect that to be used for multiple
>> applications running in the
>> same process that have no knowledge of how Rexx might be being used
>> elsewhere. For most
>> applications, an AttachThread()/DetachThread() should be sufficient. If you
>> are asking the sorts
>> of questions you are asking, then creating a new instance is not appropriate.
> The use case is as follows:
>
> * code in any Rexx interpreter instance using the Java bridge BSF4ooRexx
> will have a need to
> interact with Java classes like java.lang.System, java.lang.String and
> the like; so there are
> Rexx proxy objects (each being a peer for a specific Java object) that
> are used in all Rexx
> interpreter instances, however there are very few of these (less than
> twenty such objects),
>
> * the flurry of Rexx proxy objects that gets created is outside the control
> of Rexx; this is
> caused by Java (in these cases in JavaFX) which uses callbacks to e.g.
> fill-in values into
> TableView cells, to format them and the like; everytime a new record is
> inserted into or
> deleted from a TableView the JavaFX side uses its lambda functions to
> iterate over all cells
> using callbacks;
>
> o the ooRexx support for callbacks from Java looks like this:
>
> + one has to define a Rexx class and Rexx methods that correspond
> to the Java method
> used in the callback (e.g. for Java listenerers);
> + then a Rexx instance is created and wrapped up as a Java proxy
> object using
> java.lang.reflect.Proxy, such that that Java object can be used
> as an argument to e.g.
> listener callbacks;
> + each time the Java side invokes the callback (by invoking the
> respective Java method)
> the Java Rexx proxy will create a Rexx message to send its Rexx
> peer object; if there
> are Java objects as arguments, then Rexx proxy objects get
> created for them which then
> will be the arguments sent with the message),
>
> o the uninit for the Rexx proxy objects is used for reference counting
> and for making sure
> that eventually the peer Java object can be removed from the Java
> registry, if the
> references for the Rexx proxy objects drop to 0.
>
> This has been working nicely for years. Only with the advent of JavaFX
> support the use patterns
> have changed in a few (but extremely important) JavaFX controls, notably the
> TableView control.
>
> JavaFX is the successor to java.awt and javax.swing and is actually a very
> powerful architecture,
> which comes with a GUI builder (SceneBuilder), so it becomes possible with it
> for ooRexx
> programmers to create very functional and modern GUIs in a very short time.
> (I gave a presentation
> on this year's International Rexx symposium in Amsterdam about it, if
> interested please cf.
> <http://rexxla.org/events/2017/presentations/AutoJava-BSF4ooRexx-07-JavaFx.pdf>.)
>
> ---
>
> Here another use-pattern gets employed which is beyond my control: JavaFX
> allows for defining
> interfaces in XML files called "FXML" files. A specialized JavaFX loader will
> process these FXML
> files efficiently. If the FXML-file contains script code references, then a
> script engine gets
> created and the JavaFX GUI objects (e.g. a Button object) will get passed to
> it via the script
> context.
>
> The ooRexx script support for Java implements the "javax.script" framework.
> Each script engine
> that gets created in that Java infrastructure will cause a proper Rexx
> interpreter instance to be
> created, with its .local monitors .input, .output, .traceOutput, .input and
> .debugInput redirected
> to the proper Java objects that are supplied with script invocations. This
> way in the case of
> JavaFX each Rexx interpreter instance that gets created for each FXML file
> will be isolated from
> each other with the help of the .local environment, but can share data via
> the global .environment.
>
> After a FXML file was processed the Rexx interpreter instance that was
> created for it gets
> terminated by JavaFX, if the respective GUI is not being cached by the JavaFX
> main control program
> (which seems to be the rule). Then later, when the same FXML file gets
> re-processed another Rexx
> script interpreter gets created.
>
> In the JavaFX scenario it is possible to have events directed at javax.script
> languages like the
> ooRexx RexxScriptEngine, thereby effectively allowing to implement JavaFX
> event handlers in ooRexx
> (causing callbacks with the above described marshalling and demarshalling
> needs).
>
> ---rony
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
