From the Blogosphere
What's All the Fuss About?
What's All the Fuss About?
By: Clive Boustred
Dec. 1, 1997 12:00 AM
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
But what do these components really deliver?
The Java Language: What,
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.
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
So, What's an Object?
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.
The Java Virtual Machine
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.
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.
Java Native Interface (JNI)
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
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.
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
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!
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week