Java 8 support

[nehaev]

Initially the project was build around java.net.http.HttpClient and the idea to provide Loki appender with no extra dependencies. The API of HttpClient was stabilized in Java 11, that's why Loki4j was initially targeted to Java 11+.

Now that support for Apache HttpClient is added, we can think of Java 8 support as well. What if we provide a separate build for Java 8 with everything included except the part that directly depends on Java 11 (i.e. LokiJavaHttpAppender)?

How to compile the code written in Java 11 syntax to target Java 8? I'm aware of two options:

• Re-write the codebase to Java 8, eliminate the usage of Java 11 syntax
• Use Jabel

Re-writing the code from the only one officially supported LTS Java platform in favor of legacy Java platform (still popular though) doesn't sound right. Jabel worth nothing to try, so it seems like a way to go unless any significant issues with it reported.

How to deliver a version for Java 8? There are several options:

• Multi-release jar (both 8- and 11-compatible classfiles in one jar)
• Same artifactId, different classifier for Java 8
• Different artifactId for Java 8

MR jars have some significant drawbacks:

• They are supported since Java 9, so Java 8 version has to be the main one
• If we put 8- and 11-compatible classfiles for all classes, the jar will double in size
• If we put 8-compatible classfiles for all classes and 11-compatible only for LokiJavaHttpAppender, we make Java 11+ users depend on Jabel
• If we would want to discontinue Java 8 support eventually, this could cause extra friction since until then Java 8 version would be a default one

Classifier is not super popular artifact coordinate, but still its usage as a platform selector is a legitimate use case. A quote from Maven POM reference:

The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier jdk11 and the second one with jdk8 such that clients can choose which one to use.

In Gradle publish variants are also distinguished by classifier.

Having different artifactId for Java 8 seems even better (easier to find it in Maven Central), but it's harder to implement using Gradle publish plugin. I haven't yet found a proper way of doing this.

So at the moment the most reasonable options seem to be the following:

• Use Jabel
• Same artifactId, different classifier for Java 8

[nehaev]

In the end I figured out how publish different artifactId for Java 8 in Gradle. So I stick with the following options:

• Use Jabel
• Different artifactId for Java 8