Monday, June 30, 2008

Primitive Variables: Sticks and Stones

In Java there are two types of variables. The simpler type are called "primitive" variables. This makes it sound like you'd only want to use them in programs for, say, starting fires or skinning cave bears. They're actually used in almost every program, and are very powerful.

There are eight types of primitive variable, each one holds a different kind of information. The types are:

boolean--holds a true or false value.
byte--holds an integer value from -128 to 127.
short--holds an integer value from -32768 to 32767.
int--holds an integer value from about -2 billion to 2 billion.
long--holds integer values too big for int.
float--holds a normal-precsion floating point number.
double--holds a high-precision floating point number.
char--holds one character (one letter or digit or punctuation symbol.

Two Steps to Making A Variable



There are two parts to creating any type of variable; declaration and initialization. In declaration you're giving the variable a name, and telling Java what type of variable it is:

int bugs;

In this statement, we've created a variable named "bugs" and told Java that it's an int (normal integer) variable. The name can be whatever you want it to be so long as it's not one of Java's keywords. You can look up Java's keywords in the Java Language Manual available online at Oracle's Java reference site.

A variable is initialized by giving it some value. In the case of a primitive variable, it's simple:

bugs=0;

You can get away without initializing primitive variables in your program, but it's a bad practice. By putting a specific value in the variable in your program, you know what's in your variable before you start using it.

The declaration and initialization can be combined into one statement, and most programmers do this most of the time:

int spiders=0;

You can also declare multiple variables in one statement by putting the declarations (and initializations) in a comma-separated list:

int frogs=0, salamanders=100, newts=3;

You can add linebreaks and whitespace to make longer lists more readable:

char
cow='c',
horse='h',
pig='p',
duck='d',
goose='g',
snake='s';

Many methods can work with primitive types as arguments. For example, println() can have any of the primitive types in it, and it will print them out appropriately:

System.out.println(cow);

Prints:

c

System.out.println(salamanders);

Prints:

100

You can define new colors for graphics in the color class using int variables:

Color amphibianColor = new Color(frog, salamander, newt);

or float variables:

float red=0.95, green=0.98, blue=0.0;
Color lightAmber = new Color(red, green, blue);


(These Color statements are a preview of the declaration and initialization of the other type of variable, reference variables.)
StumbleUpon

Mini Review Posted: Head First Java

I've posted a mini-review of the fine book Head First Java, 2nd ed. by Kathy Sierra and Bert Bates over on my "Cats On Keyboards" blog. I don't recommend it as a first book for the beginner, but it makes a fine supplemental book.

The best part of this book is some of the explanations it gives for how Java goes about doing things. The explanations give your brain something to hang on to that makes dealing with Java's approach to object-oriented programming that much easier.

StumbleUpon

Friday, June 27, 2008

import Statements

An import statement is a way of making more of the functionality of Java available to your program. Java can do a lot of things, and not every program needs to do everything. So, to cut things down to size, so to speak, Java has its classes divided into "packages." Your own classes are part of packages, too.

No import Needed

The simple Hello.java program we've used as an example so far doesn't have any import statements:

public class Hello{
public static void main(String arg[]){
System.out.println("Hello.");
}
}

Everything in the program is already available to the compiler. The compiler can access any class in the java.lang package without needing an import statement. It can also access any classes in the "local" package, which is any classes defined in files in the same directory as the program being compiled that aren't part of another package (that is, they don't have a package statement at the start of the file.)

import Required

Anything that isn't in the java.lang package or the local package needs to be imported. An example is the Scanner class. If you look up the Scanner class in the Java API Specification, you'll see that it is in the java.util package. Remember, to look it up you scroll to the class name in the lower left frame then click on it to bring up its definition in the main frame of the browser. Class names are in regular typeface, interfaces are in italics (some classes and interfaces have the same name.)

Here's an example program that uses Scanner, with an import statement:

import java.util.Scanner;

public class ScannerTest{
public static void main(String arg[]){

// scanner gets its input from the console.
Scanner scanner = new Scanner(System.in);
String name = "";

// Get the user's name.
System.out.print("Your name, adventurer? >");
name = scanner.next();
System.out.println();

// Print their name in a a message.
System.out.println("Welcome, " + name + " to Javaland!");
}
}

We imported just the class Scanner from java.util in the import statement in this program. If we'd been using multiple classes from java.util, we could have made all the classes in java.util available to us by using this import statement:

import java.util.*;

