macOS: Python-to-Java bridge JPype1 (1.2.0) not working (Java problem)

Original problem hint on LaunchPad

from jpype import *
jvm = getDefaultJVMPath()
startJVM(jvm, classpath = '/Users/raimundhocke/IdeaProjects/_SUPPORT/_Latest/2_0_4/sikulixapi-2.0.4.jar')
Screen = JClass('org.sikuli.script.Screen')
s = Screen() # here it hangs trying to get the default Screen object
print(s)

[RaiMan]

@adrian-evo

Excellent work !!! I will have a look into it and will come back, since I am planning, to release a SikuliX version next year, that can be used from Python. JPype is one candidate and py4j the other one.

about the JPype-macOS-SikuliX problem I will dive into the next days. Thanks for your feedback.

[Thrameos]

My general understanding of this issue is that osx has interactions between threads leading to a deadlock between the main and gui threads. This does not occur on linux or windows because they place no restriction on the threading and servicing the GUI. Unfortunately I have no access to an osx machine so I have never been able to replicate it.

Assuming that it can be replicated, the solution I would try is to change the architecture in jpype/native/common/jp_context.cpp such that the the start up creates a separate thread for launching the JVM and the shutdown declares the python main thread as a daemon thread (which makes it so that the Python thread is not longer a hold up for shutdown) and then passes a message to the Java main thread so that the real shutdown can be called. Current JPype and pyjnius are both structured such that the Java and Python share the same main thread which is supposed to result in a deadlock on osx. There was a work around in jpype/_gui.py

def setupGuiEnvironment(cb):
    if _sys.platform == 'darwin':
        from PyObjCTools import AppHelper
        m = {'run': cb}
        proxy = _jproxy.JProxy('java.lang.Runnable', m)
        cbthread = _jclass.JClass("java.lang.Thread")(proxy)
        cbthread.start()
        AppHelper.runConsoleEventLoop()
    else:
        cb()

Unfortunately there is no documentation of how the workaround around was supposed to be used so I can’t give any guidance. My guess is that in this a thread which likely is the main application is launched from within Java (which make it say the Python main is now a sub process, and the actual Python main is now transferred to running the AppHelper event loop. I don’t really like the structure of this fix as for use in interactive shells and such you really want the Python main thread to be free to interact and have the JVM and AppHelper serviced by the separate worker threads.

Alternative jpype/_core.py could be changed create the threads and manage them within the Python (rather than C++). But again until I can replicate the deadlock and be able to resolve the resulting shutdown issues, I am going to be stuck trying to give guidance to others.

Both Python and Java have the magical concept of a main thread. The main thread is the one that services system calls and such. In Java the main thread is the one that was used to call the startup routine and is the only thread that can call a shutdown (without creating a deadlock) as the shutdown waits for all non daemon threads to terminate before proceeding.