# Java Modules Java Modules ![Java Module Structure](/files/0ee7b928a59ad99f03e551a94c665047749796d5) 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.). ### OSGI Bundle Information {% hint style="info" %} LicenseSpring Core is a basic bundle that you need to add to your classpath no matter which other bundle you need. If you don't add Core bundle, other bundles won't work and will generate exceptions. {% endhint %} #### To use our SDK in your OSGi bundle/plug-in follow these instructions: {% stepper %} {% step %} ### Download Core Download the LicenseSpring Core bundle from the table in [Downloads & Javadoc](/sdks/java-sdk/downloads-and-javadoc.md) {% endstep %} {% step %} ### Download other bundles Download other bundles based on your needs. {% endstep %} {% step %} ### Add bundles to project root Open your OSGi project and paste the bundles you downloaded into the root directory. {% endstep %} {% step %} ### Edit MANIFEST.MF Go to META-INF/MANIFEST.MF and open your manifest file. {% endstep %} {% step %} ### Add bundles to Classpath Add bundles into classpath (Runtime -> Classpath -> Add -> .. pick bundles). {% endstep %} {% step %} ### Use the SDK Now you can use our SDK in your OSGi project. {% endstep %} {% endstepper %} ### 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. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.licensespring.com/sdks/java-sdk/java-modules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.