Deeplearning4j: a JVM deep learning stack, from ND4J to SameDiff

What Deeplearning4j solves for JVM teams

Most deep learning tooling assumes Python. A Java service that needs a neural network therefore ends up either calling out to a Python process or shipping a model to a separate inference server. Deeplearning4j removes that boundary. The README describes the ecosystem as "a set of projects intended to support all the needs of a JVM based deep learning application", starting from raw data and ending at a tuned network. The audience is specific: teams whose application is already written in Java, Scala, Kotlin or Clojure, and who would rather keep the model in the same process and the same build than run a second runtime. The README notes that because it runs on the JVM, those other JVM languages are supported too. That is the whole pitch, and it is a narrow one. If your team is Python-first, nothing here is aimed at you.

The stack: DL4J, ND4J, LibND4J and SameDiff

The architecture is layered, and understanding the layers matters more than understanding the API surface. At the bottom sits LibND4J, a C++ library that the README calls "the C++ library that underpins everything"; the JVM reaches native arrays and operations through JavaCPP. Above it is ND4J, a general purpose linear algebra library with over 500 mathematical, linear algebra and deep learning operations, with CPU acceleration through OpenBLAS and OneDNN and GPU acceleration through cuDNN and cuBLAS. DL4J is the high level API for building MultiLayerNetworks and ComputationGraphs, and it supports distributed training on Apache Spark. SameDiff lives inside ND4J and is the autodiff framework, using a graph-based define-then-run approach that the README compares to TensorFlow graph mode. DataVec handles ETL across HDFS, Spark, images, video, audio, CSV and Excel. Python4J bundles cpython execution for the JVM. The practical consequence of this layout is that the native library is not optional: your deployment artifact carries platform-specific binaries, which is why the README says the project "only supports usage with a build tool".

Installing Deeplearning4j with Maven and running a first model

There is no installer and no CLI. The README gives the Maven coordinates directly, and they are the only supported route because of the dependency count. Add both artifacts to pom.xml: deeplearning4j-core for the network API and nd4j-native-platform for the CPU backend.

<dependencies>
  <dependency>
      <groupId>org.eclipse.deeplearning4j</groupId>
      <artifactId>deeplearning4j-core</artifactId>
      <version>1.0.0-M2.1</version>
  </dependency>
  <dependency>
      <groupId>org.eclipse.deeplearning4j</groupId>
      <artifactId>nd4j-native-platform</artifactId>
      <version>1.0.0-M2.1</version>
  </dependency>
</dependencies>

After a Maven reload you should see the DL4J and ND4J jars resolved along with their native dependencies. The README points to a full standalone project in the eclipse/deeplearning4j-examples repository if you would rather start from a working skeleton than from an empty pom. For GPU work the README does not print a CUDA snippet; it points to the build-from-source guide, and the platform-tests module documents a backend.artifactId property that defaults to nd4j-native and can be set to something like nd4j-cuda-11.6. Treat that as the naming pattern for the GPU artifact rather than a copy-paste instruction, because the README does not give the matching dependency block. Once the dependencies resolve, the README's own guidance is to work from the examples repository rather than from a tutorial in the README, since the project is a monorepo with several modules and no single quickstart.

Model import is the strongest reason to pick it

Training in Java is one thing; consuming a model that was trained elsewhere is another, and this is where DL4J is unusually concrete. The README states that DL4J supports importing Keras models from h5, including tf.keras models as of 1.0.0-beta7, and that SameDiff supports importing TensorFlow frozen model format .pb models. The examples repository has dedicated directories for ONNX import and for TensorFlow/Keras import, which tells you the project treats import as a first class workflow rather than a demo. The limits are stated just as clearly: import for ONNX, TensorFlow SavedModel and Keras models into SameDiff is listed as planned. So the split is real. Keras h5 and frozen .pb are the paths the README commits to; SavedModel and ONNX-into-SameDiff are not. If your pipeline produces a SavedModel directory, check the examples repository before you assume it will load.

Where Deeplearning4j is the wrong choice

The README is candid about execution model, and that candour is the main limitation. SameDiff uses a define-then-run graph approach; eager graph execution in the style of TensorFlow 2.x or PyTorch is described as planned, not present. If your workflow depends on stepping through operations as they execute, or on a debugger that inspects intermediate tensors interactively, this stack will feel stiff. The second constraint is the build-tool requirement. Because there are many dependencies and native binaries, there is no supported way to drop a jar on a classpath and go, which complicates environments that do not use Maven or Gradle. The third is platform coverage in the details rather than the headline: the README lists CUDA 10.0, 10.1 and 10.2 support with the explicit exception of macOS, so an Apple machine with an NVIDIA eGPU is not a supported GPU target. The fourth is versioning. The README's own snippet pins 1.0.0-M2.1 while the platform-tests module defaults to 1.0.0-SNAPSHOT, which is a reminder that milestone releases and snapshots coexist and that pinning is your responsibility.

Deeplearning4j compared with PyTorch, TensorFlow and DJL

Against PyTorch and TensorFlow, the difference is not accuracy or layer coverage. It is where the code runs. PyTorch and TensorFlow are Python-native, with the largest ecosystem of pretrained models and the fastest path from a paper to a working script. Deeplearning4j trades that ecosystem for process locality: no Python interpreter, no inter-process serialization, no second deployment artifact. If your model is trained by a research team in Python and served by a Java service, you can either export and import into DL4J or keep the Python runtime. Against DJL, which also targets the JVM, the split is architectural. DJL is an engine-agnostic interface that loads existing engines, while DL4J ships its own native compute library, LibND4J, and its own autodiff framework in SameDiff. That means DL4J can train without any Python or C++ engine underneath, and it also means you are depending on this project's native build for your platform rather than on an engine you already trust. Neither approach is universally better; they fail in different ways.

Licence, maintenance and the cost of upgrading

The repository is Apache-2.0, and the README links the LICENSE file, and a NOTICE.txt sits at the top level. Apache-2.0 is permissive and includes a patent grant; it also carries attribution requirements, which is why NOTICE.txt exists. That is a description of the licence, not legal advice, and any redistribution should be checked against the actual LICENSE and NOTICE.txt files in the repository. On maintenance: the repository is not archived, and the last push was on 2026-10-05. The README also states that Deeplearning4J "is actively developed by the team at Konduit K.K." and points to a commercial support address, so there is a company behind the project alongside the Eclipse Foundation hosting. Upgrade cost is the part teams underestimate. The monorepo contains update-versions.sh, change-cuda-versions.sh, release-specified-component.sh and publish-snapshots.sh at the top level, which reflects how many coordinated version numbers exist across DL4J, ND4J, LibND4J and the platform backends. Moving a DL4J version means moving the matching nd4j backend artifact in lockstep, and a CUDA upgrade means matching the backend artifact to the installed driver. The repository has no published GitHub releases, so checking the current published versions on Maven Central is part of the work rather than an assumption.

Editorial conclusion

Adopt Deeplearning4j when the model has to live inside an existing JVM service and you want training, preprocessing and inference in one process. Do not adopt it if you need Python-first research workflows or eager execution, because the README describes SameDiff as define-then-run and lists eager graph execution as planned. Verify three things before committing: that the artifact version you pin exists on Maven Central, that the backend artifact matches the machine (nd4j-native-platform for CPU, a CUDA artifact for GPU), and that the model format you care about is on the supported import list rather than the planned one.

Frequently asked questions

Official sources

1. deeplearning4j/deeplearning4j on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README