Is the Java EE Deployment Model Out of Date? Watch The Video.

I have watched the whole series and liked much of it. I’m going throw in my two cents from the perspective of a dev (which, I guess, is the intended audience) here at the end of the series.

1) Is Java EE Outdated and Dead?

To Quote Mark Twain: “Reports of my death have been greatly exaggerated”

J EE was an awful clumsy, awkward Framework in its first years, including standards that were screwed up beyond repair (see CORBA) and that’s the problem of J EE: Once the reputation is burned, it is hard to change people’s mind.

I have been working with J EE and Spring and for me J EE is becoming a viable overall alternative to Spring at a time when most of the Spring camp walks the path towards ADF (Application Developer Framework) with Spring Boot (a framework to configure a framework, get me outta here).

2) Are Java EE Application Servers Heavy?

Well, depends on what you mean by ‘heavy’.

In most of these discussions the ‘how easy or hard is it to manage the server?’ part is missed out. But this is crucial, too. I just checked the config of the standard domain ‘domain1’ of the Payara server that I play around with from time to time. The domain.xml is 630 lines, which you probably don’t call ‘lightweight’. Plus, it took me just about 3 seconds to stumble over a line containing
“Djdk.corba.allowOutputStreamSubclass=true”. If you don’t want your server being called heavyweight, rip out all stuff like that.

The server is up in about 11 seconds and the memory footprint after start is about 8.7 MB. This is pretty much lightweight.

3) Is Java EE Cloud-Native

I like the treatise of that topic, especially the “SOA service bus on Kubernetes” 🙂

I didn’t spot J EE on the CNCF cloud-native interactive landscape map (https://landscape.cncf.io). Maybe I wasn’t trying hard enough, but I spotted Jenkins, which is the J2EE of CI/CD. I’m not sure if I’d want my product in company with that.

I really don’t care about hypes that actually are marketing labels for a business model of the 70ties: we own the hardware, you rent capacity. For me, this is also to enterprisey. I’m watching this like I watched the dark age of J2EE with the attitude ‘walk across the battlefield and not be seen’.

4) Is the Java EE Deployment Model Out of Date?

XML sucks because of character/net information ratio and its legibility compared to say, JSON. But it has the advantage of verifiable structure, which JSON lacks. The deployment descriptors in J EE are not that long-winded as they used to be, so that toad is not that hard to swallow any more.

Thinwar vs. fatjar … it took the monstrosity of the ancient app servers to make devs voluntarily deploy wars worth up to some hundred megabytes on servlet containers like Tomcat. I thought that Tomcat sucked until I once had to make a bean work on a Websphere App Server sometime around 2015.

The question ‘Is the J EE deployment model out of date?’ is misleading because
from its inception it wasn’t up to date but a bloody mess and the question rather should have been ‘Has the mess of the J EE deployment model been cleaned up?’
I’m glad to see that to a great extend this has been cleaned up but once the
reputation is burned … (see above). For my taste, the point of the improvements
made in that area could have been driven home a bit more.

Apart from the security issues that may crop up in some lib the words “dependency hell” do mean something to devs of certain frameworks. The risk of that is much less in the J EE deployment model.

5) Can Java EE do Microservices?

Sure. A simple J EE project scaffolding with a minimal Maven pom.xml and a Payara Micro with no server config at all is all to get started (but then, you will have to specify some stuff like deployment, ports and tls-certs on the commandline to fire up Payara Micro, but there’s some decent documentation for it).

Can Spring Boot do monoliths? Well, if you don’t mind some serious trouble. I’ve seen the Spring autowiring backfiring in several not so complex apps. I’m pretty shure the autoconfiguration magic of Spring Boot will backfire in a non-trivial monolith scenario. Damned, I forgot that monoliths are bad. Really bad.

Well, if you don’t care that monoliths are bad, you can start with a monolith on
Payara Micro. For a lot of monolithic apps out there I guess the Micro will suffice. If, after a while, you really think it’s better to divide parts of your monolith (or all of it) into microservices, you can still use the Micro for the microservices. That’s something.

6) Do Java EE Standards Matter?

I guess they matter more than they did in dark ages of J2EE.

The standardization process is discussed in detail but to quote a former german
chancellour: “what matters is what comes out at the back”.

One disease that J EE suffered from is that you could nearly always bet on the first
versions of a feature or framework being complicated as hell and being next to unusable. The early beans and security versions are examples of that. The JSF 1.x versions were stuff I knew I’d better leave my fingers off that until some stuff in there got straightened out.

I.e. JACC, JAAS and JASPIC probably didn’t matter because they where a pain in the neck (for some part because of the “Independant Implementations” of the app
server vendors). At least they didn’t matter to me because at those times Spring Security, which was straight forward, was at the rescue. Its remarkable that it took 18 Years until there was a usable Security API in Java EE with the Java Security API 1.0 in 2017. That still stucks with some devs.

It seems that the new standardization process does provide effective means against
such unpleasant APIs like JACC, JAAS and JASPIC coming into extistance.

I looked at the soteria implementation. Its easily digestible code, if you want to know what’s going on under the hood you can know, for an investment of not too much time. JACC and JASPIC are still in the picture but in a lot of cases you won’t have to work with it. Working with the Security API 1.0 is actually fun, as it is working with the current CDI and JSF from at least 2.2 on (but there, the fun really started with 2.3).

It’s also worth mentioning that most J EE standards, respective their implementations, come with a decent documentation (which should be taken for granted, but unfortunately it is not in the area of IT tooling and frameworks).

— what I clearly missed in the series:

I would have liked to see the question “How is it to develop with the current J EE and its app servers?” being dealt with. I.e., this would have been an opportunity to talk about the hot reload feature, which is big performance boost for devs and provides for much more fun while developing and is implemented in some J EE app servers, albeit in different ways. Openliberty comes with a maven plugin that provides instant reload on saving changes of a class or any project resource. With Payara Micro I achieved hot reload on saving a change of a class or other resource in approx. 4-5 seconds with a fairly simple shell script. This might not be a ‘real’ J EE topic, but it is something that heavily affects devs that work with J EE.