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

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.

Current VMs such as Navigator’s and Internet Explorer’s use Java 1.02. New Java 1.1 data type features will not work on current software. Developers are left in a quandary. Back in November ’96, I suggested to Eric Schmidt, former CTO of Sun, that there was probably only room for one or two changes to the virtual machine. He agreed and said I was probably being generous with the numbers. I fear that if more VMs are developed after 1.1, the Java market will be fragmented considerably. Let’s hope 1.1 is the final VM.

The new class libraries

Java 1.1 also saw the addition of new class libraries, as well as expanded existing libraries. Licensees — including Microsoft — are required to incorporate core APIs six months after first customer ship (FCS). Class libraries are divided into core APIs and extension APIs. Most of the new class libraries belong to core APIs. These include: Java Database Connection (JDBC), class library signing, Remote Method Invocation (RMI), Internationalization, and JavaBeans (including the new event model), Introspection, and Persistence. These APIs have been covered in great detail in many trade journals and books. Suffice it to say, the additions are fundamentally sound and give Java the level of functionality required for large-scale enterprise deployment.

At JavaOne back in April, JavaSoft announced the Java Foundation Classes (JFC). Based on Netscape’s Internet Foundation Classes, these are sets of GUI components layered on the AWT and IFC. It is crucial that the JFC be rolled out quickly. In fact, it is disappointing that JavaSoft didn’t release a high-performance set of GUI components earlier.

Show me the IIOP

On the down side, one major piece of functionality that should have been included in Java 1.1 (and is sorely missing) is support for the Internet Inter-Orb Protocol (IIOP). Distributed-object fiends understand the tragedy of this oversight. But for you readers who are not privy to the IIOP story, I’ll try to give the world’s fastest IIOP explanation now.

The Object Management Group has defined a standard for how objects can interact across machine boundaries. The standard is called Common Object Request Broker Architecture (CORBA). This standard defines how a piece of software — called an Object Request Broker (ORBs) — exposes local objects for use by ORBs on other machines or process spaces. The protocol used by the ORBs for communication is IIOP. To expose an object to an ORB, or to use an object, the interface to the object must be defined using the Interface Definition Language (IDL). IDL is similar to C/C++ header files.

On the surface, this process may seem very similar to RMI and Microsoft’s DCOM. However, CORBA is technically superior. Developers will be able to easily make their objects transactional, concurrent, and persistent (among other characteristics) by mixing in vendor-supplied libraries.

IIOP in two paragraphs. I think that’s a new record! For a more detailed analysis of CORBA and IIOP, I recommend you read one of Dan Harkey and Robert Orfali’s classic client/server and distributed object books.

The bottom line is that IIOP has been “decoupled” from Java 1.1. Software from Visigenic and IONA both provide Java-based ORBs, but the ORB must be downloaded to the client browser or bundled with the Java application. Life would have been so much simpler if JavaSoft, IONA, and Visigenic could have agreed to the Java-to-IDL binding in time for Java 1.1.

Tools

JavaSoft also makes tools such as the free, command-line Java Development Kit 1.1, graphical Java WorkShop, and JavaBean Developer Kit. It appears that JavaSoft is not committing serious resources to the tool efforts. Rather, it is relying on third parties, such as Symantec, Microsoft, Borland, IBM, and others, to develop tools. While this frees up JavaSoft to expand the language, it also allows for a development environment (DE) provider to add proprietary extensions to the language. Cough.

What’s next

The next major release of Java, Java 2.0, is slated for mid- to late-1997. Although details are sketchy, release 2.0 is expected to bring Java up to the level of a regular operating system. Expect to see drag-and-drop functionality, more changes to the AWT, 2D graphics format with Adobe, sound with HeadSpace, and 3D extensions with Liquid Reality.

In 1.1, asynchronous I/O to some streams but not all (such as random access file-based I/O) was added. Full buffering should be added in the next release, but there’s no official word yet. For now, you’ll have to use third-party solutions. See the Resources at the end of this article for information on how to improve Java’s current I/O performance.

Outside of the Java 2.0 changes, various other APIs and services are in the works:

• A Java Transaction Service (JTS), which is crucial for Java to compete with ActiveX’s transaction server (Microsoft Transaction Service, or MTS) at an enterprise-server level, is in the proposal stages. JTS is a Java implementation of the CORBA transaction service.

