Jakarta specifications started suffering from repetition of APIs and utility classes that serve the same purpose in different specifications.
The first attempt to solve such an issue resulted in Jakarta Common Annotations. It seems there is now time to enhance the scope and add additional resources to a common project.
Jakarta Commons provides a shared space for the community to define utilities, annotations and APIs to be used by other Jakarta specification projects.
In scope:
- Move Jakarta Common Annotations to this project, and release it as a standalone jar (under the same coordinates)
- Provide common APIs and utilities to increase consistency of Jakarta EE Specifications (such as TypeLiteral/GenericType, JPMS support)
- Provide multiple artifacts (jars), as useful for specified components
Out of scope:
- Utilities for implementations (such as codecs, parsing, security)
After cooperating on a few Jakarta EE specifications (and looking into their implementations as well), I have realized there are certain problems solved over and over again. This leads to duplicity of APIs and to inconsistencies (where the same problem is solved differently by each specification). I think this should be remedied, and a common specification should be created to address these common problems.
Whenever you ask a question "there is this nice API in CDI that would be very useful for my standalone specification, how do I re-use it", you may have discovered a component that would fit the Jakarta Commons project.
This project would become part of Jakarta EE platform, so it can only be "here".
The following areas are considered for this project (open for discussion/additions):
- Builder API
- Generic Type API (mentioned above)
- Priority utilities (to increase consistency for new projects that want to order by priority)
- JPMS support - to help with Java module system (if feasible)
- Java Language Model - CDI Lite is introducing a model that can be used for build time processing. Such a model may be useful for other specifications as well
- Semantic versioning - possible annotations + processing (such as a maven plugin) to generate artifacts for OSGi
- Discovery support (Introspection API) - remove classpath scanning requirements from specifications (maybe similar to what Jandex is doing)
The community base should be members of other Jakarta EE specifications