An Overview of Java: Language Goals, Design Decisions, and Key Concepts

An Overview of Java Based on Concepts in Programming Languages By John C. Mitchell

Brief History • James Gosling at Sun, 1990 • Originally called Oak • Designed to run on a device called the “set-top box” – (TV controller) • Programs would be downloaded to the box • Internet programming language was needed • Oak started as a reimplementation of C++ • C++ wasn’t reliable enough

Java Language Goals • Portability – easy to transmit programs over a network • Reliability – Program crashes avoided as much as possible • Safety – Receiving environment protected from programming errors and malicious code • Dynamic Linking – programs distributed in parts, loaded by JRE

Java Language Goals • Multithreaded Execution – support for concurrent programming • Simplicity and Familiarity – appealing to C++ and Web programmers • Efficiency – important but secondary goal

Design Decisions • Interpreted – Java bytecode executed on a Java Virtual Machine (Portability, Safety) • Type Safety – Three levels: • Compile time checking of source • Type checking of bytecode before execution • Run-time checking (array bounds checking) • Objects and References – Not everything is an object (Compromise between simplicity and efficiency)

Design Decisions • Garbage Collection • Necessary for complete type safety • Simplifies programming. Avoids memory leaks • Uses concurrency. GC runs as a background thread • Dynamic Linking - Classes can be loaded incrementally as needed. Shorter wait times for transmitted programs. • Concurrency Support – Model based on Threads – Standard concurrency primitives built into language. Doesn’t rely on OS specific concurrency mechanisms

Design Decisions • Simplicity – smaller and simpler than most production quality languages. C++ features not included in Java: • Structures and Unions (Classes take their place) • Functions ( Java uses Static methods) • Multiple Inheritance (What was Stroustrup thinking?) • GoTo (Mama mia! It’s spaghetti!) • Operator overloading (small bang for the buck) • Automatic coercions – complex and unsafe • Pointers – Reference variables are conceptually easier and less prone to programming errors

Java Classes and Objects • All Java objects are explict heap-dynamic variables (nameless) • Dog d = new Dog(“Fido”); //inside method • Fido object is explicit heap-dynamic • Variable d is stack-dynamic variable • No destructors – objects are garbage collected when no references are made to them (when GC wakes up)

Java Classes and Objects • Initialization – Constructors called to create every object • All variables given initial values • Instance variable – one for each object • Static variable – one for entire class • Static fields initialized once with initialization expressions or static initialization block inside class • Public static int x = 3; • public class Dog { … static {/* code executed once when class is loaded */} }

Java Classes and Objects • Overloading of methods – based on signature of method (method name, number of parms, and parm types) • Two methods with the same name and different signatures are overloaded • Overloading resolved at compile time

Java Classes and Objects • Garbage Collection – Don’t have to explicitly free objects. No dangling references • Finalize() – Method called by GC just before space is reclaimed. Called by the virtual machine when the virtual machine exits

