Jakarta EE interview series: Meet David Heffelfinger

Confused about what’s going on with Jakarta EE? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java. Our first guest is Jakarta EE consultant and instructor David Heffelfinger. Let’s dive deeper into the Jakarta EE universe!

Transfering Java EE technologies from Oracle to the Eclipse Foundation is no easy job. The Jakarta EE brand is evolving rapidly but we need to stop for a minute and acknowledge all the changes and plans which will include the platform’s evolution into cloud, containers, microservices, serverless, and reactive technologies.

The vision for the technical future of Jakarta EE includes the following:

Enhanced support for microservices architecture

Move to Cloud Native Java, which includes better integrations with technologies like Docker and Kubernetes

Increase the pace of innovation

Build a vibrant developer community

Provide production quality reference implementations

Keeping track of what’s in and what’s out is still a work in progress, but here’s what we know for certain. While there may be some other proposals that are still pending, these are the projects that have been accepted. This list should help you keep track of Jakarta EE’s progress but we’ve only scratched the surface.

What are the current and future challenges of Jakarta EE? How is it forging a new path forwards for enterprise Java? Where is it headed? This interview series is meant to help you navigate through all the changes and understand where it’s headed, as well as how Jakarta EE plans to become the new home of cloud-native Java.

Our first guest is Jakarta EE consultant and instructor David Heffelfinger. Let’s dive deeper into the Jakarta EE universe!

JAXenter: Would it be a good idea to merge Eclipse MicroProfile with Jakarta EE?

David Heffelfinger: Although I’m not totally against the idea, Java EE had traditionally been a standardization mechanism, for example, JPA was born out of the several Object-Relational mapping tools available, JSF came to be by integrating ideas from several MVC frameworks, etc. Because of this, very little innovation actually happened in Java EE. I’m thinking that perhaps MicroProfile could be sort of an “innovation branch” for Jakarta EE, that is, new specifications could be added to MicroProfile first, then once they are stable they could be added to Jakarta EE proper, this would allow Jakarta EE to continue the stability of Java EE, while Microprofile could provide a vehicle for those members in the community that would like to innovate and implement new ideas.

JAXenter: Jakarta EE’s path has already been chosen, and that’s cloud-native. How will this goal be achieved?

Perhaps MicroProfile could be sort of an “innovation branch” for Jakarta EE.

David Heffelfinger: Although it may be too early to tell, there have been some conversations about leveraging Java 9 modules in Jakarta EE. The idea is for the concept of an application server to go away, and instead build custom runtimes at build time mixing and matching implementations of different Jakarta EE specifications. If these ideas come to fruition, then Jakarta EE applications will be a lot smaller and use a lot less resources than their Java EE counterparts, making it easier to containerize them and deploy them to the cloud.

JAXenter: How can Jakarta EE evolve to meet users’ cloud needs?

David Heffelfinger: Perhaps integrating some of the Microprofile APIs such as Config, Fault Tolerance and Health Check may help, as well as embracing Java 9 modules to build runtimes containing only the APIs used in the application.

JAXenter: Let’s focus on the Jakarta EE survey results. Over 60% of the respondents want better support for microservices. How would you implement that?

David Heffelfinger: Java EE / Jakarta EE is already very well suited for microservices development, there are several lightweight Java EE / Jakarta EE runtimes that can be used to develop and deploy microservices, such as Apache Tomee, Websphere Liberty and Payara Micro. Again, embracing Java 9 modules may make Java EE applications even lighter weight making it even more suitable for microservices.

JAXenter: Speaking of the survey, the second most desired aspect is native integration with Kubernetes. Should this be a priority for the development of the project?

David Heffelfinger: One of the advantages of Java EE / Jakarta EE and Java, in general, is that it abstracts out the specifics of technologies we may be working with, allowing flexibility to switch technologies few or no code changes. For example, the Java Virtual Machine abstracts out the operating system, the exact same codebase can run on Windows, Mac and Linux servers, JDBC abstracts out the RDBMS, allowing us to switch database vendors with minimal impact to our code. We see this pattern over and over all over the Java world.

For this reason, I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool, however, allowing it to be used with several orchestration tools would be something I would very much look forward to.

SEE ALSO: “By tying Jakarta EE to cloud-native and microservices, we have an opportunity to make the technology relevant to today’s cloud-first world”

JAXenter; Would you prefer faster releases (like Java’s new release cadence) or slower, yet bigger feature releases?

David Heffelfinger: Perhaps somewhere in between. Java EE has traditionally been used in large commercial entities, these entities tend to be very conservative and risk-averse, for this reason, many don’t upgrade their technology stack very often.

Having frequent releases of Jakarta EE would likely mean most organizations leveraging Jakarta EE would be using a version that is three or four versions behind the latest. Perhaps yearly Jakarta EE releases would be a good compromise.

Having frequent releases of Jakarta EE would likely mean most organizations leveraging Jakarta EE would be using a version that is three or four versions behind the latest.

JAXenter: How do you plan to participate in the development process of Jakarta EE? Any specs or TCKs you’re especially interested in?

David Heffelfinger: Due to other commitments, I, unfortunately, have been unable to be very active in the development process of Jakarta EE, what I have traditionally done with Java EE, and expect to do with Jakarta EE in the near future, is educate developers in the latest features of Jakarta EE by writing documentation, offer online and on-site training, and speak at technology conferences.

JAXenter: How do you think the community should adapt to the changes that have taken place recently?

David Heffelfinger: The fact that Jakarta EE is a truly open specification is something that many in the Java EE community have wanted for a long time, now that it has finally happened, the community should take an active role in Jakarta EE. Contribute to new specifications, test early implementations of Jakarta EE specifications, blog, and spread the word.

Now that Jakarta EE is truly open, if we all just “wait and see”, nothing will really happen. If we all get involved we can make great things together.

Thank you!

Our Jakarta EE interview series will be published twice a week. Join us on a journey to the depths of Jakarta EE!