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 java module structure 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