Java Libraries

This is the set of libraries currently supporting the Java programming language and its JDK based cousins. It currently consists of two libraries:

• Core - this reflects the core repository and all listeners that notify about feature changes.

You primarily use this SDK by choosing a transport mechanism which includes the core library above. The transport mechanism will automatically configure itself using Java Services, so when you create a new client, you do not have to worry about the details of each implementation.

• Android/GET Client - This is a GET implementation of the client. It does not have inbuilt polling, it is intended for use by clients who do not want or need near realtime updates (which is typical of Mobile devices - as realtime updates keep the radio on), or if you were using server side evaluation. It uses OKHttp. To refresh the client you simply use the "poll" function of your provider as detailed in the Core SDK. It is specific to Java 8+ and thus supports Android 7+.

• SSE Client - This allows you to use near realtime events using the SSE implementation in OKHttp. It is what you would use if you were not using Jersey.

• Jersey Client - this reflects the Jersey Eventsource client for Java. It also includes the Jersey implementation of the Google Analytics provider. It is designed for Jersey 2 and the javax annotations.

• Jersey Client - this reflects the Jersey 3 Eventsource client for Java (along with the new Jakarta APIs). It also includes the Jersey implementation of the Google Analytics provider. It is designed for Jersey 3 and the jakarta annotations.

If you are using Spring or Quarkus on your server, we recommend you use the client-java-sse library as it is the lowest footprint and doesn’t bring in another REST framework (i.e. Jersey).

This build working depends on featurehub being checked out as a pair directory for the time being as the API for the Edge is documented there.

Examples

The examples are shifting from the featurehub-examples folder into this Java repository. They currently consist of:

• todo-java - this is a Jersey 3 server that will use any of the Android, Jersey 3 or OKHttp SSE clients depending on configuration.

Working with the repository

First thing you need to do is run the setup.sh - so it will load the tiles into your local repository. Tiles are a Maven extension that lets you side-load and componentize plugin configuration.

We use Tiles and Composites (collections of dependencies) to avoid repeating build configuration, each artifact should include only the things that make it different.

Modules

Java 8 is used in the entire repository, consists of various artifacts:

• core-java-api - this is a local build of the SSE API from the main FeatureHub repository and will generally track that. It can be behind, but it will never be a breaking change.

• client-java-core - holds the basic local cache that is filled in different ways by different clients. It holds the definition of all of the core functionality, including the feature repository, its features, listeners, analytics capability and so forth. It does not connect to the outside world in any way, that is specific to the HTTP library you have chosen to use.

• client-java-android - this is a Java 8 client suitable for Android SDK 24 (Android 7.0) and onwards. It includes OKHttp 4 and provides a GET only API. It does not poll as that doesn’t really make sense in a Mobile application. It can handle server side or client side evaluation keys equally well.

• client-java-jersey - this is a Java 8 Jersey 2.x client for Java, use this if you use Jersey. It has an SSE client and is capable of both server side and client side evaluation keys. However, it is not recommended you us server evaluation keys for SSE and they perform badly for SSE in Jersey.

• client-java-jersey3 - As above, but for Jersey 3.x clients - using Jakarta Java EE 8+

• client-java-sse - This uses OKHttp4 to provide a SSE only client for Java.

The support libraries

In the support folder are the build tiles (common plugins used for building) and the composites (which are groupings of dependencies that are common and go together).

All of these libraries are used in the provided scope in our SDKs, which means you need to include our composites or provide your own (which is more typical). This means you need to use slf4j but not which version, you need to use jackson, but not the version we use, etc. You are free to evolve your library version choice separate to ours.

These are:

• composite-jackson - Jackson shared libraries, shared amongst all of the SDKs

• composite-jersey2 - Client specific jersey libraries for Jersey 2

• composite-jersey3 - Client specific jersey libraries for Jersey 3

• composite-logging - Logging implementation (using log4j2) for the SDKs - they use it in test mode only

• composite-logging-api - Logging API (slf4j)

• composite-test - Test libraries that we use (Spock, Groovy)