Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Additional profiles

It seems like we will head toward the question, why can't Px some subset of the universe of specifications be a profile. If there is a TCK either via composition of standalone TCKs or some profile specific one, plus and implementation, why not allow it to be EE profile Px compatible?

On Tue, Mar 16, 2021 at 8:11 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
All, I've changed the subject so that those who want to advocate for releasing profiles separately can do so.  The danger of us using that thread to discuss the idea of more profiles in general is that it becomes very unclear who is actually asking for independent profile releases or if that is widely supported.

> On Mar 16, 2021, at 6:26 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
> I do agree something like “cloud profile” is probably a poor name. Believe it or not, people want to run their old COBOL applications on the cloud as is, let alone Java EE/Jakarta EE applications. The public cloud is far more un-opinionated than most people seem to realize. It’s best to stick with something a bit more generic/neutral like Minimal or Core Profile.

Jakarta EE Core sounds fantastic.  A name like that would inspire me to think super super tiny and perhaps with a requirement that everything in it can operate in a "Java SE" way.  I may be alone in that last thought, but it's still a great name.

I personally have a desire for something that is basically the Web Profile, but without any UI technologies.  It would still contain EJB Lite, Transactions, JPA and the like.  It's really just the UI technologies I'd like to eject.  Some specific reasons:

 - Many of us are using _javascript_ front-ends.
 - Faces and standard tag libs add significantly to startup times due to TDL scanning and annotation scanning.
 - JSP requires a compiler to be shipped with creates a severe security risk completely unnecessary for those not even intending to use it.
 - _expression_ Language exploits have also been at the center of some severe security vulnerabilities as they are also interpreted and sometimes injectable.

Where I get off the bandwagon is when people start suggesting getting rid of Servlets, etc.  We all build our servers on top of servlet containers so there's no point in pretending it's not there.  Similarly, people still heavily use things like @Schedule from EJB.  I could potentially be convinced it didn't need to contain JPA as that is something that can easily be added, but it starts to open the doors for people advocating it be stripped of good and still used backend technologies.

There will definitely be people who want to see a profile without EJB, Transactions or JPA.  Perhaps that might lead us down a path were we're introducing two new profiles; one super small and one marginally smaller than the Web Profile.  I'd be fine with that.  I can see advantages in something that is aggressively small and library-like.

If that became the case, perhaps Core would be the best name for the tiniest smallest profile and something else for the name of the "Web Profile with no UI APIs" profile.  For the later, I've tossed around "Headless" profile, but it's not the best name.

What particular specs would you want to see in a Jakarta EE Core?  Any thoughts on something that'd be exactly like the Web Profile, just with no UI stuff?  Do you see them as potentially the same or as separate profiles?


jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top