Introduction

If you buy one of those do-it-yourself furniture kits, the best way to start is to just dump all of those screws, nuts, planks, tools and other odd looking widgets on the floor, group them into piles of similar looking items, and then go read the instructions. Even if you don't know what all of those widgets are for, it helps to pick them up and look them over so that you become familiar with them and can recognize them in the instructions.

So rather than dribbling them out over several chapters, here we dump out most of the basic widgets needed to construct Java programs. The goal is to start to become familiar with Java's symbols, keywords, operators, expressions, and other building blocks of the language with which to construct programs. We provide examples and starter programs (on the Web Course) that allow you to begin to write programs without needing to understand yet all of these language elements at a deep level. You should refer back to this chapter as you proceed and as your understanding of the language increases.

Note that in this chapter we occasionally mention the terms class, method, and object. If you are new to object-oriented programming, do not worry about these terms for now. We discuss them in detail in the following chapters.

We begin with a listing of the basic elements and then outline the structure of a generic program.

Introduction

Java arrived on the scene just as computer networking was expanding from isolated local area networks outward to the whole world via the Internet. The developers of Java quickly realized that exploiting the vast potential of networks would become a major activity for programmers in this new interconnected world, so they built a wide array of networking capabilities into the language. This capability grew with each new version of Java and became one of the primary reasons for its popularity.

In this chapter we review the basics of TCP/IP (Internet) networking and some of the tools that Java provides to exploit it [1, 2]. In the rest of Part II we examine many of the more sophisticated networking capabilities of Java with an emphasis on how they could benefit scientific and engineering applications.

Internet basics

As shown in Figure 13.1, networking architecture is based on the concept of layers of protocols. (The more formal OSI – Open System Interconnection – model has seven layers but this one shows the essential layer definitions.) Each layer has its own standardized protocol and standardized application programming interface (API), which allows the next higher layer to communicate with it. Internally, the layers can be implemented in different ways as long as they provide the standard API. For example, the Network layer does not know if the physical layer is Ethernet or a wireless system because the software device drivers respond to the function calls the same way.

Introduction

In this chapter we look first at several topics related to the organization of Java files. In fact, a scheme for organizing Java files and classes comes built into the language. When a class is used, the name of the class includes, either explicitly or implicitly (via the import directive), its location in a particular package. The Java package resembles the code libraries of other languages and provides a name space that successfully avoids name collisions. In practice, a large class library will contain many packages – the J2SE 1.4 class library contains over 100 separate packages – arranged in some sensible order. A very small, single-purpose library might reside entirely in just one package.

In some of the examples in previous chapters the code included the public modifier. We finally explain in this chapter exactly what that modifier does. It and the other access modifiers determine what classes, methods and fields can be used by methods in other classes and subclasses, in the same and in other packages.

For faster downloading, you can pack your Java packages, classes, images, audio files and other program resources into a single file called a JAR (Java Archive) file. JAR files use the ZIP format and compression system (a variation of Lempel-Ziv) to hold files and to maintain internally a hierarchical directory system like that on disk. We show how to create JAR files and how to extract files from them.

Introduction

A web server program runs continuously while waiting for and answering requests it receives over the Internet from browsers. Typically the requestor asks for the transmission of a web page in HTML (Hypertext Markup Language) format or asks for some other HTTP (Hypertext Transmission Protocol) service such as the running of a CGI (Common Gateway Interface) program.

Developing web servers and server applications such as online stores became the first big money-making business area that used Java extensively. Sun offers additional packages with the Java 2 Platform Enterprise Edition (J2EE) to support server development for applications such as database access, shopping cart systems for web stores, and other elaborate middleware services that can scale to large numbers of client users. Companies like IBM and BEA have been quite successful in selling their own middleware Java software.

In this chapter and the next we look at a simple socket-based approach to building web servers for specialized applications [1–4]. This can be done with the classes available in J2SE. In Chapters 16–20 we focus on RMI (Remote Method Invocation) clients and servers and other distributed computing techniques. In Chapter 21 we return to web-based networking with a discussion of web services.

We show here how to create a simple web server that could run on any platform that implements a JVM with the java.net and java.io packages.

Introduction

As has been demonstrated, Java is a very capable platform for many scientific computing tasks. Yet Java is still sometimes perceived as slow. While this often is a no-longer-deserved reputation, especially in Java 1.4 and later, there are definitely times when the nature of the scientific calculation is so demanding that typical desktop computing resources are insufficient. In such cases, moving portions of the calculation to a heavy-duty remote server machine, perhaps even a “supercomputer,” makes good sense. In this chapter, we introduce the concept of distributed computing.

We continue with the client/server paradigm discussed in the previous chapters, but rather than simply passing messages via socket connections, the client and server objects directly invoke methods in each other over the network. This allows for much more elaborate and productive interactions. The Java Remote Method Invocation (RMI) or Common Object Request Broker Architecture (CORBA) frameworks take care of the communications, and we do not need to create our own low-level protocols as we did with sockets.

We first discuss just what distributed computing is and what form of distributed computing is of value to scientific calculations. We introduce just a little Unified Modeling Language (UML) as a visual aid to understanding the various components in a distributed application. This use of UML and the Design Pattern approach allows us to describe client/server programs in a more formal manner than in the previous chapters.

Introduction

Java's graphics capability has always been a leading feature of the language. The Java designers clearly expected the graphical user interface (GUI) to dominate interactions with Java programs on all but the smallest platforms. Java appeared at the start of the Internet boom and applets were expected to bring interactivity to the browser. Many thought that Java would also quickly become popular for standalone client applications on platforms with graphical operating systems.

In Java 1.0, however, the graphical elements provided for workable interfaces but they appeared crude compared to platform-specific graphics developed with other languages. The goal of portability had led to a lowest common denominator approach that was not very pretty. This became one of the main stumbling blocks that prevented Java from becoming a popular language for desktop applications.

However, with the inclusion of the Swing packages in version 1.2, Java graphics took a huge leap forward in visual appeal and in the breadth and depth of its features. With subsequent versions, Java graphics continued to improve and now compares quite well with that available with any other programming language and still provides for relatively easy portability.

In this chapter we introduce Java graphics starting with a quick overview of the Abstract Windowing Toolkit from Java 1.0. We then look at the Java Foundation Classes system, also known as “Swing,” in some detail. We wait until Chapter 7 to discuss how to bring interactivity to the user interface.

Escaping the sandbox

The Java Virtual Machine (JVM) is often said to provide a safe and self-contained sandbox where programs such as applets can play without accidentally or deliberately entering restricted areas of the platform. That is sufficient if all a program does is interact with the user via a graphical interface but many programs need to reach out and access the world beyond the JVM to obtain information and interact with external hardware.

In Chapter 22 we showed how Java classes can link to native codes, which possess none of Java's security restrictions. This is the ultimate form of local platform access but it involves a lot of inelegant coding and violates the portability of Java. In this chapter we look at less drastic ways that a program can access the platform. We first show how a program can obtain properties describing the platform such as the operating system, the Java version, and screen size. We then explain how to run a non-Java program from within a Java program. Next we discuss how to use serial ports to communicate with external devices. We include a demonstration program in which a Java application communicates via a serial port with a temperature sensor.

We note that the security restrictions put into place by a browser JVM place severe limits on the access that applets have to the platform and the network. However, as we saw in Chapter 14, the security restrictions on Java applications can be easily customized as needed.

Introduction

Any language should come with a well-stocked toolbox of utilities to ensure programming efficiency and convenience. The Java core language, in fact, includes a large package named, quite sensibly, java.util that holds classes to handle arrays, hash tables, time keeping, and other common tasks. In this chapter, we focus mostly on this package but also discuss some handy tools in other packages such as String and StringBuffer in java.lang and StringBuilder and enum, that were added to java.lang for J2SE 5.0 [1, 2]. We also discuss the Collections Framework and the new Generics feature of J2SE 5.0.

We also look at classes and techniques for handling numbers at two extremes. For bits we have the java.util.BitSet class. For arbitrarily large numbers and for those that with very long decimal fractions we have the java.math. BigInteger and java.math.BigDecimal classes.

We can only briefly describe here the general workings of these classes, many of which contain a great number of methods. See the class descriptions in the Java 2 API Specifications for the full details.

The java.util Package

The package java.util has been part of the core language since Java 1.0. However, several classes have been added in subsequent versions. As the name suggests, the classes in this package serve a number of useful utility purposes, and we discuss several of them in this chapter.

Introduction

Chapters 16 and 17 described the client/server or distributed object paradigm at a somewhat abstract level using the UML notation language. Because of the abstract nature of that discussion there was almost no Java code in either of those chapters. In fact, the only place that any code snippets appeared at all was to illustrate UML concepts in a familiar concrete Java environment.

Now we will begin to explain how to really implement the distributed object paradigm using Java Remote Method Invocation (RMI). By the end of this chapter, we will have some real code that demonstrates simple communication between two distributed Java objects, though we still won't have a running application using the architecture of Chapters 16 and 17. That complete application will be developed in Chapter 20.

Before getting to the real code, we must first describe how distributed computing can be implemented. The concepts are not particularly new, nor are they unique to Java. However, just as in other areas, the Java platform offers advantages and an easy programming style that are absent in other languages. These advantages are discussed as we explain how distributed computing works. While the full capabilities of RMI are beyond the scope of this book, we will learn the basics of RMI, and with these skills we can implement the distributed architecture described in Chapters 16 and 17.

How distributed computing works

Consider a conventional (non-distributed) computer program, be it written in Java or some other language.

Introduction

In Java the “class” is paramount. Essentially all coding resides within class definitions. Here and in the following chapters we develop the concepts and coding for classes and objects in Java.

