I worked at a company where data scientists wrote python code using pandas and we had port it to java and a library called keanu that was very useful but soon became unmaintained.
Of course this was very time consuming and unrewarding, all because only java applications could be deployed to production due to a stupid top-down decision.
This GraalPy sounds like something I wish existed back then.
jep[0] has existed for a while now, and does what GraalPy is doing quite well.
I'm using it for similar purposes as you stated and for that it works quite well. A research group I am collaborating with does a lot of their work in one Java application (ImageJ for microscopy), so by integrating my Python processing code into that application, it finds its way a lot quicker into the daily workflows of everyone in that group.
Most recently I've also extended the jep setup to include optional Python version bootstrapping via uv[1], so that I can be sure that the plugins I'm writing have the correct Python version available, without people having to install that manually on the machine.
Jython has historically lagged hard, often falling behind for very extended periods. For a time their releases basically just stopped, which led to them missing support for pretty much anything between 2.7 and 3.6 (iirc). I know the project basically rebooted at some point, but I've since lost interest.
Besides all the nice answers given by others, a big one was not mentioned: performance!
Graal can do pretty advanced JIT-compilation for any Graal language, plus you can mix-and-match languages (with a big chunk of their ecosystems) and it will actually compile across language boundaries. And we haven’t even mentioned Java’s state of the art GCs that can run circles around any tracing GC, let alone the very low throughput reference counting.
Picture working for a big, non-tech corporation. Your BU only does Java because it has always been thus and Jeff the SVP is a law grad and doesn't want anything to change because of perceived risk. GraalVM allows smart people who have to work within such limitations to still write (mostly) the software they want while still vaguely relating it to Java for decision makers.
Those "smart people" write blackboxes in esoteric languages that only the same person maintains.
Everyone else has to write wrappers to interact with that blackbox. God forbid someone daring to even change the code, because it basically doesn't even need/use junit tests. Eventually the smart person gets bored and moves to something else, that tool then gets rewritten to Java in two days by someone else.
When I was learning programming, my coding class used a Bukkit plugin that connected to Python. I can't remember what it was called, but that was for Minecraft 1.7.10.
Not sure if you were wanting Python specifically, but KubeJS lets you use JavaScript for mods. I think there's also a clojure integration.
Maybe this would be an interesting alternative runtime environment for PySpark? I think currently PySpark runs in Python and somehow interacts with a JVM and relies on copying data from one to the other.
I am assuming - With this, JVMs needing integration with LLMs can embed LLMs in JVM instead of making outbound API calls. If my assumption is right - wouldn't this improve performance of consumer applications?