• Name and Directory services will be added. Now that millions of people are on the Web, we need common standards for how to find someone’s address and e-mail information.

• Web server extensions called servlets will allow Java bytecodes to be uploaded to a Web server. Servlets are one of the many works-in-progress needed to add a mobile agent infrastructure to the Web. Mobile Java agents, combined with database connectivity at a server, open up some very interesting market possibilities.

• To manage all those embedded systems and consumer electronics that incorporate Java, a Management API is in the proposal stages.

• An Electronic Commerce Framework involving digital wallets, payment, and smart cards also will be released.

• EmbeddedJava, PersonalJava, and Java Card comprise a set of Java class libraries designed for non-PC devices.

Stir in a little Netscape

Netscape Navigator has been a driving force behind the acceptance of Java. As the first widely deployed browser with Java, Navigator forced every other vendor to include Java support. Netscape has extended the standard class libraries with the introduction of Internet Foundation Classes (IFC). IFC has not been adopted as a standard in the industry due to developer concerns about being locked in to a non-JavaSoft windowing environment. However, in the spirit of openness, Netscape has provided source code for the IFC.

Communicator 4.0, Netscape’s in-the-works addition to its product line, will include a number of very interesting features, such as IIOP support, but the two key areas of interest to Java developers are a new security model and support for portions of Java 1.1. The new security model will allow the user to open up the JVM sandbox. This change is a crucial component in allowing Java applets a more suitable execution environment — currently, an applet either has no access or full access. The modified security measures, along with support for JDK 1.1, should provide a powerful competitive edge for Netscape over potential Communicator competitors.

Communicator 4.0 PR3 has support for all of Java 1.1, except the new AWT and JavaBeans features. Netscape has promised to support these features in a subsequent release. Netscape’s full support of Java 1.1 will provide a tremendous boost to the language. As the leading browser, it is sure to continue to draw many developers.

Add a pinch of Microsoft

Microsoft has thrown considerable weight behind Java and the Internet. Sun, Netscape, and others touted Java and the Internet as a Microsoft killer, and the consummate businessman in Redmond listened. Microsoft’s philosophy is that developers will always choose performance on a particular platform over general functionality on multiple platforms, so it is optimizing Java for the Windows platform. In effect, Microsoft has succeeded in preventing the automatic acceptance of Netscape and JavaSoft initiatives.

“Microsoft is going to create Microsoft Java and Microsoft Windows-specific VMs, and JavaSoft has to confront that reality and make it okay for all Java users and build bridges between those different implementations,” said Stan Dolberg, director of software strategies at Forrester Research.

Microsoft is “extending” Java with additions to the class libraries, in the form of Application Foundation Classes (AFC) and changes to the virtual machine to allow COM/DCOM/ActiveX connectivity. On the subject of ActiveX connectivity, the next release of the Microsoft virtual machine (MSVM) most likely will support JavaBeans and bi-directional links to ActiveX. An application that uses the MSVM and is written in Java will expose Beans as ActiveX controls, and will be able to act as a container for them. Imagine your app nestled inside Word or Excel.

Indeed, Microsoft is now giving away the MSVM as a plug-in for Netscape. Further, developers will be able to bundle the MSVM in their applications. Microsoft simply requests that it be notified by the developer.

Microsoft has stated that, with the exception of the Java Native Interface (JNI), it will support all the Java 1.1 language features. A smart move. If it had decided to create its own inner classes, reflection, data types, and other integral features, developers would have been forced to stay with Java 1.02. This is a critical distinction: Supporting Java 1.1 language features is very different than shipping Java 1.1 class libraries with products.

Parts of Java 1.1 — RMI, code-signing, JAR files, native method interfaces — compete with Microsoft standards. A very interesting issue is whether Microsoft will support all of Java 1.1. It may support Java 1.1 by offering features that conflict with Microsoft’s offerings as a downloadable and installable component, separate from Windows and Internet Explorer. Or it may not offer the features at all.

By innovating on Java separately from JavaSoft and Netscape, Microsoft is forcing developers to choose which version they support. In all fairness to Microsoft, the company believes it has hit the market earlier and with better implementations of some features than have JavaSoft and Netscape.