For those new to object-oriented programming (OOP) the learning curve can be rather steep because several concepts must be understood before the overall picture comes into focus. The Web Course Supplements section for Chapter 3 offers additional introductory material to help get these concepts across.

Note that throughout the book we use the terms object and instance interchangeably.

Custom data types

In Chapter 2 we discussed Java primitive data types such as int, float, and boolean. Data of a given type means that memory is reserved for a value of that type and that only operations specific to that type can act upon the data. So, for example, a float value has 4 bytes of memory allocated for it with the sign, exponent, and significand bits arranged according to the representation discussed in Chapter 2. When an operation such as an addition or multiplication occurs upon a float value, the JVM executes floating-point operations that carry out the proper procedures for addition and multiplication with significands and exponents. For integer addition and multiplication the JVM executes a different set of operations unique to integer type data.

Introduction

Threads in Java are processes that run in parallel within the Java Virtual Machine. When the JVM runs on a single real processor the parallelism is, of course, only apparent because of the high speed switching of threads in and out of the processor. Yet even in that case, threading can provide significant advantages. For example, while one thread deals with a relatively slow I/O operation such as downloading a file over the network, other threads can do useful work. Threads can assist in modularizing program design. An animation can assign different threads to rendering the graphics, to sound effects, and to user interactions so that all of these operations appear to take place simultaneously. Furthermore, a JVM can assign Java threads to native OS threads (but isn't required to) and on a multiprocessor system it could thus provide true parallel performance.

Java makes the creation and running of threads quite easy. We will concentrate on the basics of threading and only briefly touch on the subtle complications that arise when multiple threads interact with each other and need to access and modify common resources. Such situations can result in data race, deadlock, and other interference problems that result in distorted data or hung programs.

Introduction to threads

In Java you can create one or more threads within your program just as you can run one or more programs in an operating system [1–4].

Introduction

In the previous chapter we introduced Java graphics and focused on the display of components, drawings, and images. Here we discuss how to build a graphical display that interacts with the user. A Graphical User Interface (GUI) requires dynamic components like buttons and menus that cause something to happen when the user activates them with the mouse or keyboard. These components generate messages called events that signal what action occurred. We will first look in this chapter at the underlying structure for generating and processing events.

We then introduce several more Swing components such as checkboxes and sliders and present demonstration programs that illustrate how to receive and process the events they generate. We discuss in more detail how components are arranged on the interface with the use of layout managers. For event handling and other tasks, we examine the use of inner classes and adapter classes. After a discussion of frames and menu bars, we demonstrate GUI construction and event techniques with a couple of programs involving histograms.

Events

The graphical user interface (GUI) offers a profoundly different programming environment than the old step-by-step, linear world of a procedural program communicating via a console. In the latter approach, the user simply starts a program and waits for it to churn through its algorithm and eventually reach the end and stop. In the GUI environment, the program instead waits for the user to select some task and then carries out that selected operation.

Java is a serious language suitable for demanding applications in science and engineering. Really, we promise! Java offers a lot more than just those little applets in your Web browser.

In JavaTech we focus on how Java can perform useful tasks in technical computing. These tasks might involve an animated simulation to demonstrate a scientific principle, a graphical user interface for an existing C or C++ computational engine, a distributed computing project, controlling and monitoring an experiment remotely via the Internet, or programming an embedded Java hardware processor in a device such as a remote sensor. While other Java books intended for the science and engineering audience concentrate primarily on numerical programming, we take a much broader approach and examine ways that Java can benefit programmers working on many different types of technical applications.

This project grew out of a course given by two of us (C.S.L. and Th.L.) at the Royal Institute of Technology in Stockholm, Sweden in which students of diverse backgrounds followed the class via the Internet. For this type of distance learning situation, we developed hypertext instructional material for delivery via the Web browser that allows for a high degree of self-study. This approach works especially well with Java since many of the demonstration programs run as applets within the browser.

This book provides a handy print companion to this hypertext course, which is available online at www.javatechbook.com.

Introduction

CORBA is an acronym for Common Object Request Broker Architecture, a name that does not really convey to the new user the purpose of the technology. Most people just think of CORBA as the name of an important distributed object technology without really considering what the acronym stands for. For Java developers, RMI is generally the preferred distributed object architecture – especially when it is known that both client and server will be written in Java. However, CORBA has the advantage that it is language independent, meaning that non-Java clients can make CORBA calls to a CORBA server.

CORBA is a standard, so there is an official specification of that standard. The standard is maintained by the Object Management Group, a consortium of over 800 members. See the www.omg.org home page for voluminous information on CORBA and other technologies developed by the OMG. CORBA is also a very broad technology that covers much more than we introduce here. Our point is to demonstrate how CORBA technology can be used to implement straightforward distributed computing solutions analogous to the RMI example developed in Chapter 18.

A typical scientific application, such as the simulation described in Chapters 16 and 17, generally has only a few users. The developer writes both the client and server and, if developing in Java, probably uses RMI.