.NET vs. Java: No Easy Answers

Hi, folks!

Here we go again! Which one do you choose? Java or .Net ? It's difficult to choose, isn't it? Here, you can see an article from ftponline.com , this is very interesting!

See yah''

.NET and Java are both here to stay. How do you choose which is right for you?

At Gartner we believe two platforms will dominate e-business-oriented application development efforts over the next five years: Microsoft and Java. Today, this certainly isn't a rocket science prediction and it doesn't take a crystal ball to see that it's already happened to a large extent. To Gartner's credit, this was a more compelling prediction two years ago when Java's future was much less assured and .NET was still a whispered code name inside Microsoft's R&D labs.

Today the subject of Microsoft vs. Java is the most popular inquiry subject I receive from developers and commercial software vendors. It seems that virtually every IT development organization has two contingents locked in a constant battle to push their favorite platform onto the other. Not to mention the fringe factor that believes Linux and PHP will dominate the world, insisting that we all bow down to the great penguin.

What is surprising to many is that we don't believe there will be a clear and decisive winner in this market-share battle. Unfortunately, no matter which side of the fence you fall on, this is probably precisely what you don't want to hear. Instead, most of us prefer clear-cut victory or defeat—nobody likes a tie. However, both platforms are here to stay for awhile, so this month I'll discuss the competitive relationship between them and strategies for choosing one approach over the other for your organization's development efforts.

Between the two platforms, both Microsoft and Java solutions will collectively make up 80 percent or more of new application development projects by 2005. However, neither will have a substantial market lead over the other and they will remain closely locked and overlapped in many markets. Despite this close competition, there are some emerging trends indicating where the platforms are likely to be adopted within corporate and commercial development groups.

Java Tends to Flow From the Top Down
By their very nature, large IT enterprises must often manage highly heterogeneous data center environments; the average Global 2000 IT infrastructure typically consists of a wide variety of hardware and software platforms (such as MVS, OS/400, Unix, and Windows). These organizations are attracted to Java because of its multivendor and multiplatform features. For instance, if an organization has a long-term relationship with a company such as IBM, Oracle, or Sun, it will likely be attracted to (or coerced into) a Java-centric development strategy. Likewise, if a company has a large mixture of hardware and operating-system platforms, it's likely to look to Java for its potential to deploy an application on Windows 2000 today with the option of migrating it to a mainframe or large Unix platform in the future. In these cases, the promise of portable Java technology across these platforms is highly attractive.

Of course, Java's "write once, run anywhere" ideal is just that—an ideal that falls short of its ultimate goal. To the credit of Sun and its closest partners, they've managed to keep the platform relatively unified—no small feat considering the competitive relationships among them. I receive consistent feedback from commercial Java vendors and in-house developers that indicates most are achieving approximately 80 percent code compatibly when they move from one platform to another. This is by no means perfect, but it is substantially better than anything else on the market today.

Java technology tends to take center stage when companies address technology needs in "big" strategic terms such as best-of-breed vendor selection, long-term architectural compliance, legacy extension, and interoperability.

Microsoft Tends to Build From the Bottom Up
Alternatively, smaller enterprises and small independent groups in larger enterprises tend to lean more strongly toward Microsoft development technologies as their focal points. These groups are better able to consolidate their data centers around a single platform and are consequently better able to commit to Microsoft's technology exclusively (see Figure 1).

Because of the low cost of entry and a strong focus on rapid application development (RAD), Microsoft's platform tends to take center stage when a quick time to market dominates the decision. These organizations are under strong pressure to deliver large numbers of small applications and rely on technology such Visual Basic to deliver them quickly with limited resources.

Figure 1 Make Your Choice

In each release of its operating system, middleware, and development tools, Microsoft continues to dispel the myth that its software doesn't scale. In fact, development teams today are achieving remarkable complexity and scalability with Microsoft and Wintel-based solutions. Yet the company hasn't achieved much respect as an "enterprise" software vendor. Instead, it has slowly marched up the enterprise from its origins as the PC DOS provider, to simple departmental client/server applications, and now to larger scale Internet and e-business-centric solutions.

It is true, however, that it often does take more effort to scale Microsoft-based solutions for very large deployments (typically exceeding several hundred concurrent users) than it does to scale a similar Java application. However, this isn't necessarily a reflection of the software architecture, but rather the available deployment options.

Today, Microsoft-based solutions are limited nearly entirely to Wintel class platforms. In other words, when you choose .NET you also implicitly choose your operating system, middleware, and hardware deployment platform. Alternatively, Java is a software platform largely independent of the underlying middleware and operating system. You choose Java first, then a J2EE application server (such as WebLogic or WebSphere), then an operating system (Windows 2000, Solaris, Linux, and so on). These "choices" can be either a blessing or a curse—with Java, you're allowed to choose but likewise you are also forced to choose.

