What's all the fuss about Java? Like coffee addicts, people are running about with Java in their veins, hyped up in this new euphoria known generically as Java'. Unfortunately, many, if not most, don't really know or understand what it is all about, but they are enjoying the high anyway. The great majority seem to have garnered some idea that Java represents the uprising underdog, here to fight the battle against the great evil empire of the all-present Microsoft juggernaut. So what, after all, is this Java phenomena?

Having its origins at Sun Microsystems in a language called Oak, Java has come to represent an entire environment. Java technology now covers many domains, from a well structured third generation language (3GL) to an operating system environment and distributed object Middleware infrastructure.

The Java Phenomena
Java' encompasses a number of fundamental technologies:

• Java Language - The Object-oriented third generation Java language (Java 3GL).
• Java Applets - Half-compiled' architecture-neutral bytecode objects one creates with the Java language
• Java Scripting - A scripting environment similar to Visual Basic Script
• Java Virtual Machine - Provides the interpreter for the Bytecode Java Applets and a protected operating environment for Java applications
• JDBC and JSQL - Java Database Connectivity, an ODBC lookalike which provides database connectivity for Java applications and embedded SQL capabilities
• JNI - Java Native Interface, which provides an Interface Definition Language' allowing other non-Java languages to expose Java-based interfaces
• Java RMI - The Java Distributed Object Framework called Java Remote Method Invocation (RMI)
• JavaBeans™ - The Java Object Assembly environment called JavaBeans.

The Java Language: What, Another 3GL?
Surely, in a day and age where any product that needs to be successful requires the word visual' imbedded somewhere in it, we don't need another third generation language! One of the primary problems with software development is the necessary evil of programming. The concept of forcing a domain expert (someone who really knows what they are doing and want to accomplish) to get on their knees and bow down to some programmer guru to try to get the message across to them of what exactly they want the computer to do is a little backward. In other words, the problem with 3GL environments is that the programmer is not the domain expert. This causes all types of problems. Ever try relaying a simple message from individual to individual in a party? It is amazing how easily the message gets jumbled up somewhere along the way. The same happens in software development.

3GLs mandate a syntactically rich, or should we infer poor, environment. That is, you need to write a highly structured document (program) where everything must be just right. If you don't put the brackets in the right place and get all your verbs, synonyms, language, etc. absolutely in order, it won't work.

The human brain is not naturally a syntactical beast, we don't naturally think in terms of structured language'. The human mind thinks primarily in terms of pictures; we are generally visual animals, living in a visual world. So the marketing folk at most of the computer companies have grasped this basic concept and consequently, any new product must have the word 'visual' in it! It took some time to drum into the heads of many computer people that a Graphical User Interface (GUI) with Windows Icons Mice and Pointers (WIMPs) was important. In fact, you still manage to find a few individuals in the mainframe world and programming community who still believe that a command prompt is all you need. So, getting back to our Java issue, what's the fuss; who needs another 3GL?

Java is, quite simply, a better 3GL than the other 3GLs like C, C++, SmallTalk, Ada, Pascal and the like. Java gets rid of the imbecilic concept of pointers and pointer arithmetic which would leave you scratching your head as you tried to decipher what someone was trying to do with a program. Java also incorporated the novel concept of garbage collection which, like other concepts embedded in the Java programming model, is wisely borrowed from other languages. Garbage collection removes the problems of things like memory leaks. Memory leaks? Sounds like a problem we all have when trying to remember someone's name. Well memory leaks are a bit like that; users don't always identify them on PCs since they typically turn the PC off or hit the all encompassing Ctl+Alt+Del which effectively blows out all the memory and lets you start afresh. Memory leaks typically crop up on servers and workstations where the system is left running days and weeks, if not years, on end. It all comes from those blasted pointers they gave us in languages like C and C++, where programmers were responsible for allocating and de-allocating memory segments. Programmers, like any normal individuals, tend to forget to de-allocate the memory. The net result is a system whose memory is filled with stale data, effectively leaking' the available memory live applications can use. By the way, for those of you still mired in the world of C and C++ programming, there are great tools, such as Purify, which will examine your code and tell you when you have a leaky program.

This brings us to another one of the great advantages of the Java 3GL, one of security. The old pointer problem again comes up as a key instigator of problems. Smart hackers can use pointers to capture the information off specific segments of memory that other applications are using, providing a direct path to secure data. Take away the ability to use pointers and you get rid of many of these problems.

Pointers can, however, be useful to the wizard who wants to play tricks and get optimal performance out of some piece of code. A bit like the guy who is really nifty with his abacus or slide rule.

