jakartaee / jakartaee/platform

Provide library with an API spec projects can reuse

Open
#405 8 comments 0 reactions 0 assignees View on GitHub
jea-linked
Dominant language
No language data
Stars
230
Forks
77
Avg merge
8d 5h
Merged PRs (30d)
1

Description

**Is your feature request related to a problem? Please describe.**
[GenericType](https://jakarta.ee/specifications/platform/9.1/apidocs/jakarta/ws/rs/core/generictype) class defined by the JAXRS spec is an example of a class, which other specs may wish to reuse. Right now the only option for that is to either "depend" on JAXRS - not everyone wants or needs to do that - or "copy&paste" this class to his project.

I think that by deeper inspection of existing specs, more "utility"-like/common stuff which does not necessarily belong to the given spec's API and may be useful to others can be found.

The artifact could also provide EE platform extensions to SE classes - for example extended ServiceLoader handling provider's priority,..

**Describe the solution you'd like**
The Platform project provides an artifact, let's say `jakarta.platform:jakarta.commons` with a package `jakarta.commons.util`- with common functionality other spec projects or implementations can reuse to guarantee consistent behavior across the platform and avoid duplicating the functionality.

Spec projects should not be required to use this artifact, they should be able to opt-in/opt-out to use it at any time if they want to.

**Describe alternatives you've considered**
- proposing movement of this class to commons annotations project - seems to be an option but not a way to go, since CA project is more about annotations, not classes
- creating a spec project holding these "utility" classes - I think it does not make sense to "write a spec" on how a utility class should behave; it is also not expected others will ever need to "reimplement" provided stuff, so no CI other than the "default one" is expected
- depend on some 3rd party artifact - EE APIs have always been built right on top of Java SE, having a dependency on 3rd party APIs is not desirable

**Additional context**
depending on the output related to semantic versioning and usage of `OSGi` annotations - there may be a need to support these annotation but it is not desirable to bring 3rd-party non-Jakarta based dependency to the spec projects; an artifact like this could have the package ie `jakarta.commons.osgi` with annotations from the OSGi

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the JAX-RS GenericType API and the existing Jakarta EE specifications for reusable utility classes. Clarify the proposed jakarta.platform:jakarta.commons artifact, package contents, optional ServiceLoader and OSGi support, and whether the platform should define it. Done means the scope and ownership of a concrete reusable API are agreed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.