Ad suggested test unit for "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV"

Kevin Rushforth kevin.rushforth at
Thu Feb 27 00:06:27 UTC 2020

If you want a preliminary review of a WIP PR, then yes, announcing it 
here is fine.

-- Kevin

On 2/26/2020 7:53 AM, Rony G. Flatscher wrote:
> After studying [1], not sure whether one is supposed to announce a WIP here or not, so in doubt also
> announcing the URL for the suggested test unit (part of the systemTests) for those interested in
> checking it out: <>.  To run the systemTests tests only one
> can issue:
> |    ./gradlew -PFULL_TEST=true :systemTests:test --tests ModuleLauncherTest|
> This will include the suggested WIP test unit "testscriptapp1".
> ---rony
> [1] "Contributing to OpenJFX": <>
> On 18.02.2020 14:25, Rony G. Flatscher wrote:
>> For creating a test unit to test whether [1] is present or not, it is necessary to have a Java
>> script engine to test again. As discussed in a different thread it is not advisable to use any
>> concrete, existing Java script engine that is not part of the JDK. Therefore it becomes necessary to
>> come up with a proper implementation of javax.script.ScriptEngine and
>> javax.script.ScriptEngineFactory to serve for the sole purpose of testing.
>> I have come up with such a "pseudo script engine" which will log each script invocation together
>> with the script code, a copy of the ScriptContext in effect (for later inspection) and the time of
>> invocation.
>> For a test unit it is necessary to have this pseudo script engine loaded via the SPI to be able to
>> use from a test application. For this one can define a
>> "META-INF/services/javax.script.ScriptEngineFactory" file and/or a "" file. In order
>> to be as flexible as possible both approaches were chosen (also in mind that others may have a need
>> for such a pseudo script engine for testing purposes). This implementation creates a module that
>> contains a test application where the ideas and structures are modelled after the "systemTests"
>> modules (many thanks to Keving Rushforts for pointing at that!).
>> The test application will create a JavaFX application that processes some fxml file "demo_01.fxml"
>> which defines the pseudo script engine to be used for executing all of the scripts defined in that
>> file. The "start" method will fire the Button using  "", "btn.fireEvent( new ActionEvent()
>> )", and "btn.fireEvent( new MouseEvent( ... ) )" to have the event scripts executed. As mentioned
>> the pseudo script engine will log each invocation.
>> Upon return of the "start" method the test application's main method will fetch the log of
>> invocations from the pseudo script engine and then assert that the sequence of invocations, the
>> scripts and the ScriptContext Bindings are correct with respect to some "demo_01.fxml". This not
>> only asserts the proper existence of the entries "javax.script.filename" (also the proper values of
>> the file names) and "javax.script.argv" in the engine Bindings, but also whether the global Bindings
>> are correctly defined and their values (and types) are correct. These assertion tests are dependent
>> on a) how FXMLLoader populates the ScriptContext Bindings and b) how the test case in form of the
>> fxml-file and the supplied pseudo scripts is formulated.
>> The test unit uses assertion methods of its own (like the other module based tests) and if it ends
>> with an exit code of 0 it has passed. In the case of assertion errors (or unexpected errors) an
>> appropriate error message with a stack trace is given and a non-zero exit code is returned via
>> "System.exit()" (again modeled after/copied from the other module tests).
>> To make this test unit as simple as possible the module includes the pseudo script engine (it is not
>> a separate module). It needs to be run on its own JVM (as is the case with the other module tests).
>> Any comments, questions, suggestions?
>> ---rony
>> [1] "JDK-8234959 FXMLLoader does not populate ENGINE_SCOPE Bindings with FILENAME and ARGV":
>> <>

More information about the openjfx-dev mailing list