The Payara Foundation have recently released version 5 of Payara Server and Payara Micro with a host of new features and upgrades. Payara Server 5 now fully supports MicroProfile 1.2 and GlassFish 5. Other new features include:

A new admin console for Payara Server

Improvement with clustering

Apache Derby Replaced by H2

Support for Java EE 8

Support for Mojarra 2.4

New Hazelcast features

We highlight some of these enhancements here.

Payara Server Admin Console

The most obvious change is the new dark theme for the admin console. This is primarily a cosmetic change to reflect the Payara Server brand.

Changes to Clustering

In previous versions of Payara Server, data sharing, instance configuration, and deployment targeting were part of the cluster technology, available since the first release of GlassFish. The cluster will be deprecated in favor of Domain Data Grids and Deployment Groups for ease of use, flexibility, and improved compatibility with cloud development. Steve Milledge, founder and director at Payara, stated in his blog post:

All Payara Server instances will join a single domain-wide data grid for sharing of in-memory data like web sessions, JCache, SSO and Stateful EJBs. In Payara Server 5, all Payara Server instances in a domain will form a single domain-wide data grid and data will be shared across all instances transparent to the developer. This data grid, in the majority of cases, will require zero or very little configuration - it will just happen. For those familiar with Payara Server 4, this means the old Shoal clusters, GMS and the old Hazelcast configuration has gone to be replaced with the new Data Grid. Introducing the Data Grid in Payara Server 5 enables us to build and expand exciting new technologies like the Clustered CDI Events, lightweight domain messaging and Data Grid CDI singletons.

A New Default Database

Due to a number of issues with the Apache Derby, the H2 database will replace Derby as the built-in database. Derby is still available in version 5 for compatibility with legacy applications, but considered deprecated until its ultimate removal in the next release of Payara Server.

Michael Croft, Java middleware consultant at Payara, spoke to InfoQ about this latest release.

InfoQ: When do you anticipate Payara Server to be compatible with Java 9 and above?

Michael Croft: We've already done some work on compatibility with the new JPMS introduced in JDK 9, but there's a lot more still to do. As things stand, Oracle will only produce builds of OpenJDK in six-monthly cycles and LTS versions will only be available for OracleJDK, soon to be available exclusively to Oracle support customers. In response to this change, Payara have partnered with Azul Systems to provide a supported JDK for use with Payara Server and Payara Micro. Since Azul's plan is to produce LTS versions of Java at the same cadence as Oracle, we are targeting the first Azul LTS release - JDK 11 released this September. The release is a little out of step with our own release cadence so, providing plans don't change in the meantime, compatibility may be available by November in the 5.184 release.

InfoQ: In a blog post by Michael Ranaldo earlier this month, he said, "the current cluster technology is beginning to show its age." Please explain what that means and if there were any issues with the current cluster technology.

Croft: In the context of that blog post, the "current cluster technology" was referring to Project Shoal, used by GlassFish for clustering. It's an old project which had long been untouched even by the time we announced our very first Payara Server 4.1.144. It was a concern at the time and part of the motivation to include Hazelcast as an option to replace it so early on. The intention was always to replace Shoal with Hazelcast and, with 5.181, we have been able to deprecate Shoal and make Hazelcast a first-class-citizen. A second way that the phrase could be interpreted is that the concept of clusters (as used in GlassFish) is a little outdated when thinking about modern cloud environments that rely on elastic scaling and servers which may appear and disappear without warning. For stateless applications, this isn't such a problem, but removing state from an existing application simply shifts the problem elsewhere. To solve the problem, we introduced the concept of the Domain Data Grid and Deployment Groups which, together, leverage Hazelcast to create a dynamic and flexible way to store session data that does not rely on statically defined clusters in the same way as Shoal did.

InfoQ: What were the issues in Apache Derby that led to replacing it with H2?

