Java Modules

Java Modules

Java Module Structure

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.

Client SDKs vs Management 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.

License Client vs Floating Client

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.).

License Check Behavior

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.

Multi-License, Storage, Caching

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

Offline & Retry Features

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.