Java bindings for LP, MIP and QP, built as hand-written JNI over the public C API, with build and CI integration. Contributes to #1535 and #860. The API is deliberately small. Following review, it covers building a problem, solving it, and reading the result — nothing beyond that. Anything further can be added later with a case for it. ## API `Problem` builds and solves; `Variable` and `Constraint` carry the model and the values from the last solve; `SolverSettings` configures the solver; `Solution` reports the outcome. ```java try (Problem problem = new Problem("burglar")) { Variable x = problem.addVariable(0.0, 1.0, 15.0, VariableType.INTEGER, "take_item_0"); Variable y = problem.addVariable(0.0, 1.0, 100.0, VariableType.INTEGER, "take_item_1"); problem.addConstraint(LinearExpression.of(x, 2).plus(y, 20).le(102.0), "capacity"); problem.setObjective(LinearExpression.of(x, 15).plus(y, 100), ObjectiveSense.MAXIMIZE); try (SolverSettings settings = new SolverSettings().setSetting(CuOptConstants.CUOPT_TIME_LIMIT, 10.0); Solution solution = problem.solve(settings)) { System.out.println(solution.getTerminationStatus()); System.out.println(x.getValue()); } } ``` Solution values are read from the model — `Variable.getValue`, `Variable.getReducedCost`, `Constraint.getDualValue`, `Constraint.getSlack` — rather than as bulk arrays. Solver statistics are read as scalar solution attributes, keyed by a `CuOptConstants.CUOPT_SOLUTION_ATTR_*` value: ```java double gap = solution.getFloatAttribute(CuOptConstants.CUOPT_SOLUTION_ATTR_LP_GAP); int nodes = solution.getIntAttribute(CuOptConstants.CUOPT_SOLUTION_ATTR_MIP_NUM_NODES); ``` This mirrors the problem attribute accessors. Because the selectors are generated into `CuOptConstants` from `constants.h`, a statistic added later is a new constant rather than new Java. A selector that does not apply to the solution, or that does not have the requested value type, raises `CuOptException`. ## Build integration `java` is an opt-in target of the top-level `build.sh`: ```bash ./build.sh libcuopt # once ./build.sh java # build libcuopt_jni.so and package the jar ./build.sh java --run-java-tests # the same, then run the suite ``` It prefers the `cpp/build` tree so it works without `--install`, and falls back to the conda prefix, which is what CI uses. `ci/build_java.sh` calls `build.sh` rather than duplicating the invocation. The rmm and raft headers must be the ones `libcuopt` was compiled against — rmm carries its version in an inline namespace, so a mismatched copy links cleanly and then fails at `dlopen`. `build.sh` passes the right include and library paths when it targets a build tree. ## CI | Workflow | Job | Runner | Script | |---|---|---|---| | `pr.yaml` | `java-build` | `gpu-l4-latest-1` | `ci/test_java.sh` | | `build.yaml` | `java-build` | `cpu4` | `ci/build_java.sh` | | `test.yaml` | `conda-java-tests` | `gpu-l4-latest-1` | `ci/test_java.sh` | All three are in their workflow's aggregator job, so a Java failure fails the PR. The PR job is gated on the `test_java` changed-files group (`java/**`, `ci/build_java.sh`, `ci/test_java.sh`) and on `test_cpp`, so a C++ change that could break the bindings still exercises them. `target/` is uploaded as the `cuopt-java` artifact. The `java` dependency file-key pulls `libcuopt` plus the `libraft-headers`, `librmm` and `rapids-logger` headers that `libcuopt`'s public headers include transitively. `ci/release/update-version.sh` bumps the POM through a sentinel comment; the artifact version drops the zero-padded RAPIDS patch field, since Maven has no notion of it. ## JNI symbol check The bindings are hand-written, so a `static native` declaration and its entry point can drift apart. JNI resolves lazily, so the library still loads and the failure appears only when something calls the method. `scripts/check_jni_symbols.sh` diffs the prototypes `javac -h` derives from the Java sources against the symbols the built library exports, and fails on a mismatch either way. It reads the built artifact rather than parsing source, so the macro-generated entry points need no special casing. `build_native.sh` runs it after every native build, which covers `./build.sh java` and both CI jobs. It takes about a second. ## Packaging Version `26.10.0`. Sources and javadoc jars are attached, and the POM carries the `url`, `licenses`, `scm` and `developers` metadata Maven Central requires. Signing and upload are not wired up; that is tracked by the "Publishing & support" item in #1535. ## Known gap `cuopt_jni.cpp` still includes `pdlp/cuopt_c_internal.hpp` for parts of the problem path the C API does not cover — setting names, the quadratic objective and quadratic constraint getters, and the problem category. That couples `libcuopt_jni.so` to a specific `libcuopt` build rather than to a stable ABI, which matters before this ships as a binary artifact. Tracked in #1703. The related copy-out behaviour was #1706, fixed by #1734 and now in `main`. Authors: - Christopher Brissette (https://github.com/nvidiacbrissette) - Ramakrishna Prabhu (https://github.com/ramakrishnap-nv) Approvers: - Miles Lubin (https://github.com/mlubin) - Trevor McKay (https://github.com/tmckayus) - Chris Maes (https://github.com/chris-maes) - Cindy Wilkinson (https://github.com/cwilkinson76) URL: #1524

Java API support #1535

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions