Java

I took a Java development class years ago (back in 1999, I think). I learned a lot. I even used Java to build a server-side utility. It was quite simple, but it did have database connectivity, etc. It was nice to try it out and practice what I learned. Since then, I have been exposed to Java and its stack of technologies, but nothing hands-on.

About a month ago that all changed. My team is now deploying two Java-based 3rd-party products. The first is going through the pains of load testing, QA and production deployment. Not just little pains, but serious kidney-stone-type pains. I have learned a lot about Java during this time. I can’t help but compare it with what I know about .NET and my experience with Microsoft technologies. Here are my observations.

Application Server Confusion

This is the big one. Java has no single technology stack. You have to choose one. We have a new stack just rolled out. Our team is going through the pains of working with systems analysts and engineers who are just learning how to use the new stack. Whether it is JBOSS, Sun’s app server, weblogic, Websphere, or whatever; you have to learn and ramp-up on that app server’s quirks, expectations, deployment methodology, configuration management process, etc. Although some things are uniform across these stacks, a lot is not. “You have to unlearn what you have learned”.

.NET has one app server. One configuration management story. One runtime. I agree, there is lack of choice (i.e.: no choice), but therein lies simplicity, and therefore power and freedom. (I know, I know, you can run .NET on Linux with Mono, but seriously, who really does that? Is that really an alternative to Windows and IIS?) If I want to run a .NET web app, I just need to know Windows Server and IIS, nothing more. I don’t need to buy anything. I just buy a commodity Windows server and I am ready to roll.

Deployment

Deployment is not easy in the Java world. Maybe I am just a newbie, so it all seems complex, but man, working with wars, jars, deployment descriptors, config files, etc, can be a mess (this sentence has WAY too many commas). Especially considering migration from one environment to another, these obstacles can get even larger. Let’s say you move from your development environment to QA, you have to build a new war file with different deployment descriptors, set up your app server, data sources, etc, and deploy the application. It sounds easy when someone says, “To deploy an application, all I have to do is just drop a war file on the app server”. That is a lot more complicated than it sounds.

.NET eeks-out a win on this one, but not by much. It can be as easy as running an MSI file, but it can get as difficult as managing a mess of dlls, DSNs, config files and custom IIS settings. But, if done right, deployment can be quite simple in the .NET world. A lot of the ease, I think, comes from the unified/standard configuration system.

Operations Ramp-Up

If you look at the difference between the time it takes to learn how to use Linux/Unix/Solaris from an operations perspective versus Windows, you have to admit, there is a vast difference. This is more of an OS-specific thing, but it has tremendous bearing on the ability of operations staff to deploy, change and manage an application.

Windows server admins may be a dime-a-dozen, but that is because it is so much easier to learn. This means cheaper resource costs and quick ramp-up time and quicker time-to-market.

I am sure there are others. Maybe I will continue this later. Maybe not. Maybe I am just a Java bigot. Maybe not.

Leave a Reply