I asked Scott McNealy what would happen if Microsoft did not include Java 1.1 class libraries in Internet Explorer six months after FCS of Java 1.1. He patly replied, “Then they don’t have Java.”

Microsoft might take an alternative route and attempt to provide a “better Java.” Although I doubt this will happen, the thought is still disturbing.

What does this mean for developers? Probably, they will be stuck supporting both versions. Developers may have to do a number of things to make sure their code works in all arenas, including:

• Storing classes on a Web site in both JAR and CAB files
• Providing Microsoft and JavaSoft code signing
• Using Java Native Interface and Runtime Native Interface
• Making server objects visible via RMI, CORBA, and/or DCOM
• Using Netscape’s and Microsoft’s security capability model
• Using both or neither set of foundation classes

On the development side, Microsoft’s Visual J++ is a solid and popular contender in the Java development arena. Microsoft has not articulated when or if J++ will support Java 1.1. A key J++ differentiator is the ability to use and produce ActiveX controls from the Java environment. In fact, Java makes creating ActiveX controls somewhat bearable. Now if only there were great libraries for integration with ActiveX containers. It looks like Java will replace C++ as the preferred language for ActiveX controls.

Microsoft has become a large player in the Internet and Java markets. Microsoft is competing with JavaSoft for the future of Java. If Microsoft can grab the biggest chunk of the browser market for PCs, Macs, and Unix, then developers may code to Microsoft standards. And if Microsoft makes it easy by providing integration of features via the J++ development environment, it may well have the industry standard Java solution.

However, all is not lost for developers and users. The worse case scenario for platform independence is that Java is optimized for the Windows platform. Considering that Windows is by far the largest installed OS, a majority of users will be satisfied. I know — platform independence is the holy grail. But the version 1.1 VM and most of 1.1 will be available on all platforms. So we may not have complete platform independence, but it’s a heck of a lot better than C++.

Don’t forget Big Blue

In the age of “Co-opetition,” another large computing corporation has entered the arena: IBM. Big Blue has directed its massive market presence toward Java and network computing. If you haven’t been keeping up with the alliances surrounding Java, you may be surprised to hear that IBM, including its Lotus subsidiary, has thousands of developers currently working on Java projects. The Java credentials speak for themselves: the first Windows 3.1 VM implementation, the first VM integrated in an operating system (OS/2 Warp 4), and the first JavaBean-compliant authoring tool (AppletAuthor and Visual Age for Java). In fact, a JVM is now available for every IBM platform, ranging from OS/2 to AIX, AS/400, and MVS. IBM has opened up its applications as well, with Java libraries for CICS, MQ, DB/2, and Notes.

IBM’s approach has been to work with JavaSoft to extend the Java environment. As key participants in Java 1.1, IBM, Lotus, and Taligent contributed many of the JavaBeans, security, localization, and language changes.

On the development side, the Visual Age for Java development environment is entering beta stages. IBM continues to roll out useful components via the alphaWorks site. The San Francisco project, a Java framework for financial applications, will start deployment this year.

Lotus also is leading the charge on the application front with an extensive suite of Java components, called Kona. The Domino, née Notes, server will be accessible via IIOP, LDAP, and Java class libraries in the next major release.

IBM is flexing its 5 billion sales muscle to fund many Java initiatives: the Java Venture fund with Kleiner Perkins Caufield & Byers, the 100% Pure Java initiative, the JavaOne conferences, and the Java World Education tour.

On the vision side, IBM has clearly articulated how important Java is to network computing. Taking a bit of a higher road than Netscape’s Open Network Environment, IBM’s Network Computing Framework details the tools and technologies that are used in network computing applications.

It’s obvious to even the casual market watcher that IBM is very focused and committed to making Java the best possible environment for users and developers. And now the marketing machine is stepping up delivery of Java to the channel partners.

Add some other companies for variety

Established companies, as well as several start-ups, are embracing and extending Java in radical and different ways:

• Development environments are now available from Symantec, Borland, Metrowerks, Marimba, RogueWave, and Asymetrix.

• Visgenic, IONA, WebLogic, and BulletProof (among others) are leading the industry in an effort to provide three-tier architectures, which are needed for enterprise connectivity. The ability to abstract the business logic from the presentation and data storage provides for great flexibility in deployment. Three-tier architectures are fundamental to the network computing, or third wave of computing, revolution.

