Jakarta Commons Creation Review

Type
Creation
State
Failed
End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.

Proposal

Jakarta Commons

Thursday, December 2, 2021 - 05:02 by Tomas Langer
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Is this a specification project?
Patent License
Implementation Patent License
Parent Project
Proposal State
Withdrawn
Background

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.

Scope

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)
Description

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. 

 

Description

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. 

 

Why Here?

This project would become part of Jakarta EE platform, so it can only be "here".

Future Work

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

Initial Contribution

Current code:

  • Jakarta Common Annotations (existing code)

Other should be specified as part of this project.

Source Repository Type