The * is a "regular expression operator" that will match any combination of characters. Therefore, this import statement will import everything in java.util. If you have tried entering and running the example program above, you can change the import statement to this one.

If we need multiple classes from different packages, we use an import statement for each package from which we need to import classes (or interfaces, or any other part of that package we need.) It's not unusual to see a series of import statements near the start of a program file:

import java.awt.*;
import java.awt.event.*;
import java.util.*;
import javax.swing.*;
import javax.swing.event.*;

Now, you may wonder why we have statements importing java.awt.* and java.awt.event.*. It seems like if you import java.awt.* that ought to import everything "under" java.awt, right? And the "dot" notation sure makes it look like java.awt.event is under java.awt.

Package Names and Those Misleading Dots

The thing is, each package with its own name is an entirely separate entity. The dot notation and name similarities are just a convention for making it easier to keep track of which packages have functions that are related to each other. One package isn't inside another one. java.awt.event is an entirely separate package from java.awt, it's not inside java.awt.

This can be very confusing, since the other use of the "dot notation" is a way of getting to something that is "inside" or a member of something else. System.out.println() is a way of getting at the println() method that's a member of out which is a member of the System class. But it doesn't work that way with packages. Each package name is a whole different package, and each package needs its own import statement. java.awt.event is entirely different from java.awt.

You can see package names in the API reference in the upper left frame. If you click on a package name, the lower left frame with change to limit what it shows to just the items in the package you've clicked.
StumbleUpon

Monday, June 23, 2008

Those Pesky Semicolons

Sure, it sounds simple: "A semicolon ends a statement." The problem is that when you're new to the language, new to programming, and you sit down at the keyboard and start typing in your own programs from scratch for the first time, what seemed perfectly obvious when you were typing in code from someone else's examples turns weird and murky.

Let's take a look at a program and dink around with the semicolons in it and see what happens. Several versions of the program I'll give here won't compile, so be warned, this article contains non-working examples!

Here's our program, with no semicolons at all:
public class Semicolon{
public static void main(String arg[]){
System.out.println("argl bargl")
}
}

If you enter and try to compile this program with javac, you'll get the following error:
$ javac Semicolon.java
Semicolon.java:4: ';' expected
}
^
1 error
OK, the compiler is complaining that it got to line 4 and there was no semicolon. Does this mean it expected a semicolon here? No, the compiler tries to make as much sense of your program as it can, and when it gets to the point where it can't make any sense of things any more, it gives you an error message. That means that the place it is saying the error is at is after the place where the actual error lies.

The place that Java has to have a semicolon is at the end of line 3. When it got to the curly brace on line 4, the compiler saw that it had gotten past the point where it expected a semicolon.

So let's add a semicolon at the end of line 3:
public class Semicolon{
public static void main(String arg[]){
if (true) System.out.println("argl bargl");
}
}
This program will now compile and run. The statement here that needed a semicolon to end it was System.out.println("argl bargl"). So how can we know that it wasn't the if that needed the semicolon?

Let's try using a code block with if like this and see what happens. If the if is the statement that needs a semicolon, then we won't need a semicolon after the System.out.println("argl bargl") inside the code block:
public class Semicolon{
public static void main(String arg[]){
if (true) {System.out.println("argl bargl")};
}
}
When we hand this to the compiler, it says:
Semicolon.java:3: ';' expected
if (true) { System.out.println("argl bargl") };
^
1 error
OK, so we know it's the System.out.println("argl bargl") that needs the semicolon, not the if part of the program.

I Know How to Spell Banana, I Just Don't Know When to Stop...

OK, so now we've got the minimum number of semicolons that it takes to make our short and simple program to compile. But what about all those other lines? Why don't we need semicolons for them?

// The minimum number of semicolons:
public class Semicolon{
public static void main(String arg[]){
if (true) System.out.println("argl bargl");
}
}

Well, the comment (first line here) doesn't need a semicolon because technically it's not part of the program. The compiler ignores it. See Comments.

The second line isn't technically a statement, and neither is the line with main(). The curly braces are the same sort of thing to Java as the semicolon, they are all dividers. The curly braces at the end of the first two lines, and in the last two lines of the program define the code blocks associated with main() and the class Semicolon.

But what if we're programming away and this distinction eludes us? What happens if we just start throwing semicolons around like mad?

// Semicolons are cheap, so I use them everywhere! ;
public class Semicolon{;
public static void main(String arg[]){;
if (true){;
System.out.println("argl bargl");
}; // end of if;
};
};