• Companies like Kleiner Perkins Caufield & Byers, the venture capital firm for Netscape — and a few interesting others, including America Online, 3DO, Electronic Arts, Excite, Intuit, Lotus, Macromedia, Sun, Symantec, Verisign, Verifone, Visio — have joined with IBM in the Java venture fund. This 00 million bank roll goes toward funding Java start-ups.

Carefully fold in the hardware

The Java VM has been ported to almost all PC server hardware platforms and operating systems. But the real dream of Java — embedded systems and consumer electronics — will truly shine this year. Sun will be releasing Java chips, which are currently low-end chips designed to run Java natively.

On the embedded side, controllers and intelligent phones are poised to hit the market. Nokia and Nortel will be releasing desktop or cellular phones that run Java. Users will be able to update a personal organizer from their phone, using the same application they do on their PC. The information will be updated on a server, allowing other users to interact with the schedule or other aspects. Voilà! Same application, mobile, distributed computing.

Also gaining press and momentum are network computers. IBM, Oracle, Sun, and even Wintel have announced slimmed-down computers that avoid the hassles of a standard PC. (Remember, all of the aforementioned companies sell server hardware or server software. Dumbed-down PCs equal bigger servers. Perhaps the days of Big Iron are back.) The network computer is enabled by Java. The “write once, run anywhere” mantra is crucial for deployment of applications on widely varied hardware platforms. We’ll see tremendous growth in the non-PC computing market. The continuance of Moore’s law (every 18 months, processing speed doubles and price halves) may lead to this being the year that Xerox PARC’s vision of many CPUs per person comes to fruition.

A recipe for success or failure?

So, will the ingredients added to Java result in a bitter brew or a sweet latte? The key inflection point for Java is a question of reach versus performance. Microsoft wants to optimize Java for Windows. If you owned 80 percent of any market, you’d probably do the same. All the other software and hardware vendors want Java to reach the widest variety of platforms. The deciding factor in this heated argument is the uptake of non-PC platforms. However, with relatively inexpensive CPUs and the pervasiveness of cellular phones, network computers, and PDAs, it’s hard to see how Java in the non-PC world could fail. Certainly JavaSoft is working hard with EmbeddedJava and the like to make Java ubiquitous on the consumer electronics market. Perhaps the circle is now complete?

Java will be successful. The only real question for Java’s future is whether it will fragment into a PC and a non-PC camp. But either way, Java will be used on clients and servers.

7 questions all Java developers need to consider

As developers, you will need to do some serious soul searching if you want to hit the market running. Here are some of the key questions you need to consider:

• Will the embedded systems market and network computer market expand enough in 1997 to affect Java DEs? Each developer needs to make a platform-independence versus reach decision. If there are enough non-PC platforms available, I am confident Java developers will choose platform independence.

• What portions of Java 1.1 will be supported in Microsoft Internet Explorer 4.0?

• What will the two competing security models look like?

• Will AFC and/or JFC provide a large enough functionality enhancement that developers will target a particular browser?

• Will JavaBeans be interoperable with ActiveX? Assuming yes, then object nirvana could almost be here.

• Will questions about the Java licensing agreement reach litigation? If this very unfortunate incident happens, look for some serious mudslinging and confusion in the market. Java would suffer a tremendous black eye. It’s too late for the Java momentum to stop, but development would certainly slow.

• Will the 100% Pure Java initiative prevent the Java market from fragmenting?

Keeping my eyes on the future

Here’s my chance to play futurist for 15 minutes. It’s fun to speculate on the future, although not always rewarding (especially when you’re wrong). I’ve been researching the market extensively and offer up to you the fruits of my mental gyrations.

Standardization

I believe standardization will happen for parts of Java. Most likely, the Java 1.1 language spec will be handed over to ISO in late 1997. The class libraries and VM will wait perhaps until 1998 or later.

The not-so-raging client-side battles

The IIOP/DCOM/RMI and JavaBeans/ActiveX wars will not be as large an issue as some pundits claim. The discussions are really about network computing plumbing, and thus are just tools for building distributed applications. However, understanding the appropriate technology and knowing when to use it is crucial for developers.

