Skip to content

Why Java?

I am often asked questions like: “Isn’t Java too old now?” or “C# is better on the desktop, so why shouldn’t we use it for our next enterprise project?” or even “Java is far too difficult for our dev. team. I’m told that C# is much easier, so shouldn’t we go that way?”

I always answer that the respective Java and .Net technologies are roughly equivalent (I have my preference, of course) but that there are important differences in the ethos of the developer communities that IMHO make Java a better choice overall.

I don’t want to get into a flame war here, but Dear Developer… reinforces this quite nicely:

Here’s my point: some of the most influential books on software development and programming such as …hold a vast, deep and rich knowledge of the craft of software development that VB/VB.NET developers are mostly ignorant of. …they should take a look at Enterprise Library from the Patterns and Practices Group at Microsoft (…) for it can save them time, cost and effort in common development situations. I even tell them that it is open source, which means they have access to the code. However, I don’t get much excitement from their part, …, I haven’t even heard of one VB developer simply using Enterprise Library in his projects. The same goes for projects like nHibernate, the Castle project, NUnit, even mocking tools like Rhino.Mocks and Moq. That’s very sad, because by not using some of these tools, VB developers tend to stay far behind common practices such as TDD and technologies like ORM tools…

It comes down to: which group of developers is going to create better quality software? This is not a “my for loop has better syntax than yours” question, but a question that speaks to the fundamental ethos of the developer group; to their willingness and ability to embrace and improve with new tools and techniques.

I have witnessed several .Net teams operate and it has always seemed to me that they have been pushed into adopting the technology and are looking for the minimal step to take, for the minimal change to their toolkit or their technique toolbox, for the quickest way to return to their comfort zone.

This is not universal, of course (trust me; I have seen things come from the Java/J2EE communities that would curl your hair!) but my experiences point to the truth of what I have written.

To me, this is the key differentiator.


C, Java Enterprise Edition, JEE, J2EE, JBoss, Application Server, Glassfish, JavaServer Pages, JSP, Tag Libraries, Servlets, Enterprise Java Beans, EJB, Java Messaging Service JMS, BEA Weblogic, JBoss, Application Servers, Spring Framework, Groovy, Grails, Griffon, GPars, GAnt, Spock, Gradle, Seam, Open Source, Service Oriented Architectures, SOA, Java 2 Standard Edition, J2SE, Eclipse, Intellij, Oracle Service Bus, OSB