Files
2026-06-17 14:00:51 +02:00

46 lines
1.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
The jython/test/Python3Test.py3 provides some examples of these.
You can access jmri.Turnout.CLOSED but jmri.Turnout.UNKNOWN is undefined. You have to access jmri.NamedBean.UNKNOWN instead, which is a real pain.
The Jython property wrapper syntax that makes the next two lines the same is not available:
```
turnout.state
turnout.getState()
```
Some Java super-class methods of a Python class need to be called via e.g.
```
self.__super__.waitMsec(1000)
```
But others dont, and its not clear why.
Referencing Python local variables in a Java-based object requires .this. syntax:
```
m = MyListener()
#
# invoked the listener, which sets 'internalVariable'
#
m.this.internalVariable
```
We can't yet put JMRI symbols into the Python context, so you have to run
```
exec(open("jython/jmri_bindings.py3").read())
```
at the start of each script. This provides definitions for the usual symbols: ON, OFF, ACTIVE, turnouts, sensors etc.
Referencing a class type needs a java.type wrapper:
```
sm = jmri.InstanceManager.getNullableDefault(java.type('jmri.SensorManager'))
```
We've put a helper method in place for that specific case
```
sm = jmri.InstanceManager.getNullableDefault('jmri.SensorManager')
```
but you may need the `java.type('jmri.SensorManager')` syntax in other places.
The debugging support is terrible: Syntax errors generate opaque error messages that dont point to the relevant line in the script.
AbstractAutomaton subclasses occasionally cause the whole of JMRI to stop with a thread deadlock. Not understood why the GraalVM Python interpreter is occasionally taking a lock on the Swing/AWT thread.