Other elements Java dumps that have caused problems in the C++ world are things like no operator overloading (Java does have method overloading) and no multiple inheritance (only single inheritance). Also, Java has no templates, extensive automatic coercions, etc. Java provides true arrays instead of having to use pointers. It also enforces things such as static typing, which is enforced by the compiler, producing clean code. While the dynamic loading feature of Java eliminates any explicit link phase, method lookup occurs on-demand at run-time, which enables applications to dynamically exploit the latest revisions or replace objects on the fly during runtime.

The other key element of Java, which helps address the limitations of 3GLs and brings us into the visual' world, is JavaBeans, which we will get to shortly. There is, however, one more aspect to the Java language we must examine, that of bytecode.

Bytecode?
Sounds a bit like a sandwich. Well, bytecode is also not new; it has also been around for some time in other languages. Bytecode provides a halfway architecture-neutral state to fully-compiled code. The key feature to bytecode is that it does not force any unique features of a specific hardware or operating system platform. Java is an interpreted environment but the interpreter does not have to start from scratch in order to interpret the program. It interprets the precompiled architecture-neutral Java bytecode. This allows you to run the exact same Java program on your PC, on all of your different Unix systems and even on your mainframe or mini-computer.

The Java bytecode environment is faster than other interpreted languages like SmallTalk, but slower than C or C++. You can, however, fully compile Java, defeating the platform independence but getting closer to C and C++ performance.

Internet is Good
Another advantage of the Java language environment is that it comes with an extensive library of routines for TCP/IP protocols like HTTP and FTP, which makes it handy for Internet applications.

So, What's an Object?
Isn't my coffee mug an object? Well yes, and herein lies the problem of explaining the real advantages of object-orientation: everything is an object. But in the computer or programming world, the honest explanation of an object lies in the following statement: Object-orientation allows us to separate the interface from the 'implementation'.

So what does this mean? The separation of the interface means that we take out the interface part of the program, the instructions like start, stop, print, etc. and only expose these to the outside world. The actual implementation details of how we internally structure and create this piece of code is hidden. You need not know any details of how the object is written; you only need to know what interfaces are made available and how you can use them. It's a bit like your car. You do not need to know the details and workings of the combustible engine to drive a car; all you need to know is how to operate the interfaces: the steering wheel, the ignition key, the brakes, etc. Other programmers can then take your object and exploit its interfaces without having to know anything about the internals of the program. Thus, objects provide the fundamental building block technology for assembling comprehensive applications from object building blocks.

There are other aspects to object-orientation that are important, such as inheritance, polymorphism, encapsulation, classes, etc. But we will not get into the details here. The important thing to recognize is that Java provides us with an object oriented environment which allows us to write pieces of code, expose only the interfaces to the code and let other people use the object (program) without having to know the gory details of the code itself. In the Java world, we call these objects Java Applets.

JavaScript
The other element to the Java environment is an object-based scripting language that you can embed in HTML, the Hyper Text Markup Language we use to describe web pages. This scripting language allows us to make calls to initiate Java Applets and provides us some other features to make the HTML environment a little richer. Java Script is based on the Java language and is used to call Java applets from HTML and glue' the Java applets to each other. You use it for scripting of events and actions such as startups, exits and user mouse clicks. It also provides constructs for database connectivity. Of course, there are many other scripting alternatives as well, such as Visual Basic Script from Microsoft and Dynamic HTML, etc.

The Java Virtual Machine
This is, again, an old concept borrowed from the mainframe world. Mainframers have been providing hosted Virtual Machine environments for years. On mainframes, we would host other operating systems' which provided protected worlds' in which programs could operate without affecting the whole system. So if you had the concept of Ctl+Alt+Del on the mainframe, it would not bring the whole system to a grinding halt, but would only kill the offending segment. It's a little like the kill command in Unix, or the new popup you get on NT or Windows 95 which allows you to get rid of badly behaved programs without killing anything else. Except, like the mainframe concept, the Java Virtual machine provides a completely separate world in which programs can execute - a virtual sandbox' in which programs can play without causing problems in the rest of the house.

One of the primary responsibilities of the Java VM is to interpret incoming bytecode into the native machine language. This allows the exact same Java Applet to be shared across many different hardware implementations without recompiling the application. It also imposes a natural performance disadvantage when compared to fully compiled environments where the object is already compiled into the binary code of the specific platform. The first time you import an object into the Java VM, it gets interpreted and is slow; however, future calls made to that object while in memory can be nearly as fast as C or C++ calls.

