Embedded network devices from cell phones to set-top boxes are useless in isolation. Plus, though they may work with their peers, they rarely implement a peer network, instead requiring a server. Sun Micro-systems would like that platform to be Java, or more specifically J2EE (Java 2 Enterprise Edition). Microsoft wants to use a .Net server instead. But either approach can be fraught with long-term danger and benefits.
Both platforms are built around a virtual machine (VM), and multiple vendors offer the Java Virtual Machine. The .Net VM ECMA-335 (www.ecma.ch) is relatively new, and a couple of VMs are in the works, though only Micro-soft's contribution has made an impact on developers so far.
J2EE and .Net define an intermediate language to describe execution, yet typical implementations take things a step further with translation to machine code for increased performance. This might be done using just-in-time (JIT) compilers or ahead-of-time (AOT) compilers. The two environments are surprisingly similar, even to the extent of having garbage collection as a required feature. The big problem is that this low-level specification is just the tip of the iceberg.
The ability to execute Java bytecodes—the intermediate language for Java—doesn't provide J2EE compatibility. Rather, J2EE is a framework consisting of dozens of class definitions that offer a wide range of services. The same holds true for .Net with its Common Language Runtime (CLR). Without these, the server-based environments wouldn't exist.
Note this important distinction because such support provides communication and services to devices that access the servers. This may happen by using standard protocols like HTTP, and by employing standard formats such as XML. However, the lack of compatibility at the servers for higher-level protocols prevents de-vices from working with the servers. No information exchange takes place without the servers.
Here's the rub. Creating the server code that runs above the VMs and even the basic services defined by the platform is a daunting task. Java has an edge here.
The Java Community Process (JCP) was used to define the standards for J2EE, which led to a wide range of J2EE-based server products. Compatibility between platforms re-mains an issue, but not as much due to the open standards process. Still, there's a significant product difference in the area of tools, management, and additional services.
Microsoft more tightly controls .Net. Also, .Net is a relatively new environment. It's unlikely that major third-party competition at the compatible platform level will arise, but the possibility always exists. In the meantime, .Net server development will mean using an x86 platform running a Microsoft operating system.
The big question is whether or not J2EE developers can wait for version 1.4 and its XML support. Likewise, can Microsoft deliver on its .Net promises, or will the manufacturer continue to make changes to its de facto standards as in the past? OLE, anyone?
Java and .Net sit on the client side too. Java supplies a greater number of selections because it has been available longer. Microsoft is improving its client and server solutions, although the choices available to developers will likely be limited. If choice isn't an issue, Java may not have the edge.
Have you made a choice yet? Drop me an e-mail about which platform you support and why.
