Eclipse Foundation Pursuing "Cloud Native" Java With Jakarta EE

[phoronix]

Phoronix: Eclipse Foundation Pursuing "Cloud Native" Java With Jakarta EE

Following Oracle offloading Java EE to the Eclipse Foundation and then renaming the project to Jakarta EE, we now know more about the future of this Java Enterprise Edition...

http://www.phoronix.com/scan.php?page=news_item&px=Jakarta-EE-Cloud-Native

[bug77]

This is actually terrible news. Deployment strategy is an orthogonal concern to development and it should remain as such.
The problem Jakarta EE (and JavaEE before it) faces is the server side these days is reduced to a simple REST server. For that, not only are there several alternatives out there, but the stack is overkill (e.g. JSF and MVC?).
There's still a lot of goodies in there, but you need to become a Jakarta/Java EE black belt first to know where they are.

[cen1]

Hmm not sure this is the right direction, they should just stick to core technologies and let Microprofile and friends do the cloud work.

[Michael_S]

This is actually terrible news. Deployment strategy is an orthogonal concern to development and it should remain as such.

I agree with your point that JavaEE has so much baggage it may not be worth the effort to sift through for the good parts.

But on the particular point of deployment strategy, I think it's not an orthogonal concern to development. There are tradeoffs to weigh - if you restrict your development to certain models, deployment and scaling for certain kinds of workloads become simpler to handle. "Write anything that gets the job done properly and we'll worry about deployment later" is a legitimate strategy, but not the only one.

[bug77]

I agree with your point that JavaEE has so much baggage it may not be worth the effort to sift through for the good parts.

But on the particular point of deployment strategy, I think it's not an orthogonal concern to development. There are tradeoffs to weigh - if you restrict your development to certain models, deployment and scaling for certain kinds of workloads become simpler to handle. "Write anything that gets the job done properly and we'll worry about deployment later" is a legitimate strategy, but not the only one.

Oh, it is, trust me. Design can be modular or not, stateful or not (and has been) since well before Docker. I do not need the stack to know more about Docker than it does about Tomcat or WildFly. Fwiw, deployment on Docker today is almost identical to deploying onto a JavaEE cluster ten years ago. Thus my concern about further "native support".

[paulpach]

Oh, it is, trust me. Design can be modular or not, stateful or not (and has been) since well before Docker. I do not need the stack to know more about Docker than it does about Tomcat or WildFly. Fwiw, deployment on Docker today is almost identical to deploying onto a JavaEE cluster ten years ago. Thus my concern about further "native support".

There are a few things that can be done to make Jakarta EE more cloud friendly:

• Tomcat takes about 50 seconds or so to start an application. Cloud applications should start much quicker than that so you can kill an instance and replace it quickly. Especially if you consider serverless model.
• Docker passes configuration to applications using environment variables. Jakarta EE has no way to configure resources like database and queues using environment variables, so applications typically create their own database connection pools instead of using the container's. This makes it harder to use things like XA transactions. Each implementation is free to implement these features, but maybe there is something that can be standardized.
• Memory usage could be much smaller. Java 9 introduced modularization, Jararta EE could use this to trim some fat. A typical microservice does not need the entire Jakarta EE. If we were able to pick and choose the parts we need, we could make microservices lighter.
• The JDK is 100+ MB, a Jakarta EE implementation will add some more. A docker image therefore will be a few hundred megabytes in size. Java 9 has AOT and with modularization, Jakarta EE based images could dramatically shrink.
• There could be a module for communicating with kubernetes & docker compose, for example to auto scale based on some specific metric
• the oracle JDK binaries are linked against glibc, which makes them unsuitable for alpine. Having a build linked against musl means I could use alpine and save dozens of megabytes.

These things are not cloud specific at all, but would certainly make Jakarta EE more appealing for cloud applications.

[cen1]

Startup time: true but doesn't have much to do with the spec
Config: Microprofile already has config covered, there is also LRA in sandbox right now to help with cross-microservice transactional behaviour
Memory usage: nothing to do with the spec..
JDK size: nothing to do with the spec..
Kubernetes/docker module: yes, I guess they could work on that
Glibc: you have alpine based openjdk docker images already??

[Michael_S]

As Phoronix and other sites have posted, Oracle has released the GraalVM project under GPLv2. Among other things, it has compile-to-native for Java and Kotlin as long as you avoid certain features like dynamic class loading and runtime reflection. The resulting native code has a builtin copy of one of the Java garbage collectors and only includes the portions of the Java standard library actually used by the code. That said, according to GraalVM documentation on ahead-of-time compiled images at https://www.graalvm.org/docs/referen...t-compilation/ "Right now peak performance is a bit worse than HotSpot, but we don’t want to advertise that (and we want to fix it of course)."

So you still have garbage collection but you have none of the typical JVM startup overhead or memory overhead. I think if I was starting fresh and going to use Java/Kotlin in a 'cloud-native' environment where low memory footprint and fast start mattered more than peak throughput, I think I would go this way instead of JakartaEE.

...that said, if I was starting fresh it might make sense to sidestep the Java ecosystem entirely, depending upon the business needs.