My Java Experience
time to read 6 min | 1142 words

As I mentioned before, I am actively trying to find what I don’t know, and plug it. As part of that endeavor, I spent the last week learning Java EE. I decided that in the interest of saving time I am going to invest some money and I took a week long course in it. That allowed me to kill several birds in a single stone, I got to experience Java in an environment that had an instructor that I could call on for help, it allowed me to learn Java EE and it allowed to me experience how people using Hibernate Profiler feel like.

Now that it is over, I can say that the course has met my expectations to a T. But that isn’t the point of this post. I wanted to talk about what I learned and my experience.

Nitpicker corner: please note that I am talking only about Java EE and EJB 3.0. I am well aware of the existence of frameworks that build on top of that (and earlier versions), but right now I intend to discuss Naked Java EE.

From language perspective, working with Java was incredibly frustrating. I had not really realized how much I come to rely on such things as object initializers, the var keyword or null coalescing operators.

As a platform, I have a much better understanding for how the Java EE eco system developed. Basically, it works like this (the concepts does not translate exactly, mind you):

Java EE .NET
Servlet Http Handler – but with singleton semantics & with threading issues.
JSP ASPX – but without any code behind.
Listener Http Module

One of the things that really drove me crazy is the notion of making everything a singleton. I wonder if there was a time where object creation in Java was very expensive, that might result in this design. The problem in making everything a singleton is that it become shared state, which means that you need to handle concurrency yourself. This is a bad thing. In fact, I would go further and say that any framework that requires users to handle concurrency for standard scenarios is flawed.

When I learned that you had to wire each independent servlet in the web.xml, I was quite shocked. The sheer friction that this is going to add to a project is mind numbing. Imagine the camera unzooming, and the full picture showing up. There are usually very few servlets in an application, often only one. They handle the request by sending the data to an EJB to handle the business end and a JSP to handle the HTML generation end. If it sounds a lot like MVC, it should. The interesting bit is that I don’t think that all the Java MVC frameworks came out because of anything unique in the Java sphere. They came out of sheer self defense out of the amount of toil & trouble that you have to go through using what the bare bones Java EE gave you.

Moving on to what I would call the controller side of things, we have EJBs, Enterprise Java Beans. There are Session Beans and Message Driven Beans. The MDB reminded me quite strongly of a very basic service bus. Considering something like Rhino ServiceBus or NServiceBus, it looks very similar in concept and execution, but without a lot of the things that the those two do for you. Session Beans are supposed to handle requests, they are divided into stateful and stateless beans. In general, I seems that you would generally use the stateless beans.

A stateless bean is a class implementing a specific interface, and that is where a lot of the interesting things are happening, dependency injection, automatic transaction management, session management, etc. It is interesting to note that with .NET we have gotten to the same result, but without having the overreaching presence of the container everywhere. I really like the fact that there is no attempt to disguise how they are doing things, the Java’s language decision to make everything virtual by default has really paid off in here.

Still, I can’t say that I like the default architecture, it seems very inflexible. I do like the ideas of full blown servers that you can just deploy a file into. It is a very nice concept, but it has some sever downsides, the time that it takes to do a modify-deploy-test cycle is significantly larger than what I noticed on the .NET side of things. And keep in mind that I am talking about projects that had about 5 classes in them all told.

During the course, the instructor said something that I found very insightful, “the tooling help you deal with… [wiring the xml, inheriting from the appropriate interfaces, etc]”. I found this very telling, because up until then I was quite puzzled by the behavior of all the standard wizards in Eclipse. They seem to violate the KISS principle, especially after getting used to the Yes, Dear experience when using R# on VS. It was only after I realized just how much work those poor wizards had to do for me that I understood what was going on.

After the course, I took a look at some of the MVC frameworks in the Java market. Just reading the tutorials is fascinating, from a code archaeology perspective. You can clearly see that Struts came early on, since while I am sure it is an improvement over Naked Jave EE, the amount of XML you have to deal with is not funny.

All in all, I find myself unimpressed by the amount of work that was shuffled to the tools, it doesn’t seem right. And it seems like a justification of a bad practice. When I consider my own design principles (Zero Friction!) in light of this, I am much happier that I am mainly working in the .NET world. But I think that having this understanding is going to be very helpful moving forward.

Tweet Share Share 39 comments
Tags: