JPMML-Evaluator: scoring PMML models in a JVM without reimplementing the maths

One model file that travels from R, Python and Spark into the JVM

JPMML-Evaluator solves a specific deployment problem: a model was trained somewhere else, and now it has to run inside a Java application. Predictive Model Markup Language is the interchange format that makes that possible, a document describing the data dictionary, the mining schema, the model itself and the post-processing rules. The library's job is to take that document and execute it.

The README describes the project as the de facto reference implementation of the PMML specification versions 3.0, 3.1, 3.2, 4.0, 4.1, 4.2, 4.3 and 4.4 for the Java and JVM platform. That range is the practical headline. A model exported in an older PMML version, or exported by a tool that emits an older version, can be scored by the same code path as a current one.

The audience is Java developers building services around models, and the interoperability list in the README shows where the models come from. There are libraries for R and Rattle, for Python and Scikit-Learn, for Apache Spark, for H2O.ai, for XGBoost, for LightGBM and for TensorFlow, alongside tools such as KNIME, RapidMiner, SAS and SPSS. In each case the pattern is the same: the model is converted to PMML, and this evaluator scores it.

One performance claim appears in the README, and it is worth quoting precisely because it is specific about the hardware class: the library can deliver one million scorings per second already on a desktop computer. Whether that holds for your model depends on the model, and the README does not publish a benchmark method, so treat it as an order of magnitude rather than a promise.

Pre-processing, evaluation and post-processing all come from the document

The mechanism that makes the library more than a prediction function is that the whole pipeline is driven by the PMML document rather than by configuration in your code. The README splits this into three stages.

Pre-processing follows the DataDictionary and MiningSchema elements. That means the complete data type system and the complete operational type system are applied, including treatment of outlier, missing and invalid values. This is the part that quietly causes the most integration bugs in other stacks, where a null arrives at a model and has to be handled by whatever convention the training tool happened to use. Here the rule travels with the model.

Evaluation covers a long list of model families: association rules, cluster model, general regression, Naive Bayes, k-nearest neighbors, neural network, regression, rule set, scorecard, support vector machine, tree model and ensemble model. Each is linked in the README to the corresponding PMML element, so the supported surface is defined by the standard rather than by convenience.

Post-processing follows the Targets element: rescaling or casting regression results, replacing a missing regression result with the default value, and replacing a missing classification result with the map of prior probabilities. Auxiliary output fields are computed according to the Output element, with over twenty different result feature types. On top of that, the library performs model verification according to the ModelVerification element, so a document can be checked against its own declared expectations rather than failing silently at scoring time.

The vendor extensions are what make it more than a strict reading of the standard. The README lists memory and security sandboxing, Java-backed model, expression and predicate types that let you integrate a third party Java library into the PMML data flow, and MathML prediction reports. A sandboxed evaluation of a model file is a meaningful property when the file did not come from your own team.

Maven coordinates, a runtime component and Java 11

Installation is through Maven Central, and the JAR files are released there together with Java source and Javadoc JAR files. The README states the prerequisite plainly: Java 11 or newer. The current version given in the documentation is 1.7.8, dated 11 October 2026.

The one thing to get right is which artifact to depend on. The main component is org.jpmml:pmml-evaluator, but the README explains that in most application scenarios you do not include that directly. You include a data format specific runtime component, org.jpmml:pmml-evaluator-${runtime}, which handles the loading and storage of PMML class model objects. The recommended format for PMML documents is XML, with the recommended implementation being Jakarta XML Binding through the Glassfish Metro JAXB runtime:

<dependency>
	<groupId>org.jpmml</groupId>
	<artifactId>pmml-evaluator-metro</artifactId>
	<version>1.7.8</version>
</dependency>

That single dependency is the whole installation for an XML based service. The alternative runtime components cover the other formats, and the README tabulates them: pmml-evaluator-jackson for JSON, YAML and TOML through the FasterXML Jackson suite, pmml-evaluator-kryo for Kryo serialization, pmml-evaluator-moxy for JSON and XML through the EclipseLink MOXy JAXB runtime, and pmml-evaluator itself for Java serialization.

The separation is the design point worth understanding. The core artifact holds the model execution logic, and the runtime artifact holds the parsing and storage. That means choosing Metro versus Jackson is a deployment decision about how your PMML documents arrive, not a change to the model semantics.

