Today the Eclipse Foundation have announced an Update on Jakarta EE Rights to Java Trademarks which has dramatic implications for the future of Java EE and Jakarta EE. The Payara team have only recently learned about this - so we thought we would blog about how we feel this impacts customers and users of the Payara Platform. We'll also give our thoughts on how Jakarta EE should evolve given the constraints outlined in Mike Milinkovich's blog from the Eclipse Foundation.

Goals of the Payara Platform

Four years ago when I made the first pull request into the Payara repository the team had a number of goals in creating Payara Server. The first was to build a robust, reliable and supported open source application server that could be deployed into production environments and the second was to evolve the Payara Platform to enable Java EE developers to embrace new architectural models and new deployment infrastructure like cloud, IOT and containers. We have achieved many of these goals and driven forward others, and they are still our primary focus as we look towards Payara Platform 6.

One of our key goals for the Payara Platform is to enable developers to use the Java EE skills they have honed over many years to take advantage of new infrastructure, architectures and programming models. We fundamentally believe that a managed runtime platform combined with industry standard APIs like Java EE and in the future Jakarta EE is a perfect fit for cloud and containerized infrastructure. Java EE has always separated the development of applications from the construction and management of the infrastructure to run those applications using the concept of deployment artifacts. This has a natural fit to cloud and container platforms including in the future serverless models.

As 2019 is in full swing, let's reflect on the highlights of improvements for the Payara Platform in 2018 and review the plans for enhancements and changes coming in 2019.

At Java One last year, Oracle announced that they had made the monumental decision to open source Java EE and move it to the Eclipse Foundation. As Oracle Code One (the successor conference to Java One) comes around I thought it would be good to reflect on where we are and how far we still have to go.

Microsoft Azure provides fully managed Cloud SQL databases for use by your Azure hosted cloud services. Payara® Micro is built to be the best runtime for Cloud Native Java EE and MicroProfile applications. Here’s how to rapidly create a REST web service that retrieves data from an Azure SQL Database and returns it as JSON.

Azure Container Instances allow you to rapidly deploy containers to the Microsoft Azure cloud without having to manage virtual machines and the corresponding infrastructure. Container Instances can be used to rapidly deploy Java EE and MicroProfile applications using Payara Micro as the underlying platform for your Cloud Native applications.

The Payara Platform is perfect for deploying Jakarta EE and MicroProfile applications on Microsoft Azure. One rapid option for deploying on Azure is to use Azure Application Services, especially Web App for Containers. The WebApp for Containers service allows you to rapidly deploy production Payara Micro applications onto Azure in seconds, allowing both rapid horizontal and vertical scaling on demand.

Recently I was tasked with preparing a presentation on an update to Jakarta EE and Eclipse MicroProfile® and it got me thinking about the organisation and structure involved in this huge effort to transform Java EE into a truly open source standard under the Eclipse Foundation. While organising my thoughts I put together a picture showing the structure and tensions of this undertaking to help people understand what various groups do and perhaps how better to get involved. The structure and governance is evolving as I write this so I may not get everything right. 

In Payara Server 5 we have introduced the concept of a Deployment Group - in this blog post, we'll explore why they are important and what they are used for.