[Java] CUDA 13 support

[jameslamb]

Description

CUDA 13 support is rolling out across RAPIDS libraries: https://github.com/rapidsai/build-planning/issues/208

The first pass at that only added that support in devcontainers, C++, conda packages, and wheels (#1273).

This issue tracks work to add CUDA 13 support for the cuvs-java Java packages.

Benefits of this work

• allows cuVS Java users to get the latest improvements in CUDA

Acceptance Criteria

• cuvs-java can be used with CUDA 13

Approach

Decide on and document a CUDA support strategy for Java packages here.

For example, there is a package published under the name cuvs-java at https://mvnrepository.com/artifact/com.nvidia.cuvs/cuvs-java. Answer some of these:

• should that only ever support a single major CUDA version?
• is there a mechanism like the cuda-version on conda-forge (docs) that could be used to differentiate between builds targeting different CUDA versions?
• should suffixed packages like cuvs-java-cu13 be published?

Implement any docs, build, packaging, testing, etc. changes required.

Notes

Some initial building and testing was set up in https://github.com/rapidsai/cuvs/pull/1273

[cjnolet]

cc @mythrocks @benfred @ChrisHegarty @ldematte @chatman @narangvivek10

[ldematte]

We need to run extensive tests on this, but cuvs-java should be largely independent from CUDA versions, as it mostly calls libcuvs functions (not CUDA functions directly). Also, the mechanism Java uses to bind to functions is "late" and based on symbols, so as long as there is not a difference in function signatures, it won't matter which CUDA version we are using. https://github.com/rapidsai/cuvs/pull/1323 is covering the one case we found; with that merged, cuvs-java should be usable with both CUDA 12 and 13 with no changes. If we spot other differences, we should address them in a similar way, there is no need for a prefixed package like cuvs-java-cu13 IMO.

[ldematte]

run extensive tests

CI tests on both CUDA 12 and CUDA 13 (with the matching CUDA version) would be fine.

there is no need for a prefixed package like cuvs-java-cu13

I stand corrected: the slim-jar will be CUDA independent; the fat-jar will need 2 versions, as it embeds the native dependecies (like libcuvs but also librmm), which are definitely version dependent. I think most of it (all of it?) has been already been covered in #1296 though

[mythrocks]

I think most of it (all of it?) has been already been covered in https://github.com/rapidsai/cuvs/pull/1296 though...

That is accurate; I've covered this for the most part in #1296.

When cuvs-java is built using the docker-build, by default, the fat-jar artifacts are built with CUDA Toolkit v12.9.1. It can, however, be built with CUDA Toolkit v13.0.0, as documented in thedocker-build README:

CUDA_VERSION=13.0.0 JNI_DOCKER_DEV_BUILD=ON ./build-in-docker

This will produce either cuvs-java-25.10.0-x86_64-cuda12.jar or cuvs-java-25.10.0-x86_64-cuda13.jar, depending on the CTK version. As @ldematte points out, the thin jar remains independent of CUDA version.

Note: This build hasn't been integrated into the CI processes yet. One sticking point is that the docker build happens via a separate Dockerfile, while the CI processes use their own Docker environment. These will need merging, to avoid a docker-in-docker situation.

[mythrocks]

Just a heads up here, tangentially related to CUDA 13: With CUDA 13, there might be a re-ordering where of CUDA symbols are made available by jextract in Java: headers_h vs header_h_1.

If this occurs again, there might be value in investigating if jextract can place the CUDA-functions in a separate, deterministic class.