Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Simplifying the platform by merging some specs?


I agree this would make sense and simplify the platform.
See comments below

On Tue, Mar 1, 2022 at 11:43 AM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

In the past we've split out functionality from specs where it made sense into new specs and that worked quite well.

Currently however we also have a number of specs which I think are never or rarely shared, and should perhaps be considered to be merged.

For instance; 

Jakarta Mail and Jakarta Activation

Does anything out there ever use Jakarta Activation in a context not related to Mail? Seeing as they are always implemented and released together, it may make sense to merge them.

Same observation here.
It's even worse today in Mail at least. The line between API and IMPL isn't clear and as far as I am aware of, implementations aren't very clear either.

Jakarta Pages and Jakarta (Standard) Tags

I don't think Tags are ever used outside Jakarta Pages. Does it really make sense to have the core tags for Pages in a separate spec? For instance, Faces has a number of core tags too, but despite us desperately wanting to slim the spec, I don't think anyone would dream of making those Faces core tags a separate spec.


Jakarta Security, Jakarta Authentication and Jakarta Authorization

It has been proposed before to merge these, but hasn't been done yet. In this case the lower level specs are used standalone, but there's no independent development or teams working on either of them in isolation, and actually never have been. So for these making Jakarta Authentication and Authorization sub-specs of Security might be the way to go (so they automatically have the same committer team, same CI, etc)

+1 and now that the security manager will be removed, it will make even less sense to keep Authorization alone.
Having Security and including Authentication and Authorization is a good improvement.

Jakarta Dependency Injection and Jakarta Contexts and Dependency Injection and Jakarta Interceptors

Within Jakarta EE the split between Jakarta Dependency Injection and Jakarta Contexts and Dependency Injection is rather superficial, only brought about because of the competing JSR 330 at the time. Like in security, there is no individual team with its own roadmap maintaining Jakarta Dependency Injection. Here too it may simplify things by making it at least a subspec of Jakarta Contexts and Dependency Injection (and while at it, renaming it to simply Jakarta Inject).

I think it was more for Spring and others at that time.
No special opinion here

Interceptors was originally split off from EJB, and it still applies to Jakarta Enterprise Beans. But as the platform has been migrating all Enterprise Beans services to CDI compatible ones, and there is no desire to advance Enterprise Beans in any way, practically speaking Interceptors would only be advanced in the context of CDI.

Too early for Interceptor in my opinion.


Kind regards,
Arjan Tijms

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

Back to the top