-
Institutional memory is important
-
A very long running open source project is a very special kind of institutional memory.
-
A project that is an ecosystem of open source projects even more special still.
- A project that is both is truly rare. One of our themes for EE 11 is responding to the needs of developers. This looks very different in a project with the above very special qualifiers than in a "leaf node" project. It is far easier to show responsiveness when the possible costs of a committing a mistake are contained within a single project. In light of the possible costs, we were intentionally modest with our goals for incorporating developer feedback. This is our implementation of the tried and true strategy of "underpromise and overdeliver".
Let's review our modest goals and see how we did in EE 11.
-
-
Jakarta Data
-
Jakarta NoSQL
-
Adopt Java SE 11, 17, 21 new features and Breaking Changes
-
Virtual Threads
-
TCK Refactoring
-
CDI Centric
-
CDI replacing managed beans
-
CDI repleacing EJB
-
-
Resolve redundant HTTP stacks: Servlet and REST
-
MicroProfile and Jakarta Alignment
-
CORS support
-
Jakarta Config
-
Make it easier to migrate from one vendor to another
I'm going to group the delivery in four buckets: over-delivered, delivered, somewhat delivered, did not deliver.
- Jakarta Persistence - programmatic configuration instead of persistence.xml and a lot more Gavin King blog post
- Jakarta Security - dynamically choose an authentication mechanism security-311
-
Jakarta Data
-
Adopt Java SE 11, 17, 21 new features and Breaking Changes
-
TCK Refactoring (we will deliver this. We're holding the release for it)
-
API Flexibility, i.e. no more Umbrella JARs.
- No more questions like "do I have to wait for Jakarta EE xx" to have this feature?
- Jakarta EE Platform APIs are now just a collection of default APIs.
- Individual specs can be excluded or upgraded by the users as they wish,
- New specs can be added as well.
- This makes Jakarta EE platform as flexible as Spring Boot, but without having the implementation baggage in your application, the best of both worlds!
-
Virtual Threads
-
CDI Centric
-
CDI replacing managed beans
-
We did
-
remove the @ManagedBean annotation
-
Move the "integration" parts of CDI from the CDI spec to the platform spec
-
Jakarta Concurrency adds scheduling to the
@Asynchronousannotation to replace the@Scheduledannotation on EJBs concurrency-271 -
Injecting Concurrency resources into CDI beans instead of using
@Resourcein an EJB concurrency-348 -
Removed managed beans support in Rest
-
Qualifiers for persistence units in Persistence - allow injecting persistence context in a CDI-way
-
-
-
-
New Java features
-
records as embeddables and IDs in Jakarta Persistence
-
records in Expression Language
-
records in Validation (formerly Bean Validation) validation-275
-
Flow API in Concurrency concurreny-368
-
-
MicroProfile and Jakarta Alignment
-
We did
- Create the Jakarta Security MicroProfile Security bridge spec.
-
We could have done more here.
-
-
Jakarta NoSQL
-
Resolve redundant HTTP stacks: Servlet and REST
-
CORS support
-
Jakarta Config
-
Make it easier to migrate from one vendor to another
Delivered:
API Flexibility, i.e. no more Umbrella JARs.
No more questions like "do I have to wait for Jakarta EE xx" to have this feature?
Jakarta EE Platform APIs are now just a collection of default APIs.
Individual specs can be excluded or upgraded by the users as they wish,
New specs can be added as well.
This makes Jakarta EE platform as flexible as Spring Boot,
but without having the implementation baggage in your application, the best of both worlds!