# The CDK is a Java class library for molecules, not a chemistry application

> The Chemistry Development Kit is an LGPL licensed Java library covering molecule and reaction representation, file format conversion, ring finding, kekulisation, fingerprints and QSAR descriptors, used from inside other programs. It suits cheminformatics code written in Java or JVM languages, and it is the wrong shape for a team that wants a command line tool or a Python native library.

**cdk/cdk** — The Chemistry Development Kit

- Repository: https://github.com/cdk/cdk
- Website: https://cdk.github.io/
- Stars: 610 · Forks: 179
- Language: Java
- License: LGPL-2.1
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/cdk-cdk

## A library to call, not a program to run

The first sentence of the installation section settles what the CDK is. It is a class library intended to be used by other programs, and it will not run as a standalone program. That is unusual to say out loud, and it is worth pausing on, because the name Chemistry Development Kit sounds like a toolchain with a command line and a pipeline of stages.

What it actually is: a Java library whose entry points are classes you instantiate and call from your own code. The feature list is a list of algorithms, not a list of commands. Molecule and reaction valence bond representation. Ring finding, kekulisation and aromaticity. Coordinate generation and rendering. Canonical identifiers for exact searching. Substructure and SMARTS pattern searching. Fingerprints including ECFP, Daylight and MACCS. QSAR descriptor calculations. Reading and writing SMILES, SDF, InChI, Mol2, CML and other formats.

So the user is a developer writing cheminformatics code in Java, who needs structure perception and descriptor calculation that they do not want to implement from chemical first principles. If your team wants a command line tool to convert formats, this is the wrong dependency, because there is no executable here to call.

## Building the JARs, or downloading one that already exists

The library is built with Apache Maven and requires Java 1.7 or later. From the root of the project, one command builds the JAR files for each module.

```bash
$ mvn install
```

The bundle/target directory then contains the main JAR with all dependencies included. A pre-built library JAR can also be downloaded from the project's releases page.

Using it from a plain classpath looks like this.

```bash
$ javac -cp cdk-2.13.jar MyClass.java
$ java -cp cdk-2.13.jar:. MyClass
```

The version in those commands is 2.13, matching the most recent release listed, cdk-2.13, dated 2026-08-18.

One instruction deserves emphasis, and it is easy to miss because the uber artifact is the easy path. If you use Maven, the documentation says you can use the uber cdk-bundle to grab everything, and then notes that it is much more efficient to include the modules you need. A bundle artifact pulls in the whole toolkit on your classpath and in your build, which for a cheminformatics library means a lot of code you will never call.

## Depending on cdk-bundle, or on the modules you need

The Maven coordinates for the uber artifact are as follows.

```xml
<dependency>
  <artifactId>cdk-bundle</artifactId>
  <groupId>org.openscience.cdk</groupId>
  <version>2.13</version>
</dependency>
```

The group is org.openscience.cdk, so any module you depend on directly uses the same group and version. The repository layout shows how the code is divided, and it maps onto the feature list: base holds the core data model, storage holds the file format readers and writers, descriptor holds descriptor calculation, tool holds higher level tooling, display holds rendering, descriptor and tool are joined by app, and legacy contains older modules kept around for compatibility. The top level also has a bundle directory, which is the uber artifact, plus a src directory, a doc directory for the site, a misc directory and an .mvn directory.

Two files at the root are worth knowing about for a project rather than a user. pom.xml is the Maven reactor definition for the whole multi module build, and checkstyle.xml is the style configuration the build enforces, which tells you the project takes its own conventions seriously enough to fail a build over them.

CITATION.cff and AUTHORS.txt sit alongside them, so the project is set up to be cited in academic work.

## Structure perception is the part that is hard to write

Look again at the feature list and a pattern appears. Ring finding, kekulisation and aromaticity are the operations that any cheminformatics code needs and that are painful to get right: deciding where rings are in a graph of atoms and bonds, assigning alternating single and double bonds so a structure can be written out, and deciding which bonds count as aromatic.

The CDK does those as library calls. Kekulisation in particular is the operation that lets a molecule read from one format be written to another, since SMILES needs a valid alternating bond assignment while a connection table may not carry one.

Around that core sit the things that turn a molecule into a searchable thing. Canonical identifiers give you a stable key for exact search. Substructure and SMARTS pattern searching turns a query pattern into a match across a dataset. Fingerprints, in the ECFP, Daylight and MACCS flavours, turn a molecule into a vector so similar molecules can be found by similarity search rather than by equality. QSAR descriptors compute the numeric properties that statistical models consume.

This is the shape of a toolkit that other tools build on. The CDK is the layer underneath a virtual screening pipeline or a structure editor, and the repository includes a tool directory and an app directory for exactly that kind of higher level work.

## Python users reach it through a bridge, not a native module

The documentation has a short section for Python users, and it is worth reading carefully because it describes bridges rather than a Python package.

