Read an Excerpt
Chapter 1: Deploying JavaThis introductory chapter presents the deployment of Java software with a discussion of the current pervasive state of this computing technology. At the end, some general concepts are introduced that will form the base of the remaining book.
The Java Runtime EnvironmentWhat is software deployment all about, and how does it apply to Java? Generally speaking, the software deployment process is a sequence of steps as detailed in Figure 1.1. This is a deceptive diagram because, as we will see, things are not so simple.
It could help to think of our latest favorite application that we downloaded from some Web site and installed on our computer. Someone developed and then published it for use.
However, the scenario could be slightly different; we could have downloaded the latest videogame to a handheld device using another form of the Internet (for example wireless protocols rather than HTTP). The installation in that case could have taken place automatically, given the simplicity of our client device.
With the main subject of this book, the Java platform, suddenly the two previous cases get blurred into one, because both previous cases could have been implemented in Java. Figure 1.2 illustrates this.
Figure 1.2 depicts many of the platforms Java can run on, together with the typical connection bandwidths (a dotted arrow indicates there is not a permanent connection to a network).
Inexpensive computational power in the form of consumer devices pervading our daily lives, together with the Internet revolution, promise an unprecedented development both within the computer industry and in our society. We do not know how the world will look on the other side of this change, but we can say that Java will play an important role. Likewise, techniques aimed at distributing and maintaining Java code will also play an important role.
When it comes to deploying Java code, we must consider not only the executables and their related resources, but also a unique-to-Java piece, the Virtual Machine, in its different flavors and its runtime support (core libraries, support utilities like the RMI registry, and so forth). Because the Virtual Machine is required to run the Java code, this is like saying that if you want to listen to the music contained in some disks, you must buy and bring home the special disk player as well. Therefore, deploying Java software, at least presently, is more complicated than deploying native executables. This is because the client platforms so far do not come with preinstalled, up-to-date Java Runtime Environments (JREs). The JRE to be installed depends on the specific platform, as do the size and the communication mechanism, and many other parameters. This completely changes the situation, and makes the deployment of Java software different from all other software.
The Desktop FrontDepending on your perspective, the battle for allowing Java on the PC desktop can be thought of as a WWII scene where allies try to conquer a position by bravely parachuting light infantry. From another vantage point, the Windows OS can be viewed as the last paradise to be guarded against clumsy Java weapons and fanatic marketers. Indeed, Sun has tried hard to gain some ground on the desktop. Technological attempts included first Java applets, and then the Plug-in, followed by JIT technology or Hotspot. The latest attempt, the Java Native Launching Protocol (JNLP), will be the subject of Part III of this book.
Java executables on the desktop (such as PCs, Macs, and Linux machines) suffer from a serious deficiency. In order to be run, they need to download an installation of a bulky piece of software that weighs in at around 5 megabytes. Of course, there are alternative solutions, like taking advantage of your Web browser's JVM or using JREs pre-installed on some OSes, but these usually turn out to be closer to compromises than proper solutions. This is a severe hurdle. Even worse, the size of the J2SE JRE has been constantly increasing (see Figure 1.3). Fortunately, J2SE size seems to be stabilizing.
In Figure 1.3, the size (y-axis) refers to the download dimension of the JRE installation package, and the 1996-figure (JDK 1.0.2) refers to a development kit, which includes a compiler and other tools. The x axis lists the release year for each version. This data refers to Win32 versions.
More importantly, the Internet connections are improving relentlessly, so that paradoxically, it is now quicker to download the SMB bundle for the J2SE JRE for Windows than it was to download the smaller JDK 1.0.2 package in 1997. As we will see, this plays an important role in favoring new software deployment techniques.
If Java wants a bigger role on the desktop scene, it needs to land soundly, that is, to gain the capability to run full-fledged applications with the latest JREs, on that ground. This can be compared to the ancient epic story of the Troy siege, where Greeks resort to a gigantic wooden horse to fool Trojans and penetrate the city. Probably Sun engineers do not need to be as astute as Ulysses, but they won't progress very far if they don't find the correct solution. We will address a proposal in Part 111, "JNLP."
Virgin LandsApart from the fiercely fought battle for Web-enabled desktops, there is much more promising and (apparently) easy ground to be won on handheld, wireless devices and other specialized hardware. These devices are addressed by the J2ME edition, the Java Card, and the Java Embedded Server technologies. Also, Jini Technology will play an important role in this market.
Embedded devices are all devices based on simple microprocessor architectures-simple because they are designed to run only very specialized programs, unlike PCs, where hardware is designed to run different kinds of programs. For example, a coffee machine cannot run a spreadsheet program because its hardware is specialized for certain operations only. The same is true for a PDA (Personal Digital Assistant) or a cell phone. Because of their focused nature, embedded devices can vary greatly from one another. Differences are captured in the APIs that each device supports. Sun has defined special configurations and profiles to address this problem. When two devices are said to belong to the same configuration they share a common, minimum set of APIs. Differences are described using profiles. An example of a profile is the J2ME Mobile Information Device profile, or MIDP.
Given the nature of client machines in this market, deploying Java code could become rather easy or quite difficult. It could be easily compared to desktop applications because executables for the consumer and embedded markets are generally much smaller and simpler. Nevertheless, deploying such Java programs could be difficult if cross-device software editions are enforced. An example of a difficult deployment is a word processor that is available on Java-enabled cell phones, high-end digital assistants , and other Java platforms. This example requires a careful software design and smart deployment techniques. The risk is to write many different versions of the same application, each one specialized for a given device, which diminishes the advantage of the Java language. The bytecode format with which they are written is the only thing these versions would have in common....