https://github.com/moqui/moqui-jep

Moqui-Jep embeds CPython in Java through JNI
https://github.com/moqui/moqui-jep

Last synced: about 1 month ago
JSON representation

Moqui-Jep embeds CPython in Java through JNI

• Host: GitHub
• URL: https://github.com/moqui/moqui-jep
• Owner: moqui
• License: other
• Created: 2026-04-20T18:04:01.000Z (3 months ago)
• Default Branch: master
• Last Pushed: 2026-05-13T21:07:09.000Z (about 2 months ago)
• Last Synced: 2026-05-13T23:12:53.546Z (about 2 months ago)
• Language: Groovy
• Size: 26.4 KB
• Stars: 0
• Watchers: 0
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE.md
  • Authors: AUTHORS

Awesome Lists containing this project

README

          
# Moqui JEP - Java Embedded Python

Jep embeds CPython in Java through JNI.

Moqui tool component that adds Python script execution through Jep.

What this component contains:

- The JepToolFactory

- The PythonScriptRunner

- The PythonServiceRunner

- Python package requirements

- Root Gradle helpers to prepare `runtime/python_venv`

Default behavior:

- Moqui starts even if Python/Jep is not installed

- Python scripts become available only when the venv contains Jep and its native library

- Use `./gradlew moquiJepSetup` to prepare the local Python environment

Typical service definition:

## Concurrency and the GIL

Both `SharedInterpreter` and `SubInterpreter` (in the default `legacy` mode) share the same CPython process and serialize through the Global Interpreter Lock. Concurrent Moqui threads calling Python services will therefore queue at the GIL — which is fine for training, simulation, or batch inference, but becomes a bottleneck under high concurrent HTTP load.

`SubInterpreterOptions.isolated()` (enabled via `-Djep_sub_opts=isolated`, requires Python 3.12+ with experimental per-interpreter GIL) can eventually lift this constraint, but it is still experimental upstream. Select the interpreter mode with the `-Djep_sandboxed_interpreter=true` system property (default: `false`, i.e. `SharedInterpreter`).

For latency-sensitive concurrent inference workloads, consider delegating to an out-of-process runtime (ONNX Runtime, TorchServe, Triton) and calling it from a standard Moqui service rather than routing through moqui-jep.

## Examples and tests:

- `src/test/groovy/JepServiceTests.groovy` covers Moqui service/script integration

- `src/test/groovy/JepDocsExamplesTests.groovy` contains small examples inspired by the Jep wiki:

  - How Jep Works

  - Numpy Usage

  - Interactive Console

- Run them with `./gradlew :runtime:component:moqui-jep:test`