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
