Eclipse Hono™ 2.0.0
This is the second major release of Eclipse Hono which we used to remove a lot of deprecated code and some components that we do not want to support any more as well.
The 2.0.0 release also marks the end of our transition from Spring Boot to Quarkus. Consequently, all Spring Boot based implementations of service components have been removed from the code base.
With the availability of the new Java 17 long term support release, the JDK compliance level has been updated from 11 to 17.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
The biggest change has been the migration from Spring Boot to the Quarkus framework. All Spring Boot based variants of the Hono components have been removed and the container images published to Docker Hub are now all Quarkus based. We also provide images that use native executables created using Graal VM's native image compiler. The native executable based images are being used on the Hono Sandbox because they have a very small minimum memory footprint and therefore better match the very limited hardware resources on the Sandbox server. However, in production environments the JVM based images still have (much) value because they can take advantage of the VM's JIT compiler and therefore (potentially) provide better performance.
Hono has always supported distributed tracing of message proccessing based on OpenTracing instrumentation. In the past, we had used the Jaeger Java client for reporting the traces to a Jaeger back end. The Jaeger client has been retired in the meantime in favor of the Open Telemetry client SDKs which are now used by Hono's components to report tracing information to an Open Telemetry collector, from which they can be exported to a tracing back end.
This release does not fix any reported vulnerabilities.
The Getting Started guides for AMQP 1.0 and Kafka based messaging infrastructure have been consolidated into a single guide, with the default messaging infrastructure now being Kafka. The documentation of Hono's north bound APIs, which are specific to the messaging infrastructur being used, has been adapted accordingly.
The core and the client module have supported Java 8 and have been implemented as OSGi bundles in order to allow them to be used in OSGi based gateway components. In the meantime, demand for this kind of support has diminished (if not disappeared). Consequently, the core module no longer is implemented as an OSGi bundle and now requires Java 17 as all other components. Most classes of the original client module had been deprecated already. The client module has been removed completely and the non-deprecated classes have been moved to the new service specific set of client modules.
During the 1.x development cycle, the underlying concept for routing commands from (north bound) applications to (south bound) devices has changed significantly. At first, all routing of commands had been done by the protocol adapters themselves, employing information kept in the Device Connection service for that purpose. This had the disadvantage of requiring protocol adapters to implement this (complicated) functionality which made it hard(er) to add new protocol adapters. The current design uses a more centralized approach with the Command Router component being responsible for both keeping track of information relevant for routing commands as well as doing the actual routing. The original functionality in the adapters as well as the Device Connection service had been deprecated some time ago and is now removed altogether.
The migration from Spring Boot to Quarkus has been finished and the Spring Boot based variants of the components have been removed from the code base.
Assessing the number of Hono users is hard because we do not have a single artifact to track download numbers from. The number of image pulls on by Docker Hub, which we use to distribute our container images, also do not provide a clear picture simply because it is unclear, when the images are being pulled. This may reach from "only when the Helm chart is used to install Hono" to "every time integration tests are being run".
In any case, most of the support issues created on GitHub seem to come from academia related users, may be as part of student projects or as part of an IoT specific curriculum. We also have an established base of users who use Hono in production use cases but that number has not increased significantly as far as we can tell.
The number of active committers has decreased during the last months as some of the committers have moved on to other projects and/or do no longer find the time to work on the project.