Believe it or not, this program compiles and runs just fine:

$ javac Semicolon.java
$ java Semicolon
argl bargl
Now, I'm gonna shake my finger at you and say "You really ought to know where the semicolons are supposed to be!", but the fact is that if you accidentally thrown in extras it doesn't hurt. Java sees the extra semicolon as an empty statement, so you can put an extra semicolon anywhere a full statement would have been legal. So, if you accidentally throw a semicolon in at the end of a line where it's not necessary it's not going to hurt anything.

OK, where will extra semicolons do actual harm to your program? In the middle of a statement, that's where. Here's an example of a bad semicolon:

public class BadSemicolon{
// This program has an error in it! It won't compile!
public static void main(String arg[]){
int a=4;
int b=5;
int c;

a=b; +c;
System.out.println(a, b, c);
}
}
The semicolon that got put in between b and +c is going to hose the program. It's in the middle of an expression, breaking it up into two pieces. The first part, a=b;, makes sense to the compiler. It says "OK, take the value of b and stick it in a!" This isn't what you wanted it to do, but the compiler only knows what you tell it.

Then the compiler get to +c;, and by itself it doesn't make any sense:
BadSemicolon.java:6: not a statement
a=b; +c;
^
1 error

Because the semicolon is a separator, you've separated one statement into two by sticking one in the middle of things. +c is not a statement in Java, as the compiler tells you. So now you know why we don't just throw semicolons around everywhere, like every other character, just to make sure we get all the ones in that we need.

OK, so a few extra semicolons don't matter. If you just want to get something working in your early days as a programmer and don't want to fuss with semicolons you can throw them in pretty much whenever you think they might be called for and call it a day. If you do that I recommend that once the program is working with too many semicolons in it, that you go back and start taking them out and recompiling to see which ones you didn't need until you get down to just the ones that were really necessary.

Otherwise, I recommend that you only do the ones that you know you need for sure, and when in doubt, leave them out. Then, when you compile, expect to go back into the program and add them where needed. This is a far better approach for learning where you need them than spamming your program with semicolons.

Most of all, have fun!
StumbleUpon

The Java Language Manual

The Java language itself, as opposed to the classes, interfaces, and so on, is defined in the Java language specification, which can be found online. You can either view the online HTML version, or download a copy to your own system in several formats from this location:

http://java.sun.com/docs/books/jls/

This describes how Java programs are put together. It's not an easy read, it's written for compiler implementors more than it's written for programmers.

Look for "API, Language, and Virtual Machine Documentation", the link to view or download this document is in that section, titled "The Java Language Specification."

There are a few items of clarity in the document, like the section on Blocks (code blocks.)

For most programmers, especially beginners, the time to refer to this document is when you have a specific question in mind about some code you're writing that doesn't seem to want to compile. If you take a look at it occasionally, however, looking up things that you do understand and feel like you've got a handle on, it'll start making sense. Then you'll be able to make more use of it as your Java programming ability grows.

StumbleUpon

Saturday, June 21, 2008

Java's Reference Manual

Java has a peculiar name for the reference where you look up Java classes and their methods and member variables. It's called the "API Specification." If you want to know what something does, or how to use it, you look it up in the Java API Specification for the version of Java that you're using.

The online home of these Java language reference manuals is at http://download.oracle.com/javase/

Look for the link here to "API Specification."

Here are direct links for several versions of Java in current use:
Java SE 5.0 (a.k.a. Java 1.5.0): http://download.oracle.com/javase/1.5.0/docs/api/

Java SE 6: http://download.oracle.com/javase/6/docs/api/

Java SE 7: http://download.oracle.com/javase/7/docs/api/

Your Java Version
To find the version of Java that you're using, open a Terminal or Command Line window and enter the command "java -version" (without the quotes, of course.) It will print out something like this:

java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)

The key item here is the information in the quotes in the first line, "1.5.0_13". For the purposes of figuring out which version of the API specification we want to be referring to, we look at the digits before the underscore. In this case, "1.5.0" is the part that's important to us. For this version of Java, we'd select the link for J2SE 1.5.0.

Another approach that's simpler is to simply go to the most recent API reference. Within the API reference, it lists what version of Java each feature appeared. You want to check that on each item before you dig into reading about what cool things it can do--it's terrible to spend a bunch of time reading about a class and methods that solve your programming problem only to have your compiler reject it because you're using a version that doesn't have that feature yet!