Clay Ryder of Zona Research says comparing Java to ActiveX “is comparing apples and oranges. Java is a language that can be used inside ActiveX and work with ActiveX. The real question is whether JavaBeans is going to articulate a position superior to Microsoft’s when Microsoft controls 80 percent of the desktops.”

Developers will build Java objects, then run them through an “IIOPizer” and “DCOMizer.” Visigenic’s Caffeine creates IIOP interfaces for Java, and JavaSoft’s ActiveX bridge does the same for DCOM/ActiveX. As a developer, you should be able to use whatever local or remote components you wish and tie them together using whichever builder you prefer. Look for an explosion of controls and components.

The windowing toolkits battle that has been brewing between Microsoft and JavaSoft may also be a non-starter. If Netscape and Sun simply swallowed their collective pride and adopted Microsoft’s AFC set in addition to JFC, developers would have a clear choice. This type of humbling attitude is somewhat unlikely. In fact, I’d venture that Netscape and Sun may try to install the JFC classes into the Internet Explorer/Nashville environment. It will end up coming down to which company ends up deploying more libraries, and which company blinks first. Further, if Java applications, rather than applets, become common, the choice of toolkits will not tie a developer or user to a particular browser or development environment.

The new security

Browsers will be opening up the Java security sandbox. Granting partial or full access to system resources on a call or library basis promises to greatly extend the reach of Java within the context of a browser.

Performance

The interpreted nature of Java leads to one of its largest current stumbling blocks, performance. Substantial performance increases in the interpreters and just-in-time compilers — such as the Hotspot VM — will bring Java much closer to C++ in execution speed.

Applications abound

1997 stands to be the year of the Java application. Among the leaders will be Java-based games and entertainment sites. Applications will be delivered and installed independently of a Web browser — say via Marimba’s Castanet.

Server-side Java

Server use of Java also promises to be very exciting. Java and database connectivity, Java-to-native compilers, Java-to-legacy system integration, and much more will happen this year. Every server application vendor will be opening up its system, and application builders will use it.

“Server-side Java that leverages the power of corporate networks is going to play a larger role as companies begin to overcome some of the performance limitations of Java,” said Daryl Plummer, a research director at the Gartner Group. “I think it will be a big trend by the end of the year. Server-side Java is the key to this whole picture.”

Most compiler and IDE companies have been very quiet about Java-to-native compilers. These make great sense for server-side Java applications. I’m guessing that every compiler vendor and server hardware vendor has plans for native compilers. This may offend many purists, but generally speaking, server code doesn’t migrate from server to server.

On the connectivity side, streaming applications and data, aka push media, will probably become the most hyped part of the Web. We’ll sit back a bit from our pull media and surf the channels that are pushed to us. But because the channels are digital, we can interact with them. This will allow Webcasters to personalize at a fine grain the streams we receive. Indeed, perhaps each channel of behavior or data will be customized to our personal needs and preferences. Stay tuned (sorry, couldn’t help myself) for more on push media.

Keeping your eyes on the future

So what’s a poor developer to do? As usual, it all depends upon your target audience and its requirements. Most important: use Java. To many of you such a statement is obvious. However, many large corporations are still hesitant about deployment of Java. They need to be informed about the benefits. Java is a good, stable environment for developing applications, be they local or distributed. The programming language provides significant improvement in developer productivity — numbers range from 2 to 4 times. And the code produced is of much higher quality.

For those of you already developing Java code, I have a few specific recommendations:

• Client code should be 1.02 VM compliant — using Interim JavaBeans until JavaBeans is accepted by a large enough portion of your audience.

• Server-side code should migrate to Java 1.1 very quickly. You’ll be able to connect to legacy stores, databases, and Web servers.

• For small to mid-size applets and applications, use only JavaSoft extensions (they have the widest deployment).

• Be very careful about which class libraries and VM extensions you use. Beware of the temptation to lose platform independence. Err on the side of reach rather than specialization as platform dependence is a slippery slope.

• Evangelize Java like crazy. It’s here, stable, and can be used in virtually every development scenario.

Java is continuing to progress at an enormous rate. The year ahead promises to be the transition year from small applications and applets to enterprise-level adoption. The year will be chaotic, and developers may need to make tough choices. In the long term, competition will create a better Java for all of us.