Dropbox Core SDK for Java: version 8 forces a Java 21 decision

Version 8 is a runtime requirement change, not just a feature release

The most consequential line in the documentation is the one about Java versions. Starting with version 8.0.0, the SDK requires Java 21 or newer, and if your project needs Java 8 through Java 20, the guidance is to use the latest 7.x release, which remains available for Java 8 and up. That is a hard fork in the road rather than a soft preference, and it lands in a project that many teams still run on older runtimes. The Android side has its own floor, with the current release supporting Android 8 and newer, which is SDK 26 and above. The release history shows how fast this moved: v7.1.1 and v8.0.1 were both published on 2026-06-30, and v8.0.2 followed on 2026-07-15. If you are on a team that has not yet moved to a modern JDK, this SDK now forces a scheduling conversation about whether it should.

Older SDK versions stopped working in January 2026

The compatibility warning at the top of the project documentation is worth reading closely, because it is not a deprecation notice about a future change. It says to use version 7.0.0 or newer of the SDK for compatibility with the Dropbox API servers, and that older versions stopped working in January 2026, with a link to a blog post about API server certificate changes. So the 7.x line is not merely the compatibility fallback for older Java, it is the minimum supported floor. Any project pinned to a 6.x or earlier SDK is not on a deprecated path, it is on a broken path, which changes the urgency of the upgrade considerably. The practical consequence is that a Java 8 team cannot simply stay where it is, it has to move to the 7.x line at minimum, and the 8.x line only once it can also move the runtime.

Adding the dependency through Maven or Gradle

The setup section covers the two build systems you are likely to use. For Maven you edit the pom.xml and add the dependency to the dependencies section.

<dependency>
    <groupId>com.dropbox.core</groupId>
    <artifactId>dropbox-core-sdk</artifactId>
    <version>8.0.2</version>
</dependency>

For Gradle you add the same coordinates to the dependencies block of your build.gradle.

dependencies {
    // ...
    implementation 'com.dropbox.core:dropbox-core-sdk:8.0.2'
}

There is a third route for people who cannot use a repository: downloading the JAR and its required dependencies directly from the latest release page. The documentation flags one catch there, that the distribution artifacts on the releases pages do not contain optional dependencies, so a manual download can leave you without whatever the optional pieces provide. The artifact is published to Maven Central under the com.dropbox.core group with the dropbox-core-sdk artifact name.

The client is built from a request config and an access token

Every call starts from one object, and the tutorial shows exactly how to construct it. The request config names the application, in the example dropbox/java-tutorial, and the client is built from that config and an access token.

import com.dropbox.core.DbxException;
import com.dropbox.core.DbxRequestConfig;
import com.dropbox.core.v2.DbxClientV2;

public class Main {
    private static final String ACCESS_TOKEN = "<ACCESS TOKEN>";

    public static void main(String args[]) throws DbxException {
        // Create Dropbox client
        DbxRequestConfig config = DbxRequestConfig.newBuilder("dropbox/java-tutorial").build();
        DbxClientV2 client = new DbxClientV2(config, ACCESS_TOKEN);
    }
}

To use the API you first register a new app in the App Console, choose Dropbox API app, and pick the app's permission, then use the app key created with that app to access API v2. The client exposes one accessor per API area, so files operations hang off client.files() and account information off client.users(), which is the shape that makes the typed API pleasant to use.

Listing a folder means handling the cursor yourself

Listing a folder is where the cursor pattern shows up, and it is worth understanding before you write a file browser. The listFolder call takes a path, an empty string meaning the Dropbox root directory, and returns a result object. The result carries entries and a hasMore flag, and the loop keeps calling listFolderContinue with the cursor from the previous result until hasMore is false.

// Get files and folder metadata from Dropbox root directory
ListFolderResult result = client.files().listFolder("");
while (true) {
    for (Metadata metadata : result.getEntries()) {
        System.out.println(metadata.getPathLower());
    }

    if (!result.getHasMore()) {
        break;
    }

    result = client.files().listFolderContinue(result.getCursor());
}

So the SDK does not hide the pagination. You get a first page, you check the flag, and you keep pulling with the cursor. The entries are typed as Metadata, and the path you would print is the lowercase form, which is the canonical form the API uses for case-insensitive comparison. Uploading follows a similar shape, with uploadBuilder taking a destination path and uploadAndFinish consuming an InputStream, and the try-with-resources block closing the file handle for you.

Credentials for the examples live in a JSON file with key and secret

The examples in the repository expect the app key and secret on disk, and the format is minimal. You save the key and secret to a JSON file.

{
  "key": "Your Dropbox API app key",
  "secret": "Your Dropbox API app secret"
}

Both values come from your app page in the App Console. The example set includes a web application example, a Web File Browser with a DropboxAuth class, and an Android application example written in Kotlin. Building from source is also documented, and it needs submodules updated before anything else.

git clone https://github.com/dropbox/dropbox-sdk-java.git
cd dropbox-sdk-java
./update-submodules    # also do this after every "git checkout"
./gradlew build # requires `python` command to use Python 3.9, pip dropbox

The repository is a Gradle build with the core library in a core directory, the generated API surfaces produced by a stone-java-gradle-plugin, an android directory, a proguard directory, and an examples tree holding the Java and Kotlin examples. The Javadocs are published separately, and the CHANGELOG and RELEASING files sit at the top level next to the source.

Core API v1 support is on the way out

The SDK still supports the older Core API v1, but the documentation states that this support will be removed at some point,. There is no date attached, which is the worst kind of notice to plan around, because you cannot schedule the migration. The v2 surface is the one to build on, with the v1 compatibility layer there for older code rather than as a recommendation. The client class name makes the split visible, since DbxClientV2 is the v2 entry point and the older client is a separate type. Practically, that means an application you write today should target the v2 accessors, and if you inherit an integration that still uses v1 you should treat that as technical debt with a written-off timeline rather than a stable choice.

Editorial conclusion

The Dropbox Core SDK for Java fits a Java 21 or Android 8 and newer service that talks to user files through the Core API v2 and wants typed request and response objects instead of hand written JSON, and it fits a team that can migrate off the retired Core API v1 surface. It does not fit a project still on Java 8 to Java 20 unless you accept the 7.x line, which is the release line that still supports those runtimes. Before you pin a version, check whether your build already runs on Java 21, read the notice about SDK versions older than 7.0.0 no longer working against the API servers since January 2026, and decide whether your credential handling can live with the app key and secret JSON file the examples use.

Frequently asked questions

Official sources

1. dropbox/dropbox-sdk-java on GitHub
2. License: MIT
3. Project website
4. README
5. Releases