Java HUFF

Java, The Hype, The Use, The Fiction, The Facts
January 1998

By Clive Boustred

INDEX

1. Introduction
2. The Java Phenomena
3. The Java Language - What, Another 3GL?!
4. Bytecode?
5. So what's an Object?
6. Java Script
7. The Java Virtual Machine
8. JDBC
9. JSQL
10. Java Native Interface (JNI)
11. Java RMI (Remote Method Invocation)
12. Java Beans
13. The Java Coup - Can the Java phenomena undermine the Microsoft phenomena?

Introduction

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 it's origins at Sun Microsystems in a language called Oak, Java has sprouted forth 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 Orientated 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	The Java Virtual Machine which provides the interpreter for the Bytecode Java Applets and a protected operating environment for Java applications.
JDBC & JSQL	Java Database Connectivity, an ODBC lookalike which provides database connectivity for Java applications & 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).
Java Beans	The Java Object Assembly environment called Java Beans.

Sure Java is a lot of things, but what do these components really deliver?

The Java Language - What, Another 3GL!?

Surely, in a day and age where any product that needs to be successful requires the word 'visual' somewhere imbedded 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.

3GL's 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… stuff… 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 eventually 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 dregs of 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 3GL's 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 (often that someone was yourself). Java also incorporated the novel concept of garbage collection, which like other concepts embedded in the Java programming model, are 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 PC's 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 individual, tend to forget to de-allocate the memory. The net result is you end up with 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 coercion's, etc. Java provides true arrays, instead of having to use pointers. It also enforces thing 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. We will not get into more gory details in this article, as we are already getting way too deep for most peoples liking.

The other key element to Java, which helps to address the limitations of 3GL's and brings us into to 'Visual world, is Java Beans, 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 half-way 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 nifty for Internet applications.

Java is a nicely designed language
which has some key advantages,
like Object Orientation.

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 form the implementation'. Ok, so we got all theoretical and philosophical, what does this mean? The separation of the interface means that we take out the interface part of the program, the instruction 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. 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 it's 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, take a look at the 'O-Scale White Paper' if you have further interest. The important thing to recognize, is that Java provides us with an object orientated 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. But then other programming languages can also do the same thing, so what's all the fuss?

Java Script

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 such as Visual Basic Script from Microsoft and Dynamic HTML etc.

The Java Virtual Machine

This again, is an old concept borrowed from the mainframe world. Mainframers have been providing hosted Virtual Machine environments for years. Yes, you young wiper snappers, there are many things you can learn from the old geriatrics! 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. 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 'sand box' 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 naturally imposes a 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 startup. Imagine installing your word processor, spread sheet and database each time you turned 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 contains 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 spreadsheet document.

JSQL

JSQL, like JDBC provides database connectivity to the Java language. JSQL, however, provides a more concise environment than JDBC, 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 exponent of Open Systems, essentially 'ignored' the Open Systems industry an 'up yours, I'll do it my way' and produced Java RMI, even though Sun did 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 CORBA ORB implementations. Java RMI's standard inter ORB protocol is the Java Remote Method Protocol (JRMP).

Java RMI's limitation is that it currently only supports the Java language. It is however relatively simple for a Java developer to implement distributed Java applications using Java RMI, 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 enough to read this article, should definitely learn more about ORB's 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.

Java Beans

The Java object assembly environment, called Java Beans 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. Java Beans provides a standard way for implementing development environments where components (beans / objects / Applets) can be visually integrated.

There is already an impressive array of Java Beans compliant tools on the market such as: Sybase's PowerJTM , Borland's JBuilderTM, IBM's Visual AgeTM for Java, SunSoft's Java WorkshopTM and Symantec's Visual Café, for a comprehensive list visit the Java Soft site at http://www.javasoft.com/beans/tools.html

If we were to rate any of the Java elements in order of importance, Java Beans comes out top. Providing a standard Computer Aided Software Engineering (CASE) environment with standard underlying communications infrastructure (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 Java Beans model.

The Java Coup

Now 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 phenomena undermine the Microsoft phenomena?

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

Browsers were the first to recently raise challenge to Microsoft's desktop dominance. Browsers, even had Microsoft worried for a while. The Internet explosion caught most of the vendors unaware, including Microsoft (see our now historic White Paper on Vendor Strategies). 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 slew of new products, all focused entirely around Internet. Microsoft spearheaded these efforts with a free Microsoft based browser, the Internet Explorer. Microsoft has subsequently come 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 it's own Virtual Machine (VM) environment, an operating system in itself. The Java VM can run independently 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 keen 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 Java VM in it's 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. One can however, fully compile Java code to a specific machine's binary environment and obtain nearly the same performance as C or C++. This however 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). Thus making Java objects just 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 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 want's 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 (see 'Clive's Law').

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, most probably futilely, Microsoft has already entered the back door of the ivory tower with the goal of 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!