Skip to content
Compare
Choose a tag to compare

[5.6.4] - 2021-11-30

Fixed:

Compare
Choose a tag to compare

[5.6.3] - 2021-10-12

Fixed:

  • If Java's default locale was not US/English, the SDK would fail to parse dates in the standard RFC1123 format in HTTP responses. The symptoms were that the warning Received invalid Date header from events service would appear in logs, and event debugging might not stop at the correct time if the system clock was different from the LaunchDarkly services' clock (which is why the SDK checks the Date header).
Compare
Choose a tag to compare

[5.6.2] - 2021-08-09

Fixed:

  • FeatureFlagsStateBuilder.build() is now public. The other builder methods were made public in v5.6.0, but were not useful because build() was still package-private.
Compare
Choose a tag to compare

[5.6.1] - 2021-07-07

This release fixes two packaging errors that could produce unwanted Java dependency behavior, as described below. There are no changes to the SDK's functionality in this release, and you do not need to modify your code or your build.

Fixed:

  • Two Jackson packages (com.fasterxml.jackson.core:jackson-core, com.fasterxml.jackson.core:jackson-databind) were mistakenly listed as dependencies in the SDK's metadata, causing those packages to be downloaded and included in the classpath even if you were not using them. The SDK does not require Jackson, even though it can optionally be made to use it. This was meant to be fixed in the 5.5.0 release as previously described in the changelog, but was not.
  • The SDK jar manifest contained a Class-Path attribute that referenced SLF4J and Jackson jars at a specific relative file path. This could cause a warning to be printed if those jars did not exist at that file path, even if they were elsewhere in your classpath. The Class-Path attribute is mainly useful for independently-deployable application jars and is not useful here; it has been removed. (#240)
Compare
Choose a tag to compare

[5.6.0] - 2021-07-02

Added:

  • The builder() method in FeatureFlagsState, for creating instances of that class (most likely useful in test code). (#234)

Fixed:

  • If you called the LDClient constructor with an SDK key that contained a character less than 0x20 or greater than 0x7e, it would throw an IllegalArgumentException that contained the full SDK key string in its message. Since the string might contain a real key (if for instance the application had read the SDK key from configuration data that included a newline character, and neglected to trim the newline), exposing the value in an exception message that might end up in a log was a security risk. This has been changed so that the exception message only says the key contains an invalid character, but does not include the value. (The underlying exception behavior is part of the OkHttp library, so be aware that if you inject any custom headers with illegal characters into your HTTP configuration, their values might still be exposed in this way.)
  • In polling mode, the SDK would attempt to reconnect to the LaunchDarkly streaming service even if it received an HTTP 401 error. It should reconnect for other errors such as 503, but 401 indicates that the SDK key is invalid and a retry cannot succeed; the SDK did have logic to permanently stop the connection in this case, but it was not working. (This is equivalent to the bug that was fixed in 5.5.1, but for polling mode.)
  • Fixed documentation comments for FileData to clarify that you should not use offline mode in conjunction with FileData; instead, you should just turn off events if you don't want events to be sent. Turning on offline mode will disable FileData just as it disables all other data sources. (#235)
Compare
Choose a tag to compare

[5.5.1] - 2021-06-24

Fixed:

  • The SDK was attempting to reconnect to the LaunchDarkly streaming service even if it received an HTTP 401 error. It should reconnect for other errors such as 503, but 401 indicates that the SDK key is invalid and a retry cannot succeed; the SDK did have logic to permanently stop the connection in this case, but it was not working. (#228)
Compare
Choose a tag to compare

[5.5.0] - 2021-06-17

Added:

  • The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.

Fixed:

  • Removed unnecessary dependencies on Jackson packages in pom.xml. The SDK does not require Jackson to be present, although it does provide convenience methods for interacting with Jackson if it is present.
Compare
Choose a tag to compare

[5.4.1] - 2021-06-10

Fixed:

  • If a rule clause in a feature flag or user segment had a JSON null as a match value, the SDK would fail to parse the JSON data, causing an overall inability to receive flag data from LaunchDarkly as long as this condition existed. This is an abnormal condition since it is not possible to match any user attribute against a null value, but it is technically allowed by the JSON schema. The SDK will now correctly parse the data.
Compare
Choose a tag to compare

[5.4.0] - 2021-04-22

Added:

  • Added the alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.
  • In com.launchdarkly.sdk.json.LDGson, added convenience methods valueToJsonElement and valueMapToJsonElementMap for applications that use Gson types.
  • In com.launchdarkly.sdk.LDValue, added convenience method arrayOf().

Changed:

  • In com.launchdarkly.sdk.json, the implementations of LDGson.typeAdapters and LDJackson.module have been changed for better efficiency in deserialization. Instead of creating an intermediate string representation and re-parsing that, they now have a more direct way for the internal deserialization logic to interact with the streaming parser in the application's Gson or Jackson instance.

Fixed:

  • Gson.toJsonTree now works with LaunchDarkly types, as long as you have configured it as described in com.launchdarkly.sdk.json.LDGson. Previously, Gson was able to convert these types to and from JSON string data, but toJsonTree did not work due to a known issue with the JsonWriter.jsonValue method; the SDK code no longer uses that method.
  • LDValue.parse() now returns LDValue.ofNull() instead of an actual null reference if the JSON string is null.
  • Similarly, when deserializing an EvaluationDetail<LDValue> from JSON, if the value property is null, it will now translate this into LDValue.ofNull() rather than an actual null reference.
27dd8b1
Compare
Choose a tag to compare

[5.3.1] - 2021-04-08

Fixed:

  • Updated the commons-codec dependency from 1.10 to 1.15. There was a known vulnerability in earlier versions of commons-codec-- although it did not affect this SDK, since it involved base64 decoding, which is not a thing the SDK ever does.