The Cinfony project provides access via Jython. Cinfony, by Noel O'Boyle, provides a wrapper around the CDK and other toolkits, exposing core functionality as a consistent API so you can move between them. ScyJava can also be used, as explained in the ChemPyFormatics documentation hosted on the CDK site.

So the Python path runs through the JVM. That works for interactive work, scripts and Jupyter style exploration, and it works well enough that the project bothers to document it. It is not the same as a native library, and the performance profile of a JVM call from Python is not the same as a native extension either.

If your team is writing production Python that parses millions of molecules, that is the deciding factor. The CDK does not offer a native Python distribution in the project documentation, and the two documented routes both cross the JVM boundary.

The same logic applies in reverse to any language that is not Java or JVM based. The library is a Java artifact with a classpath interface, and the interoperability story runs through Cinfony and ScyJava rather than through a language binding.

## LGPL v2, a regular release train, and a Java floor that still says 1.7

The project is licensed under the LGPL, version 2, with the licence file at the root of the repository and a copyright line covering 1997 to 2026. LGPL is a weak copyleft licence, so linking the library into your application generally leaves your own code under your own terms, while modifications to the library itself stay open. That is the practical reason many commercial cheminformatics tools are comfortable depending on it. This is a description of the licence shape, not legal advice, and your own counsel should confirm the terms for your distribution model.

The release cadence is regular by the numbers here: cdk-2.11 on 2025-03-29, cdk-2.12 on 2026-03-03 and cdk-2.13 on 2026-08-18, with the last push on 2026-10-22. The repository is not archived. That is a healthy signal for a library you intend to depend on for years, where the risk is not abandonment but API churn between minor versions.

The Java requirement is the other thing to check. The build currently requires Java 1.7 or later, which is a very old floor. It means the library can run on modern JVMs without you worrying about it, and it also means the code is conservative in what it uses. Whether that floor still matches your organisation's supported Java version is worth confirming, particularly if your build enforces a minimum Java release of its own.

## Finding the right class for a task, which is the real learning curve

The project anticipates that knowing the library name is not the same as knowing which class to call. There is a Toolkit-Rosetta wiki page with examples for common tasks, and a wiki page on building the CDK in an IDE for people who would rather not fight Maven by hand. There is JavaDoc for the API, a wiki for general documentation, an issue tracker on GitHub, and a user mailing list at cdk-user@lists.sf.net, with the note that you have to subscribe before you can post.

The Rosetta page is the one to read first. A CDK user is usually looking for a specific operation, such as reading an SDF file and computing a fingerprint for each record, and the distance between that goal and the correct class is where the time goes. The wiki examples exist to shorten that distance.

The issue tracker and the mailing list split the two kinds of questions. Bugs and concrete requests fit an issue on GitHub. Questions about how to use the library fit the mailing list, and the project treats the list as the support channel rather than an afterthought.

One structural detail to keep in mind while browsing: the repository carries a legacy directory alongside the current modules. Legacy code is still there for compatibility, and a class you find in that part of the tree may not be where current development happens.

## Conclusion

The CDK fits a Java or JVM team that needs chemistry-aware parsing, structure perception and descriptor calculation inside an existing application, and it is a reasonable dependency to build on because the licence is LGPL and the release train is regular, with 2.11 on 2025-03-29, 2.12 on 2026-03-03 and 2.13 on 2026-08-18. It does not fit a Python shop that wants native speed, since the documented bridge is Jython or ScyJava rather than a native binding, and it does not fit anyone expecting a runnable program, because the library states it will not run as a standalone program. Before adopting it, add the module JARs you need rather than the uber bundle, check that the Java version you target is compatible with the stated Java 1.7 or later requirement, and read the Toolkit-Rosetta wiki page for the task you actually need, since the mapping from a chemistry operation to a CDK class is the part that takes time.

## FAQ

### How do I add the CDK to a Maven project?

Add the uber artifact with group org.openscience.cdk, artifact cdk-bundle and a version such as 2.13. The documentation notes that it is much more efficient to depend on the individual modules you need instead of the bundle.

### Can I use the CDK from Python?

Yes, through a bridge rather than a native module. The documentation points to Cinfony, which provides access via Jython and exposes the CDK and other toolkits behind one API, and to ScyJava as described in the ChemPyFormatics documentation.

### Does the CDK come as a command line program?

No. The installation section states that it is a class library intended to be used by other programs and that it will not run as a standalone program, so you call its classes from your own code.

### What is the latest CDK release and which Java version does it need?

The most recent release listed is cdk-2.13, dated 2026-08-18, and the library is built with Apache Maven and currently requires Java 1.7 or later.

## Sources

- [cdk/cdk on GitHub](https://github.com/cdk/cdk)
- [License: LGPL-2.1](https://github.com/cdk/cdk/blob/main/LICENSE)
- [Project website](https://cdk.github.io/)
- [README](https://github.com/cdk/cdk/blob/main/README.md)
- [Releases](https://github.com/cdk/cdk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cdk-cdk