Java jihad against the infidels at Microsoft doesn't quite convince
Java at the enterprise level dangles several promises: Truly open computing, sharply lower client administration costs, big savings in total cost of ownership, rapid development and deployment, fuller use of legacy systems and better security. Open computing, or open systems if you will, has long been the dream of Unix and every other recent operating system from OS/2 to NextStep and Microsoft Windows NT. But I don't believe we're any closer to open computing than we've
Java at the enterprise level dangles several promises: Truly open computing, sharply
lower client administration costs, big savings in total cost of ownership, rapid
development and deployment, fuller use of legacy systems and better security.
Open computing, or open systems if you will, has long been the dream of Unix and every
other recent operating system from OS/2 to NextStep and Microsoft Windows NT. But I don't
believe we're any closer to open computing than we've been for the last 15 years.
Sun Microsystems Inc., which controls the new language, claims Java's strength is in
not being controlled by a single company-read Microsoft Corp. If we're ever to see really
open computing, there must be an end to these silly holy wars between companies seeking
only to advance their own products.
Reduced cost is the mantra of all the big computer companies. Unsurprisingly, Sun's
vision of reduced cost requires you to buy the network computer, Java, Java Beans and Sun
servers. Its rivals are Microsoft and Intel Corp. They want you to buy the NetPC, Windows
NT, the Win32 application programming interface and Intel servers.
I suggest that if these companies gave superior technical support, which would cost them
more money, it would do more to lower our total cost of ownership than any hardware or
software changes.
Every survey I've seen ranks support and training as the most expensive fraction of
overall cost per user. Hey, Sun and Microsoft, why not help us reduce that?
Java as a programming language is really just C++ stripped of several features and
constructs. The only thing I consider novel is that it runs inside a virtual Java machine
on the client. Some refer to this as Java's sandbox, the idea being that Java plays only
on its own turf.
This sounds like the old good news/bad news routine. The good news is Java applets and
applications are a bit more secure. Notice I didn't say really secure. And with fewer APIs
to deal with, it may be a bit easier to build small apps.
The bad news is the Java virtual machine is implemented differently on all platforms,
so its cross-platform promise is limited. Within the sandbox, you don't have access to all
the API hooks into the operating system and other applications. This might cripple some
applications.
The rapid maturation of the Java concept has not been accompanied by similar maturation
of its rapid application development tools. In a few years that might change, but for now
it's a severe limitation, in my view.
Using Sun's Java APIs, you can build Java-based applications that tap into legacy
systems through easy-to-use browser software. That's true of all the other programming
languages, too.
Sun recently announced extensions to the Java sandbox that weakened the security
hard-coded into the security manager Java applications use.
Security policy now is expressed in a separate, persistent format. Security is
configurable. If allowed by an enterprise's global policy, even end users can redefine
their desktop policy.
The policy configuration file uses a simple, extensible syntax that lets you specify
access to specific files or particular network hosts. Access to resources can be granted
only to code signed by trusted principals.
The sandbox is generalized so that applications of any stripe can use the policy
mechanism. This means you can build an application with a policy that's separate from the
application's implementation.
Developers can define new resource types with fine-grain access control. They need only
define a new permission object and a method that the system invokes to make access
decisions.
The policy configuration file and policy tools automatically support
application-defined permissions.
Pot calling kettle black?
To me, these extensions sound a lot like the same features that Sun criticizes in
Microsoft's ActiveX.
Unless specifically prohibited by the administrator, users can leave gaping security
holes on their desktop machines. Outside applications can modify policies to interact with
other applications and read/write to users' disks.
Below the surface, I believe Java can be a useful developer tool, but it doesn't have
such superior features that it will make all other development tools obsolete. Think about
it, and let me know if you agree.
Charles S. Kelly is a computer systems analyst at the National Science Foundation.
You can e-mail him on the Internet at ckelly@msn.com. This column expresses his personal
views, not the official views of NSF.
NEXT STORY: Health records project hits pay dirt