For a first use, the practical sequence is: add the runtime dependency above, place a PMML file on the classpath or read it from disk, build an evaluator from it, and call the evaluation method with a map of input fields. The README's API section names the entry points: the EvaluatorBuilder interface, the ModelEvaluatorBuilder class for building from a PMML instance, the LoadingModelEvaluatorBuilder for building from a PMML byte stream or file, and the ServiceLoadingModelEvaluatorBuilder for building from a PMML service provider JAR.

Staying inside the training tool instead of converting to PMML

The real alternative to this library is not another Java scoring library. It is not converting at all, and keeping the model inside the tool that trained it.

That is a genuine option, because the README's interoperability list is also a list of places where the model already runs. The JPMML-R library and the r2pmml, pmml and pmmlTransformations packages work from R, the JPMML-SkLearn library and sklearn2pmml package work from Python, and the JPMML-SparkML library with pyspark2pmml and sparklyr2pmml work from Apache Spark, including through the mllib.pmml.PMMLExportable interface. If your service is a Python service or a Spark job, the model can be scored by the framework you already have, and PMML is not involved.

The difference in approach is where the semantics live. A native scoring path keeps the model's behaviour tied to the library that trained it, and any preprocessing convention is that library's. The PMML route moves the rules into the document, so the same artifact can be scored by a JVM service that has never seen the training tool, and so pre-processing, missing value handling and post-processing come from the file rather than from the training environment's defaults.

The trade-off runs the other way as well. Converting to PMML is a step that can fail, and the failure is often visible only as a scoring difference rather than as an error, which is exactly why the ModelVerification support in this library matters. PMML also constrains what can be expressed. The Java-backed model, expression and predicate types listed as vendor extensions exist because the standard cannot express every third party library call, so a model that depends on exotic behaviour may only be scoreable in its original toolchain.

The decision therefore comes down to where the model has to run. If it has to run in a Java service, PMML plus this evaluator is the route the ecosystem is built for. If the model can stay where it was trained, conversion is an extra risk you can decline to take.

Where the evaluator does not reach, and what AGPL means for a service

Three limits deserve plain statement.

The first is the platform. This is a Java Evaluator API, it needs a JVM, and it needs Java 11 or newer. There is no path from this library to a Python process, a Go binary or a browser, short of running a Java service beside them. A team with no JVM anywhere in its stack should not be considering it.

The second is the model coverage, and it is narrower than the PMML specification's full surface. The supported model families are enumerated in the README and the list is finite, so a model relying on a construct outside that list will not be scoreable. The features.md file is referenced for more detail on what the implementation covers, and the README does not document what happens when a document contains an element the evaluator does not implement, so the failure mode is worth checking for yourself with the specific documents you intend to load.

The third is licensing, and it is the one most likely to cause a problem. The licence field on the repository says AGPL-3.0. A library under that licence carries network use obligations, which for a service that scores models for remote clients is a different question from a permissive dependency. This review is not giving legal advice and cannot tell you what the obligations mean for your deployment. What you can do is read LICENSE.txt and NOTICE.txt in the repository root, both of which are present in the tree, and settle the question with your own counsel before the library is wired into a service you distribute.

On maintenance, the picture is healthy. The repository is not archived, the last push was on 2026-10-11, and release 1.7.8 carries the same date. Before it, 1.7.7 was released on 2026-02-01 and 1.7.6 on 2025-11-28, so the project ships on a cadence of a few releases a year rather than continuously. That is worth knowing for an upgrade policy: the model format will keep moving in the training tools, but the evaluator moves in measured steps.

Editorial conclusion

JPMML-Evaluator is the right choice for a Java or JVM service that has to score PMML models from several training tools, since the pre-processing, model and post-processing rules come from the model file rather than from your code, and the runtime component keeps the parsing layer out of the core artifact. It is the wrong choice for a Python or R service with no JVM in the stack, and it is a serious consideration for any deployment where AGPL-3.0 terms, as stated in the repository licence field, conflict with how you distribute the service. Before you adopt it, read the LICENSE.txt and NOTICE.txt in the repository root, check that the model you need loads under the ModelVerification checks, and pin the pmml-evaluator component version to 1.7.8 rather than tracking the release cadence.

Frequently asked questions

Official sources

1. Issues
2. jpmml/jpmml-evaluator on GitHub
3. License: AGPL-3.0
4. README
5. Releases