5.10.5

[5.10.5] - 2023-01-04

Fixed:

• Fixed vulnerability CVE-2022-1471 which could allow arbitrary code execution if using FileDataSource with a YAML file. (Thanks, antonmos!)

5.10.4

[5.10.4] - 2022-12-20

Changed:

• The internal implementation of the SSE client for streaming updates has been revised to use a single worker thread instead of two worker threads, reducing thread contention and memory usage.

6.0.1

[6.0.1] - 2022-12-20

Changed:

• The internal implementation of the SSE client for streaming updates has been revised to use a single worker thread instead of two worker threads, reducing thread contention and memory usage.

6.0.0

[6.0.0] - 2022-12-07

The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."

This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.

If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.

For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.

Added:

• In com.launchDarkly.sdk, the types LDContext and ContextKind define the new context model.
• For all SDK methods that took an LDUser parameter, there is now an overload that takes an LDContext. The SDK still supports LDUser for now, but LDContext is the preferred model and LDUser may be removed in a future version.
• The TestData flag builder methods have been extended to support now context-related options, such as matching a key for a specific context type other than "user".

Changed (breaking changes from 6.x):

• It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
• There is no longer such a thing as a secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in an LDContext, it will simply be a custom attribute like any other.
• The anonymous attribute in LDUser is now a simple boolean, with no distinction between a false state and a null state.
• Types such as DataStore, which define the low-level interfaces of LaunchDarkly SDK components and allow implementation of custom components, have been moved out of the interfaces subpackage into a new subsystems subpackage. Some types have been removed by using generics: for instance, the interface DataSourceFactory has been replaced by ComponentConfigurer<DataSource>. Application code normally does not refer to these types except possibly to hold a value for a configuration property such as LDConfig.Builder.dataStore(), so this change is likely to only affect configuration-related logic.

Changed (requirements/dependencies/build):

• The SDK no longer has a dependency on SLF4J. It will still use SLF4J as the default logging framework if SLF4J is in the classpath, so it is the application's responsibility to declare its own dependency on SLF4J, as any application that uses SLF4J would normally do.
• Applications that use the database integrations for Redis, DynamoDB, or Consul must update to the latest major versions of the corresponding packages (launchdarkly-java-server-sdk-redis-store, etc.).

Changed (behavioral changes):

• If SLF4J is not in the classpath, the SDK now uses System.err as its default logging destination. See "requirements/dependencies/build" above.
• The SDK can now evaluate segments that have rules referencing other segments.
• Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.

Removed:

• Removed all types, fields, and methods that were deprecated as of the most recent 5.x release.
• Removed the secondary meta-attribute in LDUser and LDUser.Builder.
• The alias method no longer exists because alias events are not needed in the new context model.
• The inlineUsersInEvents option no longer exists because it is not relevant in the new context model.

5.10.3

[5.10.3] - 2022-10-20

Fixed:

• The pom.xml specified a dependency on com.launchdarkly:launchdarkly-logging even though that library is already contained inside the SDK jar, which could cause extra copies of classes to be in the classpath. The dependency has been removed and the classes are still in the jar. (#282)

5.10.2

[5.10.2] - 2022-09-12

Fixed:

• Updated snakeyaml to v1.32 to address CVE-2022-38752. This vulnerability would only have affected applications that used the FileData feature with a YAML file, assuming an attacker had write access to the filesystem.

5.10.1

[5.10.1] - 2022-09-02

Fixed:

• Updated snakeyaml dependency (used only if using FileData with YAML files) to v1.31 to address CVE-2022-25857 (#275)
• Corrected documentation for default value of LDConfig.Builder.startWait(). (Thanks, richardfearn!)

5.10.0

[5.10.0] - 2022-07-28

The main purpose of this release is to introduce a new logging facade, com.launchdarkly.logging, to streamline how logging works in LaunchDarkly Java and Android code. Previously, the Java SDK always used SLF4J for logging; developers needed to provide an SLF4J configuration externally to specify the actual logging behavior. In this release, the default behavior is still to use SLF4J, but the logging facade can also be configured programmatically to do simple console logging without SLF4J, or to forward output to another framework such as java.util.logging, or to multiple destinations, or to capture output in memory. In a future major version release, the default behavior may be changed so that the SDK does not require SLF4J as a dependency.

Added:

• In LoggingConfigurationBuilder, the new methods adapter and level, for the new logging capabilities mentioned above.
• TestData.FlagBuilder.variationForAll and valueForAll: new names for the deprecated methods listed below.

Deprecated:

• TestData.FlagBuilder.variationForAllUsers and valueForAllUsers: These methods are being renamed because in the future, there will be other possible kinds of evaluation inputs that are not users, and these test methods will apply equally to those.

5.9.3

[5.9.3] - 2022-07-28

Changed:

• Updated okhttp dependency to version 4.9.3 to address a reported vulnerability in earlier versions of that library, which could have allowed potentially sensitive information to be written to the log if you had put that information in a custom header value that contained an illegal character (see release notes for Java SDK 5.6.0). (#271)

5.9.2

[5.9.2] - 2022-07-20

Changed:

• Further optimizations to reduce how many short-lived objects the SDK produces as a side effect of flag evaluations, causing less work for the garbage collector in applications that evaluate flags very frequently.