4.12.1

[4.12.1] - 2020-03-20

Changed:

• Improved the performance of the in-memory flag data store by using an immutable map that is atomically replaced on updates, so reads do not need a lock.
• Improved the performance of flag evaluations when there is a very long user target list in a feature flag or user segment, by representing the user key collection as a Set rather than a List.
• Updated OkHttp version to 3.12.10 (the latest version that still supports Java 7).

4.12.0

[4.12.0] - 2020-01-30

The primary purpose of this release is to introduce newer APIs for the existing SDK features, corresponding to how they will work in the upcoming 5.0 release. The corresponding older APIs are now deprecated; switching from them to the newer ones now will facilitate migrating to 5.0 in the future. See below for details.

This release also adds diagnostic reporting as described below.

Note: if you are using the LaunchDarkly Relay Proxy to forward events, update the Relay to version 5.10.0 or later before updating to this Java SDK version.

Added:

• The SDK now periodically sends diagnostic data to LaunchDarkly, describing the version and configuration of the SDK, the architecture and version of the runtime platform, and performance statistics. No credentials, hostnames, or other identifiable values are included. This behavior can be disabled with LDConfig.Builder.diagnosticOptOut() or configured with EventProcessorBuilder.diagnosticRecordingInterval().
• Previously, most configuration options were set by setter methods in LDConfig.Builder. These are being superseded by builders that are specific to one area of functionality: for instance, Components.streamingDataSource() and Components.pollingDataSource() provide builders/factories that have options specific to streaming or polling, and the SDK's many options related to analytics events are now in a builder returned by Components.sendEvents(). Using this newer API makes it clearer which options are for what, and makes it impossible to write contradictory configurations like .stream(true).pollingIntervalMillis(30000).
• The component "feature store" will be renamed to "data store". The interface for this is still called FeatureStore for backward compatibility, but LDConfig.Builder now has a dataStore method.
• There is a new API for specifying a persistent data store (usually a database integration). This is now done using the new method Components.persistentDataStore and one of the new integration factories in the new package com.launchdarkly.client.integrations. The Redis class in that package provides the Redis integration; the next releases of the Consul and DynamoDB integrations will use the same semantics.
• The component "update processor" will be renamed to "data source". Applications normally do not need to use this interface except for the "file data source" testing component; the new entry point for this is FileData in com.launchdarkly.client.integrations.
• It is now possible to specify an infinite cache TTL for persistent feature stores by setting the TTL to a negative number, in which case the persistent store will never be read unless the application restarts. Use this mode with caution as described in the comment for PersistentDataStoreBuilder.cacheForever().
• New LDConfig.Builder setters wrapperName() and wrapperVersion() allow a library that uses the Java SDK to identify itself for usage data if desired.

Fixed:

• The Redis integration could fail to connect to Redis if the application did not explicitly specify a Redis URI. This has been fixed so it will default to redis://localhost:6379 as documented.
• The getCacheStats() method on the deprecated RedisFeatureStore class was not working (the statistics were always zero). Note that in the newer persistent store API added in this version, there is now a different way to get cache statistics.

Deprecated:

• Many LDConfig.Builder methods: see notes under "Added", and the per-method notes in Javadoc.
• RedisFeatureStore and RedisFeatureStoreBuilder in com.launchdarkly.client: see Redis in com.launchdarkly.client.integrations.
• FileComponents in com.launchdarkly.client.files: see FileData in com.launchdarkly.client.integrations.
• FeatureStoreCacheConfig: see PersistentDataStoreBuilder.

4.11.1

[4.11.1] - 2020-01-17

Fixed:

• Flag evaluation would fail (with a NullPointerException that would be logged, but not thrown to the caller) if a flag rule used a semantic version operator and the specified user attribute did not have a string value.
• The recently-added exception property of EvaluationReason.Error should not be serialized to JSON when sending reasons in analytics events, since the LaunchDarkly events service does not process that field and the serialization of an exception can be lengthy. The property is only meant for programmatic use.
• The SDK now specifies a uniquely identifiable request header when sending events to LaunchDarkly to ensure that events are only processed once, even if the SDK sends them two times due to a failed initial attempt. (An earlier release note incorrectly stated that this behavior was added in 4.11.0. It is new in this release.)

4.11.0

[4.11.0] - 2020-01-16

Added:

