You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I gave a shot at embedding JPype in a host JVM. The pattern for this was actually pretty easy. The good news is we already have 95% of the machinery required to make it work, so the delta from a Python host running an embedded Java to a Java host running an embedded Python is actually very small. I also poked at some of the existing embedded solutions such as jep. They are missing some of the finer points of interacting between Java like lifetime control and utf encoding, etc, so moving JPype in this direction will actually be a worthy improvement.
We just need to identify the location of the Python shared library from an external copy of the JPype jar. Then we add a few symbols to the shared library so that Java can successfully name bind. Drop in the routine to start CPython (with a PYTHONHOME set), call the JPype module init and we have an embedded copy of Python to bridge to.
Based on the preliminary work, here are the tasks required to complete it.
Wrap the object protocol in a Java object.
Set up the converse from a raw Python object to Java as a explicit conversion.
Complete a round trip with Python object.
Come up with a scheme to keep the JPype jar separated from the shared library (install scripts and bootloader)
Come up with a scheme to find the embedded info with the dll, (version of CPython, default location of home, name of JPype shared library).
Define a start up routine for the JPype module from within embedded.
Disable functions that do not apply in embedded context (startJVM, shutdownJVM)
Register our ScriptEngine with Java.
Add a test suite for embedded Python from Java.
Several of these tasks were already in the plans, so the delta for this feature is modest. Most of the work is going to be in the bootloader and test suite.
The one big difficulty is that if we are providing both directions to the bridge we end up in a very odd place in terms of our packaging system. When embedding Java we would need to look like a Python package for an installer for Pypi. But if we are providing embedded Python we would be best to look like a maven repo. I don't see how we can accomplish looking like both easily and maven is so picky about how it works in terms of structure it would force reorganization which we really do not want to do.
The text was updated successfully, but these errors were encountered:
I gave a shot at embedding JPype in a host JVM. The pattern for this was actually pretty easy. The good news is we already have 95% of the machinery required to make it work, so the delta from a Python host running an embedded Java to a Java host running an embedded Python is actually very small. I also poked at some of the existing embedded solutions such as jep. They are missing some of the finer points of interacting between Java like lifetime control and utf encoding, etc, so moving JPype in this direction will actually be a worthy improvement.
We just need to identify the location of the Python shared library from an external copy of the JPype jar. Then we add a few symbols to the shared library so that Java can successfully name bind. Drop in the routine to start CPython (with a PYTHONHOME set), call the JPype module init and we have an embedded copy of Python to bridge to.
Based on the preliminary work, here are the tasks required to complete it.
Several of these tasks were already in the plans, so the delta for this feature is modest. Most of the work is going to be in the bootloader and test suite.
The one big difficulty is that if we are providing both directions to the bridge we end up in a very odd place in terms of our packaging system. When embedding Java we would need to look like a Python package for an installer for Pypi. But if we are providing embedded Python we would be best to look like a maven repo. I don't see how we can accomplish looking like both easily and maven is so picky about how it works in terms of structure it would force reorganization which we really do not want to do.
The text was updated successfully, but these errors were encountered: