Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] A Composable Platform Over Profiles

The TL;DR is that profiles are an antiquated and imprecise concept for defining a runtime, and that instead of introducing additional difficult to agree upon profiles, we should focus on enabling a model where the developer can customize (slim) as required. One of the biggest limiting factors that vendors have to workaround today is the EE certification rules.  If we just change them in Jakarta EE to support subsets and allow for spec upgrades it will make a huge difference. We don’t have to redesign EE’s APIs, or introduce JPMS support to facilitate this, which is why I have been careful not to characterize this as modular EE (which we have long discussed in the past).  Although that's not to say these aren’t worthy, yet IMO separate, goals.

Once that is achieved profiles still have a role, but it is limited to defining the set of a technologies a vendor is expected to provide to label their product/project Jakarta EE. Although even then, the barrier to implement the full profile is significantly lower than it used to be, since there is a rich set of open source implementations (including the RIs) that can be reused.

On May 2, 2018, at 7:06 AM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:

If I am understanding this correctly, this is what I had suggested in the earlier thread? Or is there a nuance I am missing? Are you suggesting vendors never ship a predefined profile and developers must always compose their own profile?

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Jason Greene <jason.greene@xxxxxxxxxx>
Date: 5/1/18 2:11 PM (GMT-05:00)
To: Jakarta EE community discussions <>
Subject: [] A Composable Platform Over Profiles

Over the years there has been vigorous debate about what makes the perfect profile. “Should spec X be included or not?” “Should we create a “plus” variant of the web profile?" “How many profiles is too many?" “How many is too few?" Recent threads you can see the topic rising again with Stable and Legacy profile proposals, and debate about whether or not JAX-WS should be part of the platform.

A related issue is that EE compliance is overly strict. An implementor must ship exactly what a profile defines, with limited exceptions on variation. As an example, a certified web or full implementation can’t ship a newer version of the Servlet API, even though it’s fully backwards compatible. The default run mode / config of the implementation is also not allowed to enable a subset of the profile, even though the implementor’s primary audience may not need all of the specified technologies.

The idea behind a rigid platform certainly had merit, and it arguably led to the very strong level of portability across containers we enjoy today. However, this one-size-fits-all approach just no longer fits the current state of software, with developers expecting a high degree of application specific tailoring.

I argue that a better approach would be to define the platform as a palette of composable standards[1], where profiles define only what must be available for a developer to choose from, and only limit the version of a given standard to the minimum that must be provided[2]. Under this model there is less of a need to define a perfect profile, since it can be freely adjusted by the developer to fit his or her needs. Instead, all that matters is that we have a sensible array of choice.

[1] It’s worth noting that this would require the TCK to be split up, as discussed previously, to facilitate the flexibility required in testing a near arbitrary combination of standards.

[2] For clarity, the full and web profiles would still be versioned (8.0 etc) as today, this is just a rule softening to support variation.

Jason T. Greene
Chief Architect, JBoss EAP
Red Hat

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top