TensorFlow Java now releases on its own, and its platform list keeps shrinking

The bindings left the main TensorFlow repository

The repository describes itself simply as Java bindings for TensorFlow, and the README opens with TensorFlow can run on any JVM for building, training and running machine learning models.

The organisational change is the part worth knowing. The README explains that in the early days the Java language bindings were hosted in the main TensorFlow repository and released only when a new version of the core library was ready to be distributed, which happens only a few times a year. Now all Java related code has been moved to this repository so that it can evolve and be released independently of official TensorFlow releases.

That is a straightforward decoupling with real consequences for a user. A JVM team no longer waits for a core release to get a binding fix, and the Java versioning is its own line, with v1.0.0, v1.1.0 and v1.2.0 published as TensorFlow Java releases.

The build tooling moved with it. Most of the build tasks have been migrated from Bazel to Maven, which the README calls more familiar for most Java developers. The repository root confirms that with pom.xml, .mvn/ and the per-artifact directories, alongside RELEASE.md, MIGRATING.md and CONTRIBUTING.md.

The licence field on the repository says Apache-2.0, so it is permissive, with the usual attribution and patent terms.

Three artifacts aimed at three different audiences

The README describes the repository layout as three artifacts, and the split is by intended audience rather than by feature.

tensorflow-core holds all the artifacts that build up the core language bindings. Its stated audience is projects that provide their own APIs or frameworks on top of TensorFlow and just want a thin layer to access the TensorFlow native library from the JVM. If you are wrapping the library in your own abstraction, this is the only piece you need.

tensorflow-framework is the primary API for building and training neural networks with TensorFlow, aimed at neural network developers, with its own README for detail. This is the layer that turns a saved model into something you can train, evaluate and serve.

tensorflow-ndarray is an API for creating and manipulating n-dimensional arrays, and the README makes the point that it can be used independently from TensorFlow. That is the piece to reach for if all you need is a tensor library in Java.

The layering means you can start at the ndarray level and move up to framework and core as required, or stop at core if you are wrapping the native library yourself. What the README does not spell out is which parts of tensorflow-framework depend on which parts of tensorflow-core, so the practical dependency audit is a look at the poms rather than a decision you can make from the README alone.

Four platform classifiers ship, and two have been dropped

While TensorFlow Java can be compiled for multiple platforms, the README is explicit about which binaries are supported and distributed by the project.

There are four. linux-x86_64 covers Linux platforms on Intel and AMD chips, linux-x86_64-gpu is the same with Cuda GPU support, linux-arm64 covers Linux on Arm chips, and macosx-arm64 covers MacOS X on Apple Silicon chips.

Two more exist historically and are worth knowing about because they are easy to find in older examples. Binaries for macosx-x86_64 were available for TF-Java 1.0 series releases and earlier, and were dropped from TF-Java 1.1 and newer as they are no longer supported or released by Google. Binaries for windows-x86_64 are available for TF-Java 1.1 and earlier, and were dropped for the 1.2 release and newer for the same reason.

So the support matrix is shrinking in a specific direction. Intel Macs lost their binaries at 1.1, and Windows lost them at 1.2. A project that upgrades the TF-Java version and still targets Windows x86_64 or Intel macOS breaks at deployment rather than at build, because the classifier resolves to an artifact that no longer exists.

The four remaining classifiers are also the practical limit on what you can put in one application, which is the subject of the next section.

Only one native dependency per platform may be declared

The individual dependency route needs tensorflow-core-api plus one or more tensorflow-core-native dependencies with a platform classifier. The README prefers this option because it minimizes the size of the application by including only the TensorFlow builds you need, at the cost of being more restrictive.

For a Linux CPU only deployment, the Maven coordinates are short.

<dependency>
  <groupId>org.tensorflow</groupId>
  <artifactId>tensorflow-core-api</artifactId>
  <version>1.2.0</version>
</dependency>
<dependency>
  <groupId>org.tensorflow</groupId>
  <artifactId>tensorflow-core-native</artifactId>
  <version>1.2.0</version>
  <classifier>linux-x86_64</classifier>
</dependency>

The Gradle equivalent sets a version variable and adds the classifier to the notation.

def tfVersion = '1.2.0'
implementation "org.tensorflow:tensorflow-core-api:$tfVersion"
implementation "org.tensorflow:tensorflow-core-native:$tfVersion:linux-x86_64"