The Java Virtual machine does take away some key elements that are typically considered fundamental to most computer operating environments, particularly that of an integral and permanent file system. The Java VM has no persistent storage system; only a cache is provided in which objects are temporarily stored and then cleared out when they are not referenced regularly. Applications in the Java VM are restricted from making local OS file system I/O calls amongst other operating system specific calls. While this provides some security advantages, it is probably the most fundamental problem with the Java VM in that it requires you to reload all applications into the Java VM each time you start up. Imagine installing your word processor, spreadsheet and database each time you turn on your computer!

However, the advantage of the Java VM "sandbox effect" is that it allows you to run applications in a protected environment. This is particularly important if you are downloading programs off the Internet and you are not necessarily sure if they contain viruses or if they will behave properly.

JDBC
Java DataBase Connectivity, an ODBC lookalike, provides database connectivity for Java applications. JDBC itself is a low-level interface which incorporates SQL commands into the Java language. An API is provided for database drivers which makes the actual connection and translation to the specific database. A JDBC to ODBC bridge allows the exploitation of standard ODBC drivers.

ODBC is really the market leader in this segment by such a long margin that JDBC does not really pose any threat to ODBC itself. Microsoft, however, is interested in moving ODBC to their new OLE DB environment. OLE DB provides a common data access method to any OLE-compliant object, whether it is a database, a word processor, or a spreadsheet document.

JSQL
JSQL, like JDBC, provides database connectivity to the Java language. JDBC, however, provides a more concise environment than JSQL while it allows more efficient static analysis and type checking.

Java Native Interface (JNI)
JNI provides a standard native programming interface that allows the integration of applications and libraries that are not written in Java. A key aspect of JNI is that it provides binary compatibility across all Java VM implementations on a specific platform. JNI is independent of the implementation of the underlying Java VM, enabling programmers to write applications or libraries in different languages that should run on any standard-compliant Java VM on that platform.

JNI, of course, competes with Microsoft's MIDL (Microsoft Interface Definition Language) and CORBA IDL (Common Object Request Broker Architecture Interface Definition language). Both MIDL and CORBA IDL provide language bindings, which allow method invocations (instructions) to be passed from one object to another object regardless of what programming language the object is written in.

Java RMI (Remote Method Invocation)
The Java Object Request Broker (ORB), called Java RMI, provides a distributed object framework for Java applications. That is, it allows developers to create applications that run transparently over multiple different computers, harnessing the horsepower of multiple parallel computers and exploiting the distributed demographics of networked systems.

