A Beginning Programmer's Guide to Java

Java under Mac OS X 10.7 Lion

2012-01-23T17:15:00.000-08:00

Lion is the first version of Mac OS X that doesn't come with Java already installed. Earlier versions not only had the Java Virtual Machine or runtime element installed, but they also had the JDK installed, which is the part that lets you write your own Java programs.

Once, Java was an important part of Apple's strategy. They maintained their own version of Java for the Mac and encouraged its use by developers every bit as much as they encouraged the use of Objective-C.

The success of the iPhone and the iPad have changed that, however. Apple decided that Java would not be part of those platforms. The lack of Java is the very reason I've chosen not to get an iPhone. Instead, I get phones with Java so that I can run my own Java applications that I write for my own use.

Now that Lion doesn't have Java pre-installed, what do you do? Fortunately, a deal has been struck where Java is still available for the Mac. It's much the same arrangement as Java for other platforms. In fact, it's easier to install Java on your Mac than any other platform. And you get the JDK along with the runtime (JVM) environment.

Simply use Finder to go to Applications=>Utilities. There, start Terminal. Once Terminal starts, type in the command 'javac'. Your Mac will tell you that Java isn't installed, and let you install it.

I'm pleased that the Mac has not entirely forsaken Java, even if it's not an integral part as it has been. The basic software supplied with the Mac has declined severely over the past few years, but fortunately Java is still available and easy to install when you want it.

Embedded Java

2012-01-06T23:58:00.000-08:00

Embedded Java sounds almost like an oxymoron. Taking a high level, large, interpreted language like Java and using it in an application field dominated by assembly and C certainly seems odd. But it's a reality.

For one thing, the microcontrollers of today are not the limited 1K to 2K ROM, 8-bit, 200kHz machine cycle rate CPUs of yesteryear. They're more powerful than the desktop systems of 10-15 years ago in many cases. And we were playing Quake II on those. So maybe Java isn't quite such a stretch, after all.

NanoVM is a small, subscale Java-ish virtual machine that runs on tiny 8-bit microcontrollers like the AVR ATMega8. It's not a full Java, but it covers most of what's interesting to the microcontroller programmer.

The JStamp is a Java development system for the aJile micros. It's also not a full Java SE implementation (what would you do with the extra bits, even if it was?), but it is a verifiable real-time Java system for embedded development.

Also, IS2T has MicroEJ, another embedded Java for a number of processors. Everything from the basics of execution and I/O up to GUIs, SOAs, and safety-critical libraries are available.

I still remember when it was considered laughable to consider a C-language embedded development system. But it has either nudged assembly out of the top spot for embedded development or is close to it, now. Any language that is popular enough can be brought to the task now, and Java is no exception.

It's all just a bunch of ones and zeroes in the end.

Mobile Java

2011-10-20T19:47:00.000-07:00

One of the nice things about Java is that is supported on more than desktop platforms, and has been for a long time. This means there is not only a large library of existing software, but also well-tuned development systems to use with mobile platforms.

By "mobile platform", I'm referring to smartphones and tablets. There are other mobile platforms, but these are the most common ones. Netbooks may also run a "mobile" operating system, or they may run a normal desktop OS. Those that run a normal desktop OS will run normal Java SE applications. Java SE is "Java, Standard Edition", the version that typically runs on a desktop or laptop computer.

Java ME is Java, Mobile Edition. It runs on most smartphones, and many tablets. It is very similar to the Java SE version covered in most of my articles. In fact, it is possible to write many applications using a subset of Java that will run without change under both Java SE and Java ME.

But normally a Java ME application will use user interface objects and interfaces that are specific to Java ME. In many ways these are more sophisticated than the ones for Java SE. Creating many types of graphical interfaces, such as tiled graphics, is easier in the mobile edition than in standard Java.

I have been writing small, simple applications for my cellphones for about ten years now. It's nice to be able to write your own little application for your own unique needs. I started writing Java applications for my Nokia 3650, called a "feature phone" at the time I got it. It was a Symbian Series 60 phone that ran an early version of Java ME with a very basic library of GUI features.

My next phone was a step up the Java ladder. It was a Sciphone G2, a fake Android phone. I didn't mind that it was "fake", it ran a real version of Java ME with updated GUI capabilities, which made it far easier to write applications for.

My current phone is a Blackberry Curve 8900. It runs Java ME with all the latest bells and whistles, plus a lot of Blackberry add-ons that make it easy to access the phone's features.

With my Nokia, I had a special Java development environment provided by Nokia that included a simulation of my phone, so that I could see how my programs would run before I put them on the phone. With the G2 I was on my own. I ran a standard Java ME development environment from within Eclipse, a great Java integrated development environment. The version linked above is a version specific to Java ME.

Now I'm back to having a development environment provided by my phone's maker. I have a program that simulates my phone on my computer, which again allows me to try out my programs before I put them on the phone (with my G2 I tested them as well as I could, then loaded them on the phone and hoped for the best.) It is build on Eclipse, so it is still very familiar. There is also a slew of information on the Blackberry site (linked above) about Java development.

Unfortunately, the tutorials on the site don't exactly match the actual current version of the software, but it's close enough it's not too hard to figure out. One thing that confused me, however, is the installation instructions. I thought I had to install the version of Eclipse they called for before installing the "Blackberry Java Eclipse Add-On". It's an add-on, right?

Well, it turns out that the "add-on" from Blackberry is actually the entire thing, Eclipse and all. So you just need to do that one download to get the development environment. Then download the simulator for your phone and any others you want to test your software on. Finally, apply for a signature key to make it so that you can "sign" your software to allow it to be installed on the phone through the software manager or Over The Air (OTA) when using the Blackberry-specific libraries.

If you'd rather not do this, you can develop software using a plain-jane version of Java ME, then transfer the software to your phone however you please. I put the software I developed for my Sciphone G2 on the memory card for my Blackberry, and it runs just fine.

Translating applications between Java SE and Java ME can be simple for ones with minimal amounts of graphics, like programs that mainly use text, buttons, and text entry boxes for communication. Things like games, with a more involved use of graphics, take more effort to translate between the two versions of Java. For these, I usually re-use the game logic code without changes, then rewrite the graphical display parts of the program from scratch. Because I use good object-oriented coding practices (most of the time), this isn't too much effort.

Java ME applets are easy to translate, though I write almost all of my Java software as applications now.

Numeric Literal Values

2011-09-05T21:00:00.000-07:00

Java 7 has added a new feature, binary literals for integer number types (byte, short, int, and long.) Before we can get excited about this, we need to know what that means. In earlier versions of Java, we have had several other types of literal value.

Let's Get Literal

What is a "literal"? A literal is an explicit value. For example, in this line:
int number=123;
the value 123 is a "literal". Since it's a normal base-10 value, we might say it is a "decimal literal". Decimal values don't have to be marked in any special way.

A hexadecimal literal looks like this:
int number=0x007b;
The value 0x007b is a hexadecimal (base 16) number that is expressed literally (stated explicitly.) The 0x at the beginning is what marks it as a hexadecimal value. The leading zero shows that it's a numerical value, not a variable name or keyword or something like that. The x marks it as a hexadecimal number.

Hexadecimal numbers take binary values four bits at a time (a bit is a single one or zero value) and puts them into a single digit. Octal (base 8) digits each represent the values of three bits.

To tell Java you're using an octal value, place a leading zero in front of the number itself:
int number=0173;
Here the number 0173 is an octal value equal to 123 in decimal. If we accidentally put a zero in front of a decimal integer, we'll either get an error (if we use the digits 8 or 9 in that number) or the value will be interpreted incorrectly. For example, if we want to put the value of one hundred twenty-three into a variable, but instead of the line we have above we accidentally add a zero, like this:
int number=0123;
The value of the number will be interpreted as eighty-three, not one hundred twenty-three. So watch out for that.

New for Java 7--Binary Literals
In Java 7 we get a new ability, the use of binary numbers. Since you know that you can encode binary values into both octal and hex either three or four bits at a time, this may not seem like a really big deal. In fact, there's been a request to add this feature to Java for a long time, but it's been low priority.

But now it's finally here.

So you can define values as individual bits, like this:
int number=0b01111011;
That's the binary for one hundred twenty-three, by the way. Why is this important?

As Java becomes more mature, and more widely used, it is used in more places. Over time, high level languages that deal with things at a very abstract level tend to get used in more situations where it is nice to have the high level features while also having the ability to have low level control or simulation of the actual computer hardware. In cases like these, it is nice to be able to manipulate single bits in places where they represent specific individual signals in the computer system or simulation.

For example, let's say we want to recreate an old 1980s computer in a Java program, like a Commodore 64. The Commodore 64 reads several signal lines directly on its joystick ports. We want to be able to simulate the behavior of these ports so that we can play old C-64 games in our simulation. Each of the lines represents a switch in the joystick. So we may take a particular keypress and represent it as the following binary value:

byte stick_up=0b00001;

In this case, we show it setting the lowest order bit. We might have another like this:

byte fire_switch=0b100000;

Since these each equate to specific electrical signals that get "turned into bits" in the C-64's CIA chip, it's nice to be able to tell them to Java as bits. We could have used hex or octal, but it's a bit nicer to see them as individual bits.

Java Variable Value Assignment: Left Equals Right, Left Becomes Right

2011-06-24T17:16:00.000-07:00

One of those things that vexes beginning programmers is assigning values to a variable in Java. Part of what makes it so vexing is that the problem is practically invisible to an experienced programmer. Another part of it is that we use the equals sign (=) to do the assignment.

Take a look at these statements:

int i = 1;
j=7;
7+count=c;
b+14=a+9;

The first two are fine (assuming that 7 is a valid value for whatever type of variable j is), but the last two are wrong.

Remember All That Algebra We Taught You? Well, We Broke It.

After you've gone to all the trouble to learn how to deal with things like 7+count=c and b+14=a+9 in algebra class, now we take what you know and turn it on its ear in programming class. Sweet, eh?

The problem is that the = we use in programming has pretty much nothing to do with the = that you use in math. It's just close enough to be confusing. In Java, the equals sign is an assignment operator, not an indicator of equality between values as it is in math. There is a comparison operator for equality in Java, it's ==, and we'll talk about it shortly. First, let's talk assignment.

Assignment

In computers, we use the term assignment to describe sticking a value into the computer's memory so that we can get it back later. It's like using the memory in a programmable calculator. We put some number into our calculator's memory so that we can get it back later for another part of our calculation. It's pretty much the same thing with computers.