The restriction worth internalising is stated as a rule: only one dependency can be added per platform, meaning that you cannot add native dependencies to both linux-x86_64 and linux-x86_64-gpu within the same project. The CPU build and the CUDA build of the same platform are mutually exclusive in one dependency tree.

That is a sensible constraint on size, since both natives contain the same TensorFlow library compiled twice, and it forces a decision: one artifact for every environment, with the GPU build as the only option that can serve both, or separate builds for GPU and CPU hosts.

tensorflow-core-platform is the alternative, with a size warning

For deployments that span platforms, the README describes a single dependency option that pulls in all the required artefacts transitively.

The artifact is tensorflow-core-platform, and it includes tensorflow-core-api plus native artifacts for linux-x86_64, linux-arm64 and macosx-arm64. Note what is not in that list: the GPU classifier.

<dependency>
  <groupId>org.tensorflow</groupId>
  <artifactId>tensorflow-core-platform</artifactId>
  <version>1.2.0</version>
</dependency>

Or in Gradle.

implementation "org.tensorflow:tensorflow-core-platform:1.2.0"

The README's stated use case is running TensorFlow Java on any CPU platform for which a binary is distributed by the project.

The warning is explicit: the builds of TensorFlow are quite voluminous, and including too many native dependencies may significantly increase the size of your application, so it is good practice to limit dependencies to the platforms you are targeting.

That is the whole trade-off in one paragraph. The single dependency removes the per-platform declarations and the mutual exclusion problem between the CPU and GPU classifiers of one platform, at the price of shipping native binaries for platforms your users may never touch. For a containerised service with one deployment target, the individual route is smaller; for a jar handed to several teams, the platform artifact is simpler.

GPU use means installing the driver, CUDA Toolkit and cuDNN yourself

The native binary is not the whole of a GPU setup, and the README says so plainly: to use an NVIDIA GPU you need to install the NVIDIA device driver, the CUDA Toolkit and cuDNN.

For Ubuntu 24.04 it gives the command.

sudo apt install -y nvidia-driver-550 nvidia-cuda-toolkit nvidia-cudnn

Those are three separate installation obligations on every machine that runs the service, including containers where the host driver has to be visible to the image. This is where the deployment story gets heavier than the dependency list suggests: the classifier tells the JVM which native library to load, and the operating system still has to provide a working CUDA stack for that library to talk to.

The same weight applies to the CPU path in a different form. The native binaries are large, so an application that carries several of them, or the whole platform artifact, ships a lot of bytes for a machine that needs one of them.

The troubleshooting section of the README is truncated in the text available here, so the guidance on native library loading paths and the JNI options is not visible, and that is the part you will want when the class fails to load on a machine you did not configure yourself.

Maintained by the JVM SIG, with a release roughly every year

The repository is maintained by the TensorFlow JVM Special Interest Group, and the README explains how to reach them: by posting to the TensorFlow Forum with the sig_jvm tag, by writing on the sig-jvm Gitter channel, or simply by sending pull requests and raising issues to the repository.

The release history shows three tags. TensorFlow Java 1.0.0 was published on 2024-12-06, 1.1.0 on 2025-06-29 and 1.2.0 on 2026-07-24. The repository is not archived and the last push was on 2026-07-24, the same day as the 1.2.0 tag.

So the Java line moves at roughly one release a year, which is a very different rhythm from the core TensorFlow library the README describes as being released a few times a year. That difference was the entire point of moving the code out, and the tag list confirms it works.

Two documents in the repository root are worth a look before you upgrade. MIGRATING.md exists for people moving between versions, and RELEASE.md documents the release process. Given that 1.1 and 1.2 each dropped a platform classifier, the migration notes are where you will find out what changed for your deployment target.

The licence is Apache-2.0, the kind of licence that makes it comfortable to embed the bindings in a commercial Java product, and the maintenance arrangement through a special interest group is the kind of governance that tends to keep a niche binding alive after the enthusiasm of its author has gone.

Editorial conclusion

TensorFlow Java suits an enterprise JVM team that needs to run a trained model inside an existing Java, Scala or Kotlin service without shipping a Python sidecar, and the independent release train means a Java fix no longer waits for a core TensorFlow release. It does not suit a team that deploys to Windows x86_64, because those binaries were dropped for version 1.2, or one that needs both CPU and GPU natives in a single artifact. Before you pick a version, check the classifier list against your deployment targets, and note that a GPU deployment adds the NVIDIA driver, CUDA Toolkit and cuDNN as separate installation obligations.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tensorflow/java on GitHub