Java against the (Microsoft) world
Does the war between the Java camp and Microsoft really matter?
I learned programming on Wang VS systems back in 1986 using Wang COBOL. A year later, I moved into C programming on an IBM-AT machine with Microsoft Quick C and Borland Turbo C. Another year later, I took my newly acquired C programming skills and began programming on an AT&T Unix System V. I continued programming in C (and later in C++) on multiple flavors of Unix systems — everything from SCO Unix to Amdahl to AIX to Solaris. Sometime in 1992, I got involved with programming on Microsoft Windows systems using Borland Object Windows Library, followed by Microsoft Visual C++/Microsoft Foundation Class Library and Visual Basic. From a user perspective, I actually began using Microsoft Windows 2.1 in 1987 and have used office applications (e.g., Microsoft Office, Lotus SmartSuite) on Windows to date; on Unix, I have used packages such as FrameMaker and WordPerfect for basic word processing.
Having had my foot in both camps, that is, Microsoft and Unix, I have seen the pros and cons of each operating system environment. Unix utilities and regular expressions are tough to beat for developer tools. The idea of piping input through a dozen commands resulting in the desired output has always fascinated me, and I still use Unix utilities on Windows every chance I get. Shell scripting on Unix has also been my passion; ksh/bsh/bash are my favorites. On Microsoft Windows, GUI tools with drag and drop and consistent copy, cut, and paste have their significant benefits because they are less error prone than command line tools.
Enter Java
Since I got involved with Java in late 1995, I now pay less and less attention to the operating system (i.e., the plumbing) and focus more and more on the application layer (i.e., the business software). I’ve developed and deployed dozens of Java applications on a variety of operating systems, including Microsoft Windows 9x/NT/2000, Sun Solaris, IBM AIX, SGI Irix, Linux, and Apple Macintosh. Many customer projects involve development on Microsoft Windows and deployment on some flavor of Unix/Linux. Sometimes source code, and even class files, are checked in a version control system, and new class files are automatically picked up by the middleware software (e.g., WebLogic) on the server (e.g., Solaris). In other cases, I simply FTP the class files to the server or just rebuild the application on the server.
My point is that when you adopt Java as your application development technology, the operating system becomes irrelevant. In fact, even other software such as databases and middleware becomes irrelevant, thanks to standard Java APIs (e.g., JDBC, servlets, Enterprise JavaBeans).
The trade-off
One thing I have had to learn over and over again in life is that “you get what you pay for.” After six years of working with Java, however, I’m still looking for the catch. Today, any individual or organization can construct an end-to-end, multitier application using complete freeware. This includes the Web browser, standards such as HTML and XML, Java APIs, relational databases, JavaServer Pages/servlet/EJB engines, and much more.
On the flip side, if you want a mission-critical quality environment, you usually pay through the nose. For example, a typical multitier, Internet-based application consists of a Web browser on the client side, an application server (e.g., WebLogic Server) in the middle tier, and a database (e.g., Oracle) on the back end. This can easily cost in the tens of thousands of dollars, depending on the configuration of the hardware this software will be deployed on.
I must admit that the construction of Java applications is not an easy task either. Even though Java development and deployment tools have come a long way, they do not come close to the ease of use of proprietary Microsoft tools such as Visual Interdev. With technologies like Microsoft Internet Information Server, COM/DCOM, and Microsoft Transaction Server included in the Microsoft operating system, the cost of acquiring similar functionality with a Java-based application server such as WebLogic or iPlanet is often tough to justify.
Java forever
Still, I believe Java application development and deployment is the way to go. Use whatever infrastructure (i.e., hardware, operating system, database) you want, but ensure that the application layer is pure Java. Factors such as Java’s performance, challenges of object-oriented development, lack of platform-specific features, and poor development tools are often cited as arguments against Java. Nevertheless, the benefits of Java technology and standards, in my opinion, far outweigh any disadvantages.
Discuss your thoughts in the iSavvix Soapbox forum for this column.