With Java, we can store all kinds of values, not just numbers. We can store sections of text, called strings in a String variable, for example. (Java prefers the term "member" over variable, in general. For what we're talking about now, the two terms are interchangeable.) We can also store more than one thing at a time, like all the information about a bicycle in a Bicycle object that keeps track of a bicycle's color, frame size, tire size, gear ratios, etc., all together in one object.

But we're here to just look at assignment today, not the wide variety of things we can assign as values.

To store a value on a calculator, you use some key sequence like M+ or STO 00 to store the value in the calculator's display to memory. With Java, we use the equals sign to store some value on the right into whatever is on the left side of the equals sign. We read from left to right like this:

count = a;
"count equals a"

This means we take the value of a and place it in count. But a better way to read that equals sign is to use the word "becomes" instead of "equals":

count = 9;
"count becomes nine"

This makes it more obvious that we're putting in a new value that changes the value of count. In this case, we're putting in a value of 9. The statement up above would be "count becomes a" or, better yet, "count becomes a's value." Because what we're doing in count= a; is taking the value in variable a and copying it into count. If we then print the value in count, it will be the same as whatever is in a at that time.

We can also compute a value to put into our variable.

count = a + 1;
"count becomes a plus one"

This makes the value in count be one more than the current value of a.

What we can't do is change sides around the equals sign. In algebra, c = a + 1 is the same as a + 1 = c. But in Java that doesn't work:

a + 1 = count
This is wrong in Java. Does not compute. Norman, Norman, help me Norman!

We would be trying to make a+1 become the value in count. The problem is, you can't have a storage location named "a+1". Java doesn't see this the way your algebra trained eyes do.

Comparisons

In normal math, when we use the equals sign we are making a comparison. We are stating that what's on one side of the equals sign is the same as what's on the other side. For most algebra problems, we assume that the statement is true and try to find values for the variables that result in that.

Another use of equals in some math problems is to state that two things are equal when they may or may not be, then determine whether that statement is true or not. You remember those problems, they looked something like this:

State whether each of the following is true or false.
1. 11 = 6 + 5 2. 14 = 3 x 7 3 65 - 14 = 17 x 3

In Java, the equals sign is already used for assigning values to variables. How do we do a comparison to see whether it's true or not?

The == Operator

In some languages, = does both jobs. But in Java, there's a second operator for doing equality comparisons, ==, "equals equals". When we want to see if two values are the same, we compare them using a statement something like this:

if (count == 100) then stop();

This compares count to the value 100, and executes the method stop() if the result of the comparison is true.

The Dangers of the = Operator

Something to look out for is using = by accident in such a situation. Like this:

if (count = 100) then stop();
Don't do this if you want to compare count to 100!

What this does is assign the value 100 to count. If the assignment is successful (which it almost certainly will be, if the program compiles), the program will then do stop() every time it hits this statement! Because the assignment was successful, so the result is considered to be true.

Summary

The equals sign makes the variable on the left equal the computed value from the right side of the equals sign:

name = "Mergatroyd";
"name becomes Mergatroyd"

It doesn't work the other way around (putting something from the left into the variable on the right.)

If you want to compare to values to see if they're equal, use "equals equals":
if (state == "done") then exit();
"if state equals equals done then exit" or
"if state is equal to done then exit"

Doing Math in Java part 2:Functions

2011-06-07T13:16:00.000-07:00

The basics of math in Java using operators was covered in Part 1: Operators. There I went over the standard operations built into the language itself, rather than in its APIs (libraries).

But that's hardly the end of useful math operations. Especially when doing graphics, where all those geometric and trigonometric functions come in so useful. Square root, cosine, absolute values, etc.

If you're wandering into the Java APIs unguided, the java.math package might catch your eye right away. Unfortunately, it's a false trail when what you're looking for is a simple general purpose math package (it's a nice special-purpose math package for particular sorts of calculation, however.)

What you really want is the java.lang.Math class, in the java.lang package.

This has most of the standard math functions you're used to. They're defined as static methods, so you don't need to create a Math object to use them. You just call them like this:

    float distance = Math.sqrt(dx*dx + dy*dy);
    float speed = Math.abs(velocity);

These call the square root function Math.sqrt() and absolute value function Math.abs(). There are a slew of others like degree to radian conversion, the standard trig functions, and so on.

Date Calculations

Calculations with dates are another standard sort of math that's not covered by standard operators. In the package java.util we've got the Calendar class. The Calendar class itself is an abstract class. This means that it's a class used to build other classes with, not to use directly. The GregorianCalendar class is a concrete implementation of Calendar that you can use directly. The Calendar object's add() method will add or subtract some amount of time--days, minutes, hours, etc.--to or from a given date (the date that the object is set to:

Create a GregorianCalendar Object

Set its date

Use its add() method to add or subtract the time difference.

Example:

GregorianCalendar myDate;
myDate = new GregorianCalendar(2011, 6, 7); //set the date to 07 June 2011.
myDate.add(Calendar.Date, 165); // add 165 days to that date.

before(), after() and compareTo will return whether one date occurs before or after another. Computing the number of days between two dates is a bit more complex, unfortunately, as are similar calculations. Basically, the procedure is to use getTime() to convert both dates to time values, get the difference, then divide that by the time units you want to see the difference in (e.g. divide by 24 hours periods to get the difference in days.)

Unfortunately, the Calendar class demonstrates one of the problems with much of Java. It's an overly generalized class that prevents simple solutions to many simple and obvious problems. The older Date class took a more direct approach, but it has been deprecated in favor of the Calendar based classes. Unfortunately, even obtaining a printable date value according to the system's current locale takes a fair bit of set up in Java. A better solution would have been a very general class like Calendar behind a more usable class for solving conventional problems, but Java's development got it backward. We got the simple class first, it's inflexibility for solving certain problems resulted in criticism, then came a general class, which is no good at doing simple and obvious things for most users. The extra layer that we should have to make Calendar more usable has not yet appeared in the standard API (and possibly never will.)

So it takes a lot of code to do what should only take a line or two, when working with dates.

Still, give the Calendar and GregorianCalendar class a look-over. Even though it takes some extra code and set-up to do some simple tasks, the solutions to these problems are well established and many examples are available. It's just not as simple as System.out.println(myDate);

I'll be adding articles dealing specifically with dates myself at a future date.

Doing Math in Java part 1: Operators

2011-05-27T14:31:00.000-07:00

One of the most valuable uses of a computer is...computing. That is, acting as a mathematical calculator. Java has a plethora of tools for doing computation.

Operators

The standard math functions that are built into the Java language are called operators. These are the sort of math functions you would expect to find on a simple calculator, plus some extras:

+ - * / % ++ --

There are other operators used for comparisons, these are the math operators. You can learn more about them in the Java Language Specification, specifically in Integer Operations, Floating-Point Operations, and more extensively through Chapter 15, Expressions.

+ and - do what you would expect, they add and subtract one value from another. * is the symbol used for multiplication, instead of the × used in math class. * is used because it's easier for the computer to recognize it as a math operator, × just looks like a letter 'x' to the computer. Similarly, / is used for division. The ÷ sign isn't on most keyboards, but / has been common on keyboards even before they were attached to computers.

The % sign doesn't do what you might, at first, expect. It doesn't calculate a percentage, as it does on most calculators. It returns the remainder of a division. For example, if you do 10/3 (ten divided by three), the result will be 3. But what if you want to get the remainder? That's what % does. 10%3 will return a value of 1. '%' is sometimes called "modulo". It's a bit of a misnomer, mathematically, but the use of the term is common and well understood, so it's not unusual to pronounce 10%3 as "ten modulo three". This is a very valuable function for keeping a value within a certain range, such as keeping an object located onscreen in graphics by having it "wrap" from one side of the screen to the other when it reaches an edge.

++ and -- are the "increment" and "decrement" operators. Increment means "go up by one unit", and decrement "go down by one unit". So if you've got a variable like:

int i = 5;

And you do i++, the value of i will become 6. Doing i-- will take away 1. ++ and -- can be placed either before or after the value they act on, for example:

number = i++;
count = --j;

There will be different effects on your program depending on whether they come before or after the value. You can find information on that in the Java Language Specification as well, in sections 15.14 and 15.15 which cover the two ways of using these operators. In general, it's best to stick to using them after your value until you understand the differences.

Assignment Operators

You can also do math as part of assigning a value. For example, let's say we want to add three to a value in our program. The obvious way to do this would be:

i = i + 3;

This takes the prior value of i, adds 3 to it, then puts the result back into variable i. With an assignment operator we can do the same thing more tersely:

i += 3;

We've combined the + with = to create an operator. This does the same thing as i = i + 3;. Your program doesn't care which way you type it. The same thing can be done with the other operators that take two values:

i *= 4; // Multiply i by four, store result back in i.
i /= 2; // Divide i in half.
i %= 3; // Put the remainder of i/3 in i.
i -= 7; //Subtract seven from i.

More Complex Math

This is what we can do with the basic math operators built into the language. To get more operations, like those found on a scientific or programmer's calculator, we use methods of some of the standard packages of Java. Which I'll cover in a future article.

Until then, have a look at java.lang.Math.

Your Own Java Classes

2011-05-20T13:49:00.000-07:00

To use Java effectively, you want to create and use your own classes. This is one of the great powers of object-oriented languages--the ability to construct programs out of independent building-blocks that cut large problems down into small, easily solvable ones. There's a lot more that can be said, and much of it is elsewhere. So I'll get right into a very simple, very basic example here.

We're going to create a very simple object class that will print a "Hello" message to the screen when called. This class will have two different methods that will do the same thing, though we'll vary the messages they print a bit so that we can see which one is doing the work.

Here's our class: (download HelloClass.Java)

public class HelloClass{

/**
 * sayHello() prints "Hello!" to the Java console output.
 */
 public void sayHello(){
  System.out.println("Hello!\n");
 }

/**
 * doHello() prints "Hello, hello!" to the Java console output.
 * It's static, so you don't need to instatiate a HelloClass 
 * object to use it.
 */
 public static void doHello(){
  System.out.println("Hello, hello!\n");
 }

} // End of HelloClass

The two methods we have to print messages are sayHello() and doHello(). To use sayHello(), we need to have a HelloClass object created, then call that object's sayHello() method.

doHello(), however, is a static method. This means is belongs to the class, not to any object of the class. So we can use it without any HelloClass objects being created first.

Here's a class that uses these methods as described: (download UseHello.java)

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

  // We can use doHello() without a HelloClass object:
  HelloClass.doHello(); // call the HelloClass's doHello() method.

  // But we need to create a HelloClass object to use sayHello():
  HelloClass hello=new HelloClass();
  hello.sayHello(); // call hello's sayHello() method.

 }
} // End of UseHello.

If we try to call sayHello() without first creating a HelloClass object, like this:
HelloClass.sayHello();

then we'll get the dreaded "calling a non-static method from a static context" error message. That's letting you know that you need to instantiate (or create) a HelloClass object first, then tell that object to call its method.

Static methods are useful for things like general arithmetic and calculation or other methods that might be used in a way where state information is unimportant. But beware, it's easy to create static methods when what's really wanted is an object that does what you want.

Files available for download through: http://saundby.com/beginwithjava/.

A Java CSV File Reader

2011-05-13T11:35:00.000-07:00

One of the most common types of data file is a CSV (Comma Separated Value) file. They can be exported by many popular applications, notable spreadsheet programs like Excel and Numbers. They are easy to read into your Java programs once you know how.

Reading the file is as simple as reading a text file. The file has to be opened, a BufferedReader object is created to read the data in a line at a time.

