4.5.0

[4.5.0] - 2018-10-26

Added:

It is now possible to inject feature flags into the client from local JSON or YAML files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See com.launchdarkly.client.files.FileComponents.

4.4.1

[4.4.1] - 2018-10-15

Fixed:

• The SDK's Maven releases had a pom.xml that mistakenly referenced dependencies that are actually bundled (with shading) inside of our jar, resulting in those dependencies being redundantly downloaded and included (without shading) in the runtime classpath, which could cause conflicts. This has been fixed. (#122)

4.4.0

[4.4.0] - 2018-10-01

Added:

• The allFlagsState() method now accepts a new option, FlagsStateOption.DETAILS_ONLY_FOR_TRACKED_FLAGS, which reduces the size of the JSON representation of the flag state by omitting some metadata. Specifically, it omits any data that is normally used for generating detailed evaluation events if a flag does not have event tracking or debugging turned on.

Fixed:

• JSON data from allFlagsState() is now slightly smaller even if you do not use the new option described above, because it completely omits the flag property for event tracking unless that property is true.

4.3.2

[4.3.2] - 2018-09-11

Fixed:

• Event delivery now works correctly when the events are being forwarded through a LaunchDarkly Relay Proxy.

4.3.1

[4.3.1] - 2018-09-04

Fixed:

• When evaluating a prerequisite feature flag, the analytics event for the evaluation did not include the result value if the prerequisite flag was off.
• The default Gson serialization for LDUser now includes all user properties. Previously, it omitted privateAttributeNames.

4.3.0

[4.3.0] - 2018-08-27

Added:

• The new LDClient method allFlagsState() should be used instead of allFlags() if you are passing flag data to the front end for use with the JavaScript SDK. It preserves some flag metadata that the front end requires in order to send analytics events correctly. Versions 2.5.0 and above of the JavaScript SDK are able to use this metadata, but the output of allFlagsState() will still work with older versions.
• The allFlagsState() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option FlagsStateOption.CLIENT_SIDE_ONLY. (#112)
• The new LDClient methods boolVariationDetail, intVariationDetail, doubleVariationDetail, stringVariationDetail, and jsonVariationDetail allow you to evaluate a feature flag (using the same parameters as you would for boolVariation, etc.) and receive more information about how the value was calculated. This information is returned in an EvaluationDetail object, which contains both the result value and an EvaluationReason which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.

Fixed:

• Fixed a bug in LDUser.Builder that would throw an exception if you initialized the builder by copying an existing user, and then tried to add a custom attribute.

Deprecated:

• LDClient.allFlags()

4.2.2

[4.2.2] - 2018-08-17

Fixed:

• When logging errors related to the evaluation of a specific flag, the log message now always includes the flag key.
• Exception stacktraces are now logged only at DEBUG level. Previously, some were being logged at ERROR level.

4.2.1

[4.2.1] - 2018-07-16

Fixed:

• Should not permanently give up on posting events if the server returns a 400 error.
• Fixed a bug in the Redis store that caused an unnecessary extra Redis query (and a debug-level log message about updating a flag with the same version) after every update of a flag.

4.2.0

[4.2.0] - 2018-06-26

Added:

• New overloads of LDUser.Builder.custom and LDUser.Builder.privateCustom allow you to set a custom attribute value to any JSON element.

Changed:

• The client now treats most HTTP 4xx errors as unrecoverable: that is, after receiving such an error, it will not make any more HTTP requests for the lifetime of the client instance, in effect taking the client offline. This is because such errors indicate either a configuration problem (invalid SDK key) or a bug, which is not likely to resolve without a restart or an upgrade. This does not apply if the error is 400, 408, 429, or any 5xx error.
• During initialization, if the client receives any of the unrecoverable errors described above, the client constructor will return immediately; previously it would continue waiting until a timeout. The initialized() method will return false in this case.

4.1.0

[4.1.0] - 2018-05-15

Added:

• The new user builder methods customValues and privateCustomValues allow you to add a custom user attribute with multiple JSON values of mixed types. (#126)
• The new constant VersionedDataKind.ALL is a list of all existing VersionedDataKind instances. This is mainly useful if you are writing a custom FeatureStore implementation.