Jakarta EE interview series: Meet Josh Juneau

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 third guest is Java Champion Josh Juneau. 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 series debuted last week. Here are the interviews published so far: David Heffelfinger: “I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool”

“I wouldn’t like to see Jakarta EE tied to any specific container orchestration tool” Markus Eisele: “I strongly believe there is a lot to do to make Jakarta EE ready for the future”

Now it’s time to welcome our next guest, Java Champion Josh Juneau. Let’s dive deeper into the Jakarta EE universe!

asap

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

Josh Juneau: My opinion is that MicroProfile should continue to evolve on its own. It is leading the way with cutting-edge features for developing microservices with the Jakarta EE Platform. Jakarta EE should possibly take snapshots of the MicroProfile and utilize as a standard profile for the platform, but it should not evolve together at the same time as a single project…at least not yet.

On the other hand, I think it may be a good fit for MicroProfile to become an EE4J project, continuing to evolve at its own pace.

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

Josh Juneau: The cloud-native goal will be achieved by designing a platform that provides an easy means for development of services and applications to containers and cloud services. Although not all Jakarta EE applications are going to be targeted towards cloud-deployment, it should be the developer’s choice to where an application or service developed via the platform shall be deployed. There should be no special configuration or development considerations when targeting a specific deployment option.

The platform should automatically be container-agnostic, allowing applications and services to become more portable, and hence, cloud-native.

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

The slow-paced evolution of the Java EE platform caused it to fall behind in the cloud space.

Josh Juneau: The platform needs to evolve more dynamically than it had done in the past, meaning that there needs to be a more agile process for adding new technologies to the platform. The slow-paced evolution of the Java EE platform caused it to fall behind in the cloud space. The platform needs to provide an easy way to deploy to containers. There also must be an easier means for external configuration capability. I really like what the MicroProfile is doing with respect to configuration, and it would be great to see Jakarta EE adopt that strategy.

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?

Josh Juneau: It would be really nice to have a CLI for easily generating a simple microservice. This generated microservice project would include all of the necessary dependencies for a lightweight service, allowing the developer to add other dependencies, as needed. The generated project would also be deployable, with very little configuration required, to the container of choice. Jakarta EE also needs to specify a standard health-checking API, such as the ones offered by MicroProfile or Payara server. It should be easy for a developer to create and deploy a service…leaving the developer with more time to focus on the business logic of that service.

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?

Josh Juneau: I feel that if Jakarta EE were to contain native integration with Kubernetes, it would certainly make it easier for developers to deploy systems to containers and manage them effectively. I do believe that this should be an opt-in option, as not all Jakarta EE applications are going to require this type of integration. Perhaps this could be an option when utilizing a CLI to create a default microservice.

SEE ALSO: Jakarta EE: No turning back

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

Josh Juneau: Indeed, I would prefer more frequent, smaller releases. One of the problems that enterprises or small businesses have today is that it generally takes a significant effort to migrate to newer releases of the Java EE Platform due to all of the significant changes. If Jakarta EE release cadence followed something similar to that of Java SE, then I think that the effort to upgrade may be much less, thereby allowing customers and applications to adopt new releases of Jakarta EE much easier.

Of course, on the flip side, those organizations that do not wish to upgrade often may fall behind much quicker if they do not adapt their upgrade cycle to follow the new release cadence. So a faster release cycle is a bit of a double-edged sword. I think in the end, there is generally more gain having smaller, more frequent releases.

The community is now in control of the Jakarta EE platform and can steer the direction.

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

Josh Juneau: I plan to stay involved with Mojarra, minimally, as a committer. I also would like to partake in the general decision-making process via mailing lists, helping to steer the platform as a community member, and possibly join on as a member of different Jakarta EE specs. Of course, I plan to provide documentation and examples…helping to promote the platform so that the community can continue to grow.

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

Josh Juneau: The community should embrace these changes, as the community is now in control of the platform and can steer the direction. Not long ago, the community was up in the air about the future of the Java EE Platform, and there was very little that could be done about it besides voicing an opinion.

Now it is easy to get involved by joining the mailing lists, and joining in on the EE4J project by becoming an Eclipse Foundation member…which is very easy to do. The platform can now go in any direction that the community wishes to take it…the community just needs to get involved.

Thank you!