Catching Up On the Server Side
Pages, Portability, Problems
Fat and Rich—Furthering the Lead
The Microsoft Mobility Mission
Forms, Clients, and Developer Kudos
End-User Productivity Really Does Matter
James Governor
September 24, 2002
This Internet-browser-delivered, page-based model leads developers to build GUIs that are less rich than traditional Windows-based clients. The affinity between J2EE and thin clients may only be a "soft affinity"—developers are free to build extensions to client interfaces as they see fit when building applications. However by doing so they also reduce portability. J2EE allows application portability to some extent, but client-side JavaScript and support for other client-side markups such as DHTML and XHTML is patchy at best. In fact, the inability of Sun and its partners to establish Java as a single desktop standard to compete with Microsoft is one reason that so much Java development and processing was handed off to the server.
Java 2 Standard Edition (J2SE) could in theory become a decent rich-client platform—but only if its performance and standardization problems are eliminated first. Can you imagine building everything using applets and JSPs?
One specialized example that clearly shows the limitations of client-side Java is Swing, the highly portable GUI mechanism for creating Java integrated development environments (IDEs). Swing is used by Oracle, Sun, and BEA—but in ways that show that portability comes at a price. Swing doesn't take advantage of any native systems calls or windowing functionality. Swing performance is frighteningly bad—and that's being polite. Java developers know the sinking feeling upon downloading a brand new shiny IDE only to find their decently spec'd workstation then slows to glacial speeds. So much for the rich Java client!
IBM's Eclipse-based WebSphere Studio shows that it doesn't have to be this way. By taking advantage of native systems calls it offers much better performance. Eclipse is an open source initiative, and Eclipse-based IDEs blow away anything we have seen using Swing.
Ironically, development is another function where fatter clients are more appropriate. Developers need big, fat, juicy clients with powerful local processing. The last thing a developer wants to do is send an app across to a server in order to run a compile. An environment such as Rational XDE, which includes powerful modeling within the IDE, needs powerful client functionality. It is no accident that Rational chose to build XDE on top of IBM's open-source Eclipse foundations.
Java 2 Mobile Edition further illustrates some issues with client-side Java. While J2ME is a standard that developers enjoy using to build powerful client-side functionality, it still lacks standardization at the GUI level. Every wireless carrier adopting Java has its own set of extensions—be it DoCoMo, KDDI, or Sprint. J2ME allows good enough portability to appeal to developers (who only need to know one language for programming mobile apps) without offering true simplicity of testing and deployment. J2ME promises developers they can write an app once, then test and debug it everywhere, not write-once run-anywhere. That has not stopped J2ME from being widely deployed. It has far wider mind- and market-share than its Microsoft equivalent, but this is more a function of political and competitive issues than functionality.
 |
|
 |
|
|
|
|
|
|
|
|
|
|
||||||||||||