Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java 1997: A detailed look at where Java's going this year and in the near future

Java has made a tremendous splash in its short life. Find out how industry strategies and hardware/software innovations will affect the future of this prodigy

By Dave Orchard, JavaWorld.com, 06/01/97

We got our first glimpse of Java back in early 1995 with the HotJava browser, and Sun released the JDK 1.0 in early 1996. Now, more than a year later, Java has seen its second major version, with the release of JDK 1.1 three months ago. The hype surrounding Java (particularly the 1.1 release) has been incredible, and it's clear Sun's Java technologies have opened up a potentially huge new marketplace for software consumers and developers. In fact, any developer who hasn't yet found a niche in the world of Java might as well start waiting tables.

Contrary to typical media hype, the Java build-up has not been empty: Look at the amazing number of run-times, components, and tools that have been delivered. Java 1.0 has been incorporated into or is available on every major operating system, ranging from desktops to workstations to mainframes. And soon, the original goal of Java, embedded systems, will be realized. Indeed, with Java in consumer electronics, the circle will be complete. Development environments from all the usual suspects -- Symantec, Borland, Microsoft, and IBM (not to mention the others who didn't want to be left in the cold) -- are now stable and in full release. Indeed, Java-to-native compilers for most processors will be available soon.

JavaSoft never intended to have Java and its class libraries do everything. (Some people -- myself included -- believe that Arthur Van Hoff's "Just say no" attitude toward too much non-essential work being done on the Java language, has been sorely missed at JavaSoft.) To extend the built-in libraries, companies like Netscape and Microsoft have been hard at work designing class libraries from windowing additions to cross-industry frameworks. Such industry-wide acceptance is surely a recipe for success ... or is it?

The old adage about shovel vendors making more money than gold-diggers is holding true for Java. Seems just about everybody is a contributing author to a Java book or a columnist for a Java magazine. And although small and mid-size Java applets and applications (which most often are free) are currently the norm, full-blown applications -- Corel's WordPerfect for Java springs to mind -- eventually will provide the bulk of the Java revenue stream.

One part JavaSoft

JavaSoft controls Java specifications and is currently the de facto standards body for Java. Similar to the C language that came before it, Java is composed of several components -- the language itself, the virtual machine (VM), and class libraries; the inherent fragmentation and conflicting owndership make it vulnerable. In an effort to steer clear of the misfortune and disintegration of the C language standard (the original C dream was "write once, run on any Unix" -- sound familiar?), JavaSoft has introduced the "100% Pure Java" initiative to ensure 100% compatibility among third-party virtual machines and class libraries. In keeping with the initiative, a Java component, virtual machine, or class library vendor must submit to a suite of tests at a Pure Java lab. Upon successful completion, the 100% Pure Java logo is granted.

Speaking of standards, eventually JavaSoft will release portions of Java to a standards body. A preliminary ISO meeting was held earlier this year, but little progress was made. Considerable pressure is being brought on Sun by the other Java ISO members to standardize Java sooner rather than later. My prediction is that the Java language specification will be released to a standards body this year, with specs for some of the 1.1 class libraries released in 1998. JavaSoft believes Java must evolve through several releases to stabilize the functionality before standardization can occur. Language changes, like the addition of new types (such as the new void type in 1.1) or the introduction of inner classes, can have huge effects on the VM and compiler. The dream of "write once, run anywhere" will never be realized if developers have to create versions for eight different virtual machines.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.