Moving away from Java EE
Last year I did a talk at the CoJUG in Bogotá about the state and best practices of web development1. There, I explained how Java EE is hurting the Java platform and why we need to move away from it. In this post I will expose the reasoning behind that statement in plain vanilla English.
Let me give you some background first. I worked extensively with Java EE for ten years or so. I’m a SCEA (Sun Certified Enterprise Architect), have a JBoss Seam app in production at elibom.com (my company)2 and used to write about Java EE and JBoss Seam in the past. I was really deep into this stuff.
Not anymore.
But don’t worry. I wont try to convince you about moving away from Java EE. This post is not going to be a long list with the things that are wrong with it. Instead, I’ll tell you what opened my eyes and, hopefully, you will find inspiration to see it for yourself.
A couple of years ago I started to learn Ruby on Rails, Express.js (Node.js) and more recently Sinatra (Ruby) and Flask (Python). I realized that you can create secure, scalable, reliable and robust applications without the hassle of an application server.
Really? How?
Well, you just put your code in a file and run it. Want to check an example? Create a file named app.py and paste the following code3:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run()
Open the console, locate the file and then type4:
$ pip install Flask $ python app.py
There you go, you now have an application running!
What about security, transactions, etc?
Include them when you need them. That’s the way it should be. Each of the mentioned framework has great modules that you can use for everything that the application server “gives you”.
What about standards?
Don’t need them. I can show you unlimited examples supporting this. Companies are adopting Ruby, Python and Node.js successfully and actually finding developers with the required knowledge. All without standards. You might be thinking that this could lead to a maintainability issue in the future but have you tried to maintain an EJB 2.1 application yourself?
So, why do application servers exists in Java?
History and politics.
Remember these big mainframes that cost thousands and thousands of dollars? You had to justify the investment. You couldn’t just pay all that money to install “one” application. Today we are experiencing an important paradigm shift regarding infrastructure with cloud computing. Having smaller instances allows you to scale easily. You don’t need an “application server” anymore, your application should be able to run in one or more small independent processes. It should be self-contained and stateless5.
On the other hand, Java EE is a big industry. The application server vendors sell billions of dollars in “Enterprise Editions”, support and other Java EE related services. Killing Java EE is killing one their products, a profitable one. Their customers include banks, insurance and health companies that couldn’t care less about software development.
What alternatives exists in Java?
Spring has always been a good alternative. They lost direction when they tried to align with Java EE5 but quickly realized the error and got back on track. They are doing a good job by being a step (or two) ahead of Java EE. Recently, you might have read some posts explaining why Java EE is better than Spring. This is “the industry” trying to keep the machine running.
For web development you could use Jetty or Tomcat but there are more complete alternatives such as Play! Framework (a port of Ruby on Rails), vert.x (a port from Node.js) and Spark (port of Sinatra) among others.
The problem with these ports is that they feel weird in the Java language. A couple of months ago I started Jogger, a micro-web framework that takes ideas from Ruby on Rails, Express.js and Flask to create a tailored solution for Java, built from the ground up. The project is hosted on Github if you want to check it out.
Related post: Java web development: back to basics
1 You can actually watch the recording here. It’s in Spanish.
2 We are actually rewriting it in Jogger and Spring.
3 The code is taken from the Flask site.
4 You will need to have Python and Pip installed.
5 This is also the approach of PaaS services such as Heroku.