Java Modules
Learn what's supported in each SDK and more on this page dedicated to guiding you through the various Java SDK options and the features offered within each SDK.
License Client and Floating Client modules are together referred to as "Client SDKs" and should be directly integrated within your application. These contain a separate API key and a shared secret which should be provided within configuration.
The Management SDK is meant to be used in a backend process somewhere within the purchase funnel, its code that should never reach your clients, as the SDK is meant to issue new licenses, modify their properties, list devices, etc. This is an optional integration which is required in cases where the entire purchase -> license model needs to be automated.
The License Client, historically, was the initial implementation of the LicenseSpring APIs, and it followed the designs and principles set in the other SDK implementations. As the interfacing is done via a LicenseManager class, which is a singleton, the License Client allows for only a single License per-process/class-loader paradigm. This means that only a single license is available for the application to use within this context.
The Floating Client was developed as a stand-alone module primarily to separate the floating license features from normal usage as these are quite different flows. But within this module, we've decided to allow for multi-license usage as there are some valid use-cases when a single license is not sufficient. For this reason there is no singleton implementation within the SDK, but a service has to be used when interfacing with LicenseSpring APIs.
The module sets up automated periodical checks of licenses activated, and releases licenses and deactivates the device on shutdown. Of course, all of this behavior may be disabled, but it's on by default as it sets up a very opinionated way of handling floating licenses. The Floating Client, by default, uses the PER_PROCESS Device Identification Strategy, as the licenses are floating in a pool. This allows for the module to be very flexible, as some of the Device Identification issues on stacked virtualized environments are no longer an issue (virtual machine within virtual machine, docker within virtual machine, etc.).
Module | Feature Name | Feature Available | Default Behavior | Description |
License Client | Periodic Check License | Yes | No | The license can be checked and synced periodically |
Floating Client | Periodic Check License | Yes | Yes | All references to activated licenses are kept in memory , all of the active licenses are deactivated on shutdown. |
License Client | Subscribe to Check | No | No | The only way to check the status is to call Check directly, or to getCurrent license from the manager. |
Floating Client | Subscribe to Check | Yes | No | A custom implementation can be passed to respond to Check events (fail, success) |
License Client | Shutdown Hook | No | No | There are no shutdown hooks, and they are not in the product road-map |
Floating Client | Shutdown Hook | Yes | Yes | All references to activated licenses are kept, all of the licenses are deactivated on shutdown. |
Module | Feature Name | Feature Available | Default Behavior | Description |
License Client | Multi-license | No | No | LicenseManager is a singleton class, will not change |
Floating Client | Multi-license | Yes | Yes | Multiple licenses, multiple products possible - via multiple LicenseService instances |
License Client | Save license to disk (encrypted) | Yes | Yes | The license is saved to disk every time a check/(de)activation/consumption is performed |
Floating Client | Save license to disk (encrypted) | No | No | The feature is not in the roadmap for Floating Client |
License Client | Consumption Caching | Yes | Yes | Currently unable to disable, will be possible in the future |
Floating Client | Consumption Caching | No | No | Currently only direct server calls, will be implemented in a future release |
Module | Feature Name | Feature Available | Default Behavior | Description |
License Client | Offline Activation | Yes | No | Licenses can be activated via offline file, no server will be called on any method. |
Floating Client | Offline Activation | No | No | The feature is not in the roadmap for Floating Client |
License Client | Retry on infrastructural errors | Yes | No | The mode can be activated in order to retry failed requests up to 5 times, with a back-off algorithm |
Floating Client | Retry on infrastructural errors | Yes | Yes | The mode can be activated in order to retry failed requests up to 5 times, with a back-off algorithm |
License Client | Grace period on Check | Yes | No | This mode uses localCheck when there are infrastructural issues, if the latest check license was within x configurable days. |
Floating Client | Grace period on Check | No | No | The feature won't be implemented due to time limitations imposed by floating model. |
