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
But what do these components really
- 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
- 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
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
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
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
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.
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
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
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.
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
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.
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, 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
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.
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
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 firstname.lastname@example.org