Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 36 million developers.Sign up
[4.6.5] - 2019-05-21
userKeysFlushIntervalwas mistakenly setting the value of
flushIntervalinstead. (Thanks, kutsal!)
- CI tests now run against Java 8, 9, 10, and 11.
[4.6.4] - 2019-05-01
- Changed the artifact name from
- Changed repository references to use the new URL
There are no other changes in this release. Substituting
launchdarkly-client version 4.6.3 with
launchdarkly-java-server-sdk version 4.6.4 will not affect functionality.
[4.6.3] - 2019-03-21
- The SDK uberjars contained some JSR305 annotation classes such as
javax.annotation.Nullable. These have been removed. They were not being used in the public API anyway. (#156)
identifyis called without a user, the SDK now logs a warning, and does not send an analytics event to LaunchDarkly (since it would not be processed without a user).
[4.6.2] - 2019-02-21
- If an unrecoverable
java.lang.Erroris thrown within the analytics event dispatching thread, the SDK will now log the error stacktrace to the configured logger and then disable event sending, so that all further events are simply discarded. Previously, the SDK could be left in a state where application threads would continue trying to push events onto a queue that was no longer being consumed, which could block those threads. The SDK will not attempt to restart the event thread after such a failure, because an
Errortypically indicates a serious problem with the application environment.
- Summary event counters now use 64-bit integers instead of 32-bit, so they will not overflow if there is an extremely large volume of events.
- The SDK's CI test suite now includes running the tests in Windows.
[4.6.1] - 2019-01-14
- Fixed a potential race condition that could happen when using a DynamoDB or Consul feature store. The Redis feature store was not affected.
[4.6.0] - 2018-12-12
- The SDK jars now contain OSGi manifests which should make it possible to use them as bundles. The default jar requires Gson and SLF4J to be provided by other bundles, while the jar with the "all" classifier contains versions of Gson and SLF4J which it both exports and imports (i.e. it self-wires them, so it will use a higher version if you provide one). The "thin" jar is not recommended in an OSGi environment because it requires many dependencies which may not be available as bundles.
- There are now helper classes that make it much simpler to write a custom
FeatureStoreimplementation. See the
com.launchdarkly.client.utilspackage. The Redis feature store has been revised to use this code, although its functionality is unchanged except for the fix mentioned below.
FeatureStorecaching parameters (for Redis or other databases) are now encapsulated in the
- The exponential backoff behavior when a stream connection fails has changed as follows. Previously, the backoff delay would increase for each attempt if the connection could not be made at all, or if a read timeout happened; but if a connection was made and then an error (other than a timeout) occurred, the delay would be reset to the minimum value. Now, the delay is only reset if a stream connection is made and remains open for at least a minute.
- The Redis feature store would incorrectly report that it had not been initialized, if there happened to be no feature flags in your environment at the time that it was initialized.
asyncRefreshare deprecated in favor of the new
cachingmethod which sets these all at once.
[4.5.1] - 2018-11-21
- Fixed a build error that caused the
com.launchdarkly.client.filespackage (the test file data source component added in v4.5.0) to be inaccessible unless you were using the "thin" jar.
- Stream connection errors are now logged at
WARNlevel, rather than
[4.5.0] - 2018-10-26
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
[4.4.1] - 2018-10-15
- The SDK's Maven releases had a
pom.xmlthat 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] - 2018-10-01
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.
- 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