In-Depth
Can Java save Corba?
Fearful of Microsoft's desktop domination, Corba backers have jumped on the Java bandwagon as a way of infiltrating the desktop. The theory goes that as Java transcends the native operating system, Corba will transcend the "native" DCOM. Realizing that the Internet model demands free distribution, these Java ORBs (most significantly the Netscape/Visigenic ORB) will have zero incremental cost over the cost of the Netscape browser.
To buy this theory it is also necessary to buy into the idea that Java will transcend the desktop. However, there are many reasons it might not. The part of Java that needs to ascend in this theory is really the Java Virtual Machine. These ORBs are really VM byte codes, and their source language is not relevant. Can the Java VM dominate the Internet World? I don't believe it can. Take, for example, recent evidence that JavaSoft has backed off from its 100% Pure Java campaign. It turns out that every truly interesting Java program was breaking out of its sandbox to use native methods. In the end, developers and users will demand the security of sandboxing and the performance of native code -- that is, a secure operating system with memory protection in hardware.
The VM has one fundamental purpose: to implement memory protection in software. To do this is to give the boot to any language that uses pointers (C, C++, Pascal, Fortran and so on), as well as take a major hit in performance. So why memory protection in software? One reason would be to dispense with the hardware for memory protection (which can take up to 10% of the CPU to implement). Clearly this is not an objective for most computers where memory protection is a requirement for reasons other than running Internet applications. Remember that Java has its roots in embedded programming, and that most embedded processors and no DSPs provide memory protection. Even here there is a tradeoff of the additional overhead of the virtual machine versus the overhead of adding memory protection in hardware. My bet is on hardware protection even for embedded applications.
For desktops, the Java VM would have never taken hold at all except for all the lame Windows 3.1, Macintosh and yes, Windows 95 systems, which don't offer adequate memory protection through the operating system. This means it is not going to be easy to sandbox arbitrary binary applications on these systems, but it is going to happen. And at that point, the Java VM may join UCSD P Code and all the other virtual machines on the trash heap of discarded ideas.
In my opinion, Corba vendors should not put all their eggs in the Java byte
code basket. Robust, free and native binary implementations for Windows and
Macintosh systems are necessary for Corba's survival. Microsoft's desktop domination
does not cede them ultimate domination of the network, but the lack of any real
competition will.