Java RMI came out of Sun Microsystems at a time when the rest of the industry, including Sun but excepting Microsoft, had provided full endorsed support for the Object Management Group (OMG) Common Object Request Broker Architecture (CORBA). Java RMI is not CORBA and is not CORBA-compliant. Sun, an advocate of Open Systems, essentially gave the rest of the Open Systems industry an I'll do it my way' and produced Java RMI, even though Sun does have a CORBA-compliant ORB called NEO (by the way, JOE is Sun's NEO implementation that provides Java language mapping). Sun's defense might be to raise the question as to which successful products in our market have been designed by a committee. To fend off the understandable fury of the CORBA camp, Sun has added the CORBA Internet Inter ORB Protocol (IIOP) support as a low level means (not Java's standard) of communication from Java RMI to other IIOP ORB implementations. Java RMI's standard Inter ORB protocol is the Java Remote Method Protocol (JRMP).

Java RMI's limitation is that it basically supports only the Java language. It is, however, relatively simple for a Java developer to implement distributed Java applications using Java RMI. It is much easier than implementing distributed applications using a CORBA ORB or Microsoft DCOM. For this reason alone, Java RMI might offer a long-term solution to distributed computing.

We will not go into the details of how Java RMI works here, but recommend that any person who is interested should definitely learn more about ORBs as they will form the foundation of future computing. The three key ORB standards are OMG's CORBA, Microsoft's DCOM and Sun's Java RMI.

JavaBeans
The Java object assembly environment, JavaBeans, embodies the heart and soul of future development environments. This building block approach will enable domain experts to develop advanced applications with naturally cognizant development tools. JavaBeans provides a standard way for implementing development environments where components (beans/objects/Applets) can be visually integrated.

There is already an impressive array of JavaBeans-compliant tools on the market, such as Sybase's PowerJ™ , Borland's JBuilder™, IBM's Visual Age™ for Java, SunSoft's Java Workshop™ and Symantec's Visual Café, amongst others.

If we were to rate any of the Java elements in order of importance, JavaBeans comes out on top. Providing a standard Computer Aided Software Engineering (CASE) environment with standard underlying communications infrastructure, the Java RMI ORB. It is what the industry desperately needs to enter into the next generation of computer technologies, where domain experts will at last be able to create the software they need out of standard building blocks. An interesting aspect to consider is that the next CORBA interface standard, CORBA 3.0, may well embrace the JavaBeans model.

The Java Coup
Now that we know a little of what Java is all about, we can start to understand the excitement. But what are the underlying currents? Why, for example, is Sun Microsystems trying to sue Microsoft Corporation? What are the war room' strategies that are driving the computer systems juggernauts?

No one denies the fact that Microsoft has captured the heart of the industry, seriously threatening companies like IBM and Sun. Can the Java phenomenon undermine the Microsoft phenomenon?

Windows controls the desktop market and NT is rapidly making inroads into controlling the server market. How can any vendor stop this massive landslide?

Browsers were the first to recently raise a challenge to Microsoft's desktop dominance. They even had Microsoft worried for a while. The Internet explosion caught most of the vendors unaware, including Microsoft. When Marc Anderson's Mosaic brought a new user-friendly desktop' interface to the largest network in the world, the Internet and browsers took off. The browsers were definitely not from Microsoft, providing a significant new alternative desktop interface to Microsoft Windows.

Recognizing the serious threat browsers posed to their control of the desktop, on December 7th 1995, Microsoft announced a massive reorganization and a host of new products, all focused entirely around the Internet. Microsoft spearheaded these efforts with a free Microsoft-based browser, the Internet Explorer. They subsequently came up with an even smarter strategy to combat the browser threat - by simply incorporating browser technology into the heart of Windows itself, Microsoft will make the need for a separate browser mute.

But Java goes beyond the browser. Java provides its own Virtual Machine (VM) environment, an operating system in itself. The Java VM can run independent of Microsoft's Windows, providing an alternative platform' to Windows. It is this alternative that Microsoft's competitors are trying so desperately to protect and propagate. And this is where Microsoft is so eager to come up with a strategy to divert any massive migration to the Java VM.

The Java VM, however, was designed primarily around the concept of providing a protected environment in which you can run potentially suspect code on your primary operating system without affecting the whole system. This is why the Java VM limits access to file system I/O and is also the very reason why the Java VM in its current state will probably never manage to usurp Microsoft Windows. It is necessary to download an application over the network each time you restart. As we mentioned before, imagine having to re-install your word processor and spreadsheet each time you turned on your computer. The other problem is that when compared to standard Windows applications, bytecode is inherently slower than complied code, handicapping true Java applications. You can, however, fully compile Java code to a specific machine's binary environment and obtain nearly the same performance as C or C++. however, this eliminates Java's machine independence.

Microsoft's current strategy to dilute any Java VM threat is to expose Java Applets as full COM (Component Object Model) objects. Turning Java objects into COM objects (the same thing as ActiveX objects), makes Java objects the same as any other language's objects in the Windows environment. Microsoft is thus opening up' the Java VM to be an integral part of the Windows Operating System environment. Developers are consequently likely to exploit Microsoft Windows-specific features even when developing Java applications, particularly by exploiting the ability to utilize local persistent storage on Windows and thus effectively locking the application to the Windows platform. The Java VM then becomes a mute point, since it is inherently incorporated in the Windows operating system.

Microsoft is obviously not playing along with Sun's Java strategy and licensing model' and this is why Sun is jumping up and down frantically because Microsoft won't play properly. To be perfectly honest, why should Microsoft have to play along with Sun? Are vendors not free to innovate as they choose? If Sun wants to compete with Microsoft, they have to do it in the 'Open'. In the Open Systems world, the vendor with the most cost-effective product (and the best marketing) wins.

So far, Microsoft has managed to dilute any attempts to dethrone their dominance on the desktop. Microsoft's strategy reflects that of a wise commander who has been through, and won, many battles. What the other vendors seem to be unaware of, in their frantic attempt to unseat Microsoft's dominance of the desktop, is that while they are deploying all their forces against the desktop, probably futilely, Microsoft has already entered the back door of the ivory tower and is taking over their server market.

However, the real battle lies in the adaptation of vendors' distributed object Interface Definition Languages and underlying ORB infrastructure DCOM vs. CORBA vs. Java RMI. In particular, the features and functionality of CASE tools that allow applications to be built around any of the distributed environments will determine the industry direction. Whoever manages to control the hearts and minds of developers and manages to get developers to build applications around their distributed object model wins!

About the Author
Clive Boustred is the Chief Technical Strategist for Advanced Technical Strategy, Inc.(www.strategize.com). He has held senior positions and consulting engagements with numerous corporations such as Microsoft, Sun Microsystems, General Electric and Teknekron, where he was involved in the development of Corporate Computerization Strategies. Clive specializes in Distributed Systems, CASE and Networking and is responsible for providing the vision for many highly advanced systems and some of the largest Distributed Object implementations to date. He can be reached at clive@strategize.com