8.2 The Java Programming Language
8.2 The Java Programming Language The Java programming language is described as "a simple, object-oriented, network-savvy, robust, secure, architecture-neutral, portable, high-performance, multithreaded, interpreted, dynamic language." [2] Also, with the appropriate peripherals, it will wash your car and baby-sit your kids . Okay, I threw in that last part, but with all the claims that are made concerning Java, it is almost believable. Let's take a moment to understand some of these claims and how they relate to IEBI.
8.2.1 SIMPLEWhen we first approach the Java language, we note its simplicity. As we consider the complexities of other object-oriented languages, such as C++ and Smalltalk, we wonder how an object-oriented language could be simple. Isn't the basic methodology complex? Both Smalltalk and C++ are very much like the first video camera I ever bought. Prior to purchasing it, I went out and read all the reports on video cameras . I soon learned there were certain features that were absolute necessities. First, I had to have the ability to add scrolling titles. Second, I desperately required the ability to focus in on objects as tiny as a ladybug. When it finally came time to buy the camera, I selected the model with the highest rating and the most features. Oh, it was a marvel of modern recording devices. Visions of mini-epics danced through my mind the night I bought that camera. In years to come, my children would bless me for documenting their childhood so well and so creatively. You could probably guess where this story is going. In the end, I took the basic home movies: my children's first steps, birthday parties, and Christmas mornings. The only feature I used at all was the fade-in /fade-out; it was the only one I could figure out. Today, that particular camera sits inoperable in the back of a closet, and a new one with fewer features has taken its place. This is what is happening with programming languages, at least in the Internet-enabled world. Both Smalltalk and C++ have a rich programming environment with all sorts of features and functions. Unfortunately, a good number of these functions are not necessary to the majority of applications, or they simply don't make sense. Consider some of the things we can do with C++: operator overloading, multiple inheritance, and automatic coercions. (Automatic coercion! I have relatives doing time for this!) Is this functionality necessary? Every good engineer knows KISS, Keep It Simple, Stupid. Simplicity, however, is even more important in an IEBI implementation. Time and quality are critical success factors. As we noted earlier, Business Intelligence 101 tells us that we sell IEBI to the C-level executives. The trouble with this rule is that their attention span is short. Do not expect to walk away with their buy-off on an IEBI system and return 16 months later with the beginnings of what you sold them. They will pull the plug on such a project long before you deliver; I have the battle scars to prove this is true. We need to get the C-level executives some basic level of functionality as soon as possible to insure continued support for the project. Java's simplicity allows us to get something developed quickly. Rather than provide an extensive syntax in which the language implements every conceivable function, Java is a simple, straightforward language. IEBI is difficult enough; adding a complex language into the mix does not make it any easier. While the language is simple, the power to develop very complex applications is great. We shall see how we can easily develop complex applications with Oracle's BI JavaBeans later in this chapter. 8.2.2 ROBUST AND SECURERobust is one of those words like "nice" overused to such an extent that it tends to lack real meaning. We talk of environments being robust, but it is typically a term used by marketing when searching for a nondescript adjective or beefing up a presentation. The dictionary defines robust as "powerfully built" or "sturdy." While simplicity is beneficial, are we sacrificing the ability to build robust applications? Actually, Java's simplicity contributes to the robustness of the language. Both Smalltalk and C++ are like a chainsawthey could easily cut through most objects with little resistance. That is the good thing about chainsaws. The not so good thing about chainsaws is that they cut through most things with little resistance. Slicing off an arm or a hand is a simple process that occurs far too often. Although a handsaw might not be able to cut through a redwood, when was the last time you heard of someone accidentally cutting off his or her arm with a handsaw? True, Smalltalk and C++ give you a lot of power, but with that power you can easily hurt yourself. One of the features of the C language, and later C++, is the ability to point at specific memory locations through pointer data types. In C, a program can easily step outside the memory boundaries of an application. If we are lucky, the operating system will pick this up and we'll get an error. In a less lucky environment, the program will be allowed to access memory and possibly cause a more devastating error. Java's memory management model is much simpler, which makes it much more robust. We work in an object-oriented environment, which means that everything we do is in terms of objects. When we create a new object, we do so with the new operator. There is no such thing as a programmer-defined memory pointer type. Everything we do in memory is within the context of objects. Robustness entails more than simplicity. Java helps to insure robustness by catching errors before the application is deployed, a novel concept in the application development world. One way it does this is by applying strict compile-time and runtime checking. C++, on the other hand, allows the implicit declaration of methods and functions. Java requires explicit declarations. 8.2.3 ARCHITECTURE-NEUTRAL, PORTABLEIn Chapter 5, we discussed the features of the Internet and the importance of a pervasive client, a single, consistent environment for every client that desires access to the system. The importance of this is that the application developer can now write to a single platform. He or she need not develop separate versions of the software to accommodate for the nuances of the variety of platforms that will act as clients . Java extends this capability. With most other high-level languages, applications are compiled to generate machine code, the binary instructions that cause the system to perform the tasks described in the source code of the program. One of the problems with this approach is that each system has its own machine code. Any application developed in this manner is dependent on the underlying system. A Java compiler, however, generates bytecodes. These are high-level, machine-independent codes. Sitting between the Java application and the actual system is the Java virtual machine ( JVM ) . Figure 8.4 shows this structure. This platform abstracts the specific hardware and operating system. Recall our definition of abstraction from earlier in the chapter; with abstraction, we focus our attention only on the relevant aspects of an object, ignoring those aspects that do not relate. The JVM hides the specifics of the hardware and operating system. Instead, it creates a standard virtual machine across all systems, providing Java applications with a single environment in which to execute. Where traditional compilers generate machine code that runs on the specific system, the bytecodes generated by the Java compiler run on the virtual machine. Figure 8.4. The JVM. One would assume that architectural independence would be synonymous with portability. While the two are closely related , they are not the same. Portability drills down a step. In the bad old days when I was a programmer and we had steam - powered computers, we would joke about memory pages. A page of memory isn't a term you hear that often these days. Back then, the page size would vary from one system to another. The joke was that when someone would move code from one system to another, they would ask, "How big is a page?" The answer was, "Oh, typically eight and a half by eleven." This may not be funny to you, but we were programmers and everyone knows how funny programmers are. The point of the story is that memory varied from system to system. The length of an integer, floating-point number, or character changed from system to system as well. Specifications for languages such as Fortran, C, and C++ designated the size of these data types as implementation-dependent. Java did not make this mistake. As we can see in Table 8.1, the arithmetic functions and the primitive data types used by these functions are all defined by the Java specification. The data types have specific, defined lengths regardless of the system. Most platforms are capable of supporting arithmetic in each of these formats. By implementing the Java language with these specifications, the data types become standard across all platforms. This enhances the portability of the programming language by eliminating a possible implementation dependency. Table 8.1. Java Data Types
8.2.4 HIGH-PERFORMANCEYou may wonder how the overall performance of the application is affected when intervening layers of software are added. After all, we have bytecodes executing on a virtual machine that is sitting on top of an actual system. For most applications, this environment delivers sufficient performance. There are, however, instances where better performance is necessary. In such cases, the bytecodes can be transformed at runtime into the machine code that is native to the system upon which the application is executing. This provides for performance that is equal to, if not greater than, the performance of other high-level languages such as C and C++. This is referred to as just-in-time (JIT) compilation. 8.2.5 MULTITHREADEDMultithreading, as the name implies, allows multiple parallel streams or threads of control to flow through the application. One of the challenges of parallel processing is making sure that we don't step on one another's toes. When two processes are competing for the same resource, there needs to be some method of arbitration to allow one process to gain and maintain control of that resource. In short, threads need to learn to do what we all tell our children to do: share . In the past, parallel processing was more at the mercy of the underlying operating system. High-level programming languages did not provide specifications for parallel processing. These specifications were again considered implementation-dependent, which left the implementation of these functions to vendor-supplied libraries. This is contrary to Java's design goals. First, it is complex. It is not a trivial task to share resources between different threads of control. Locks must be acquired and released appropriately. The applications also need to contend with how to handle abnormal termination. Each vendor has its own way of dealing with these issues, which leads us to the second issue, portability. We have discussed how Java's design is architecture-independent and portable. Implementation of multithreading through vendor-specified libraries defeats this design goal. The Java THREAD class provides built-in support for multithreading. This built-in support overcomes the shortcomings we described earlier. For example, within the THREAD class is a set of methods used to start, stop, and check the status of threads. This makes the process of developing multithreaded applications much simpler and more portable. Java threads are preemptive; threads of a higher priority are able to take control of the processor from threads of a lower priority. Java threads may also be time-sliced when the underlying system supports it. By implementing multithreading at the language level, a method within a class can be declared as synchronized . This synchronization uses a monitor and condition variable strategy to ensure that variables maintain their integrity. The point of multithreading is to be able to do more than one thing at a time. This is especially beneficial to IEBI. When doing multidimensional analysis, for example, data for a view can be displayed by one thread, while another thread pre pares another view. Another possible use is the ability to predrill the data. The next level down in detail can be retrieved by one thread while other threads retrieve data at a deeper level of aggregation. 8.2.6 SUMMATIONWe began this section with a description of the Java language: "a simple, object-oriented, network-savvy, robust, secure, architecture neutral, portable, high-performance, multithreaded, interpreted, dynamic language." [3] Table 8.2 summarizes the benefits Java delivers to IEBI.
Table 8.2. The IEBI Benefits of Java
As you will note, we have not discussed several of the features of Java, such as network-savvy, interpreted, and dynamic. We will look at them as we discuss the Java environment.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 113