You also want to make sure that your compiler version matches your JVM version. "java -version" gives you the version of your JVM (Java Virtual Machine) a.k.a. Java Runtime Environment (they're not exactly the same thing, but close enough for this discussion and the terms JVM and JRE tend to get used interchangeably.)

To get your compiler version, enter the command "javac -version" at the Command Line or command prompt of your Terminal window. Some versions may want you to enter "javac --version" instead of "javac -version", so if you get a big long error message instead of a version message, try using two dashes (or read the usage message and see what it says, it may want "javac -v" or something.)

If your compiler version is newer than your JVM version, you'll want to follow the instructions for your system to point it to the newer JVM as a default so that you are interpreting your programs with the same version of Java that you are compiling it with. Your Java compiler may be compiling code that your JVM can't run, otherwise! The Java Development Kit (JDK), which contains the compiler, also has a JRE bundled with it that matches the version of the compiler. So you shouldn't have to download any updates to get a JRE that matches your compiler, you just have to let your system know which version of the JRE you want it to run.

How this is done varies between different operating systems, so consult the online information on how to do this for your OS or distro.

If your JRE is a newer version than your compiler, you'll probably want to update your compiler so that you can take advantage of all the features of your JVM. Once again, this is a system-specific process.

Looking Things Up in the Java API Specification

Once you're at the correct API specification (say language reference manual or library reference in your mind) you can find a list of classes on the lower left hand side (in the frames view.) Chances are you don't know what package the classes are in that you want to look up, at least at first, so scanning through the long alphabetic list of class names is usually the place to start. There are also names in italic, these are names of interfaces.

Let's say we want to look up System.out.println() which has appeared in many of our examples here. The class name is System, so we click on System in the lower left hand frame. This makes the documentation page for System appear on the right side frame.

Above the words "Class System" you'll see the name of the package that System is part of, java.lang. Click on java.lang in the upper left hand frame and you'll see that it updates the lower left frame to show a much shorter list, a list of the interfaces, classes, enums, and errors that are part of the java.lang package. It's worthwhile to remember the package your commonly used classes are part of, for this and other reasons.

We wanted to look up System.out.println(). Back on the main frame on the right side of the window we can scroll down a little to see the Field Summary, where out is listed. This field, or member variable, is System.out. Click on out.

out is a PrintStream object, which means that it has all the methods of the PrintStream class, among other things. Below its verbose description is a set of links to PrintStream methods, including PrintStream.println(). Click on this link now.

This takes you to a list of different versions of the println() method, which do different things depending on what sort of data is inside the parentheses. In the examples we've been using so far, we've been using "System.out.println("Hello")" so we've been putting String data inside the parens ("Hello").

If we scroll down a bit we see println(String x), which tells us what the expected behavior is for a call of println() with a string inside the parens.

Try looking up some other classes and methods. For example, take a look at what the Scanner class can do.
StumbleUpon

Thursday, June 19, 2008

Code Blocks

A code block in Java is a chunk of code that's surrounded by a matched pair of curly braces: { }

Sometimes the curly braces put people off. They're odd-looking and it's hard to remember where you're supposed to use parentheses ( ), square brackets [ ], angle brackets < > (also known as the less-than and greater-than signs), and all the other odd little bits of punctuation that most folks only ever used for one semester of English class.

Curly braces { } are used to mark the start and end of a piece of code that all works as a piece. If you like, you can think of the opening curly brace { as standing for the word BEGIN to mark the beginning of a section of code. The closing curly brace } would then stand for the work END to mark the end of a section of code. (There are languages that actually use BEGIN and END instead of curly braces, like Pascal and Modula-2.)

In a Java program, there are usually several code blocks. Code blocks can be "nested" with one code block entirely inside another:

public class Hello{
  public static void main(String arg[]){
    System.out.println("Hello.");
  }
}

In this case, the first opening curly brace matches the last closing curly brace (the green ones.) The second opening curly brace, after main(), matches the second-to-last closing curly brace (the red ones.)

Here I've colored the contents of the inner code block red:

public class Hello{
  public static void main(String arg[]){
    System.out.println("Hello.");
  }
}

This would be called the main() code block, since this is the code associated with the main() method.

And here I've colored the contents of the outer code block green:

public class Hello{
  public static void main(String arg[]){
    System.out.println("Hello.");
  }
}

This would be called the Hello class code block, or simply Hello's code block.

Note how the main() code block is entirely within Hello's code block. Because of how Java matches up the curly braces, you can't have one code block "sticking out of" another code block. They always go one entirely inside the other, like nested boxes.

Here's the same program with the BEGIN and END words substituted for the curly braces. This isn't proper Java! It won't compile. It's just a mental exercise:

public class Hello BEGIN
  public static void main(String arg[])BEGIN
    System.out.println("Hello.");
  END
END

Matching pairs are again colored the same.

To make it easier to live with curly braces, there are a lot of editors that will match pairs of curly braces, parentheses, and square brackets for you. Usually you can put your cursor on one, and it will highlight the matching one. Some will "blink" over to the opening character as you type a closing one.
StumbleUpon

main()

There are two basic types of Java programs: applets and applications.* Applets run through a browser or a special program called AppletViewer. Applications are stand-alone programs that run on the same system they're stored on, like most traditional programs. Since there's lots of information elsewhere on applets, we'll concern ourselves mostly with applications.

Every application has a special method called main(). The main() method marks the starting point in the program for the Java Virtual Machine. Here's a short example program:

public class Hello{
public static void main(String arg[]){
System.out.println("Hello");
}
}

When this program is compiled using javac then run with the command
>java Hello
the JVM loads Hello.class and looks in it for the main() method, then starts executing the code inside main()'s code block.

Now, you'll notice there's a bunch of other stuff with main():
public static void main(String arg[]){

Because of how Java works, that stuff has to be there in a Java application. You can't just put "main(){" on the line by itself. The other stuff has a purpose, though it all looks very confusing, and certainly it looks like a lot of extra junk in a short program.

public allows the method to be accessed from outside the class (and its package--we'll get into that later.) If you leave out public, the JVM can't access main() since it's not available outside of Hello.

static says that this is the one and only main() method for this entire class (or program). You can't have multiple main()s for a class. If you leave static out, you'll get an error.

void says that main() doesn't pass back any data. Since the JVM wouldn't know what to do with any data, since it's not set up to accept data from main(), main() has to be of type void, which is to say that it's a method that doesn't pass any data back to the caller. If you leave this out main() won't have a data type, and all methods have to have a data type, even if it's void.

Inside main()'s parentheses is String arg[]. This is a way for the program to accept data from the host system when it's started. It's required that main() be able to accept data from the system when starting. And the data must be in the form of an array of Strings (or a variable-length list of Strings as of Java 5, but that's something we'll save for later.) The name "arg" can be whatever you want to make it. It's just a name I've given the array. It could just as well be:
public static void main(String fred[]){

I'd just have to be sure to use fred whenever I wanted to access the information that the system has passed to my application when it started, instead of arg.

Finally, after the parentheses, comes the open curly brace { that marks the start of main()'s code block.




* There are other types as well, but I'm limiting my discussion to Java SE/client side stuff for now.
StumbleUpon

Wednesday, June 18, 2008

Comments

Comments are lines of the program that are just for humans to read. The computer ignores them. They're useful for putting in notes about what the program is doing, who wrote it and when, and so on.

Here's a program that includes some comments. One way of putting a comment in a Java program is in red, the other way is in green:

/* Hello.java
  A really simple program that prints the word hello.
  This program is a console, or command-line program.
*/
// Written 18 June 2008

public class Hello{
  public static void main(String arg[]){
    System.out.println("Hello");
  } // End of main()
} // End of Hello
The /* marks the start of the first comment. The compiler sees the /* and ignores everything it sees until it gets to the */. Other text could have been on the same line as the */, it doesn't have to be on its own line. The compiler would ignore any text that appears before the */, and read anything that comes after.

A comment that starts with a /* and ends with a */ is called a multi-line comment. It can go across multiple lines easily. It can all be on one line, though--it doesn't have to be split across multiple lines:

/* This is a perfectly OK comment. */

The second type of comment starts with a //. When the compiler sees a // it ignores everything that follows up until the end of that line. As soon as it reaches the end of the line, it starts reading again.

In the example program, I've got a line with the date the program was written that uses the //, and I've used it at the closing curly braces for each block in the program to add comments there about which program block is being closed.

Just to make sure I'm clear here, I want to point out that there's nothing magic about what's in these comments. They don't affect the program. The comment that reads // End of main() could just as well read // Arfn Snuglhoffer. The computer doesn't care. I just wrote "End of main()" to let me know that the closing curly brace the comment is next to closes the main() method of Hello, so I don't get it confused with any other closing curly braces.
StumbleUpon