• When an EvaluationReason indicates that flag evaluation failed due to an unexpected exception (getKind() is ERROR, and EvaluationReason.Error.getErrorKind() is EXCEPTION), you can now examine the underlying exception via EvaluationReason.Error.getException(). (#180)

4.10.1

[4.10.1] - 2020-01-06

Fixed:

• The pom.xml dependencies were incorrectly specifying runtime scope rather than compile, causing problems for applications that did not have their own dependencies on Gson and SLF4J. (#151)

4.10.0

[4.10.0] - 2019-12-13

Added:

• Method overloads in ArrayBuilder/ObjectBuilder to allow easily adding values as booleans, strings, etc. rather than converting them to LDValue first.

Changed:

• The SDK now generates fewer ephemeral objects on the heap from flag evaluations, by reusing EvaluationReason instances that have the same properties.

Fixed:

• In rare circumstances (depending on the exact data in the flag configuration, the flag's salt value, and the user properties), a percentage rollout could fail and return a default value, logging the error "Data inconsistency in feature flag ... variation/rollout object with no variation or rollout". This would happen if the user's hashed value fell exactly at the end of the last "bucket" (the last variation defined in the rollout). This has been fixed so that the user will get the last variation.

Deprecated:

• Deprecated LDCountryCode, LDUser.Builder.country(LDCountryCode), and LDUser.Builder.privateCountry(LDCountryCode). LDCountryCode will be removed in the next major release, for setting the country user property, applications should use LDUser.Builder.country(String) and LDUser.Builder.privateCountry(String) instead.
• SegmentRule is an internal implementation class that was accidentally made public.
• NullUpdateProcessor should not be referenced directly and will be non-public in the future; use the factory methods in Components instead.

4.9.1

[4.9.1] - 2019-11-20

Changed:

• Improved memory usage and performance when processing analytics events: the SDK now encodes event data to JSON directly, instead of creating intermediate objects and serializing them via reflection.

Fixed:

• A bug introduced in version 4.9.0 was causing event delivery to fail if a user was created with the User(string) constructor, instead of the builder pattern.

4.9.0

[4.9.0] - 2019-10-18

This release adds the LDValue class (in com.launchdarkly.client.value), which is a new abstraction for all of the data types supported by the LaunchDarkly platform. Since those are the same as the JSON data types, the SDK previously used the Gson classes JsonElement, JsonObject, etc. to represent them. This caused two problems: the public APIs are dependent on Gson, and the Gson object and array types are mutable so it was possible to accidentally modify values that are being used elsewhere in the SDK.

While the SDK still uses Gson internally, all references to Gson types in the API are now deprecated in favor of equivalent APIs that use LDValue. Developers are encouraged to migrate toward these as soon as possible; the Gson classes will be removed from the API in a future major version. If you are only using primitive types (boolean, string, etc.) for your feature flags and user attributes, then no changes are required.

There are no other changes in this release.

Added:

• LDValue (see above).
• The new jsonValueVariation and jsonValueVariationDetail methods in LDClient/LDClientInterface are equivalent to JsonVariation and JsonVariationDetail, but use LDValue.

Deprecated:

• In LDClient/LDClientInterface: jsonVariation/jsonVariationDetail. Use jsonValueVariation/jsonValueVariationDetail.
• In LDClient/LDClientInterface: track(String, LDUser, JsonElement) and track(String, LDUser, JsonElement, double). Use trackData(String, LDUser, LDValue) and trackMetric(String, LDUser, LDValue, double). The names are different to avoid compile-time ambiguity since both JsonElement and LDValue are nullable types.
• In LDUserBuilder: custom(String, JsonElement) and privateCustom(String, JsonElement). Use the LDValue overloads.
• In LDValue: fromJsonElement, unsafeFromJsonElement, asJsonElement, asUnsafeJsonElement. These are provided for compatibility with code that still uses JsonElement, but will be removed in a future major version.

4.8.1

[4.8.1] - 2019-10-17

Fixed:

• The NewRelic integration was broken when using the default uberjar distribution, because the SDK was calling Class.forName() for a class name that was accidentally transformed by the Shadow plugin for Gradle. (#171)
• Streaming connections were not using the proxy settings specified by LDConfig.Builder.proxy() and LDConfig.Builder.proxyAuthenticator(). (#172)
• The SDK was creating an unused OkHttpClient instance as part of the static LDConfig instance used by the LDClient(String) constructor. This has been removed.
• Passing a null sdkKey or config to the LDClient constructors would always throw a NullPointerException, but it did not have a descriptive message. These exceptions now explain which parameter was null.

4.8.0

[4.8.0] - 2019-09-30

Added:

• Added support for upcoming LaunchDarkly experimentation features. See LDClient.track(String, LDUser, JsonElement, double).

Changed:

• Updated documentation comment for intVariation to clarify the existing rounding behavior for floating-point values: they are rounded toward zero.