.NET: Pride and Prejudice
We can't get around talking about Microsoft, can we? Redmond has spent three and a half years and US$2 billion dollars to create .NET -- the be-all-end-all of Networked Enterprise Programming ... for Windows. Unsurprisingly, Microsoft is pushing its advertising tendrils deep into the J2EE and J2SE community, seducing and beckoning innocent little Java-minds.
Just to let you know where I stand: Unlike a lot of programmers, I'm not a rabid anti-Microsoftie. I use Windows 2000, Word, and Excel daily, and while I have my fair share of crashes, conundrums, and complaints, I don't think these apps are half bad compared to lots of other software I've had to deal with.
Yes, Microsoft's monopolistic and opportunistic worldview offends me. Yes, I realize that Microsoft only makes good development tools and Web browsers to ensure the hegemony of their operating systems. Yes, I know Microsoft only has their best interests at heart in the end. Yes, yes, yes. But it has always seemed to me that, for better as well as for worse, they know what they are doing.
So if I'm going to really review .NET as a platform for today's Java developer, I'm going to have to be less idealistic, and less philosophical. I'm going to have to be practical.
Microsoft's come-on is detailed in their JUMP to .NET page. Their targets are those who use Visual J++ (which I actually liked a lot as a Java IDE), as well as fresh-faced Java developers looking for another solution to address some of Java's shortcomings. Basically, Microsoft is pushing two products.
The Microsoft Java Language Conversion Assistant is a tool that automatically converts existing Java code into C#. This, of course, is the best thing Microsoft could hope for. Just click a button and your kingly cross-platform, cross-device code is suddenly zapped into a pure Windows slave. The tool, to Microsoft's credit, does work pretty well. And if you're thinking of learning C# or just seeing exactly what the differences are, this tool can help you out.
The second product is Visual J#. This IDE essentially allows you to use the Java syntax to create .NET objects. The Visual J# program makes it pretty easy to import existing Visual J++ projects and code to the Visual Studio.NET format. Microsoft is clear to point out, "Applications and services built with Visual J# .NET will run only on the .NET Framework, and will not run on any Java virtual machine. Visual J# .NET has been independently developed by Microsoft. It is not endorsed or approved by Sun Microsystems, Inc."
So what do I think of this all?
Once again, Microsoft clearly and frighteningly knows what they're doing.
|Whenever we make a change to our application, we first code it in the Java applet, test it out, then migrate it all to the .NET way.|
Let me give you an example. Recently, my company needed to create a sort of instant messaging client. We wanted to build a standalone application with a slick and familiar user interface that could be immediately distributed and deployed. I would have loved to use pure Java, but it just didn't make sense -- we couldn't justify forcing our users to download a mammoth Java Runtime Environment.
But we didn't want to back ourselves into a pure Windows solution. We did want to handle the Mac and Unix crowd, small as it was, as well.
So we prototyped the application as a Java 1.1 applet. The user interface looked so-so. But it ran well and allowed Mac and Unix people to access our instant messaging servers via their Web browsers.
Taking the Java code as a base, we then converted it over and used Microsoft's Visual tools to throw on slick interface components such as Tree Views, Task Bar icons, context menus, and colorful Rich Text Format boxes. Microsoft's development environment made it extremely easy to create a professional, quickly downloadable, and fully functional Windows application ... something that would have been pretty much impossible to do with pure Java.
Whenever we make a change to our application, we first code it in the Java applet, test it out, then migrate it all to the .NET way. It's a little bit of pain to go through the two-step process. But it actually solves our needs.
Do I wish that most of our customer's computers supported an advanced version of Java so that we could avoid proprietary formats? Do I wish that Java's Swing interface components were as stable and full-featured as Microsoft's widgets? I do, I do, I do. But here in the real world, Microsoft's solution actually pans out -- as long as Java is at the core.
About the Author
David Fox is the author of numerous books and articles about cyberculture and technology.