Working with others’ code II: Packages and Exceptions
[Part 6]
So, we've now covered almost all of the core java language: we'll cover the last couple of bits now. Having got to this stage we're in a position to start thinking about the real joy of Object Orientated Programming, which is the way it allows us to use code written by other people. In truth, probably 0.1% of a program you develop will actually be written by you. The key to Object Orientated Programming is the vast collection of community and Java code that runs whenever you run a Java program.
We've already seen a major element of this process when we looked at inheritance: the option to build one class into another. The only remaining trick is to get hold of other people's classes, then we can use object creation and inheritance to build objects from their code and fold their classes into your own.
Further info:
Hopefully you can now see just how full of stars Object Orientated Programming is: imports allow us access to any other code anyone has made available. You can either make objects from their code, or extend it to add your own functionality! It's a stunning world of Windows, and Web Servers, and Robots, and Artificial Intelligences, and Video Special Effects, and Mobile Apps, and Statistics, and Satellite Tracking, and Analysis, and Ecological Models, and, well, just about everything you might like to do with a computer. Hope you're excited!
To show you how easy this makes everything, here's some code that you can run that shows you the power of imports and extension. We're getting a few parts ahead of ourselves, but heck, we might as well have some fun -- we've sweated enough to get this far:
import javax.swing.JFrame;
import java.awt.Label;
public class HelloFrame extends JFrame {
public HelloFrame () {
super("HelloWorld!");
setSize(300,300);
setLocation(300,300);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
add(new Label("Hello World"));
setVisible(true);
}
public static void main (String args[]) {
new HelloFrame();
}
}
And there you go -- tens of thousands of lines of code run in the background to get all that running, and you don't need to know and understand anything other than the 15 lines above (which hopefully you have some broad ideas about)! How fab is that!
Quiz:
Given this directory set up:
If you were at the command line in the the highlighted "presidents" package directory on windows you'd move to the right directory and
compile and run a class "Roosevelt" in it by typing:
______________________________
______________________________
______________________________
-
cd ..\..\..
javac *.java
java us.gov.presidents.Roosevelt -
cd .\.\.
javac *.java
java us.gov.presidents.Roosevelt -
cd ..\..\..
javac us\gov\presidents\*.java
java us.gov.presidents.Roosevelt -
cd .\.\.
javac us\gov\presidents\Roosevelt.java
java Roosevelt -
cd .\.\.\.
javac us\gov\presidents\Roosevelt.java
java Roosevelt
Correct!
1) You need to move down three directories to the "src" directory, where the package hierarchy starts. The
cd command, followed by .. will drop a directory, ..\..\.. will drop three (. means "this directory", so
.\.\. won't move you anywhere).
2) If the program just uses files in the "presidents" directory, you can actually get away with compiling within that directory, but if it
uses any other non-core packages you need to be the "src" directory to compile -- if you are here, the compiler will find
and compile any needed classes. Nevertheless, you still need to tell the compiler what to compile, for example
all the java files in us\gov\presidents\.
3) Finally, because the file is in a package, you need to use the
full class name when running: us.gov.presidents.Roosevelt .
Further info:
One of the most common runtime exceptions is the NullPointerException. This
is usually generated when using a label which has no object attached to it. This is
suprisingly easy and often takes some checking to track down. The usual way it happens is
people working with local variables thinking they're working with instance variables, and
vice versa, and when people forget to fill arrays with objects before using them. The code
below does both.
Point[] pointArray = new Point[10];
Looks dumb, but, trust us, sooner or later you'll do both.
----------------------------------
public void configureArray() {
Point[] pointArray = new Point[10];
for (int i = 0; i < pointArray.length; i++) {
pointArray[i].setX(20.0);
}
}
----------------------------------
pointArray = configureArray();
pointArray[0].getX();
There were actually some very nice additions to exception handling in Java 7, so if you can guarentee your users have updated to the appropriate JRE, you might like to check out this brief introduction.
To be honest, it's unlikely, unless you develop some generic 'toolkit' classes for others to use, that you'll ever have to make your own exceptions. Nevertheless, here's some code that does it (well, the most basic job of it), should you want to see how it is done. The code generates a number of different errors and shows the difficulties associated with getting the catch exceptions wrong. The first exception thrown is a home brewed one:
Quiz:
Given the following code:
public class Play {
|
public class Psy {
|
The code prints _________________ .
"Gangnam style Op op op op oppan""Gangnam style""Op op op op oppan Gangnam style"- what it prints -- I'm not even going to justify this question with an answer
Correct! Note that we can twist the try-finally statement to get stuff done after the return statement has run, but before the calling code
is evaluated. This is like slipping into weird gap in time, albeit a gap, with this code, filled with Psy. Remember, the finally
code will always run if it can. We don't actually need a catch block. This code is, though, quite odd.
Further info:
Getting your head around both making java docs and reading them is key to being a Java programmer. Making docs makes your code future proof and as useful as possible. Reading docs... well, basically you can't program anything advanced without them.
Given this, you'll need to work through these two tutorials:
Reading documentation comments.
Writing documentation comments.
Here's a quick link to the API Docs.
We saw a brief intro to the extensive java 'Collections Framework' when we looked at Vectors in the first set of slides. Now we've looked at generics we're in a better position to understand these. If you intend on doing any data storage it is worth checking out the Oracle introduction to the Collections Framework. Classes worth checking out are ArrayList (the preferred alternative for arrays), Hashtable (for linking a list of unique data like IDs with attributes like home addresses), along with the interface Enumeration (which a lot of these classes implement and which provides a way of looping through them using while loops, which tends to be the preferred option).
In general, if you are interested in 2D data stored so it can reliably be found at a location in the storage object, use an array. If you want a bag where you can throw stuff, use a collection.
If you are interested in generics, you can find more info in this Oracle tutorial. You may also be interested to see how Java allows for primitives to be added to the collections, through a processes called Autoboxing.
Quiz:
Have a look at the here's a quick link to the API Docs for
java.lang.ArrayIndexOutOfBoundsException.
The only method declaration from the list below that is available through the class is ______________________.
public String getMessage()public String printStackTrace()public int initCause()- ...none of them, they're all inherited
Correct! All the methods in ArrayIndexOutOfBoundsException are inherited, it has none of its own. printStackTrace returns
void, so, rather than using it with System.out.println, it is called like this:
exceptionObject.printStackTrace();