Croft: We have never recommended Apache Derby for production use and the same is true for H2. For the kinds of workloads that Payara Server or Payara Micro usually support, it is best to use a more robust database such as Oracle, PostgreSQL or MariaDB/MySQL. The in-built database can often be used for relatively simple cases where there's not much complexity, or in local testing to avoid having to set up a larger database just to test a small change. We have found issues with locking when Derby is used concurrently, which often causes things like batch tests to lock up. When creating and running tests with more traditional databases this isn't an issue, but our findings were that tests designed to smoke test or unit test the server were failing for reasons completely separate to Payara code. We came to the conclusion that, if these were problems for us, it was reasonably likely that other users may encounter them eventually.

InfoQ: Payara Server is derived from GlassFish Server Open Source and Payara 5 is in-synch with GlassFish 5. Are there use cases in which a developer would choose one over the other?

Croft: Probably the key point is that Payara Server is actively supported and fully open source on GitHub. We try to engage with the community as much as we can, too. We are very aware that our community users can be very valuable to the quality of the product too, since they will often be the first to try our pre-release builds and give us early feedback. We do our best to listen and act! Payara Server 5.181 provides APIs which are in sync with GlassFish 5, enabling Java EE 8 applications to be deployed. Aside from that, Payara Server is a significant departure from GlassFish and forges ahead with our vision for how the future of Enterprise Java will look. Part of this is the Domain Data Grid, as I mentioned, which makes life much easier when working with AWS, Azure, or Google Cloud Platform. Another part is our participation in the Eclipse MicroProfile effort which means even more tools in the toolbox, including a modern monitoring system provided by MicroProfile Metrics, a fault tolerance API and a way to inject configuration at runtime. Payara Server also provides its own features for operations teams to use, like a Request Tracing service which is compatible with OpenTracing (and soon to be compatible with MicroProfile OpenTracing), advanced SQL diagnostic tools and ecosystem tooling like Maven and NetBeans plugins. Finally, both Payara Server and GlassFish Server are completely open source under the same license, meaning there is no restriction on downloading the latest released version and using it in production for either server. If at some later stage, however, you decide you need production support you would need to be on Payara Server to get it. Beginning projects on a supported server saves pain in the future and avoids a need for migration and the testing that may be needed for that.

InfoQ: What would you say makes Payara Server and Payara Micro unique over the competition?

Croft: Speaking of competition, probably the closest comparison would be in other open source servers which can run Java EE applications, so that would mean WildFly or OpenLiberty. We are different to WildFly and WildFly Swarm in that Payara Server and Payara Micro share the same API implementations and are fully compatible. We actively encourage customers to cluster both kinds of server together and offer support for both products. Red Hat's positioning of WildFly and WildFly Swarm is a little different when it comes to support, too. WildFly is where new features are delivered, and stability and support are offered through JBoss EAP. For both Payara Server and Payara Micro, we aim to be both innovative and stable and provide our customers with even more stability with extra patched releases every month. In contrast to OpenLiberty, we do not hold back any features from our public releases. Indeed, the feature releases which we make public to the community are exactly the same as the ones provided to our customers and we do not have a separate brand for an open core because the whole code base is open!

InfoQ: What's on the horizon for Payara Server and Payara Micro?

Croft: Back at the start of the year, Steve - the founder of Payara - outlined our roadmap for 2018. This year, we are focusing on specific themes for each release, beginning with the 181 focus on standards thanks to Payara Server 5 and MicroProfile 1.2. Next up, in 182, is a focus on security and an expansion of the number of supported security providers. We'll also aim to ship MicroProfile 1.3 support in that release since it was a bit too late in our development cycle to make 181. Following that will be 183 which should expand support for reactive and asynchronous programming. We have some early ideas of how this would look (supporting Lambdas as message listeners, for example) but exactly what features we will include remains to be seen. The 184 release continues the focus on developer productivity but this time on tooling. We have already begun to build tools for use with Payara Server and Payara Micro, but this release aims to make it as easy as possible to work with Payara Server or Payara Micro.

Resources