This repository has been archived by the owner on May 30, 2024. It is now read-only.
Releases: launchdarkly/java-server-sdk
Releases · launchdarkly/java-server-sdk
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 callserviceEndpoints(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 passingnull
as the default value parameter, would result in anEvaluationDetail
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 aWRONG_TYPE
error reason, andNO_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 generatedpom
file. This introduces duplicate classes in the application'sjar
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
andafter
date operators, if two ISO-8601 string values were compared that represented the exact same absolute date in different time zones (such as2000-01-01T08:00:00Z
and2000-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 anull
value. This mainly affected JSON data produced byLDClient.allFlagsState()
, where the presence of a flag key with anull
value would indicate that the flag existed but could not be evaluated due to an error, as opposed to the flag not existing.