Repository navigation
JVM, .NET Language Support #3
Description
Activity
Since raw performance is one of the goals of this library I think that pure implementations don't make too much sense.
A prettier API on top of the generated interfaces would be nice though.Although we may not pursue this ourselves, the internal formats used for communication (
GraphDef, etc.) are all platform independent protobuf. Thus, it is possible to implement all or part of the tensorflow API in Java while preserving communication compatibility with the existing code. Since a Java version would likely be slower, one useful bit would be a pure inference layer that evaluates graphs but isn't necessarily able to build them; this would allow graphs built in Python and trained in Python / C++ on GPUs to be run from Java servers.Reacted by Jean-Charles and Ankur SethiIs there a canonical / repeatable test suite, so language bindings can have a target and level of confidence? Is there a build server? Could there be a build server?
There's a testsuite with fairly good converge, but currently it's mostly Python with a few C++ tests. There's also a lot of functionality for building graphs that's currently Python only, in particular the automatic differentiation functionality, though that doesn't matter for evaluation of graphs in Java. There are plans to move this functionality into the underlying C++ in future, at which point Java SWIG bindings would be more useful for creating graphs.
If someone takes up the Java SWIG challenge, we'd be happy to accept it upstream pending review, etc., at which point it would be part of our continuous testing. The details of accepting contributions is in flux at the moment, but that will stabilize.
Also perhaps https://github.com/bytedeco/javacpp can be used to generate bindings.
If you search for
RegisterGradientin the python directory, you'll see all the places we define the gradients of various ops. The gradients are defined by Python code, so they aren't available from pure C++ as yet (we hope to change this at some point).I don't fully grasp the architecture/order of operations, but could one populate the gradients using python, while still calling into the C++ code via a bridge?
Alternatively: Run the python code once to generate the gradients for every op, serialize all those gradients to a file, and then other runtimes can read them off and register them?
Both of those might work, but I don't know how much of a savings they are compared to doing it the right way and porting the code to C++.
I fully agree, just sounding out a temporary solution so I'm not blocked (I imagine it might be a while before all that code is ported)
+1 for Java
- added a commit that references this issue
on Mar 9, 2016 121 remaining items
- added a commit that references this issue
on Jul 29, 2025 - added a commit that references this issue
on Nov 26, 2025 - added 9 commits that reference this issue
on Jan 22, 2026 - added a commit that references this issue
on Aug 15, 2026 - added a commit that references this issue
on Sep 29, 2026
Your website says "... contribute SWIG interfaces to your favorite language ...". It will be good if yo have pure implementations in other languages like JVM and .NET without having to use SWIG.