Once a line of data has been read, we make sure that it's not null, or empty. If it is, we've hit the end of the file and there's no more data to read. If it isn't, we then use the split() method that's a member of Java's String object. This will split a string into an array of Strings using a delimiter that we give it.

The delimiter for a CSV file is a comma, of course. Once we've split() the string, we have all the element in an Array from which our Java programs can use the data. For this example, I just use a for loop to print out the data, but I could just as well sort on the values of one of the cells, or whatever I need to do with it in my program.

The Steps

Open the file with a BufferedReader object to read it a line at a time.

Check to see if we've got actual data to make sure we haven't finished the file.

Split the line we read into an Array of String using String.split()

Use our data.

The Program

// CSVRead.java
//Reads a Comma Separated Value file and prints its contents.

import java.io.*;
import java.util.Arrays;

public class CSVRead{

 public static void main(String[] arg) throws Exception {

  BufferedReader CSVFile = 
        new BufferedReader(new FileReader("Example.csv"));

  String dataRow = CSVFile.readLine(); // Read first line.
  // The while checks to see if the data is null. If 
  // it is, we've hit the end of the file. If not, 
  // process the data.

  while (dataRow != null){
   String[] dataArray = dataRow.split(",");
   for (String item:dataArray) { 
      System.out.print(item + "\t"); 
   }
   System.out.println(); // Print the data line.
   dataRow = CSVFile.readLine(); // Read next line of data.
  }
  // Close the file once all data has been read.
  CSVFile.close();

  // End the printout with a blank line.
  System.out.println();

 } //main()
} // CSVRead

Downloads

This program, and an example CSV file to use it with (a section of a spreadsheed I use to keep track of my integrated circuits) are available at my code archive.

Writing to CSV Files with Java

Writing to a CSV file is as simple as writing a text file. In this case, we write a comma between each field, and a newline at the end of each record.

Give it a try, starting with TextSave.java, modify it appropriately, then see what your favorite spreadsheet program thinks of the results.

Java File Save and File Load: Text

2011-05-06T12:58:00.000-07:00

We've looked at saving and loading objects to files. If we need to exchange information for use by a different program than our own it will seldom be convenient to save objects. Text files are commonly used to do this.

Text files are even simpler to deal with than Object files, thanks to classes in the java.io package. FileWriter gives us everything we need to write from our program to a text file. All we need to do is feed it String data.

FileReader lets us access a file, but using a BufferedReader makes it a lot easier to handle reading data from a file as lines of text.

As with object files, the basic steps are:
1. Open a file.
2. Write or read data.
3. Close the file.

Here are example programs, the first writes a simple text file. After you run it, you can take a look at the file it creates (in the same directory) using your favorite text viewer. You'll see normal text written line by line.

Then run the second program. It reads in the information line by line. It takes advantage of the fact that we know the format of the data file to read what's in it back into Java objects. You can do the same thing with any file that you either know the format of, or can detect the format of. For example, reading data from CSV files saved by spreadsheets (I'll provide a specific example of this in a future article.)

As always, you can download the program files from the Begin With Java Code Archive.

TextSave.java


import java.io.*;

public class TextSave{

  public static void main(String[] arg) throws Exception {
    // Create some data to write.
    int x=1, y=2, z=3;
    String name = "Galormadron", race = "elf";
    boolean hyperactive = true;

    // Set up the FileWriter with our file name.
    FileWriter saveFile = new FileWriter("TextSave.txt");

    // Write the data to the file.
    saveFile.write("\n");
    saveFile.write(x + "\n");
    saveFile.write(y + "\n");
    saveFile.write(z + "\n");
    saveFile.write(name + "\n");
    saveFile.write(race + "\n");
    saveFile.write(Boolean.toString(hyperactive) + "\n");
    saveFile.write("\n");

    // All done, close the FileWriter.
    saveFile.close();

  } //main()
} // TextSave

TextRead.java


import java.io.*;

public class TextRead{

  public static void main(String[] arg) throws Exception {
    int x, y, z;
    String name = "", race = "";
    boolean hyperactive;

    BufferedReader saveFile=
        new BufferedReader(new FileReader("TextSave.txt"));

    // Throw away the blank line at the top.
    saveFile.readLine(); 
    // Get the integer value from the String.
    x = Integer.parseInt(saveFile.readLine()); 
    y = Integer.parseInt(saveFile.readLine());
    z = Integer.parseInt(saveFile.readLine());
    name = saveFile.readLine();
    race = saveFile.readLine();
    hyperactive = Boolean.parseBoolean(saveFile.readLine());
    // Not needed, but read blank line at the bottom.
    saveFile.readLine(); 

    saveFile.close();

    // Print out the values.
    System.out.println("x=" + x + " y=" + y + " z=" + z + "\n");
    System.out.println("name: " + name + " race: " + race + "\n");
    if (hyperactive) 
      System.out.println("Oh, yeah. He's hyperactive all right.");
    else System.out.println("What a mellow dude.");
    System.out.println();

  } //main()
} // TextRead

Java File Save and File Load: Objects

2011-04-14T12:51:00.000-07:00

Jump to Reading Data from Files with Java>>

Saving Data to Files with Java

Saving objects to a file in Java has a few steps to it, but it's pretty easy. We open a file to write to, create a "stream" for putting objects into the file, write the objects to that stream to put them in the file, then close the stream and file when we're done.

To reiterate:

1. Open a file.

2. Open an object stream to the file.

3. Write the objects to that stream.

4. Close the stream and file.

1. Opening the File
To open a file for writing, we use a FileOutputStream object. When we construct the new FileOutputStream, we give it a file name to open. If the file name exists, it opens the existing file. Otherwise, it creates a new file. To keep things simple, we're not going to check for a file existing here, or anything like that.

Example:
FileOutputStream saveFile = new FileOutputStream("saveFile.sav");

2. Open an Object Stream
To write objects to the FileOutputStream, we create an ObjectOutputStream. We give it the FileOutputStream object we've set up when we construct the new ObjectOutputStream object.

Example:
ObjectOutputStream save = ObjectOutputStream(saveFile);

3. Write Objects
When we write objects to the ObjectOutputStream, they are sent out through it to the FileOutputStream and into the file.

Example:
save.writeObject(objectToSave);

4. Close Up
When we close the ObjectOutputStream, it'll also close our FileOutputStream for us, so this is just one step.

Example:
save.close();

Example Program:


import java.io.*;
import java.util.ArrayList;

public class SaveObjects{

  public static void main(String[] arg){

    // Create some data objects for us to save.
    boolean powerSwitch=true;
    int x=9, y=150, z= 675;
    String name="Galormadron", setting="on", plant="rutabaga";
    ArrayList stuff = new ArrayList();
    stuff.add("One");
    stuff.add("Two");
    stuff.add("Three");
    stuff.add("Four");
    stuff.add("Five");

    try{  // Catch errors in I/O if necessary.
      // Open a file to write to, named SavedObjects.sav.
      FileOutputStream saveFile=new FileOutputStream("SaveObj.sav");

      // Create an ObjectOutputStream to put objects into save file.
      ObjectOutputStream save = new ObjectOutputStream(saveFile);

      // Now we do the save.
      save.writeObject(powerSwitch);
      save.writeObject(x);
      save.writeObject(y);
      save.writeObject(z);
      save.writeObject(name);
      save.writeObject(setting);
      save.writeObject(plant);
      save.writeObject(stuff);

      // Close the file.
      save.close(); // This also closes saveFile.
    }
    catch(Exception exc){
      exc.printStackTrace(); // If there was an error, print the info.
    }
  }
}

Reading Data Files with Java

Now we need to know how to get data back from a file with Java. Since the data objects were stored using an ObjectOutputStream, they are saved in a way that makes them easy to read back using an ObjectInputStream.

There's one problem with ObjectImputStream, however. It doesn't return objects of the specific classes that they were originally. It just returns generic Objects. To get things back into their original class, we have to cast them into that type. Usually that means we need to know what their class was when they were written. It's possible to save class information along with the data, but in this case we just assume that we're reading back a file we have written, so we already know what class everything should be. I'll go into the details of reading other files in another article.

The steps are practically the same as for writing objects to a file:

1. Open a file.

2. Open an object stream from the file.

3. Read the objects to that stream.

4. Close the stream and file.

1. Opening the File
To open a file for reading, we use a FileInputStream object. When we construct the new FileIntputStream, we give it a file name to open. If the file name exists, it opens the existing file. Otherwise, we get an error which will print out a nastygram when we get to our catch statement. To keep things simple, we're not going to check for a file existing here.

Example:
FileInputStream saveFile = new FileInputStream("saveFile.sav");

2. Open an Object Stream
To read objects to the FileInputStream, we create an ObjectInputStream. We give it the FileInputStream object we've set up when we construct the new ObjectInputStream.

Example:
ObjectInputStream restore = ObjectInputStream(saveFile);

3. Read Objects
When we read objects from the ObjectInputStream, it gets then from the file.

Example:
Object obj = restore.readObject();

3 and a half. Cast Back to Class
Step 3. only restores a generic Object. If we know the original class, we should cast the Object back to its original class when we read it. If we had stored a String object, we'd read it something like this:
String name = (String) restore.readObject();

4. Close Up
When we close the ObjectInputStream, it'll also close our FileInputStream for us, so this is just one step.

Example:
restore.close();

Here's an example program to read back information saved by the first example program:


import java.io.*;
import java.util.ArrayList;

public class RestoreObjects{

 public static void main(String[] arg){

  // Create the data objects for us to restore.
  boolean powerSwitch=false;
  int x=0, y=0, z=0;
  String name="", setting="", plant="";
  ArrayList stuff = new ArrayList();
  
  // Wrap all in a try/catch block to trap I/O errors.
  try{
   // Open file to read from, named SavedObjects.sav.
   FileInputStream saveFile = new FileInputStream("SaveObj.sav");

   // Create an ObjectInputStream to get objects from save file.
   ObjectInputStream save = new ObjectInputStream(saveFile);

   // Now we do the restore.
   // readObject() returns a generic Object, we cast those back
   // into their original class type.
   // For primitive types, use the corresponding reference class.
   powerSwitch = (Boolean) save.readObject();
   x = (Integer) save.readObject();
   y = (Integer) save.readObject();
   z = (Integer) save.readObject();
   name = (String) save.readObject();
   setting = (String) save.readObject();
   plant = (String) save.readObject();
   stuff = (ArrayList) save.readObject();

   // Close the file.
   save.close(); // This also closes saveFile.
  }
  catch(Exception exc){
   exc.printStackTrace(); // If there was an error, print the info.
  }

  // Print the values, to see that they've been recovered.
  System.out.println("\nRestored Object Values:\n");
  System.out.println("\tpowerSwitch: " + powerSwitch);
  System.out.println("\tx=" + x + " y=" + y + " z=" + z);
  System.out.println("\tname: " + name);
  System.out.println("\tsetting: " + setting);
  System.out.println("\tplant: " + plant);
  System.out.println("\tContents of stuff: ");
  System.out.println("\t\t" + stuff);
  System.out.println();

  // All done.
 }
}