Java Classes and Objects • Method main is invoked with the name of the class • public static void main(String [] args) • toString() – invoked when a string representation of the object is needed. (Much easier than C++ operator overloading of <<

Packages and Visibility • Four visibility distinctions for methods and fields • public – accessible anywhere the class is visible • protected accessible to methods of the class and any subclasses, as well as to other classes in the same package • Private – accessible only in the class itself • Package –accessible only to code in the same package. Members declared without an access modifier have package visibility

Access Qualifiers Package CLASS B CLASS A public int w; Protected int x; Private int y; int z; CLASS C

Packages • Used to organize classes into logical and physical units • Set of classes in a shared name space • Package names match directory structures • Package names combine with CLASSPATH names to define paths to classes

Inheritance public class Rectangle { private int length, width; public Rectangle(int length, int width) { this.length = length; this.width = width; } public setLength(int l) { length = l; } public int getLength() { return length; } }

Inheritance public class Box extends Rectangle { private int height; public Box(int length, int width, int height) { super(length,height); this.height = height; } public setHeight(int h) { height = h; } public int getHeight() { return height; } }

Method Overridng • Class B extends A • B is the Subclass • A is the Superclass • Class B inherits all fields and methods of A • If A and B have a method with the same name, the B method overrides the A method • If A and B have duplicate field names, the name in B hides the name in A

Constructors • Constructors are called to create objects • Box b = new Box(3,4,5); • For derived classes, superclass constructors are called at the beginning • Rectangle(3,4) • Default constructors pass no parms

Final Methods • Methods or classes can be declared final • public final void myMethod( ) • public final Class A … • Final methods can’t be overriden • Final classes can’t be subclassed

Class Object • All classes in Java are subclasses of Object • Subclassing Object occurs by default • Object methods: • getClass() • toString() • Equals() • hashCode() • Clone() • Wait(), notify(), notifyAll() • Finalize()

Abstract Classes and Methods • A class that does not implement all of its methods • Can’t be used to instantiate objects abstract class Shape { abstract int getSize(); abstract void doNothing(); }

Interfaces • A Java interface is a “pure abstract” class • All interface members must be constants or abstract methods • No direct implementation • Classes “implement” the interface by agreeing to code every method in the interface

Interfaces • public interface Speakable { public void speak(); } • public class Dog implements Speakable … • Classes can implement several interfaces. This takes the place of multiple inheritance used in other languages • Interfaces can be used as the type argument for methods public void makeSpeak(Speakable s) …

Java Types: Classification • Java types fall into two categories: • Primitive – values:true,false and numbers • boolean • byte, short, int, long, char, float, double • Reference – values refer to objects • Class • Inteface • Array

Pointers • There are no explicit pointer types in Java • Java does have implicit pointers • Every reference variable is a pointer that can refer to an object • Dog d = new Dog(“Fido”); d Fido

Reference Manipulation • Dog d = new Dog(“Fido”); Dog e; e = d; Object obj = d; obj d Fido e

Subtyping for Classes and Interfaces • If class B extends class A, then the type of B objects is a subtype of the type of A objects • A class can implement one or more interfaces • (Multiple) interface subtyping allows objects to support (multiple) common behaviors without sharing a common implementation

Array Covariance • Type rule in Java: If B is a subclass of A, B[ ] is a subtype of A[ ] • A <: B implies A[ ] <: B[ ] • This causes a problem called the array covariance problem Class A { …} Class B{ …} B[ ] bArray = new B[6]; A[ ] aArray = bArray; //Ok since A[ ] <: B[ ] aArray[0] = new A( ); //allowed but causes // run-time error - ArrayStoreException

Exceptions • Exceptions are objects • can indicate errors • can indicate unusual events that deserve special attention • Four categories of exceptions • Code or data errors – bad array index • Standard method exception – substring() can generate StringIndexOutOfBoundsException • Programmer generated exceptions – build your own • Java errors – JVM can generate exceptions

Exceptions • Java forces programmers to deal with certain errors • Certain exceptions don’t need to be caught – nothing to be done • Provide a structured form of jump for exiting a block or function • Data can be passed when the exit occurs • Return is made to a point in the program that was set up to continue the computation

Exceptions • Two mechanisms for supporting exceptions: • throw - a statement or expression for raising (throwing) an exception – aborts current computation and causes a jump • try-catch - a handler that allows some code to respond to an exception (catching)

Exceptions • In Java, exceptions are represented as objects of some subclass of class Throwable • The exception object carries information from the point the exception was thrown to the handler that catches it • Designed to work well in multithreaded programs

Exceptions • Exceptions are thrown and caught inside a try-catch block try { … some statements that might cause an exception…} catch(excp1 e) { …response statements } catch(excp2 e) { … response statements } finally { …statements}

Java Exception Classes Throwable Error Exception Runtime Exception Unchecked Exceptions User- Defined Exception Classes Checked Exceptions

Exceptions • Compiler checks that a handler exists for each checked exception • Checked exception that might occur must be named in a throws clause public void foo() throws IOException • Error and RuntimeExceptions are usually thrown by the operating system and are exempt from being listed in the throws clause

Subtype Polymorphism • With Java subtyping, if any method m will accept any argument of Type A, then m will accept any argument from any subtype of A • (Every subtype of A “is-an” A object) • Subtype polymorphism provides a means for writing generic programs

Subtype Polymorphism Stack myStack = new Stack() Dog d1 = new Dog(“Fido”); myStack.push(d1); … Dog d2 = (Dog) myStack.pop();

Generics • Java supports Generic types Stack<Dog> myStack = new Stack<Dog>( ) Dog d1 = new Dog(“Fido”); myStack.push(d1); Dog d2 = myStack.pop();

Java Virtual Machine • Java compiler produces “bytecode” in a .class file • Class file contains bytecode and symbol table – constant pool • Class loader reads the class file and arranges the bytecode in memory • Class Verifier checks that the bytecode is type correct • Linker resolves interfile references • Bytecode interpreter “executes” the bytecode

JVM Java Compiler A.java A.class JVM Network Loader B.class Verifier Linker Bytecode Interpreter

Loader • Classes are loaded incrementally when needed • Classes are objects • Customized ClassLoader objects can be defined

Verifier • Makes sure of the following: • Every instruction has a valid op-code • Every branch instruction branches to the start of an instruction • Every method has a structurally correct signature • Every instruction obeys the Java type discipline

Interpreter • Executes Java bytecode • Performs run-time tests like index checking on arrays • Run-time architecture includes program counter, instruction area, stack and heap • Stack contains activation records containing local variables, parms, return values, and intermediate calculations for method invocations

Interpreter • JVM has no registers. Intermediate values left on stack • Objects stored on the heap • All threads running of the same JVM share the same heap • New threads are given a program counter and their own stack

Interpreter • Activation records have three parts • Local variable area – for local method variables • Operand stack (within a stack) – for intermediate calculations and passing parms to other methods. Instructions are shorter since they implicitly reference the stack • Data area – constant pool resolution, normal method return, exception dispatch

Interpreter: Constant Pool • Bytecode contains a data structure called the “Constant Pool” • Symbolic names – fields, classes, methods • Each entry is numbered • Bytecode instructions reference constant pool numbers

Interpreter • Performs run-time tests: • All casts are checked to make sure they are type safe: Dog d = (Dog) e; • All arrary references are checked to insure the index is within bounds: x[i] = x[j] + x[k]; • References are checked to make sure they are not null before a method is invoked: d.toString( ); • Garbage collection and absence of pointer arithmetic contributes to type-safe execution

Interpreter: Bottleneck • Bytecode references to a field or method cause table lookups for addresses that can be a bottleneck for concurrent programs getfield #5 <Field Obj var> • Bytecode references are modified dynamically during execution with instructions that have direct addresses getfield … quick 6 • Reuse of the instruction is more efficient

An Overview of Java: Language Goals, Design Decisions, and Key Concepts