5.9.1

[5.9.1] - 2022-06-30

Changed:

• The SDK now uses memory more efficiently when parsing JSON flag/segment configuration data that it receives from LaunchDarkly, so there will be a less sizable transient memory usage spike if the flag/segment data is very large. This does not affect the baseline memory requirements for storing the data after it is received.
• The SDK now produces fewer short-lived objects as a side effect of flag evaluations, causing less work for the garbage collector in applications that evaluate flags very frequently.

5.9.0

[5.9.0] - 2022-05-26

Added:

• LDConfig.Builder.serviceEndpoints provides a simpler way of setting custom service base URIs, if you are connecting to a LaunchDarkly Relay Proxy instance, a private LaunchDarkly instance, or a test fixture. Previously, this required setting a BaseURI property for each individual service (streaming, events, etc.). If using the Relay Proxy, simply remove any BaseURI calls in your SDK configuration and call serviceEndpoints(Components.serviceEndpoints().relayProxy(myRelayProxyUri)) on the configuration builder.

Fixed:

• Fixed documentation comments for the variation methods to clarify that defaultValue is used if there is an error fetching the variation or the flag doesn't exist, not when the flag is disabled.

5.8.1

[5.8.1] - 2022-05-04

Fixed:

• Calling stringVariationDetail with a flag whose variations are not strings, and passing null as the default value parameter, would result in an EvaluationDetail that had a null value but had a regular evaluation reason and variation index (whatever those would be for a successful evaluation of that flag). It now correctly returns a WRONG_TYPE error reason, and NO_VARIATION for the variation index.
• If a field in Config.ApplicationInfo is set to a string longer than 64 characters, the SDK will now log a warning and discard it, since the LaunchDarkly services cannot process such strings for these fields.

5.8.0

[5.8.0] - 2022-04-18

Added:

• LDConfig.Builder.applicationInfo(), for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.

5.7.1

[5.7.1] - 2022-02-04

Fixed:

• Fixed a packaging issue causing launchdarkly-java-sdk-common to be included as a dependency in the SDK's generated pom file. This introduces duplicate classes in the application's jar file. The duplicate classes can prevent the SDK's custom serialization logic from being used, due to not correctly referencing the shaded class names. (#258)

5.7.0

[5.7.0] - 2022-01-28

Added:

• The SDK now supports evaluation of Big Segments. An Early Access Program for creating and syncing Big Segments from customer data platforms is available to enterprise customers.

Changed:

• CI builds now include a cross-platform test suite implemented in https://github.com/launchdarkly/sdk-test-harness. This covers many test cases that are also implemented in unit tests, but may be extended in the future to ensure consistent behavior across SDKs in other areas.

5.6.7

[5.6.7] - 2022-01-28

Fixed:

• When using allFlagsState to produce bootstrap data for the JavaScript SDK, the Java SDK was not returning the correct metadata for evaluations that involved an experiment. As a result, the analytics events produced by the JavaScript SDK did not correctly reflect experimentation results.
• In feature flag rules using the before and after date operators, if two ISO-8601 string values were compared that represented the exact same absolute date in different time zones (such as 2000-01-01T08:00:00Z and 2000-01-01T00:00:00-08:00), the SDK wrongly treated them as unequal. This did not affect strings that represented different absolute dates, which were always compared correctly. The SDK now handles both cases correctly.
• The com.launchdarkly.sdk.json serialization methods were sometimes omitting JSON object properties in cases where it would have been more correct to show the property with a null value. This mainly affected JSON data produced by LDClient.allFlagsState(), where the presence of a flag key with a null value would indicate that the flag existed but could not be evaluated due to an error, as opposed to the flag not existing.

5.6.6

[5.6.6] - 2022-01-07

Fixed:

• The SDK build process was accidentally including a module-info.class file in the jar that was from a different module (jdk.zipfs). This has been removed. The SDK does not currently have Java module metadata. (#252)

5.6.5

[5.6.5] - 2021-12-08

Fixed:

• If it received an HTTP 401 or 403 error from LaunchDarkly, indicating that the SDK key was invalid, the SDK would still continue trying to send diagnostic events. (#250)

5.6.4

[5.6.4] - 2021-11-30

Fixed:

• Updated Gson to 2.8.9 for a security bugfix.