This version of the LaunchDarkly SDK works with Java 7 and above.
Three variants of the SDK jar are published to Maven:
- The default uberjar - the dependency that is shown below under "Quick setup". This contains the SDK classes, and all of the SDK's dependencies except for Gson and SLF4J, which must be provided by the host application. The bundled dependencies have shaded package names (and are not exported in OSGi), so they will not interfere with any other versions of the same packages.
- The extended uberjar - add
<classifier>all</classifier>
in Maven, or:all
in Gradle. This is the same as the default uberjar except that Gson and SLF4J are also bundled, without shading (and are exported in OSGi). - The "thin" jar - add
<classifier>thin</classifier>
in Maven, or:thin
in Gradle. This contains only the SDK classes.
-
Add the Java SDK to your project
<!-- in Maven: --> <dependency> <groupId>com.launchdarkly</groupId> <artifactId>launchdarkly-client</artifactId> <version>4.6.1</version> </dependency> // or in Gradle: "com.launchdarkly:launchdarkly-client:4.6.1"
-
Import the LaunchDarkly package:
import com.launchdarkly.client.*;
-
Create a new LDClient with your SDK key:
LDClient ldClient = new LDClient("YOUR_SDK_KEY");
-
Create a new feature flag on your dashboard
-
In your application code, use the feature's key to check wthether the flag is on for each user:
LDUser user = new LDUser(username); boolean showFeature = ldClient.boolVariation("your.feature.key", user, false); if (showFeature) { // application code to show the feature } else { // the code to run if the feature is off }
The LaunchDarkly SDK uses SLF4J. All loggers are namespaced under com.launchdarkly
. For an example configuration check out the hello-java project.
Be aware of two considerations when enabling the DEBUG log level:
- Debug-level logs can be very verbose. It is not recommended that you turn on debug logging in high-volume environments.
- Potentially sensitive information is logged including LaunchDarkly users created by you in your usage of this SDK.
For testing purposes, the SDK can be made to read feature flag state from a file or files instead of connecting to LaunchDarkly. See FileComponents for more details.
LaunchDarkly servers operate in a load-balancing framework which may cause their IP addresses to change. This could result in the SDK failing to connect to LaunchDarkly if an old IP address is still in your system's DNS cache.
Unlike some other languages, in Java the DNS caching behavior is controlled by the Java virtual machine rather than the operating system. The default behavior varies depending on whether there is a security manager: if there is, IP addresses will never expire. In that case, we recommend that you set the security property networkaddress.cache.ttl
, as described here, to a number of seconds such as 30 or 60 (a lower value will reduce the chance of intermittent failures, but will slightly reduce networking performance).
Check out our documentation for in-depth instructions on configuring and using LaunchDarkly. You can also head straight to the complete reference guide for this SDK or our Javadocs.
We run integration tests for all our SDKs using a centralized test harness. This approach gives us the ability to test for consistency across SDKs, as well as test networking behavior in a long-running application. These tests cover each method in the SDK, and verify that event sending, flag evaluation, stream reconnection, and other aspects of the SDK all behave correctly.
We encourage pull-requests and other contributions from the community. We've also published an SDK contributor's guide that provides a detailed explanation of how our SDKs work.
- LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard. With LaunchDarkly, you can:
- Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
- Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
- Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
- Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
- LaunchDarkly provides feature flag SDKs for
- Explore LaunchDarkly
- launchdarkly.com for more information
- docs.launchdarkly.com for our documentation and SDKs
- apidocs.launchdarkly.com for our API documentation
- blog.launchdarkly.com for the latest product updates
- Feature Flagging Guide for best practices and strategies