Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Jakarta 10.1?


here are my thoughts:

A Jakarta EE 10.1 release, following semver rules,  could add support to new features, but is not allowed to drop something, meaning doing a breaking change.

So in a  Jakarta 10.1 Release we could add Java SE 21 support, but not allowed to drop Java SE 11. However, as Scott pointed out, if there is direct use of the SecurityManager API in at least one Jakarta specification API (or SPI) of an intended to be part of at least one Jakarta EE 10.1 profile, it is impossible to achieve a minor release without breaking at least one of the semver rules.

In a minor release we could address some minor changes like addressing some of  the dependency issues in the APIs, deviating uses of them in the corresponding TCKs as far as they to not break anything beside bug fixes. A subset of these examples could be addressed in a API service/patch release too.

May be it would be a good idea sorting the change requests regarding their semver impact, and if there enough changes and supporters for spending resources on it, we can do a release. An interesting alternative to a final minor/patch/service release could be to do mandatory milestone releases on a major release to address specific changes, i.e.:

* require Java SE 17 as a minimum (dropping Java SE11 support)
* support for Java SE 18+ temporarily (removing SecurityManager dependencies)
* support for Java SE 21 (when available)
* may be, require Java SE 21 as a minimum (if agreed later)
* TCK split up towards component spec
* Breaking changes of a (sub-)set of component specs (to fulfil alignment of depending higher level specs)
* etc.

These milestones could limit the risks for a major release and could give transparency during the release. There are many reasons for the delay of Jakarta EE 10, but one significant is the complexity of the platform and some lack of visibility during the release process, leading to us to address issues in a more serial instead of a parallel way - and at the end accumulating time on the critical path of the project. Another idea is to move forward using 'Continuous Integration technics that are best practices in application development for a long time.
I am dreaming from something as simple as

  git clone <jakarta.project.url>
  mvn clean verify

to get valid feedback for changes on the spec and the registered Compatible Implementation(s) for the upcoming release. Heading for that goal would increase quality (i.e. refactorings can be done with limited risk) and release cadence (i.e. takes burden form the release management to address issues manually and contributors do not have to wait for somebody the run the test, that could be busy, on vacation or simply sleeping because of a different time zone ;-) ).

@Steve: That last could be a point to the Jakarta EE 11 requested release changes, but it would be independent of a specific release. The jQA Jakarta EE dependency analysis is step in that direction, splitting up the TCK would be another...

I agree, this is a very valuable conversation in deed.


Am 06.10.22 um 20:38 schrieb Scott Marlow:

On 10/6/22 11:38 AM, arjan tijms wrote:

In a similar vein to how we did Jakarta 9.1, what about doing a Jakarta 10.1 that only focuses on the security manager removal and JDK 17?

Jakarta 10.1 would then make sure that all TCKs are updated to not use the security manager in any way, and subsequently only JDK 17 is tested. Implementations certifying for Jakarta 10.1 are therefore guaranteed to run without a security manager and are also guaranteed to run at least on JDK 17.

During the EE 9.1 development, David reminded me that TCK tests need to work on both eager/lazy class loading JVMs.  In order to pass on eager class loading JVMs, classes that reference the Security Manager classes cannot be loaded or they will get a class not found exception (CNFE).

I think we need to concentrate our effort on EE 11, otherwise we won't complete the release in a timely manner.  Also due to the eager class loading JVMs which we would want to support I think, the security manager needs to to be removed from the SPEC APIs also (to avoid CNFE failures), which requires a major EE release I think.

The work for Jakarta EE 11, which mainly takes place in the component specification projects, can largely or even entirely continue in parallel.

My preference is to start on EE 11 now and not delay starting the work which includes a lot of TCK changes that need to happen before we start any SPEC Ballots (we might be able to do some parallel effort but once ballots start, TCKs that are used must be completed).


Thanks for starting this thread to discuss now!  A lot of good feedback!


Kind regards,
Arjan Tijms

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top