<<Return to How to Save to a File with Java

The example programs can be downloaded at:
Begin With Java Code Downloads

Cleaning Out the Sun References

2011-03-20T16:22:00.000-07:00

Today I'm going to start cleaning out the references in old posts to Sun Microsystems. Sun is gone now, except for a page that tells you it's gone and points toward Oracle. Oracle bought Sun, and now owns Java.

Many of my old articles point toward the previous Sun website. I'll be changing those to point to current locations for the same resources, mostly to be found on java.net.

If you come across something I appear to have missed, feel free to email me with the article title so that I can fix it. Thanks!

One More Thing

It's worth noting that since some of these articles were written, the official online resources have improved. I still think there are some major gotchas for new learners in Java, but things are definitely better than when I started this blog.

Java's File Names and Class Names

2011-01-25T11:52:00.000-08:00

Java is picky about the file names you use.

Each source file can contain one public class. The source file's name has to be the name of that class. By convention, the source file uses a .java filename extension (a tail end of a file name that marks the file as being of a particular type of file.)

So, for a class declared as such:


public class HelloWorld{
...

The file it is stored in should be named HelloWorld.java.

The capitalization should be the same in both cases. Some operating systems don't notice whether file names are capitalized or not. It doesn't matter, you should be in the habit of using the correct capitalization in case you work on a system that does care about capitalization.

When you compile your file with javac, you pass the full file name to javac:

javac HelloWorld.java

Let's say we save the file under a different name. We write the following program:

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

Then we save it as HelloWorld.java, and try to compile it:


>javac HelloWorld.java
FileName.java:1: class HelloThere is public, should be declared 
in a file named HelloThere.java
public class HelloThere{
       ^
1 error

Java lets us know that it won't compile until we rename the file appropriately (according to its rules.)

So let's rename the file. Let's call it HelloThere.javasource. Seems a bit more explicit than just .java, right? Let's run the compiler:


>javac HelloThere.javasource 
error: Class names, 'HelloThere.javasource', are only accepted 
if annotation processing is explicitly requested
1 error

Java's still not happy with us. Annotation processing? That's when we include extra information in the program about the program itself. We're not bothering with that just now. So we should just name the file HelloThere.java, and not get fancy with our file names.

But, under the right circumstances, javac does allow file name extensions other than .java. That's why we always type in the full file name, including .java, when we use javac. We say 'javac HelloThere.java', not just 'javac HelloThere'. Javac can't assume that we mean a .java file, though that's what it will usually be.

The Class File

Once we make javac happy with a proper file name, and a program with no errors, javac produces a new file. This file will have the original file name, but with .java replaced with .class. This is your bytecode file, the file that the Java Virtual Machine can run.

When we run the program with Java, we're running the .class file. In the case of HelloThere, we're running the HelloThere.class file. But we don't type in the full file name. Why?

Unlike javac, java requires a .class file. That's all it will work with. There's no opportunity to have a different extension to the file name. So it assumes the .class part of the file name. But that's not the whole story.

If you add .class yourself, here's what you'll get:


>java HelloThere.class
Exception in thread "main" java.lang.NoClassDefFoundError: 
 HelloThere/class
Caused by: java.lang.ClassNotFoundException: HelloThere.class
 at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

Pretty ugly. What we're actually doing when we type "java HelloThere" is telling Java to run the class HelloThere. Java assumes that it will find this in a file called "HelloThere.class", so that's what it's looking for first.

We're not telling Java to run the file HelloThere.class, we're telling it to run the class HelloThere, which it expects to find in the file HelloThere.class.

But what if we ask for another class that doesn't have its own .class file?

Just for fun, let's change HelloThere.java like this, and see what happens:

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

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

After we edit it, we compile with 'javac HelloThere.java' and hold our breath.

Hurray! No errors!

Now we have a second class, HelloZoik, in the HelloThere.class file. Can Java find it?

Let's try:

