Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News What's New in MicroProfile 4.0

What's New in MicroProfile 4.0

This item in japanese

Lire ce contenu en français


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:

It would be now possible to extract all the properties into one class:

public class ServerDetails {
    public String host; // the value of
    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,, 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.

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.