Class Loading and Packages Section 3.6

1
Class Loading and Packages (Section 3.6)

• What are packages?
• sets of classes that are related in some way
  and/or tend to be used together
• example java.util, javax.swing
• potential example our input utilities consisting
  of console and Swing user interface
  implementations, the Scanner class, and perhaps
  others
• potential example all of the classes associated
  with a particular application, like our Course
  application which now has 3 or 4 classes
• Why use packages?
• ease in grouping
• so all can be loaded at once
• to solve the problem of namespace clashes
• so every class does not have to have a different
  name when an application is built from many
  different libraries coming from many different
  places

2
Loading Classes in a Java Program

• Everything in Java (except the primitive data
  types and syntax) is provided in a class of some
  kind (System, String, ArrayList).
• The question is how do classes get loaded into
  your Java Virtual Machine image?

Class loading
String.class
JVM
ArrayList.class
Input and output streams
Heap(memory storage)
Class defns.(code)
Scanner.class
Symbol table(variable references
MyClass.class
3
Class Loading

• The bootstrap loader runs whenever the JVM is
  started. It loads
• native-mode operations like primitive arithmetic
  operators
• the classes in the java.lang package, like
  System, Object, and Number
• After that, user classes (including Java classes
  not in java.lang) are loaded on demand

public class MyClass private ArrayList al
private Scanner sc public MyClass
(Scanner sc) AnotherClass ac
public aMethod(ThirdClass tc)
FileReader fr new FileReader()
4
The Class Path

• Now we know what Java is looking for
  (ArrayList.class, ThirdClass.class,
  Scanner.class, etc.) and when it is looking, the
  next question is where does it look?
• The Java VM has a property called java.class.path
• you can see the value of this property in Java by
  looking at System.getProperty("java.class.path")
• there are two accepted ways to change this
  property
• in the operating system, by altering the
  CLASSPATH environment variable
• in Windows XP for example, System control panel,
  Advanced tab, button to manipulate the
  environment variable
• when calling the Java JVM, using the -classpath
  flag
• java MyApplication classpath ".myutilities"
• Java recommends the second, but that can be
  cumbersome and difficult especially when the IDE
  does the command dispatch for you
• at the very least you should make sure that your
  CLASSPATH environment variable contains the
  current directory .
• Java is configured to find all classes in the
  java. packages, so you'll never have to
  configure your CLASSPATH to find ArrayList and
  classes like that

5
Packages What's In a Name

• So far we know all there is to know about how a
  class is requested by the JVM (on demand, when
  the class is used in code) and how it is found
  (by searching folders in the java.class.path
  property in order)
• To move to the world of packages we have to
  introduce the idea of a class's name being either
  qualified or unqualified
• Some classes are contained in packages, and some
  are not. When a class is contained in a package,
  its "full" name is qualified by the name of its
  package.
• how does a class come to be installed in a
  package?
• how does package membership affect how a class is
  loaded?
• how do we get away with using the class's
  unqualified name?

6
Creating a Package

• Let's consider the problem of making a package
  out of all our IO Utilities
• the Scanner
• the interface and implementations (console,
  Swing) for IO utilities
• First, put these four classes (Scanner, two
  implementations, and the interface) in a package
• simply by putting package ioutilities as the
  first line in the file
• We notice that Bluej knows that Java will require
  all the class files to be in a folder with the
  same name as the package
• when we're finished, all source files are
  qualified with the package name and are in a
  folder that has the same name as the package
• Now in an application class we can refer to the
  qualified class names, e.g. ioutilities.Scanner,
  and when we do that Java knows to look for a
  folder ioutilities in its class path, and within
  that folder to look for Scanner.class

7
Using Unqualified Names

• Even though Java can find the IO Utility classes,
  we still can't use the unqualified names (why??)
• That's where the import statement comes in
• The import statement has nothing to do with class
  loading (which means it's a dumb name).
• All that the statement import
  packagenamemeans in a class definition is
  "within the definition of this class, allow me to
  say Classnameinstead of packagename.Classname
  assuming that Classname is actually defined in
  that package
• So the statement import java.util allows you
  to declare a variable to be an ArrayList and not
  a java.util.ArrayList
• but this is just for convenience you always
  could have used the fully qualified name

8
Importing, Unqualified Names, and Name Clashes

• Packages are useful because they introduce
  "namespaces" that avoid name clashes
• Suppose we all are working jointly on pieces of
  an application (somebody is working on the base
  data classes, somebody else is working on the
  collection classes, somebody else is working on
  the interfaces).
• We are all working in isolation, but that's fine
  because we know what the interfaces are!
• But now we put all our work together and discover
  we have all defined a "helper" class called
  Attribute
• that's a name clash
• If we put our pieces in different packages, the
  name clash goes away because we actually have
  three different class names
• base-data.Attribute
• collection-support.Attribute
• ioutilities.Attribute
• But of course if our Application class imports
  all three packages, we can once again refer to
  the Attribute class, and it is ambiguous which
  one we are talking about?
• exercise write a small Java experiment to test
  what Java does in the case where two packages
  that define the same class are imported and
  loaded into an application class

9
Packages and JARs

• JAR stands for "Java Archive File" which is a
  handy way to bundle up groups of classes and move
  them around
• just like a ZIP file in that regard
• the JAR file preserves
• The Java class loader has the additional ability
  to load classes stored in a JAR file directly
  (i.e. without unzipping the JAR file)
• The utility command jar is part of the JRE
  release
• creates, displays, and extracts files from JAR
  files
• Also, many IDEs like BlueJ will create a JAR file
• To get the Java class loader to load a JAR file,
  the JAR file itself (not the path containing it)
  must be on the Java classpath
• Last exercise package our IO Utilities up into
  a JAR file, and make our Course application load
  from the JAR file

10
Some Final Notes on Package Names

• You will often see package names that appear
  nested, e.g. javax.swing and javax.swing.event
• it is the case that the classes in the first
  package must be stored in a directory javax/swing
  that appears in the class path, and the second
  package must appear in a directory
  javax/swing/event that also appears in the class
  path
• but import statements are not nested import
  javax.swing. allows you to refer to all the
  classes in the javax.swing package without a
  package qualifier, but it does not apply to the
  javax.swing.event package (even though the
  somehow suggests a recursive wildcard)
• In big commercial projects, you are importing
  packages from many vendors / contractors, and
  there's always the possibility that two
  contractors will produce the same package name,
  and then you have a clash again. So the Java
  standard is to qualify your packages with your
  domain name. If we were to release our IO
  Utilities to the outside world they would be in a
  package something like this edu.washington.tacom
  a.css.tcss143.ioutilities

11
Summary

• A package is a set of related classes
• Packages are good because they are easy to
  manipulate (through directories and/or JAR files)
  and because they reduce the possibility of name
  clashes
• A class is (implicitly) qualified by the name of
  its package
• To load any class, Java looks in its CLASSPATH
  property to find locations
• for a package, it traverses through a folder
  structure that mirrors the package name
• Once a class is loaded from a package, it can be
  referenced by using its fully qualified name
• The import statement allows a program to use a
  class's unqualified name
• A JAR file is a convenient way of bundling up
  classes and packages into a single file