What Went Wrong with Enterprise Java – InApps 2022

It’s been a long strange trip for enterprise Java. Marketed as a panacea for enterprise development, the promise of Java’s type safety and memory management seemed to point to a future where Java would be the lingua franca of business.

Unfortunately for Java developers, Java 2 Enterprise Edition (J2EE), as the Java Enterprise Edition was originally called, was hampered by XML verbosity and complex configuration routines. It was designed by committee and voted on over time. Updates took years, and were written first as specifications, then implemented, then ratified into being. Only after all of this work was the code released to the public, and only then were the problems found.

Enter Spring framework. Originally created by Rod Johnson in 2002, Spring was designed by developers, for developers, as Spring’s designers were building the framework and based on developer feedback. It went on to capture a significant portion of Java developers.

In 2009, Johnson sold his company, SpringSource, to VMware, and for a time he walked away from the community and the business. SpringSource went on to form the basis of Pivotal, and today, it makes up a healthy portion of that company’s main line of business.

We caught up with Johnson at the SpringOne event in San Francisco last month, and discussed his new company, Atomist, and chatted about the current state of Spring, the future of continuous integration/continuous deployment (CI/CD), and just what went wrong with enterprise Java.

What problems were you solving with Spring back in the day that, perhaps, still exist today for developers?

I think the biggest problem back then was that everybody invented everything all the time. Back in that timeframe, 2001-2004, you had J2EE, which was borderline unusable. There hadn’t even been the open source frameworks like Struts that did some of the work and simplified things for you. There wasn’t even the concept of continuous integration. It was Make in every environment. The code you had to write was incredibly complex.

The next problem was that absolutely everything was ad-hoc. You had people using JavaC, even ANT was relatively new at that point in time. Clearly, the biggest pain point was that it was so hard to build applications.

Now you see automation has progressed a lot. Obviously, Maven solved the build problem in a way ANT didn’t, through the notion of a centralized repository.

Everyone does continuous integration now, unless they’re crazy, and you still have problems around trying to observe what’s happening. You have problems around consistency that didn’t exist before.

You wanted to change something in J2EE, you’re going to sit in a room with people who specialize in sitting in standards bodies for IBM and Oracle.

There were good things about those days, too. One good thing was that you didn’t have many applications. Even by the early 2000’s, you had decent tooling for your monolith. You got to actually work on the code on your monolith in a consistent fashion. Now you can’t do that anymore. You don’t have one to five monoliths, you have one to 500 much smaller services. There’s a new class of problem where even if you have a decent pipeline for all those services, you’ve got a lot of stuff going on. People are collaborating in groups around those services and deployments are happening at different times for different services.

So I don’t think it’s been uniformly better: we’ve created some new problems as well.

This SpringSource event seems to be replacing JavaOne, which Oracle merged onto its main floor this year. Did you ever expect Spring to take over the Java community like this?

This is totally what I always envisioned for Spring. I absolutely dreamt of this. In fact, in the early years of Spring, I had to go a little quietly about this even with the Spring team: saying that J2EE should die. Even in the Spring team in 2004 not everyone would have been comfortable with that idea. If I said that in the community, it would have been wildly controversial. Now it’s finally happened. Oracle has pretty much given up on J2EE.

Should Java EE have been contributed to the Eclipse Foundation years ago?

Should it have happened years ago? Maybe it would have made more of a difference if it had happened years ago. I think, unfortunately, that it proved that having a standards process at that level of the stack was just not the way to go. Ruby on Rails didn’t come from a standards process. Node.js didn’t come from a standards process.

Second, with a standards process, despite the fact people criticize spring for being “proprietary,” if you want to change something, you make a pull request; where if you wanted to change something in J2EE, you’re going to sit in a room with people who specialize in sitting in standards bodies for IBM and Oracle. You’re going to find your desire to live is severely compromised before you achieve anything.

I think, to be honest, that Oracle are doing a good job with Java. I really like what they’re doing with Java. I think having a strong body that controls Java and formality around the Java Community Process (JCP) makes sense, but it just didn’t work at the EE level of the stack.

Your new company, Atomist, is focused on the whole lifecycle of software, and uncovering all the information in the CI/CD and management process with overall management. Why did you choose this field for a startup?

Continuous integration is changing in that you’re building more things, but the builds are simpler. It’s a different problem from 10 years ago. Now you’re probably having 100 little builds of things that are way more prescriptive. Spring wasn’t particularly prescriptive. Spring Boot is extremely prescriptive. I think to some degree we’re dealing with a different problem: lots of builds that are simpler.

In terms of the interesting aspects of CI/CD, we’re not directly going after CI. We’re not trying to replace Jenkins. What is really interesting is trying to fill in the overall pipeline, so more of the steps people do are automated, and secondly so that it’s easier to observe what’s happening.

I like to say CI is necessary, but not efficient. If you don’t have CI, everything will fail because you don’t have the feedback loop. Nevertheless, people try to use it for things it can’t really automate, because you don’t have the context of the model behind it. You end up running Bash scripts in the sky, but there’s a reason this is a conference about building services in Spring and Java rather than Bash.

What’s new and interesting out there? Seeing new language being used, like Go?

I haven’t seen a lot of enterprise use of Go. Having said that, maybe it’s partly selection bias. Java is doing really well. Kotlin is increasing significantly. Scala is doing OK, but I wonder if Kotlin is taking away the potential for its growth. I am massively enthusiastic about TypeScript. There is a ton of growth in Typescript as well.

I think TypeScript is probably the most important language right now, because if you think about languages, you could think about a language that’s ideal and wonderful and makes something like 50 times better, but if it isn’t easy to adopt there’s no point. You can think about a language that’s incredibly easy to adopt and makes everything twice as good. The former is Haskell, the latter is TypeScript.

TypeScript makes JavaScript twice as good, and that’s a conservative estimate. It takes an astonishing amount of things you need to do and means you’re going to be significantly more successful. In terms of impact, TypeScript is the most important thing right now possibly.

Photo by Larm Rmah on Unsplash.