Yes, I support the idea of putting common functionality to a separate project. It could be Jakarta Annotations, but in this case it should be renamed to Jakarta Commons because it won’t contain annotations only. Its scope statement will
need to be changed too.
Currently it’s: Jakarta Annotations defines a collection of annotations representing common semantic concepts that enable a declarative style of programming that applies across a variety of Java technologies.
From: jakartaee-spec-project-leads <jakartaee-spec-project-leads-bounces@xxxxxxxxxxx>
On Behalf Of Emily Jiang via jakartaee-spec-project-leads
Sent: Thursday, September 16, 2021 11:42 PM
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Cc: Emily Jiang <emijiang6@xxxxxxxxxxxxxx>; jakartaee-platform-dev@xxxxxxxxxxx
Subject: [External] : Re: [jakartaee-spec-project-leads] Jakarta EE common functionality
I think the common utilities can be placed in a single spec, e.g. Common Annotations. I have the following thoughts/questions.
1. I think these common utilities should be domain independent. In other words, I don't think we lift some security APIs in this common space so that another spec such as REST can use it.
2. This common spec should be properly owned by an active body - e.g. Jakarta platform spec team to actively release this spec. It should have a more frequent release cycle. More committers should be added to help with the release etc.
3. Test effort: how to ensure all APIs/SPIs are properly tested? How to track which specs use a particular APIs? We should retire some APIs if no specs use it.
On the last platform meeting we touched a topic of a common functionality across different specifications in Jakarta EE. Currently specifications are not using much shared code.
As the result, some functionality is implemented differently in different specifications which makes the platform APIs inconsistent. We've discussed the CDI object model API which can be used in other specifications such as JSON Binding without adding a hard
dependency to CDI. Servlet team also said that they were planning to add a similar API to their spec. Another example is generic type holder object which is used in CDI, JSON-B and maybe some other specifications. It needs to be resolved at the platform level
and there are many ways how it can be done. We can create additional specifications, move shared code to a separate repository and release it as part of the platform project, or move code to Jakarta Annotations which is de-facto only one specifications containing
some shared code. There could be more options.
I would like to initiate a community discussion around this topic. Please post your ideas to this thread. I am planning to create a meeting when there are enough ideas for discussion,
possibly next week.
jakartaee-spec-project-leads mailing list
To unsubscribe from this list, visit