Laya can now run inside Java and Kotlin apps
Inference runs without Python. Setup still requires a source build and model export.
Java and Kotlin developers can now run Laya decisions inside their applications without keeping a Python process running. The October 4 release adds a Java runtime that uses ONNX Runtime for inference.
Getting started still takes some setup. The documentation for version 0.3.27 requires JDK 17 or newer, a local source build and a Python step to export the model. It does not provide a published Maven Central package.
Choosing an option inside an existing service
The runtime returns a selected option, a score or a probability that a statement is true. It includes tokenization, input preparation and answer decoding. Batch prediction processes multiple inputs while returning results in their original order. Developers can set a batch size to limit memory use.
Consider a support service already written in Java. Its developers could evaluate which queue should receive a ticket inside that service, then keep their existing rules for sending it onward. That may simplify deployment, but the team still owns model loading, resource use and the consequences of a wrong assignment.
Usage information exposes input truncation, including which questions lost part of the supplied text. The documentation also warns that its two confidence measures have different meanings. They should not share an acceptance threshold, and the supplied checkpoints can be overconfident.
How the Java results are checked
The contribution behind the release includes reference fixtures generated from the Python implementation. Automated comparisons are designed to reveal when the Java results drift from that reference. Tests requiring model files must report missing coverage rather than quietly passing. These are project testing claims, not tests reproduced by ByteForward.
The maintainer accepted the Java checks as advisory. A failure can identify work needed in the port without blocking a Python change. The maintainer also says the Java code has not received the same depth of review as the core Python implementation.
The documentation records small numerical differences caused by the runtimes using different precision for probability calculations. Matching a reference on selected examples should therefore be read within the stated tolerances and test coverage.
Which Python features are still missing
The accepted Java contribution leaves out hooks, the language router, long prediction, shortlist support and the structured decision API. The HTTP client module and Android support are also unfinished. Teams relying on those capabilities need to evaluate the narrower Java surface before planning a migration.
A separate .NET port entered the previous release on October 3. Its proposal had been public since September 28. That source contribution also arrived without a consumable NuGet package, a useful reminder to check distribution separately from a repository merge.
Try ticket routing without changing live decisions
For a first trial, keep the current ticket routing path and record what the Java implementation would have chosen. Include long tickets and closely worded options. Compare its results with the existing system and inspect discarded input before allowing the model to change a destination.
A team whose service already runs on the JVM has a concrete reason to try this release. The question is whether bringing inference into that service is worth the build work and resource use. Keep the existing routing rules until the results on real tickets justify changing them.
Illustrative programming photograph by Mohammad Rahmani from December 2024 under the Unsplash License. The screen shows Dart and Flutter code, not Laya or Java. Source supplied image unchanged. No endorsement is implied.
