|
INTEGRATION WATCH:
The Faithful Spouse
By Andrew Binstock
 November 1, 2004 — In my last column, I discussed my plans to use Java for future development projects because of the announced changes to Windows APIs. Since those changes will be the third round of API changes Microsoft has announced in five years, I chose Java over .NET purely because I don’t want to keep rewriting the same software.
The cost of constantly evolving APIs is rarely discussed in the tug-of-war between Java and .NET, but I believe it will become compelling as IT departments and ISVs face rewriting existing software anew. My choice of Java APIs says a lot about how much progress Java has made during the last few years—many of the defects from which the platform suffered have now been cleaned up sufficiently that they no longer pose obstacles to adoption. Principal among these, of course, was performance. This issue has now receded due to much faster machines, better JVMs, JITs that emit better-optimized code, and reliance on native methods whenever performance is critical.
The second important obstacle Java surmounted was the lack of good development tools. This need has been met with Eclipse (although JBuilder and IntelliJ were important predecessors). Ant (and soon perhaps, Maven, a build tool from the Apache Software Foundation) resolves the tedium of build-cycle management. And JUnit, of course, has enabled the use of test-driven development on Java. Add to these, the testing, debugging, and performance-measurement tools from vendors such as Quest (formerly Sitraka) and Compuware, and it’s clear that Java’s toolchain is comprehensive, buffed, and ready to go.
The final obstacle to Java adoption had been the user-interface layer. No need to repeat the painful transition from AWT to Swing, and the subsequent realization that even Swing just couldn’t do the job properly.
The Eclipse community’s development of the Standard Widget Toolkit and JFace saved the day by giving client-facing Java applications a proper GUI. They did away with the “metal” widget style and Java’s emulation of Motif and Windows widgets; and replaced them with native widgets that are snappy and responsive for the most part.
The cost is that applications are no longer pure Java in the doctrinal sense of 100% Java and, as a result, portability of SWT is not quite as extensive as Java itself. However, most important platforms now run SWT; if they don’t support the full toolkit, it is generally because accessibility features are missing. Eventually, the full feature set will be in place everywhere. SWT and JFace conclusively solve the problem of the Java GUI.
It might appear that in the transition from AWT to Swing to SWT/JFace, Java is imposing the same kind of API transitioning that led me to move away from Windows and .NET. However, this is not really the case. Should I want to, I can continue to use AWT for my widgets. If I added Swing widgets to the app, I can still use them today, as if SWT never existed. No one is forcing me to rewrite my code and the old API sets are still fully supported. I don’t have to change a thing. This is not true with Microsoft’s APIs. I must change my code for it to work on future releases of Windows.
In addition, it’s important to note that SWT is not sponsored by Sun. In fact, it was developed in response to Sun, and Sun doesn’t like it. In other words, the tools I need are provided in APIs developed by a third-party vendor. To this day, such a broadly accepted third-party extension is not possible in .NET. Microsoft defines all the APIs to the operating system and there is no community developing widely accepted APIs or GUI toolkits for Windows.
I hasten to add that Java’s APIs are no thing of beauty. Many experts are vocal on this point. And certainly the numerous layers of APIs and their almost infinite functionality suggest that learning the full extent of Java is a nearly endless (and probably pointless) undertaking. Personally, I think this is mute testimony to how much Java can do. (Consider, if you will, the vast range of functionality provided in even the minimal implementations of J2EE.) However, the defining attraction of these interfaces is that code written for them does not need to be rewritten. In fact, even writing code for 64-bit Java does not impose rewriting previous code. Old code just runs and early APIs are still supported.
When IT sites consider enterprise applications, they must examine the longevity of their investment in code. When managers choose platforms on this basis, I believe they will find Microsoft and .NET do not provide the needed commitment to code stability.
Andrew Binstock is the principal analyst at Pacific Data Works LLC.
Andrew Binstock is the principal analyst at Pacific Data Works LLC
|
|
Advertisement
Click here for a complete listing of Integration Watch Columns
Click here to see a complete Column Archive. |
Back to Top
|