Ironically, the .NET Framework can potentially be ported to other platforms much more easily than the older Win32/COM technologies. In fact, Microsoft has submitted a subset of the framework to the European Computer Manufacturer's Association (ECMA) open standards committee to be ratified as a true portable and open standard. However, to date, this effort can only be described as half hearted.

The subset of the .NET Framework submitted to ECMA is just enough to build a C# language compiler and its supporting runtime. The problem, unfortunately, is that this technology isn't particularly interesting for real-world solutions because it's completely insufficient to build robust, portable .NET applications that you could potentially deploy across platforms.

Microsoft remains quiet regarding its intentions to submit additional elements of the .NET Framework to ECMA in the future, but don't hold your breath for it to happen anytime soon. On one hand, the company knows that to be fully competitive with vendors such as IBM and be taken seriously as an enterprise software vendor, it must support the same breadth of features as its closest competitor. On the other hand, it also knows that the company's bread and butter remains tied strongly to the sale of its operating systems and its ability to lock customers into a one-stop-shop relationship. I'll cover the details and possibilities regarding .NET beyond Windows in a future column, but you should assume that .NET will remain overwhelmingly Windows-centric for at least the next three years.

Choose Both
Despite any attempts to select either platform as a "strategic" de facto choice, virtually all large development organizations will ultimately have both. This is particularly true for companies that tend to distribute the responsibility for application development among their business units—each unit will generally choose the tools they like the best. It's entirely unrealistic to assume a large national or multinational company will have all Java or all Microsoft technology. For that matter, legacy platforms such as Cobol will also remain entrenched for many years to come.

In these cases the "us vs. them" battle must be tempered with a higher-level integration strategy. Although there are no easy answers to this problem, technology such as Web services standards are beginning to emerge and will allow better integration and interoperability between the platforms in the future.

Ultimately, larger development organizations will be under greater pressure to support both. Smaller organizations that tend to be more resource-constrained should take a more aggressive stance to choose one platform as their nearly exclusive standard. Overall, .NET will be the overwhelming choice for these developers. Moreover, as it matures over next couple of years, we should expect .NET-based solutions to take an increasing role in larger-scale projects.

One of .NET's primary design criteria is its support for multiple programming languages. This is also one of its most important points of distinction with Java; .NET is designed from the ground up to support many types of languages and there are already a dozen or more language compilers available for .NET ranging from Pascal to Perl. No one should take the "in .NET all languages are created equal" story without a healthy dose of skepticism, but the framework's design certainly makes it easier to mix and match languages within a single project.

Java, on the other hand, focuses on a single programming language integrated tightly with the platform. The Microsoft enthusiast might argue that a single language is never the best answer and instead development teams should leverage the right tool for the right job. This person would argue that by supporting Perl, Visual Basic, C++, and so on, .NET enables you to leverage the programming skills your developers have today, without retraining everyone on the team in a new language such as Java. No doubt, there is a compelling truth to this argument.

On the other hand, a Java enthusiast might debate that it's far too expensive and risky for a development team to support so many languages and variants, and that Java offers a consolidated platform that allows IT shops to "train once and write everywhere." Both arguments have compelling points and most developers will find their comfort zone somewhere between these two extremes.

What About Java Inside .NET?
Given that much of .NET's value is tied to its support of multiple programming languages, it would be a tremendous advantage if you could simply treat Java as just another .NET language.

And, in fact, Microsoft has attempted to provide exactly this functionality in its recently announced J# extension to Visual Studio .NET.

J# is essentially a Java language compiler for .NET that generates native Microsoft Intermediate Language (MSIL) code instead of Java byte code. The tool also provides a code syntax translator to convert native Java to J#. Unfortunately, the J# proposition exposes one major limitation in .NET's multilanguage strategy.

First and foremost, Microsoft has already introduced another Java-like language in .NET—it's called C#. Is there really a need for two languages within a platform with nearly identical syntax? Secondly, most truly object-oriented languages are tightly tied to a corresponding class library (Smalltalk, Java, and so on). The .NET Framework contains its own extensive class library that serves as a unifying substructure for the entire platform. If you separate a language from its class library, you effectively remove much of its value. Although J# provides a language syntax, it also forces developers to rewrite all their existing Java applications to the .NET Framework instead of the Java framework. For example, J# won't support Java Server Pages (JSP) but rather .NET's native ASP.NET. This will have a limited appeal to developers with an existing background and expertise in Java development. At worst, J# will cloud and confuse the value of Microsoft's own C# language and at best will serve as a intermediary step along the road to C# for the last half dozen developers hidden somewhere on a deserted island who still use Visual J++.

Both platforms offer choices. Java provides a single language with many deployment choices. .NET supports many programming languages with a single choice of deployment. Both platforms have emerged as de facto standards for next-generation e-business development efforts. .NET will dominate the RAD-oriented solutions while Java will dominate larger-scale "enterprise" projects. Moreover, both platforms will widely overlap in the middle. However, there will be many exceptions to this trend as .NET is increasingly leveraged for larger projects and matures over next few years.

Source: http://www.ftponline.com/