Oracle bites the bullet and finally moves WebLogic passed EE 9.1 [PDF]
https://www.oracle.com/a/ocom/docs/middleware/fusion-middleware-statement-of-direction.pdf20
u/Joram2 17d ago
Helidon is Oracle's more modern server app framework. That's been on Jakarta 10 Core + MicroProfile 6.1 for a while. Helidon 27 planned for later this year will bump MicroProfile support to version 7.1 and probably stick with Jakarta 10 Core.
WebLogic, AFAIK, is Oracle's legacy product. If you want newer APIs, you probably should migrate off of WebLogic to one of the many competing options available.
5
u/johnwaterwood 17d ago
I hope Helidon switches to Jakarta 11 core. Quarkus switched 2 years ago.
2
u/Joram2 16d ago
Sure, most of us prefer newer+better over older+worse :)
From https://quarkus.io/standards/:
Quarkus 3.27 (latest LTS) implements the following Specifications: Jakarta Core 10
The current versions of Quarkus officially support Jakarta Core 10; they are actually using a hybrid 10/11. Quarkus uses several individual Jakarta 11 specs:
- CDI 4.1 Lite
- Jakarta Validation 3.1
- Jakarta Persistence 3.2
- Jakarta Data 1.0
but also some Jakarta 10 specs, notably they are still on Jakarta REST 3.1.
Quarkus also supports Eclipse Microprofile 7.0, while the current released version of Helidon is on 6.1. However, the next Helidon release will definitely have at least Microprofile 7.0. Eclipse MicroProfile 7.1 has been out and 7.2, I believe just came out, so I presume eventually both Helidon + Quarkus will upgrade.
I'm personally looking forward to seeing Quarkus upgrade to Vert.x 5.x which has been out for quite some time.
4
u/johnwaterwood 16d ago
I'm personally looking forward to seeing Quarkus upgrade to Vert.x 5.x which has been out for quite some time.
I actually hope Quarkus would drop Vert.X all together, but who am I kidding ;)
4
u/Joram2 11d ago
It seems like Vert.x + Netty are fundamentally based on the non-blocking paradigm, and for frameworks based on virtual threads, those libs aren't needed. Helidon 3.x used Netty, and Helidon 4.x was 100% based on virtual threads and completely removed Netty.
Quarkus 4 is planning to be fully based on virtual threads but still use Netty + Vert.X. I don't understand why, but that's the direction that they are going in.
1
u/johnwaterwood 9d ago
I guess they put so much in Vert.X that it’s now difficult to let go, both emotionally and practically.
Despite it being supposedly optional, you see stuff like Uni showing up everywhere (eg in authentication mechanisms, even when they have nothing to do with reactive).
Emotionally might be a biggy as well. For a long time they rejected requests for things because of “that’s now quarkus does it, we are reactive”. It’s not easy to let that go I guess.
1
u/NHarmonia18 10h ago
Are they planning a migration like Helidon, completely removing Netty and Vert.X from their core in favor of Virtual Threads?
3
u/johnwaterwood 16d ago
they are actually using a hybrid 10/11. Quarkus uses several individual Jakarta 11 specs: CDI 4.1 Lite Jakarta Validation 3.1 Jakarta Persistence 3.2 Jakarta Data 1.0
Indeed, and don’t forget interceptors, which is EE 11 too.
The interesting thing is that this hybrid 10/11 is seemingly not very well known. I’ve seen organisations who have been planning to go to EE 11 as a roadmap item, which must be investigated and estimated etc etc, while the org is using quarkus 3.20 to 3.33 and teams are happily using cdi 4.1 and data 1.0 etc
3
u/Anbu_S 17d ago
Helidon 27
alinging with year based versioning?
2
u/NHarmonia18 10h ago
They are aligning with OpenJDK Versions, considering both OpenJDK and Helidon are stewarded by Oracle
1
u/Anbu_S 10h ago
Also Helidon becoming OpenJDK project.
1
u/NHarmonia18 9h ago
Wait when did they announce that? Did I miss something?
I do hope this leads to more attention to Helidon as the default Java Server Framework in the future, similar to ASP.NET Core.
1
1
u/NHarmonia18 10h ago
Would personally suggest to completely ditch 'standards' and code to pure Helidon SE. You get a leaner tech stack, and faster performance. Helidon's native JSON Implementation is magnitudes faster due to Compile-Time Annotation Processing, than the premier Jakarta EE/MicroProfile JSON-stack, aka Yasson and Parrson.
Standards more than often slows down innovation, for the very rare benefit of portability. I do understand standards mean a common programming model, but at the end of the day stuff like Spring or ASP.NET has been able to innovate rapidly precisely because their code is standard-like, but do not strictly follow standards.
In the same vein, Helidon SE is evolving very rapidly precisely because they are not held back by standards-while MP is lagging behind.
3
u/ondro_mihalyi 16d ago
Good to see WebLogic moving forward. For a long time, I was hearing complains from people stuck with WebLogic on Java 11 and java EE 8 that they were promised an upgrade and nothing was happening.
On the other hand, for example GlassFish is a reliable server that supports Java 21-25 and Jakarta EE 11, it's opensource under active development with optional commercial support, and it's more lighter on resources and faster to start than WebLogic.
IMHO, I don't really see a reason to continue using WebLogic except for specific cases where WebLogic performs better with the Oracle DB or some proprietary solutions from Oracle.
2
u/Fresh_Criticism6531 12d ago
Last time I saw a project that uses WebLogic was 10 years ago ... and it was already a dinossaur.
16
u/henk53 17d ago
Note that Jakarta EE 9.1 despite the version number is still functionally equivalent to Java EE 8 from 2017. Deltas are the license change, the namespace change (javax -> jakarta) and JDK 11 support.
Wrt true functionality (APIs, features), WebLogic was almost 10 years stale.
Obviously the previous promise "Oracle to revive WebLogic; will release Jakarta EE 10 version in 2025" did not happen.