powerful repo ! could you test cpp libtorch package generate for java /scala

[mullerhai]

Hi,
now we just looking for cpp library binding with java ,I think this project could do some, if javabind could generate code from cpp libtorch demo for java, it will be popular for java and scala

muller

[hunyadi]

Can you share some additional context (e.g. links to projects and/or documentation, example code) how you intend to use LibTorch, C++ and Java together?

[mullerhai]

Can you share some additional context (e.g. links to projects and/or documentation, example code) how you intend to use LibTorch, C++ and Java together?

because jvm need deeplearning tools ,and need some deeplearning tools suit with bigdata like spark flink.
do you know javacpp , they have made one pytorch jvm binding https://github.com/bytedeco/javacpp-presets/tree/master/pytorch,
so many powerful cpp tools cannot suit in jvm ,
do you know deepseek new open source project flash-mla, they use cpp as backend and use pybind11 generate python api ,so I think if we have javabind cpp like this could be more powerful

the open3d https://github.com/isl-org/Open3D is also power for slam , we need in java with big data ,but the open3d contributer tell me they not want to do anymore to support for jvm

[hunyadi]

What I don't quite grasp is the specific features you are after in javabind. If you have a C++ library such as LibTorch, and you write a small library in C++ that implements some functionality on top of LibTorch, you can expose this to Java (JVM) via JNI with javabind even today. While the sample code puts straightforward operations in C++ function bodies such as adding two numbers, nothing prevents you from adding complex functionality such as invoking a complex ML model in LibTorch.

However, if you are looking for a wrapper generator that exposes ALL features of LibTorch (or another library) to Java, javabind is likely not for you. Instead, I would expect library developers to expose a JNI API like they do with their Python API. I understand they might not be interested but I believe it would still be the right place to implement this to ensure that the library and its Java interface evolve together.