sebastiandaschner blog

Since it’s creation, MicroProfile has gained a lot of traction and produced a variety of specifications. Originally, it was created to advance enterprise Java for a microservice world, with faster progress, driven by multiple vendors. Now, with Java EE being transformed to Jakarta EE under the Eclipse Foundation, how does MicroProfile reasonably fit into the picture within the Enterprise Java universe?

The idea behind MicroProfile, as far as I see it, was to create a faster and more-effective progress in advancing Java Enterprise. Until now, there are a variety of specifications, such as Config, Fault Tolerance, or Metrics, that aim to close the gaps of the Java EE APIs for the requirements in modern enterprise Java. Similarly, MicroProfile aimed to make it possible to craft small runtimes for microservice deployments, where projects only ship the specifications they’re using.

Strengths

Today, I see the biggest advantage of MicroProfile, in advancing enterprise Java, in adding what’s currently missing in Java EE 8. Especially concerns such as resiliency, observability, or simple, vendor-independent configuration are not covered by Java Enterprise standards, yet. While these concerns were always a necessity when running enterprise applications in production, they become even more important for microservice-based systems, which are far more distributed. MicroProfile projects such as Config, Fault Tolerance, or Metrics close these gaps.

MicroProfile effectively already serves as incubator for potential new specifications. MicroProfile projects are able to define Java Enterprise extensions, but on a specification level, not only as a single implementation or vendor-specific solutions. These projects might serve as a basis for new Java Enterprise standards. As a matter of fact, the Config JSR will be based on MicroProfile Config and its real-world experience.

Besides these points, MicroProfile also allows developers to individually configure their runtime, by only including the specifications they require. Following that approach, MicroProfile only included CDI, JAX-RS, and JSON-P in its first version.

However, for me this is hardly more than a runtime optimization. I consider the standards as well as the possibility to have thin deployment artifacts far more important, as I stated a few times already. I typically use an Java EE application server that supports MicroProfile, allows thin deployment artifacts, and that still ships other enterprise standards, such as JPA. If (and only if) minimal runtime sizes are an issue, I make use of hollow WAR / JAR approaches.

What’s Missing

When comparing MicroProfile projects to Java Enterprise standards, developers will notice that the former misses some interoperability of specifications. The ability to use multiple technologies without any configuration is one of the reasons why I claim that Java Enterprise APIs comprise a very effective developer experience. Depending on which projects will be considered part of MicroProfile, future specifications could focus more on that point.

The current situation of MicroProfile and Jakarta EE being formed is in danger of reinventing the wheel, organization-wise and technology-wise. The Open Source processes and developments that MicroProfile went through and is still going through are prone to be repeated similarly by Jakarta EE. Especially, when the direction and responsibility of both technologies is not fully clarified, vendors and contributors are at risk of spending similar efforts twice. The same is true for the technology responsibilities. While most MicroProfile projects work well with the rest of the Java Enterprise world, Rest Client, for example, widely overlaps with JAX-RS and could have been based on the latter in a binary-compatible way, instead.

The deployment model of MicroProfile runtimes is mainly based on standalone executables. Besides this effort, some vendors support a combination of defining the specifications that are included at runtime and shipping thin deployment artifacts as hollow WAR / JAR artifacts. The latter offers a good compromise, somewhat the best of both worlds; still, as said before, I don’t consider a minimal total runtime size as crucial for the majority of enterprise projects.

Proposed Idea: Incubator for Jakarta EE

My proposal for the future of MicroProfile and its place in the enterprise Java world in the age of Jakarta EE, is to serve as incubator for future Jakarta EE specifications.

MicroProfile would advance enterprise Java with extensions that base on specifications, not just single implementations or vendor-specific features. Similar to today, MicroProfile projects would add what’s missing in Java Enterprise.

Unlike the current projects, an incubating MicroProfile could build upon all standards that are part of Jakarta EE. They would share the same technical design principles (see my proposal on Jakarta EE design principles). Similarly, MicroProfile could ensure interoperability between Jakarta EE and the MicroProfile specifications, analogous to today’s Java EE standards.

This would vastly enhance the developer experience. Developers can add MicroProfile projects to a Jakarta EE application to close the gaps in that Jakarta EE version. The projects would follow the same principles, offer a similar look-and-feel, and cooperate well with existing standards.

What’s already the case is that MicroProfile allows a much faster progress compared to enterprise standards. While Jakarta EE standards will take a considerably bigger amount of time and effort, incubating MicroProfile projects could be formed and pursued in a lightweight way, with less organizational overhead. Still, incubating MicroProfile would stay true to the ideas and principles behind Jakarta EE.

An incubator process is always a safer playground for extensions that are not immediately or ultimately added to the set of standards. Projects that required the incubating features, however, can incorporate them without changing the rest of their Jakarta EE application.

Ultimately, an incubating MicroProfile project leaves less remaining work once it is transitioned to become a Jakarta EE standard. While an enterprise standard needs to take more aspects into account, the overall work and effort required will be much less compared to creating two individual specifications.

Next Steps

In general, it’s crucial that the Java Enterprise community shares a common, clear image what MicroProfile’s place will be in the future.

Next steps in pursuing the idea of MicroProfile serving as an incubator for Jakarta EE would be to define and agree on:

I’m interested in your feedback. What are your thoughts on how and if MicroProfile and Jakarta EE can coexist?