Microsoft and the Java community have been battling for the supremacy of the enterprise software arena for some time. Each shares similarities with the other, yet differences abound. Let’s take a look at each.
In J2EE, you have Java, an object-oriented language designed to compile into Java bytecode and run on any platform that has implemented a Java Virtual Machine (JVM). In .NET, you have your choice from a variety of object-oriented languages including C#, Visual Basic, and Visual C++. These languages compile into an Intermediate language (IL), which is designed to run on Windows within the Common Language Runtime (CLR).
In one instance, you have a single language that’s designed to run on any platform; in the other, you have multiple languages that are designed to run on a single platform. This is an oversimplification that doesn’t include the introduction of open source projects such as Mono and JVM support for multiple languages, but let’s accept this as a generalization.
So why choose one over the other? This is a question that needs to be answered by every IT director in today’s world of enterprise software. In J2EE, you are restricted to a single language, yet the code you write can run on a variety of different platforms. This is the essence of Java’s ‘write once, run anywhere’ mantra. In .NET, you have a number of different languages to choose from, but you are restricted to a single platform – Windows. This is a philosophical decision which needs to be made, but there are other factors to consider.
In .NET, you are entering the world of the Microsoft enterprise software suite. This means that all of the pieces of the puzzle, from the operating system, to user provisioning, to databases and LDAP directories, have been architected from the ground up to work seamlessly with one another. In other words, when you buy one, you inherit the suite, an entire platform designed to work together.
In J2EE, however, an enterprise can pick from a selection of different technologies. J2EE provides a specification, but the individual J2EE vendors build their own components to that spec. This enables the J2EE enterprise to choose the best of breed from a collection of vendors and build a single system which best suits their needs. It may not have been expressly designed to work together, but the J2EE enterprise can create a unique solution to fit their requirements.
J2EE vs. .NET introduces the question of open source versus Microsoft. For example, who supports open source? Who protects you from patent infringement and copyright violations by the authors of your open source software? What is the open source service level agreement?
Turn that around with the open source questions back to Microsoft. Is my solution nimble enough to change at my company’s pace? Does my platform offer the flexibility and freedom to design my code the way I see fit?
Do I buy the suite or do I build my own? This is a question for the ages. And yet there are other considerations. For example, J2EE admins cost more than .NET admins. Security is another consideration. Linux and Solaris are considered by many to be more secure operating systems than Windows. On the other hand, open source code can come from anywhere, whereas .NET products have been put through the Microsoft design process where all developers have met a certain bar. The list goes on and on.
In the end, the IT director needs to determine the most important needs for his enterprise. He has two different schools, two different religions, and he’s forced to choose one. The battle rages on, but hopefully this has given you a better understanding of the players.