Delivered under the newly-formed MicroProfile Working Group, the much anticipated release of MicroProfile 4.0 was made available to the Java community. Features include alignment with Jakarta EE 8 and updates to all 12 core APIs. The standalone APIs, however, remain unchanged at this time.
The CDI, JAX-RS, JSON-P and JSON-B APIs, originally based on their equivalent JSRs, are now based on their equivalent Jakarta EE 8 specifications, namely Jakarta Contexts and Dependency Injection 2.0, Jakarta RESTful Web Services 2.1, Jakarta JSON Processing 1.1 and Jakarta JSON Binding 1.0. Behind the scenes, MicroProfile 4.0 utilizes Jakarta Annotations 1.3, a specification that "defines a collection of annotations representing common semantic concepts that enable a declarative style of programming that applies across a variety of Java technologies."
Originally scheduled for a June 2020 release, MicroProfile 4.0 was delayed so that the MicroProfile Working Group could be established as mandated by the Eclipse Foundation. The working group defines the MicroProfile Specification Process and a formal Steering Committee composed of organizations and Java User Groups (JUGs), namely Atlanta JUG, IBM, Jelastic, Red Hat and Tomitribe.
Emily Jiang, Liberty microservice architect and advocate at IBM, providing a retrospective on the challenges from this past year, told InfoQ:
MicroProfile 4.0 was an overdue release. The individual API specifications were ready to be released a while ago. However, the pre-requisite for the release was to establish the MicroProfile Working Group, which took us around 10 months to accomplish. After the working group was established, we immediately started the release process for MicroProfile 4.0.
MicroProfile Config 2.0 was used as a guinea pig to establish the release process including the license requirements for the specifications, javadocs, etc., as well as how to vote on the specifications. With this experiment, we created the templates and process for the API releases. I created a release plan to divide the API releases into three waves based on the dependencies. We then started the API releases, staged the releases, initiated the voting process, etc.
We tried very hard to release MicroProfile 4.0 in 2020. With the great help and assistance from Eclipse Foundation, we managed to release MicroProfile 4.0 on December 23rd. Special mention goes to the Jelastic for announcing MicroProfile 4.0 at the last minute.
Aligned with Jakarta EE 8 dependencies, MicroProfile 4.0 ships with incompatible changes to five of the APIs, namely Config, Fault Tolerance, Health, Metrics and OpenAPI. We examine a few of the APIs here.
MicroProfile Config 2.0
The MicroProfile Config API provides runtime configuration from external sources to minimize repackaging of an application. Based on a priority-based ordinal system, these sources include: system properties (ordinal = 400); environmental variables (ordinal = 300); and a .properties file (ordinal = 100). Priority is given to the highest defined ordinal value. Custom sources may also be defined by implementing the ConfigSource interface.
Config 2.0 introduces the @ConfigProperties annotation that allows the bulk extraction of properties into a property class. This eliminates the repetition of applying the @ConfigProperty annotation on a number of related properties read from a configuration source. For example, consider the following configuration:
server.host=localhost
server.port=8080
server.endpoint=movie
It would be now possible to extract all the properties into one class:
@ConfigProperties(prefix="server")
@Dependent
public class ServerDetails {
public String host; // the value of server.host
public int port; // the value of server.port
private String endpoint; //the value of server.endpoint
public String getEndpoint() {
return endpoint;
}
}
More details on new features and incompatible changes may be found in the release notes and GitHub repository.
MicroProfile Fault Tolerance 3.0
The MicroProfile Fault Tolerance API provides a number of strategies (timeouts, retries, circuit breakers, etc.) to handle failure within an application. Each of these strategies has a corresponding annotation that, when applied, will redirect the application with a necessary course of action to minimize the adverse effects of a failure.
Fault Tolerance 3.0 now specifies the lifecycle of circuit breakers and bulkheads such that they maintain state between invocations to ensure correct functioning. For example, if a @RequestScoped bean has a @CircuitBreaker method, all invocations of that method will share the same circuit breaker state, even though each request has a different instance of the bean.
Fault Tolerance metrics have been updated to support metric tags, a feature added in Metrics 2.0. As a result, information previously contained in the metric name is instead included in tags.
For consistency with other MicroProfile APIs, Fault Tolerance metrics have moved from the application: scope to the base: scope. Therefore, these metrics are now exported under the /metrics and /metrics/base endpoints replacing the previously used /metrics and /metrics/application endpoints.
More details on new features and incompatible changes may be found in the release notes and GitHub repository.
MicroProfile Health 3.0
The MicroProfile Health API determines if a computing node is on the brink of termination or shutdown and will replace that node with a fresh, healthy instance. Similar to the Metrics API, a /health endpoint is automatically provided to display an application's health information in JSON format.
Health 3.0 allows developers to define default health readiness on application startup. As readiness determines whether a container may consure requests, the container is required to return an overall negative status until application readiness can be confirmed. Therefore, the MicroProfile Config value, mp.health.default.readiness.empty.response, may be set to UP to let the container know an application is ready.
More details on new features and incompatible changes may be found in the release notes and GitHub repository.
MicroProfile Metrics 3.0
The MicroProfile Metrics API provides time series telemetry data for MicroProfile applications. A built-in /metrics endpoint sends data in Prometheus format. Custom metrics may be defined via built-in annotations such as @Counted, @Gauge, @Histogram and @Timed.
Metrics 3.0 brings a number of changes especially to MetricRegistry which was converted from an abstract class to an interface. A number of new methods (getType(), gauge(), histogram(), meter(), etc.) were added to the MetricRegistry interface for implementation. Metric registration is no longer triggered with the @Metric annotation. If application metrics require registration, it must be done using the new MetricRegistry methods.
More details on new features and incompatible changes may be found in the release notes and GitHub repository.
Getting Started with MicroProfile
Similar to web-based starter tools, such as Spring Initialzr, Quarkus and Micronaut Launch, the MicroProfile Starter page is a relatively new tool for developers to start writing cloud-based, microservices applications. Released in January 2019, MicroProfile Starter will generate a complete Maven project based on selected options such as the MicroProfile and Java SE versions, a supported runtime based on the selected MicroProfile version, and a series of check boxes to select desired MicroProfile APIs.
The MicroProfile Working Group is currently evaluating OpenTelemetry, a new project formed by the recent merger of the OpenTracing and OpenCensus projects, and the Micrometer project, a vendor-neutral application metrics facade, as potential candidates to replace the OpenTracing and Metrics APIs, respectively.
Editor's Note
This news story was updated to include the retrospective from Emily Jiang and to replace the original MicroProfile 4.0 diagram that contained a typographical error.