 java HelloZoik
Zoiks!

It worked! Java found our class inside HelloThere.class.

This shows it's not the file name that we're calling with the 'java' command, it's the class name.

If Java doesn't find the class inside a file with the same name as the class followed by .class, it'll look in the other .class files available.

Should I Still Learn Java?

2011-01-04T23:13:00.000-08:00

With all the controversy surrounding Java thanks to the purchase of Sun by Oracle, the lawsuits flying back and forth over the Java Community Process, the Apache Foundation, Android, and all the rest, does it still make sense to learn Java?

After all, the demise and abandonment of Java is being predicted practically every day.

I say Yes, now is the time to learn Java. No matter what your programming skill or background, Java is a valuable language to learn, it will be used and useful for a long time to come.

Never a Dull Moment

The Java language has been a-swirl in controversy since its public announcement. It has not become "the" language in many of the areas it originally claimed to be "the" language to use, but yet it has become popular in many other areas. In fact, Java is neck and neck with the language C for being the most popular computer language:

TIOBE Software Community Index (of most popular programming languages.)

langpop.com Programming Language Popularity Rankings.

Devtopics.com Most Popular Programming Languages.

Why Popularity Matters

Why does popularity matter? Because it entrenches a programming language, not just for now, but for many years to come. In fact, every language that has ever become deeply entrenched is still with us, so there's no way of knowing just how long popularity will keep a programming language alive.

When I was first learning to program, the big languages were assembly (the "real" programmer's language of the time), BASIC, FORTRAN, and COBOL. Every single one of those is still a viable language today. Though if you'd asked me then, I would never have thought COBOL would still be with us today. I would never have believed how popular it is, either.

But COBOL was re-invented in the late 80's. And there were a lot of big-money installations running on it. ADA failed to displace it. It's still here, and it's still a valuable part of a programmer's resume for many jobs.

FORTRAN is a language I expected to re-invent itself. It had already done so by the time I learned it (I first programmed in the original FORTRAN, but FORTRAN IV was already in common use.) But with the promulgation of Pascal, Modula-2, and C in the 80's I figured FORTRAN would be pushed into the recesses of obscurity. I was wrong.

Modula-2 was mishandled by the company that owned the rights to it, so it never took off as well as it might have. Pascal took off even though it was never intended to be anything but a classroom language. C took off since it didn't have Modula-2's licensing disadvantages and it had enough of its advantages to become the "next generation language" of its day.

Modula-2 is still with us, but it's insignificant among languages today. Because it never got popular. The others I mentioned got popular, and they're still popular today. Yeah, even Pascal. You could learn Pascal today and do a lot with it (though I don't recommend it unless you want the academic challenge of broadening yourself as a programmer.) I still write software in Pascal, though mostly for my own use, and only for older computer systems.

The key to a programming language's longevity is popularity. Once a language becomes sufficiently popular, for all practical purposes it will never die.

Java is that popular.

The Many Javas

Java has become deeply ingrained into the modern computer infrastructure. Not only does the Java Virtual Machine support a lot more languages than Java itself, but Java has spawned other languages so close to itself that if you know Java you can pick up the other languages without significant effort. C# is the most popular of these spin off languages.

Plus, there are different versions of Java. The Mobile Edition, used on cell phones, smart phones, and PDAs, is a major programming language for these platforms. Each of these platforms has its individual programming suite, and associated language. Their second language, the Esperanto of the portable world, is Java. Programmers that want their software to move easily between platforms often choose to write their code in Java.

The use of Java on servers is rife as well. Java Enterprise Edition became the most popular use of the Java language when Java was still struggling to be used as an applications programming language over a decade ago. Some say that Java on the server saved the Java language. Certainly this is what makes Java a good language to learn for professional reasons.

The Most Important Reason

The most important reason to ignore all the hullabaloo about Java's impending demise and not worry about learning it is that:

it is a good language that's fairly easy to learn,

expressive enough to do a lot of different things effectively,

easy to develop sophisticated modern programs in

without too much work for an individual or small group of developers,

gives access to all the important parts of the machine (graphics, sound, filesystem, peripherals)

and what you learn travels well to other languages when you go on to learn them.

It's not going to go away any time soon. There's too much momentum. There's no need to worry. Ever since the launch of Java I've heard that it's going to be gone or unusable tomorrow. History shows that just doesn't happen to popular programming languages.

If you learn Java now, you may still be using it 20 years from now. Or 30.

When I sat down to a card punch to write my first program 38 years ago as I write this, the computer lab know-it-all came to look over my shoulder.

"FORTRAN!" he said. "Why are you wasting your time with that language? It's a dead, old language. Did you know it's the oldest computer language? If you really want to be a programmer, you should start right out in BAL*! That's what real programmers use, and you're going to be behind if you waste your time on anything else."

FORTRAN doesn't make the "top 10" in programming languages much any more, but it gave me a good start. It's still among the most popular languages, around #20, or just out of the top 10 if you only count general purpose programming languages (that is, not counting scripting languages, query languages, application-specific languages, and so on.)

And learning FORTRAN never kept me from learning structured languages, AI languages, Object Oriented languages, and so on. Even though my first program included the "dreaded" GO TO statement.

There's never been a better time to learn to program. And there's never been a better time to learn Java (the language is in the best shape it's ever been!)

*Basic Assembly Language, a version of assembly language for IBM computers.

Interactive Keyboard Input In Java: KeyListeners

2010-09-02T09:49:00.000-07:00

In a console application, you can get keyboard input using the Scanner class, as described in Keyboard Input for Console Apps. In an graphical app, though, you can use one of the classes built to accept text input (e.g. TextArea or JTextField) or add code to your application to respond directly to the keyboard.

Playing with Today's Program

There are two basic ways of doing this. One is to set up Key Bindings, which maps keystrokes to actions in your application similar to accelerator keys or menu keyboard equivalents. The other is to use a Key Listener, similar to the Mouse Listener, which I detailed in Simple Mouse Interaction.

In this example we're going to use Key Listeners. There is less overhead to setting up a KeyListener when you just need to use a few keys. Key Bindings require more overhead to set up, but when you want to bind actions to a lot of different keystrokes, and manage the actions bound to particular keystrokes at a higher level, Key Bindings are better to use than a simple KeyListener.

As its name implies, a KeyListener is an Event Listener. If you're not sure what that is, read my article on Listeners or follow the prior link to Oracle/Sun's description.

Here's a program that demonstrates simple keyboard interaction. It's based on the MousePanel program I presented in Simple Mouse Interaction. It acts as a sort of "Etch-a-Sketch". You can download the KeyPanel program source from my Java code site.

// Import the basic necessary classes.
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class KeyPanel extends JPanel implements KeyListener{

    public KeyPanel(){
        super();
        pointX=0;
        pointY=0;
        oldX=0;
        oldY=0;
        addKeyListener(this);
    }

    int pointX, pointY, oldX, oldY;
    boolean erase;

    public void paintComponent(Graphics g){
    // Erase the board if it's been requested.
        if (erase) {
           g.clearRect(0, 0 , getBounds().width, getBounds().height);
           erase = false; // We're done, turn off this flag now.
        }

    // Draw gray where the pointer was..
        g.setColor(Color.GRAY); 
        g.fillRect(oldX-2, oldY-2, 4, 4);
    // Draw "Cursor" at current location in black.
        g.setColor(Color.BLACK);
        g.fillRect(pointX-2,pointY-2, 4, 4);
    }

    public void keyPressed(KeyEvent key){

    // Copy the last clicked location into the 'old' variables.
        oldX=pointX;
        oldY=pointY;
    // Move the current point depending on which key was pressed.
    if (key.getKeyCode() == key.VK_DOWN){
        pointY=pointY+5;
        if (pointY > getBounds().height){
            pointY=getBounds().height;
        }
    }
    if (key.getKeyCode() == key.VK_UP){
        pointY=pointY-5;
        if (pointY < 0){pointY=0;}
    }
    if (key.getKeyCode() == key.VK_LEFT){
        pointX=pointX-5;
        if (pointX < 0){pointX=0;}
    }
    if (key.getKeyCode() == key.VK_RIGHT){
        pointX=pointX+5;
        if (pointX > getBounds().width){
            pointX=getBounds().width;
        }
    }

    // Set a flag to erase the screen if Space is pressed.
    if (key.getKeyCode() == key.VK_SPACE){
        erase = true;
    }

    // Tell the panel that we need to redraw things.
        repaint();
    }

/* The following methods have to be here to comply
   with the MouseListener interface, but we don't
   use them, so their code blocks are empty. */
    public void keyTyped(KeyEvent key){ }   
    public void keyReleased(KeyEvent key){ }

    public static void main(String arg[]){
        JFrame frame = new JFrame("Use Arrows to Draw, Space to Erase.");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setSize(640,480);

        KeyPanel panel = new KeyPanel();
        frame.setContentPane(panel);
        frame.setVisible(true);

        // We *must* do this to see KeyEvents.
        panel.setFocusable(true);

        // Initialize the drawing pointer.
        panel.oldX=panel.getBounds().width/2;
        panel.oldY=panel.getBounds().height/2;
        panel.pointX=panel.oldX;
        panel.pointY=panel.oldY;

    }
}

Using this technique with the Simple Video Game Kernel would be similar. The VGKernel would extend KeyListener, register itself, and implement the KeyListener methods. But in those methods, rather than performing the operations that result from the keypress, as in this program, you would want to simply set a flag to show that the key has been pressed. Then, in your core game logic you would test to see whether the key has been pressed, and perform the appropriate actions.

That way the actions are performed at the appropriate time in your game, and not just whenever the key happens to get pressed. Reacting to a key when it is pressed is appropriate for a turn-based game, but not for a real-time game. In a real-time game the action happens according to the timing of the TimerTask that drives the game, which is why we just note that a key has been pressed, and wait until the TimerTask occurs to actually conduct the action related to that key. This would be similar to what we do with the space key here, which sets a flag to tell paintComponent() to erase the screen.

Give this program a try, see if you can extend it to allow the user to select colors to draw with or change the size of the drawing pen.

Calling System Commands in Java

2010-08-26T12:12:00.000-07:00

Let's suppose you want to run another program on your system from within Java. Personally, I first decided I wanted to do this for the sake of a prank. You may have more businesslike purposes in mind, yourself.

It's not too hard to do this since Java 1.5, which added the Process and ProcessBuilder classes.

Here's an example program that starts up Firefox at a particular website:

public class OpenSite{
  public static void main(String arg[]){
    try { Process p = new ProcessBuilder("firefox", 
            "http://beginwithjava.blogspot.com/").start(); }
   catch(java.io.IOException io){ }
  }
}

I've compressed the various parts of the action down to one line here:

Process p = new ProcessBuilder("firefox", "http://beginwithjava.blogspot.com/").start();

I'm creating an "anonymous" ProcessBuilder object, calling its start() method, which returns a Process, which I name simply "p".

The whole thing is wrapped up in a try...catch structure because javac wants to see us deal with any I/O errors that result. In this program, I just ignore them.

So you'll want to make sure that you either catch those errors and deal with them, or that they will be unimportant enough that they don't matter.

Also note that the Java program's process will last as long as the external program you call. So if you don't shut down this instance of the firefox process, you'll have Java still running.

If you want to see something fun you can do with this on Mac, check out my article on my other blog about adding speech to the Simple Video Game Kernel.

Using Game Controllers with Java

2010-08-24T18:23:00.000-07:00

In the past, I've covered using mice as input devices, and covered the general input mechanism of Listeners. I've also discussed keyboard input for console applications, and I'll soon be covering Key Bindings as a way of using the keyboard in GUI applications.

But there's no facility in Java itself that deals with game pads easily. To date, it's been necessary to create your own ActionListeners from scratch. But not any more. Thanks to the JInput project, there's an easier way to hook up game controllers to your software.

JInput attempts to do discovery on your game controller, to figure out what its setting are, what buttons and controls it has, what the center positions are of analog sticks, and so on. All that messy stuff that makes rolling your own so darn painful. It's not 100% universal, but for most controllers and most games, it will do the job admirably. If you want better for a specific controller of your own, you can extend the classes to handle your stick (and maybe feed that information back to the JInput team so that they can decide whether to include it in future releases.

It's multi-platform, Windows, Mac OS X, and Linux. So it doesn't have the limitations of a lot of the other gamepad code implementations that use native code, thus limiting themselves to one platform (usually Windows.)

If you want to see an implementation using JInput, check out Greenfoot with Gamepads. It's a good, clear example of using JInput in a general fashion.

More Collision Detection: Bouncing the Right Way

2010-08-22T19:12:00.000-07:00

A common result of a collision between two objects in a video game is a bounce. To do this right, we have to know which direction to make things bounce. Here's one way to do that easily in Java. I've got a ball that's going to bounce in one of eight directions depending on how it hits a brick.

I've marked the changes to the ball's velocity that will occur as a result of each possible type of collision. The three arrows on the left side all show that the xVel (x velocity) is a negative value, the three arrows on the bottom all show that yVel (y velocity) should become a positive value.

In the cases of the corners, both the x and y velocities are set. The bounces off the middles of the sides all cause one velocity to be set, but the other is left alone. For example, a bounce off the right side of the brick sets the xVel to a positive value, but the yVel is unchanged. So if yVel was a positive value before (meaning the ball is travelling down on screen) then it will keep travelling down. If it was negative--moving up--then it will keep moving up. Only the x direction of movement will change. It will start moving from left to right instead of right to left.

It's really easy to detect a collision, but now we need to know the relationship between the two colliding objects so that we can make the ball bounce in the correct direction. As we learned in Stopping Jonathan Livingston Seagull, the effect of how much we move an object before we check a collision can cause problems if we don't understand the limits of how we detect them.

In this program, our ball's movement is presently set at one quarter of its width. We could go as high as one half its width and still have our collision detection routines work properly here. Fortunately, we want to keep the distance the ball moves each turn short to make the movement look smoother.

When we hit the brick, we want to see where it hits the ball. This will tell the ball which way to bounce, just like a real ball. In the drawing above, we have a red brick on a cyan (blue-green) playfield. The ball is dark blue. Where the ball is intersecting, or overlapping, the brick is shown in yellow. Now we just need to know which side of the ball is getting "pushed in" this way. Then we bounce the opposite way.

Here's the program, the key code we're talking about is highlighted:

/* A simple video game style kernel, revision 4.
   by Mark Graybill, August 2010
   Has a ball bouncing off a brick.
   Because the ball moves at a fixed speed,
   slow enough we won't miss a collision,
   we can use simple colliision detection.

   Uses the Brick class from the article
   "Multiple Constructor Methods"
*/

import java.util.*;
import java.awt.*;
import javax.swing.*;
import java.lang.Math;

public class VidBrick extends JPanel{

public Rectangle screen, bounds; // The screen area and boundary.
public JFrame frame; // A JFrame to put the graphics into.
public VGTimerTask vgTask; // The TimerTask that runs the game.
public VGBall ball; // The game ball, a subclass of Rectangle.
private Brick brick; // A brick for the ball to interact with.

/* This sets up the screen area, and creates instances of
 the JFrame, VGBall, VGTimerTask, etc that we'll need. */
  public VidBrick(){
    super();
    screen = new Rectangle(0, 0, 600, 400);
    bounds = new Rectangle(0, 0, 600, 400); // Give some temporary values.
    ball = new VGBall();
    frame = new JFrame("VidBrick");
    vgTask = new VGTimerTask();
    brick = new Brick();
}

  class VGTimerTask extends TimerTask{
    public void run(){
      ball.move();
      frame.repaint();
    }
  }

  class VGBall extends Rectangle{
    int xVel, yVel; // The ball's velocity.
    Color ballColor; // The color of the ball.

/* Create a VGBall with default location of upper left
  corner, size of 20x20 pixels, moving at one quarter
  its height and width per turn--plus it's blue. */
    public VGBall(){
      super(0, 0, 20, 20);
      xVel = width/4;
      yVel = height/4;
      ballColor=new Color(0, 0, 128);
    }

/* Move the Ball. */
    public void move(){
      // Move the ball according to the game rules.
      x+=xVel; // Move horizontally.
      y+=yVel; // Move vertically.

      // Detect edges and bounce if necessary.
      if (x > (bounds.width - width)){
        xVel = -xVel; // reverse movement.
        x = bounds.width -  width; // Set location to screen edge.
      }
      if (y > (bounds.height - height)){
        yVel = -yVel; // reverse movement.
        y = bounds.height - height;
      }
      if (x <= 0) { xVel = -xVel; x = 0; }
      if (y <= 0) { yVel = -yVel; y = 0; }

     // Detect Brick and bounce if necessary.
      if (intersects(brick)) {
        // Get the intersection rectangle to find out which way to bounce.
        Rectangle iRect = intersection(brick);
        // If we hit on the left side, go left (negative x velocity).
        if ((x+(width/2))<(iRect.x+(iRect.width/2))){xVel=(0-Math.abs(xVel));}
        // If we hit on the right side, go right (positive x velocity).
        if ((x+(width/2))>(iRect.x+(iRect.width/2))){xVel=Math.abs(xVel);}
        // If we hit on the top, go up.
        if ((y+(height/2))<(iRect.y+(iRect.height/2))){yVel=(0-Math.abs(yVel));}
        // If we hit on the bottom, go down.
        if ((y+(height/2))>(iRect.y+(iRect.height/2))){yVel=Math.abs(yVel);}
      } // if intersects
    }

/* Draw the ball into the provided graphics context. Preserves
   the context's drawing color setting. */

    public void draw(Graphics g){
    // the ball draws itself in the graphics context given.
      Color gcColor = g.getColor(); // Preserve the present color.
      g.setColor(ballColor); // Use the ball's color for the ball.
      g.fillRect(x, y, width, height); // Draw the ball.
      g.setColor(gcColor); // Restore prior color.
    } // end draw()
  } // end of class VGBall

  public void paintComponent(Graphics g){
    // Get the drawing area bounds for game logic.
    bounds = g.getClipBounds();
    // Clear the drawing area.
    g.clearRect(screen.x, screen.y, screen.width, screen.height);
    // Draw the brick.
    g.setColor(brick.getColor());
    g.fillRect(brick.x, brick.y, brick.width, brick.height);
    // Draw the ball.
    ball.draw(g);
  }

/* Main program loop. */
  public static void main(String arg[]){

    java.util.Timer vgTimer = new java.util.Timer();  // Create a Timer object
    VidBrick panel = new VidBrick(); 
    
    panel.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    panel.frame.setSize(panel.screen.width, panel.screen.height);

    panel.frame.setContentPane(panel); 
    panel.frame.setVisible(true);

    // Set up the brick.
    panel.brick.x = panel.screen.width/3;
    panel.brick.y = panel.screen.height/3;
    panel.brick.width = panel.screen.width/3;
    panel.brick.height = panel.screen.height/3;

    // Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 0, 33);
  }
}

The way we figure out which way to bounce is to find the center of the ball and the center of the intersection rectangle (the yellow box in the picture, where the ball and the brick overlap.) Then if the center of the intersection (shown as an orange dot on the pic) is to the right of the center of the ball (a white dot) we bounce left. If it's to the left, we bounce right, if it's above we bounce down, below we bounce up.

This way we don't have to worry about the size or shape of the brick itself. All we care about is the bit that strikes the ball. Then the ball bounces the correct way.

If we had wanted to get really fancy, we could have made the ball bounce at different angles depending on the angle between the center of the ball and the center of the intersection rectangle. If you're familiar with trigonometry, take a look at the Math class in Java and see if you can implement this.

Web Browsing on the Atari 2600???

2010-08-20T19:27:00.000-07:00

A recent discussion on an Astronomy forum took a turn for the earthly with the announcement of a new web site at StellarVue Telescopes. People were checking it out, reporting on minor fixes they felt were necessary and trying it with different systems and OSes. Then came the first report of a total crash and burn. From a Commodore 64 user. Next we had reports of failures on Heathkit and Vic-20 systems, too.

"Aha," I thought," a perfect opportunity to try out my Web Surfer cartridge on my Atari 2600!"

Here are the results:

My Atari 2600 with the Web Surfer Cartridge,
Displaying the StellarVue Web Site.

Check out my Atari web page for more pictures and info on this amazing VCS cart!

Note to those following my Java Programming Stuff: I was supposed to post this over at my other blog, An Infinite Number of Cats on Keyboards, but I punched the wrong button on my Blogger Dashboard, and it ended up here instead. Sorry about that. Now back to our regularly scheduled Java program...

Stopping Jonathan Livingston Seagull with Java

2010-08-18T19:15:00.000-07:00

In Simple Collision Detection we used the intersects() method of two Rectangle subclasses to see if one object struck another on our playfield. It works, in the example given. But in the example given the velocity of the ball is limited.

In the VGBKernel.java example, we have a fairly slow-moving ball detecting collisions with a really large object that's hard to miss.

If we have a brick that is small, and a ball that is fast, though, the ball could pass right over the brick without even realizing it should have collided with it. In other words, if we had a brick wall stretching across the screen, the ball might fly "through" it when we want it to stop or bounce. Let's say we're falling and want to detect a brick that acts as a floor. The floor goes across the screen between heights 100 and 105. The ball starts at location 75 and has a velocity of 50. Its new location would be 125. We move it there, and check for a collision as we did in VGBKernel. No collision. The ball just flew "through" the brick wall like Jonathan Livingston Seagull!

Let's make an example program called BallGrav.java to illustrate the problem. BallGrav.java is a slightly modified version of VGBKernel.java. It uses the same Brick class as we've used before, with no modifications.

/* Based on the video game style kernel, revision 3.
   by Mark Graybill, August 2010
   Demonstrates collision detection problems, and solutions.
*/

// Import Timer and other useful stuff:
import java.util.*;
// Import the basic graphics classes.
import java.awt.*;
import javax.swing.*;
import java.lang.Math;

public class BallGrav extends JPanel{

public Rectangle screen, bounds; // The screen area and boundary.
public JFrame frame; // A JFrame to put the graphics into.
public VGTimerTask vgTask; // The TimerTask that runs the game.
public VGBall ball; // The game ball, a subclass of Rectangle.
private Brick brick; // A brick for the ball to interact with.

// Create a constructor method:
  public BallGrav(){
    super();
    screen = new Rectangle(0, 0, 600, 400);
    bounds = new Rectangle(0, 0, 600, 400); // Give some temporary values.
    ball = new VGBall();
    frame = new JFrame("BallGrav");
    vgTask = new VGTimerTask();
    brick = new Brick();
}

  // Create an inner TimerTask class that has access to the
  // members of the BallGrav.
  class VGTimerTask extends TimerTask{
    public void run(){
      ball.move();
      frame.repaint();
    }
  }

  // Create an inner VGBall class that has our game logic in it.
  class VGBall extends Rectangle{
    int xVel, yVel; // The ball's velocity.
    Color ballColor; // The color of the ball.

    public VGBall(){
      super(300, 0, 20, 20);
      xVel = 0; // Start with 0 velocity at center top of screen.
      yVel = 0;
      ballColor=new Color(0, 0, 128);
    }

    // Instance methods for VGBall
    public void move(){
      // Accelerate due to "gravity".
      yVel+=3;
      // Move the ball according to the game rules.
      x+=xVel; // Move horizontally.
      y+=yVel; // Move vertically, accelerating as we go.
      // Detect edges and stop movement if we hit them.
      if (x > (bounds.width - width)){
        xVel = 0; // stop movement.
        x = bounds.width -  width; // Set location to screen edge.
      }
      if (y > (bounds.height - height)){
        yVel = 0; // stop movement.
        y = bounds.height - height;
      }
      if (x <= 0) { xVel = 0; x = 0; }
      if (y <= 0) { yVel = 0; y = 0; }

      // Check for intersection with Brick,
      // change color when touching.
      if (intersects(brick)) {
        //Stop on top of the brick if we hit it.
        yVel = 0;
        y = brick.y - height;
      }

    }

    public void draw(Graphics g){
    // the ball draws itself in the graphics context given.
      Color gcColor = g.getColor(); // Preserve the present color.
      g.setColor(ballColor); // Use the ball's color for the ball.
      g.fillRect(x, y, width, height); // Draw the ball.
      g.setColor(gcColor); // Restore prior color.
    } // end draw()

  } // end of class VGBall

// Now the instance methods:
  public void paintComponent(Graphics g){
    // Get the drawing area bounds for game logic.
    bounds = g.getClipBounds();
    // Clear the drawing area.
    g.clearRect(screen.x, screen.y, screen.width, screen.height);
    // Draw the brick.
    g.setColor(brick.getColor());
    g.fillRect(brick.x, brick.y, brick.width, brick.height);
    // Draw the ball.
    ball.draw(g);
  }


  public static void main(String arg[]){

    java.util.Timer vgTimer = new java.util.Timer();  // Create a Timer object
    BallGrav panel = new BallGrav(); 
    
    panel.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    panel.frame.setSize(panel.screen.width, panel.screen.height);

    panel.frame.setContentPane(panel); 
    panel.frame.setVisible(true);

    // Set up the brick.
    panel.brick.x = 0;
    panel.brick.y = 4 * (panel.screen.height/5);
    panel.brick.width = panel.screen.width;
    panel.brick.height = 5;
    panel.brick.brickColor = new Color(200,50,50);

    // Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 250, 200);
  }
}

This example functions properly. When the ball falls, it strikes the brick floor and stops.

But let's make the ball accelerate a bit faster. Make the following change in Ball's move() method:

      // Accelerate due to "gravity".
      yVel+=5;

Suddenly, the ball doesn't detect the floor any more, and it goes to the bottom of the screen, right through the floor:

Stopping Jonathan Livingston Gameball from Going Through the Wall

What do we do to keep this from happening? Well, one way is to never let the ball move faster than it can detect collisions. Then we'd never let it move more than its own size in any direction. If it's important that it know what side it hits something on (like when we're going to bounce off it), then we may not want to let it go more than half its size in any direction in any one "move." To do this to BallGrav,java, we'd change the code as follows:

      // Accelerate due to "gravity".
      yVel+=5;
      // Limit our velocity to preserve collisions.
      if (yVel>height) { yVel = height; }

Now the ball will never go so fast it never sees the floor.

But what if we want the ball to move faster?

In this case, there are a number of possible solutions. Many of them are fairly complicated, with lots of math or with lots of iteration checking for collisions at each step along the way. Complexity is something we don't want, for a lot of reasons. Here is one possible solution, that uses collision prediction to see if our ball might hit something along the way:

      // Accelerate due to "gravity".
      yVel+=5;
      // Limit our velocity.
      if (yVel>(height*2)) { yVel = height * 2; }
      // Move the ball according to the game rules.
      // Check for a collision if we're moving fast.
      if (yVel>height) {
        Rectangle halfway = new Rectangle(x,y+(yVel/2), width, height);
        if (halfway.intersects(brick)) { yVel = yVel/2; }
      }
      x+=xVel; // Move horizontally.
      y+=yVel; // Move vertically, accelerating as we go.

Here, I have a velocity limit twice as high as before. This allows the ball to move along a lot faster (before, I could see the ball slow down.) Now, since the ball can move fast enough to fly through things, we first look ahead to see if there's anything in the way. We do this by seeing if there's something halfway there. If so, we cut our original speed in half before we move. Then the collision (if any) happens "naturally."

This is good enough, if the fastest we can move is twice the ball's height. If we allowed three times its height, we might check at points 1/3 and 2/3 of the way along its path.

If we don't want limits like this, we pay the price by having a more complex method to check for collisions. Here, I've limited things to movement in only one direction, up and down. If we're going side to side as well, I'd have to check for waypoints along a diagonal path. To get really precise, I'd have to do something like project lines along the corners of the ball from its current position to its intended new position and see if they intersect anything. When you get into more complex shapes than the rectangles we're using now, you get a different set of choices.

Fortunately, for video games, simple choices are almost always plenty good enough. Checking for collisions at the minimum number of points along the path is almost always good enough. This can be done by dividing the distance to be moved by the largest safe move distance, and checking that many times for collisions along the path.

Avoiding the Problem Entirely

You can also just use a different sort of movement that never has any of the objects moving more than some small number of pixels at a time--small enough that you'll never fail to detect a collision. I'll give an example in a future article, but for now I'll just describe it.

What you do is set a speed at which you move things only, say, one pixel per "move". But you only move them every so often, depending on what their speed is. The fastest objects get moved on every redraw of the screen. Slower objects only get moved on every other update, or every fifth, or something of that sort. That way an object is never moved across the screen by so many pixels at once that it misses seeing a collision with another object.

Collision Detection: Never "Easy"

Collision detection is one of the programmer's bugaboos. It's one of the places where errors are most prone to occur in code, and it can have terrible effects on a game if it doesn't work properly. The programmer's choices are to accept certain limitations or to make more complex code, or to use a technique of object movement that can either be limiting or eat up a lot of processor time.

When my students program their video game projects in class, one of our biggest problems in implementing those games is dealing with collision detection. Even though we're working in Greenfoot, which does a lot of the work for us. We still need to be aware of the limitations built into the system, and work within them.

Now it's your turn. Try reducing the brick in BallGrav.java to a small platform. Now give the ball a constant x velocity. See if you can get the ball to land on that platform reliably, with successful collision detection.

Simple Collision Detection in Java

2010-08-15T12:27:00.000-07:00

Collision detection is a basic element of a video game. It is one of the primary means of determining when objects in a game should interact. In Asteroids, there are collisions between the player's shot and the asteroids themselves. There are collisions between the player's shot and the alien spacecraft (hopefully.) There are collisions between the asteroids and the player's ship (argh!) Each of these is critical to the game.

Since we don't have actual physics to determine when there's been a collision, as we have in real life, we need to create a set of rules for when a collision has occured then implement those rules in our code. One way to handle collision detection is to see if two potentially colliding objects intersect at all on the playfield. That is, whether one of them overlays the other.

Previously, we have worked with a simple video game kernel, then updated it to make the addition of game logic simpler. We had also created a Brick class that we can use to interact with the ball in our basic video game kernel.

Here is a slightly changed version of the simple video game kernel. It uses the Brick class, so Brick.class should be in the same directory as your VGBKernel.java and VGBKernel.class (it wouldn't be a bad idea to have Brick.java there, too, in case you want to play around with it at all to get different effects with this program through changes of your own.)

/* A simple video game style kernel, revision 3.
   by Mark Graybill, August 2010
   Uses an inner class to contain game logic,
   with another inner class as a game timer.
*/

// Import Timer and other useful stuff:
import java.util.*;
// Import the basic graphics classes.
import java.awt.*;
import javax.swing.*;
import java.lang.Math;

public class VGBKernel extends JPanel{

public Rectangle screen, bounds; // The screen area and boundary.
public JFrame frame; // A JFrame to put the graphics into.
public VGTimerTask vgTask; // The TimerTask that runs the game.
public VGBall ball; // The game ball, a subclass of Rectangle.
private Brick brick; // A brick for the ball to interact with.

// Create a constructor method:
  public VGBKernel(){
    super();
    screen = new Rectangle(0, 0, 600, 400);
    bounds = new Rectangle(0, 0, 600, 400); // Give some temporary values.
    ball = new VGBall();
    frame = new JFrame("VGBKernel");
    vgTask = new VGTimerTask();
    brick = new Brick();
}

  // Create an inner TimerTask class that has access to the
  // members of the VGBKernel.
  class VGTimerTask extends TimerTask{
    public void run(){
      ball.move();
      frame.repaint();
    }
  }

  // Create an inner VGBall class that has our game logic in it.
  class VGBall extends Rectangle{
    int xVel, yVel; // The ball's velocity.
    Color ballColor; // The color of the ball.

    public VGBall(){
      super(0, 0, 20, 20);
      xVel = width/4;
      yVel = height/4;
      ballColor=new Color(0, 0, 128);
    }

    // Instance methods for VGBall
    public void move(){
      // Move the ball according to the game rules.
      x+=xVel; // Move horizontally.
      y+=yVel; // Move vertically.
      // Detect edges and bounce if necessary.
      if (x > (bounds.width - width)){
        xVel = -xVel; // reverse movement.
        x = bounds.width -  width; // Set location to screen edge.
      }
      if (y > (bounds.height - height)){
        yVel = -yVel; // reverse movement.
        y = bounds.height - height;
      }
      if (x <= 0) { xVel = -xVel; x = 0; }
      if (y <= 0) { yVel = -yVel; y = 0; }

      // Check for intersection with Brick,
      // change color when touching.
      if (intersects(brick)) { ballColor=Color.GREEN; }
      else { ballColor=Color.BLUE; }

    }

    public void draw(Graphics g){
    // the ball draws itself in the graphics context given.
      Color gcColor = g.getColor(); // Preserve the present color.
      g.setColor(ballColor); // Use the ball's color for the ball.
      g.fillRect(x, y, width, height); // Draw the ball.
      g.setColor(gcColor); // Restore prior color.
    } // end draw()

  } // end of class VGBall

// Now the instance methods:
  public void paintComponent(Graphics g){
    // Get the drawing area bounds for game logic.
    bounds = g.getClipBounds();
    // Clear the drawing area.
    g.clearRect(screen.x, screen.y, screen.width, screen.height);
    // Draw the brick.
    g.setColor(brick.getColor());
    g.fillRect(brick.x, brick.y, brick.width, brick.height);
    // Draw the ball.
    ball.draw(g);
  }


  public static void main(String arg[]){

    java.util.Timer vgTimer = new java.util.Timer();  // Create a Timer object
    VGBKernel panel = new VGBKernel(); 
    
    panel.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    panel.frame.setSize(panel.screen.width, panel.screen.height);

    panel.frame.setContentPane(panel); 
    panel.frame.setVisible(true);

    // Set up the brick.
    panel.brick.x = panel.screen.width/4;
    panel.brick.y = panel.screen.height/4;
    panel.brick.width = panel.screen.width/2;
    panel.brick.height = panel.screen.height/2;

    // Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 0, 33);
  }
}

The main changes here are the addition of the brick to the VGBKernel (that's why I renamed VGKernel to VGBKernel, by the way--it's now a Video Game Brick Kernel), and I've changed ball into an extension of Rectangle to make collision detection a bit easier.

To do the actual collision detection, I'm using the method intersects() from the Rectangle class. It tests whether one Rectangle overlaps another in the coordinate space.

In this case, if the ball is on top of the brick (a rather large brick), then the ball turns green. I could have had any of a number of other effects. For example, when I was first testing this routine I didn't change the color of the ball, instead I had the ball send a message to the Java console that read "Ow!". So whenever the ball passed over the brick I'd get a long string of messages in the console like this:

Ow!
Ow!
Ow!
Ow!
Ow!
Ow!
Ow!
Ow!
Ow!

I could just as well have the program play a sound, draw an image, update a score, or any of a number of different things when a collision occurs. Exactly what should happen is determined by the rules of the video game itself.

Going Further

Try changing the effect when the ball strikes the brick. The easiest place to start would be making the ball a different color than green. To get more sophisticated, try things like adding a sound, or counting the number of moves that the ball is in contact with the brick. Change the size and location of the brick. Perhaps try adding additional bricks, and have each create a different effect. Try changing the color of the brick when the ball strikes it.

One thing about the collision detection we are doing here. It only detects when we have actually started to overlap with the brick. In many cases, it's desirable to predict when a collision will occur as a result of a move before that move occurs. Try to develop a solution to this yourself. I'll be addressing this in a future article, so you can compare what you came up with against my method. Remember that in programming there's almost never just one way to accomplish something. The same effect can usually be produced any of a number of different ways effectively enough to use in a finished program.

Multiple Constructor Methods

2010-08-13T12:35:00.000-07:00

A special type of method that creates an instance of a method is called a Constructor Method. When an object has member variables that are objects, we need to define a constructor method to set up those variables. We'll show how to do that here. If you want a more basic introduction to constructor methods, you may want to take a look at my prior article.

As an example, we're going to create a simple class of object for use with my simple video game kernel in a new version I'll be introducing in an article in the near future. The class definition consists mostly of constructor methods, since the class itself is presently not much more than a Rectangle with an added field.

import java.awt.*;

// A Simple class for use in the simple video game examples.
// Mark Graybill, Aug. 2010

public class Brick extends Rectangle{
 Color brickColor;

 public Brick(int newX, int newY, int newWidth, int newHeight){
  super(newX, newY, newWidth, newHeight);
  brickColor = new Color(0, 128, 255);
 }

 public Brick(int newX, int newY){
  this(newX, newY, 10, 10);
 }

 public Brick(){
  this(0,0,10,10);
 }

 public void setColor(Color newColor){ brickColor=newColor; }
 public Color getColor(){ return brickColor; }

} // End Brick

In this class, we have three forms of constructor, each with a different set of parameters. The one that takes the most parameters is the "base" version. It starts with a call to super(). This calls the constructor for Brick's superclass, or parent class, Rectangle. A look at the documentation for Rectangle shows that it has a constructor that takes four integer arguments, as we use here in super().

When we use super(), it must be the first thing we do within our constructor method. If we don't use super(), Java will do it automatically as the first thing in a constructor, calling it with no parameters. Since we want to set values for our inherited fields of x, y, width, and height it's better to call super() with those parameters. Otherwise, we could just as well have done something like this:

  public Brick(int newX, int newY, int newWidth, int newHeight){
  x=newX;
  y=newY;
  width=newWidth;
  height=newHeight;
  brickColor = new Color(0, 128, 255);
 }

This would have the same effect, and Java would insert an invisible call to super() in front of x=newX;.

The other constructors use the first method. To do this, they use another special method that's like super(). It's called this(), and it calls another constructor for this class. We can't do a call to Brick(), if we try, the compiler will see it as an undefined symbol:


>javac Brick.java 
Brick.java:11: cannot find symbol
symbol  : method Brick(int,int,int,int)
location: class Brick
    Brick(0,0,10,10);
    ^
1 error

So we use this() instead.

Like super(), the this() method must be the first thing called in the constructor method's body. Since don't call super()--it's in the base constructor--so there's no conflict about which goes first. If you use this(), you don't use super().

By using this() with the other constructor methods, we can keep all our key code code for the constructor in one place. If we had each constructor setting member values and constants without calling the base constructor method, then we'd end up with repeated code--a prime opportunity for bugs to enter our code if we update the code in one place, but not another. We don't want repeated code! Multiple independent constructors are used in the Java Tutorials, but I expect they're used to keep the lesson simple, not because they are a good coding practice!

You can find out more about this() and super() in the Java Language Specification, under Explicit Constructor Invocations.

You can probably see that I should really have my base constructor allow a Color to be passed to it, too. Try adding this yourself as an exercise to try out your understanding of constructor methods, then see what javac thinks of your work.

Java's Inner Classes: The Keys to the Kingdom

2010-08-11T14:52:00.000-07:00

In my two most recent code examples I've used inner classes in the program.

Java Video Game Programming: Game Logic

A Simple Java Video Game Kernel

An inner class is a Java class that's defined inside another class. In both the examples above, I have a class called VGKernel, which is the class that implements the video game kernel. Inside that class, I define other classes. This has a special effect on the relationship between those classes and VGKernel.

Normally, our objects are encapsulated, that is, their members (variables and methods) are inaccessible to other classes unless they've been marked as public, and in those cases we take care to make sure that the object can't be messed up using those public members.

Some things in Java don't work very well with the encapsulation. Graphics and Threads are two of them. Fortunately, there's a way around the encapsulation. It lets one object access all the members of another object as if it owned them.

The downside is that this can be a dangerous coding practice, like global variables (check out the sort of problems JavaScript's had with security, if you want to know why global variables are a problem.) Your inner class has complete control over the outer class. Root access, keys to the kingdom. It could wear the outer class like the alien guy wore the redneck's skin in Men in Black.

If used well inner classes solve a multitude of problems. In the case of the two versions of VGKernel, it solves the problem of the ball being able to access the graphical context (at present, the Ball class doesn't really need to, I'll admit, but we'll see more of why it does this as the code develops in future articles), and it allows VGTimerTask to access the methods of VGKernel.

The Java Tutorial has a pretty good section on inner classes, as one type of nested class.

Java Video Game Programming: Game Logic

2010-08-09T12:21:00.000-07:00

The simple video game kernel I presented earlier is a good start, but some compromises were made to make it as simple as possible. Now we're going to start adding back some of the complexity to give us more control over what we can do with it.

The first step is to make the game's ball a real object, rather than some variables within our JFrame.

In simple video games, there is usually some object in the game that does most of the "thinking" with respect to the game's rules. In a game like Pong or Breakout, the ball does most of the "thinking". The paddles move according to user input, but they don't really need to know if they've collided with anything in the game (their own logic keeps them from moving off the playfield.) The bricks don't need to know anything about what's going on, they just need to hang around, then disappear when something tells them to, and perhaps return some information about what score they're worth, if there are different scores for hitting different bricks.

The ball, however, is a more active participant in the game. It needs to know about collisions, respond to the other objects in the game, and generally know what's going on. In other words, it is the object that keeps track of most of the game rules. In a video game, this is referred to as the game logic.

This simple kernel improves on the original. Turn it into your own Pong, Breakout, or Tank clone.

In the example below I've made a Ball class. This is where most of the game's logic will reside. Here it is in the ball's move() method. Since the ball will need access to inside information about the playfield and the objects on it, I've made it an inner class of the playfield's class (VGKernel.) As an inner class, it has access to all of VGKernel's members and methods as if it owned them itself. This simplifies the program a lot.

Here is the modified version of the video game kernel. Changes from the original have been highlighted:

/* A simple video game style kernel, revision 2.
   by Mark Graybill, August 2010
   Uses an inner class to contain game logic,
   with another inner class as a game timer.
*/

// Import Timer and other useful stuff:
import java.util.*;
// Import the basic graphics classes.
import java.awt.*;
import javax.swing.*;
import java.lang.Math;

public class VGKernel extends JPanel{

// This is not a recommended coding practice, just a shortcut.
public Rectangle screen, bounds; // The screen area and boundary.
public JFrame frame; // A JFrame to put the graphics into.
public VGTimerTask vgTask; // The TimerTask that runs the game.
public VGBall ball; // The game ball.
// Create a constructor method:
  public VGKernel(){
    super();
    screen = new Rectangle(0, 0, 600, 400);
    bounds = new Rectangle(0, 0, 600, 400); // Give some temporary values.
    ball = new VGBall();
    frame = new JFrame("VGKernel");
    vgTask = new VGTimerTask();
}

  // Create an inner TimerTask class that has access to the
  // members of the VGKernel.
  class VGTimerTask extends TimerTask{
    public void run(){
      ball.move();
      frame.repaint();
    }
  }

  // Create an inner VGBall class that has our game logic in it.
  class VGBall{
    // Accessor methods would be more proper,
    // but for now I just make the needed variables public.
    public int x, y, width, height; // Ball's location and size.
    int xVel, yVel; // The ball's velocity.

    public VGBall(){
      x = 0;
      y = 0;
      width = 20;
      height = 20;
      xVel = width/4;
      yVel = height/4;
    }
    // Instance methods for VGBall
    public void move(){
      // Move the ball according to the game rules.
      x+=xVel; // Move horizontally.
      y+=yVel; // Move vertically.
      // Detect edges and bounce if necessary.
      if (x > (bounds.width - width)){
        xVel = -xVel; // reverse movement.
        x = bounds.width -  width; // Set location to screen edge.
      }
      if (y > (bounds.height - height)){
        yVel = -yVel; // reverse movement.
        y = bounds.height - height;
      }
      if (x <= 0) { xVel = -xVel; x = 0; }
      if (y <= 0) { yVel = -yVel; y = 0; }
    }
  } // end of class VGBall

// Now the instance methods:
  public void paintComponent(Graphics g){
    // Get the drawing area bounds for game logic.
    bounds = g.getClipBounds();
    // Clear the drawing area, then draw the ball.
    g.clearRect(screen.x, screen.y, screen.width, screen.height);
    g.fillRect(ball.x, ball.y, ball.width, ball.height);
  }

  public static void main(String arg[]){

    java.util.Timer vgTimer = new java.util.Timer();  // Create a Timer object
    VGKernel panel = new VGKernel(); 
    
    panel.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    panel.frame.setSize(panel.screen.width, panel.screen.height);

    panel.frame.setContentPane(panel); 
    panel.frame.setVisible(true);

    // Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 0, 33);
  }
}

Now the ball not only is its own class, it has a more sophisticated means of keeping track of its direction of movement (xVel and yVel, tracking velocity as a positive or negative value, as opposed to the simple right and down booleans in the original.) This means that logic in the game could vary the velocity of the ball easily, as well as change its direction of movement.

Other objects on the playfield should be defined in their own classes, outside VGKernel. This will keep VGKernel from becoming too long and from making the program too monolithic and difficult to maintain.

Simple exercises:
Since the ball has access to VGKernel's members, including the drawing screen, the ball can be made to draw itself. By giving the ball its own draw() method, we can make it easier to change the appearance of the ball at will. Give it a try.

A Simple Java Video Game Kernel

2010-08-04T09:09:00.000-07:00

Most video games run continuously, rather than waiting for user input before they do something. The heart of a video game of this sort is called the kernel. The kernel is running in the background, collecting user input and updating the display. It uses logic to determine if the game has been won or lost or otherwise control the state of the game.

This simple kernel sends a ball bouncing around on the screen. Turn it into your own Pong, Breakout, or Tank clone.

To run this way, Threads are usually used to allow more than one thing to be going on at a time in a Java program. We've looked at a simple way of using threads before, the Timer class.

Here's a really, really simple video game kernel. It has all the basic elements of a video game.

/* A simple video game style kernel
   by Mark Graybill, August 2010
   Uses the Timer Class to move a ball on a playfield.
*/

// Import Timer and other useful stuff:
import java.util.*;
// Import the basic graphics classes.
import java.awt.*;
import javax.swing.*;

public class VGKernel extends JPanel{

// Set up the objects and variables we'll want.
public Rectangle screen, ball; // The screen area and ball location/size.
public Rectangle bounds;  // The boundaries of the drawing area.
public JFrame frame; // A JFrame to put the graphics into.
public VGTimerTask vgTask; // The TimerTask that runs the game.
public boolean down, right; // Direction of ball's travel.

// Create a constructor method that initializes things:
  public VGKernel(){
    super();
    screen = new Rectangle(0, 0, 600, 400);
    ball   = new Rectangle(0, 0, 20, 20);
    bounds = new Rectangle(0, 0, 600, 400); // Give some starter values.
    frame = new JFrame("VGKernel");
    vgTask = new VGTimerTask();
}
  // Create an inner TimerTask class that has access to the
  // members of the VGKernel.
  class VGTimerTask extends TimerTask{
    public void run(){
      moveBall();
      frame.repaint();
    }
  }

// Now the instance methods:
  public void paintComponent(Graphics g){
    // Get the drawing area bounds for game logic.
    bounds = g.getClipBounds();
    // Clear the drawing area, then draw the ball.
    g.clearRect(screen.x, screen.y, screen.width, screen.height);
    g.fillRect(ball.x, ball.y, ball.width, ball.height);
  }

  public void moveBall(){
  // Ball should really be its own class with this as a method.
    if (right) ball.x+=ball.width; // If right is true, move ball right,
    else ball.x-=ball.width;       // otherwise move left.
    if (down)  ball.y+=ball.height; // Same for up/down.
    else ball.y-=ball.width;
    if (ball.x > (bounds.width - ball.width)) // Detect edges and bounce.
      { right = false; ball.x = bounds.width -  ball.width; }
    if (ball.y > (bounds.height - ball.height))
      { down  = false; ball.y = bounds.height - ball.height;}
    if (ball.x <= 0) { right = true; ball.x = 0; }
    if (ball.y <= 0) { down  = true; ball.y = 0; }
  }

  public static void main(String arg[]){
    java.util.Timer vgTimer = new java.util.Timer();  // Create a Timer.
    VGKernel panel = new VGKernel(); // Create and instance of our kernel.
    
    // Set the intial ball movement direction.
    panel.down = true;
    panel.right = true;

    // Set up our JFRame
    panel.frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    panel.frame.setSize(panel.screen.width, panel.screen.height);
    panel.frame.setContentPane(panel); 
    panel.frame.setVisible(true);

    // Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 0, 100);
  }
}

This example can be expanded with methods to get control inputs, additional players on the playfield (like paddles), and logic to determine when someone scores.

The code here is far from perfect, but I've made some compromises to make things as simple as I could while still showing a full working example. Not that any code that runs and does what is supposed to is really bad, but there are other, better ways of doing this. But this works and is fairly easy to understand.

What the program does is create a JPanel that has an inner class (a class defined within itself) of VGTimerTask. The VGTimerTask is a kind of TimerTask, which can be scheduled to occur on a regular basis by a Timer. Since VGTimerTask is an inner class of VGPanel, it has access to all the members of VGPanel. This is critical. Without that, it wouldn't be able to access the ball and redraw the screen easily (it can still be done, but in a more complex way.)

Timer is a decent way of running a simple game, but more complex games should use some other timing mechanism. java.util.Timer is affected by a number of outside events, so to get smoother, more reliable timing you a timer like the one in the Java3D package would work better.

A Simple Improvement

There are many ways of improving on this basic example. One way that is very simple is to smooth the animation. The movement of the ball is pretty jerky. This is caused by both the distance that the ball moves each "turn", and by the time between screen updates. We can smooth out the animation by addressing both of these.

First, let's change moveBall() to shift the ball a smaller distance each time:

public void moveBall(){
  // Ball should really be its own class with this as a method.
    if (right) ball.x+=ball.width/4; // If right is true, move ball right,
    else ball.x-=ball.width/4;       // otherwise move left.
    if (down)  ball.y+=ball.height/4; // Same for up/down.
    else ball.y-=ball.width/4;
    if (ball.x > (bounds.width - ball.width)) // Detect edges and bounce.
      { right = false; ball.x = bounds.width -  ball.width; }
    if (ball.y > (bounds.height - ball.height))
      { down  = false; ball.y = bounds.height - ball.height;}
    if (ball.x <= 0) { right = true; ball.x = 0; }
    if (ball.y <= 0) { down  = true; ball.y = 0; }
  }

Now the ball is being moved only one quarter of its size each turn.

Next, change the Timer schedule to draw the screen every 20 milliseconds instead of every 100 milliseconds:

// Set up a timer to do the vgTask regularly.
    vgTimer.schedule(panel.vgTask, 0, 20);

Now you have a ball that moves a lot smoother.

I'll be expanding on this basic kernel and improving it in future articles, starting with Java Video game Programming: Game Logic