jakartaee / jakartaee/platform
API to expose specification versions
- Dominant language
- No language data
- Stars
- 230
- Forks
- 77
- Avg merge
- 8d 5h
- Merged PRs (30d)
- 1
Description
We're beginning to make more backwards incompatible changes to APIs and behavior, which is a totally fine evolution of the platform.
I think this means we owe it to users to allow them to reliably and portably determine which exact specification version the application might be running in so they can act accordingly. A great deal of people write libraries that are used in multiple applications and those applications typically span a few Jakarta EE versions. There really needs to be an easy API an application can make use of to tell them what spec version they're running in.
Before we get into proposals, what do you think about the goal?
In terms of proposals, we could do JNDI calls, system properties, etc. The JVM takes the system property approach. We could possibly do the same using the short names of each spec. I.e. something like:
- `jakarta.platform.version` = 10.0
- `jakarta.core.version` = 10.0
- `jakarta.servlet.version` = 6.0
- `jakarta.pages.version` = 3.1
- `jakarta.batch.version` = 2.1
...
etc
FYI all the short names are used in both these places:
- https://jakarta.ee/specifications/pages/
- https://github.com/jakartaee/pages/
The version would be just major+minor, no patch or service versions. The TCK of each spec would look for the system properties that relate to their spec. In whole, there would need to be a system property present for each spec the server implements. People would not only be able to use the system property to know what version is supported, but if there is support at all. For example, is MVC in the server? This is all information application developers can use to determine in code what kind of behavior they have.
Contributor guide
Research direction
Start by reviewing the Jakarta EE platform specification and the linked Pages specification to understand how specification names and versions are represented. The issue is still seeking agreement on the goal and possible mechanisms, including JNDI and system properties; work is not ready until a portable approach and corresponding TCK expectations are defined.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100