Using Split for Quick and Easy Java Feature Flags

Our Java SDK for feature flags keeps the developer from needing to interact directly with our underlying API. In spite of the API being relatively simple, using a framework (SDK) written in the same language as your application’s codebase is always preferred.

Java SDK setup

Split’s feature flags Java SDK can be added as a library using your favorite package manager, such as Maven or Gradle.

The following example shows how to add the Split artifact to a project using Maven for dependency management:

<dependency>
  <groupId>io.split.client</groupId>
  <artifactId>java-client</artifactId>
  <version>1.0.6</version>
</dependency>

Once the artifact is in the classpath, it’s ready to be imported and ready to be set up.

Creating a long-lived Java feature flags client

The second step to setting up the SDK is to create the long-lived Split feature flags client. You can do so by creating it manually or injecting it using your favorite dependency injection framework.

SplitClient sdk = SplitClientBuilder.build("YOUR_API_KEY")

or using Guice as the injection framework:

public class SplitModule extends AbstractModule {
    @Override
    protected void configure() {}

    @Provides
    @Singleton
    public SplitClient provideSplitClient(@javax.inject.Named("split.api.key") String apiKey) throws Exception {
        return SplitClientBuilder.build(apiKey);
    }
}

A similar approach can be used for other dependency injection frameworks, like Spring.

After this step, the Split SDK feature flags client is ready to go and be used.

Splitting feature flag code

You can use Split to make decisions on what code path to take given different responses from Split, also known as treatments.

As an example, let’s assume we have two types of credit card payments we support—Visa and MasterCard—and are about to introduce a third—Amex.

The code would look like this:

// 'Credit_Card_Payment_System' is the name of the feature we are testing.
String treatment = sdk.getTreatment("CUSTOMER_ID", "Credit_Card_Payment_System");

if (treatment.equals("visa")) {
    // insert code here to process payment using Visa payment system.
} else if (treatment.equals("mc")) {
    // insert code here to process payment using MasterCard payment system.
} else if (treatment.equals("amex")) { // Newly added treatment.
    // insert your control treatment code here
} else {
    // This is the default or CONTROL path. Define what to do in case of service degradation.
}

Feature flags kill switch and default treatment

Split provides the ability to kill a feature by hitting a red button for a specific test in the Split UI console. But what does that mean from the code standpoint? It means that, once killed, any subsequent call to getTeeatment will return the treatment marked in the UI as default. For the example above, if the user selected VISA as default treatment, then the branch in the if statement corresponding to VISA will be selected.

Split as on/off feature toggle

Imagine the valid scenario where you want to start testing a new database like Apache Cassandra to migrate part of your existing dataset in your primary datastore. A safe approach is to do what are called dark writes, which for this exercise we’ll do in a feature named double_writes_to_cassandra. This practice is known as dark writes because for each write of the data we care about, we also perform a similar write to another database to start testing its performance. But, this data isn’t yet read from the DB, hence, it’s “dark”.

For this use-case, Split can be used as a simple on/off feature toggle. The code would look something like this:

// 'Credit_Card_Payment_System' is the name of the feature we are testing.
String treatment = sdk.getTreatment("USER_ID_IN_SESSION", "double_writes_to_cassandra");

if (treatment.equals("on")) {
    // insert code here to perform writes to cassandra
} else if (treatment.equals("off")) {
    // do nothing
} else {
    // insert your CONTROL treatment code here
}

and of course the previous code can be rewritten as follows:

// 'Credit_Card_Payment_System' is the name of the feature we are testing.
String treatment = sdk.getTreatment("USER_ID_IN_SESSION", "double_writes_to_cassandra");

if (treatment.equals("on")) {
    // insert code here to perform writes to cassandra
} else {
    // do nothing. OFF/CONTROL case.
}

Wrapping Up

Hopefully this article sheds some light on how to get feature flags up and running with Split on Java, as well the basic concepts behind its core functionality in a couple different uses.

Stay tuned for upcoming articles on getting feature flags up and running using our other SDKs, like JavaScript, Ruby or PHP.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.

Switch It On With Split

The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.