PART VI: Appendices This part complements the main material of the book by providing an introduction to four important programming languages: Java, C#, C++ and (briefly) C. The presentations are specifically designed for the readers of this book: they do not describe the four languages from scratch, but assume you are familiar with the concepts developed in the preceding chapters, and emphasize the differences with the Eiffel notation that they use. The descriptions do not cover the languages in their entirety, but include enough to enable you to start programming in these languages if you have mastered the concepts of the rest of this book. For practical use of a language system (compiler, interpreter, integrated development environment) you will of course need the corresponding reference information, from books or online. Since not every reader will want to learn every one of the languages, each of the first three appendices can be read independently; this also means, since Java, C# and C++ share a number of characteristics (due to the influence of C and, for the first two, C++), that if you do read all three you will encounter some repetitions. The fourth appendix is a short overview of C presented as a subset of C++, and hence assumes that you have read the C++ appendix. The last appendix presents basic information about using the EiffelStudio environment, to help with the examples of this book and the Traffic software. The appendices are followed by the list of picture credits and the index. A An introduction to Java (from material by Marco Piccioni) A.1 LANGUAGE BACKGROUND AND STYLE Java was introduced in 1995, the result of an internal research project at Sun Microsystems led by James Gosling (other key contributors include Bill Joy, Guy Steele and Gilad Bracha). The language came at just the right time to benefit from two separate phenomena: • Widespread dissatisfaction, after initial enthusiasm for object technology in the late eighties, with the C++ language (see appendix C), particularly its complexity and the limits of its “hybrid” approach retaining compatibility with the non-object-oriented C language. • The spread of Internet access and the advent of the World-Wide Web, Gosling (2007) which seemed to call for a universal mechanism to execute programs securely from within browsers. The Java project, initially intended for “set-top boxes” and network appliances, was ready to support such programs, called applets. As noted in an earlier chapter, ← “Virtual machines, applets never became the dominant computing model as prophesied at the time, bytecode and jitting”, page 333. but Java usage quickly expanded to many other application areas. The following properties characterize the Java programming model: • A close connection between the programming language and a computing platform based on a virtual machine, called a JVM (Java Virtual Machine). • An emphasis on portability captured by the slogan “Write Once, Run Anywhere” and based on compilation to the JVM’s bytecode, which can then be interpreted, or compiled to machine code, on many platforms. • Syntax, general language style and basic instructions taken from the C-C++ line of languages. • A strongly typed object-oriented model, with many of the mechanisms studied in this book: classes, inheritance, polymorphism, dynamic binding, genericity (added in recent versions). Some missing elements are multiple inheritance (except for “interfaces”, as we will see), contracts and agents; in addition, the O-O part of the type system does not include primitive types. • Beyond the language proper, a rich set of libraries supporting software development in many application areas. B. Meyer, Touch of Class: Learning to Program Well with Objects and Contracts, 747 DOI 10.1007/978-3-540-92145-5, © Springer-Verlag Berlin Heidelberg 2013 748 AN INTRODUCTION TO JAVA (FROM MATERIAL BY MARCO PICCIONI) §A.2 A.2 OVERALL PROGRAM STRUCTURE We first review the general structure of a Java program, starting with an overview of the Java Virtual Machine. The Java Virtual Machine A Java Virtual Machine is a software system providing mechanisms to support the execution of Java programs. (We may talk of “the” JVM as the general specification of these mechanisms, and “a” JVM as one particular implementation.) Here are the principal mechanisms: •A class loader manages classes and libraries in the file system and dynamically loads classes in bytecode format. •A verifier checks that bytecode satisfies fundamental constraints on ← “Null” is the same reliability and security: type safety (non-null references always lead to as “void”: see objects of the expected types); information hiding (feature access observes “Void references”, 6.3, page 111. visibility rules); branch validity (branches should always lead to valid locations); initialization (every data element is initialized before use). •An interpreter, the software equivalent of a CPU in a physical computer, executes bytecode. •A Just In Time compiler (JIT compiler or “jitter”) translates bytecode into ← “Virtual machines, machine code for a specific platform, performing various optimizations. bytecode and jitting”, page 333. The most widely used JIT compiler is “Hot Spot” from Sun. Packages Java programs, like those in other object-oriented languages, are structured into classes, but Java offers a modular structure above the class level: the package. A package is a group of classes (like Eiffel “clusters”, which are not a language mechanism but an organizational concept). Packages fulfill three main roles. The first is to help you structure your systems and libraries. Packages can be nested, and hence make it possible to organize classes in a hierarchical structure. This structure is conceptual, not textual; in other words, you will not declare a package as such (with its constituent classes), but instead declare classes and in each of them indicate the name of its package if any: package p; class A {… Declarations of members of A …} class B {… Declarations of members of B …} … Other class declarations … §A.2 OVERALL PROGRAM STRUCTURE 749 If this is the content of a source file, all classes given belong to package p. The package directive, if present, must be the first line in the file. Nested packages use the dot notation: p.q is the sub-package q of p. The package directive is optional; in its absence, all classes in a file will be considered to belong to a special default package. The second role of packages is as compilation units. Rather than compiling classes individually, you can compile an entire package into a single “Java Archive” (JAR) file. In their third role, closely related to the first, packages provide a namespace mechanism to resolve the class name conflicts that may arise when you combine libraries from different providers. When referring to a class A belonging to a package p, you may always use the fully qualified name: p.A. This technique also applies to classes from subpackages, as in p.q.r.Z. To avoid full qualification, you may use the import directive: writing import p.q.∗; allows the rest of the file to use the classes from p.q without qualification, as long as this does not create any conflict. (The asterisk ∗ means “all classes from the package”, not including subpackages.) Fully qualified notation remains available to resolve ambiguities. The package mechanism comes with some methodological recommendations. One recommendation is to use it in its explicit form: include every class in a named package (in other words, do not rely on the default package). Another follows from the observation that packages and namespaces only push the name clash problem one step, since you can still have clashes between package names. To minimize the likelihood that this will happen, a standard convention for packages uses names that start with the institution’s Internet domain, listing components in reverse order; for example a package originating with the Chair of Software Engineering at ETH Zurich (our group, domain name se.ethz.ch) might be called ch.ethz.se.java.webtools.gui Program execution From a command line, the command to start the execution of a Java program is: java C arg1 arg2 … 750 AN INTRODUCTION TO JAVA (FROM MATERIAL BY MARCO PICCIONI) §A.3 where C is the name of a class and the optional arguments arg1 arg2 … are strings. The effect is to execute a method (routine), which must be present in C under the name main: public static void main(String[] args) { … Code for main program… } Unlike in Eiffel, this does not create an object since a “static” method (as ← “System execution”, explained below) does not need an object. Of course main will usually create 6.8, page 130. objects, or call other methods that create objects. The optional formal argument →“Static members”, is an array of strings (String[]), corresponding in the above call to arg1 arg2 … page 753. The public qualifier, also studied below, makes main available to all clients. A.3 BASIC OBJECT-ORIENTED MODEL We now take a look at the basic object-oriented mechanisms of Java; the discussion assumes familiarity with the concepts of the preceding chapters. The Java type system Most Java programmer-defined types will, as in most examples of this book, be reference types, each based on a class. At the top of the class hierarchy stands a class called Object (think of ANY, but there is no equivalent to NONE). ← “Overall inheritance structure”, A major difference with the type system assumed in the rest of this book 16.10, page 586. affects basic types. In Eiffel, and in C# as studied in the next appendix, every type is based on a class; this includes basic types describing arithmetic, boolean and character values. Java, in contrast, follows C++ in treating a number of basic types as predefined outside of the object-oriented type system.