Thursday, July 31, 2008

Getting Keyboard Input for Console Apps: Java's Scanner Class

A nice gift that came with Java 1.5 was the Scanner class. It's part of the java.util package. This class simplifies many common programming tasks. One is getting text from the keyboard.

Prior to Scanner, this took a couple of extra steps. With Scanner, it's a snap. Just as we use System.out to print text to the command line, we use System.in to receive input. Like System.out, System.in is a data stream object. In this case, an InputStream object.

import java.util.Scanner;

public class TrollTalk{
public static void main(String arg[]){
String nayme=""; // Declare & initialize a String to hold input.
Scanner input=new Scanner(System.in); // Decl. & init. a Scanner.

System.out.print("Whut yur nayme? >"); // Troll asks for name.
nayme=input.next(); // Get what the user types.
System.out.println(); // Move down to a fresh line.
// Then say something trollish and use their name.
System.out.println("Hur, hur! Dat's a phunny nayme, " + nayme + "!");
}
}

Our Scanner is named input. We could have called it gzorgnplat, if we wanted to--there's nothing magic about the name 'input'. We attach that name to a new Scanner object that accepts vlues from System.in. Then we print a message so that the user knows they're supposed to type something. The message is a question we want them to answer and a greater-than sign to let them know the computer is ready for them to type.

Being able to accept input while the program is running lets us create interactive command line apps.

Scanner can also be used to get particular types of input like numbers of particular primitive types.

It can also be used to get information from files in the same way it gets information from the user's keyboard. But that's another lesson.
StumbleUpon

Monday, July 28, 2008

Killer Java IDEs for Beginners: Arachnophilia

Arachnophilia was once one of the leading Windows-only IDEs for web page development. Now, it has grown. It's written in Java, so it runs on any current system. It also has grown to support far more than HTML. It also supports Java and a slew of other languages.

It's simple and easy to use, but very powerful. It does syntax highlighting, recognizing Java's keywords, strings, and so on, making it easier to see mistakes when entering programs. It will also match parentheses, brackets, and braces for you, making it easier to avoid--or find--errors in your program there.

Arachnophilia has a great code beautifier built in. So if you're in the practice of not always doing all the indenting you might when you first enter your program, it will go through and clean up the program with all the proper indenting and newlines to make it look really nice.

The interface is easy to configure. You can add new buttons to your toolbar, and make new buttons that do specific tasks the way you want them to. If you want a single button that backs up your old source file, saves and compiles the present one, then runs it with specific java command line options, you can make it moments with Arachnophilia.

If you work with more than Java, having one IDE for all of them is convenient. For example, if you're working with HTML and CSS as well as Java, and maybe doing some JavaScript or python on the side, you can use Arachnophilia for all of them.

My only complaint with Arachnophilia is the lack of inbuilt printing functions. But this is a minor concern. Also, if you're a Mac user, you may find it odd to be using the control key for keyboard shortcuts rather than the Apple/Command key.

Arachnophilia is the IDE that I use with my high school classes, as I mention on my other blog. I use it myself, especially on my little ASUS Eee computer which has limited screen space and not a lot of storage space. It's not an IDE that's just good for classwork. It's good enough for real work.

Give it a try.
StumbleUpon

Friday, July 25, 2008

Killer Java IDEs for Beginners: BlueJ

BlueJ is an integrated development environment created especially for new programmers learning Java. It's built to be easy to use, but also to provide powerful features to assist new programmers learn object oriented programming without headaches.

It shows a graphical representation of the classes and objects in a program. It also teaches the use of program comments for automatically generating documentation for the program. And this all happens easily without any hoops to jump through. It's just there, and it does its thing.

It also gives quick and easy access to the API documentation for Java, making it easier to use and get familiar with. Because the same documentation format will be used for your own programs, how this format works will become clear really quickly.

The BlueJ site has some great tutorials doing fun things with Java and BlueJ. There's nothing like doing interesting exercises to make learning easier.

When you're ready to move onward and upward, BlueJ can be used with NetBeans, a considerably more sophisticated, and complex, IDE for Java. So BlueJ is not a classroom-only dead end.

Learning to program has never been easier. The many resources for Java make it a great way to start programming. BlueJ is a big part of making Java a great place to start. Check it out.
StumbleUpon

Thursday, July 24, 2008

Why Start at the Command Line?

Many instructors, including myself, start students out at the command line when we teach programming. With all the great tools out there, why bother? It's not like you start out a basic computer class with an old floppy-disk based system and start teaching the students how to run Windows or OS X by having them boot up CP/M or Integer BASIC.

The main reason I do it, even though I move on to a graphical integrated development environment (IDE) pretty quickly, is that it's important to understand what your tools are doing for you. Also, it's important to be able to work with your program files outside the IDE.

Your program is saved in a file, or a group of files. You should know how to recognize those files, and where to find them. They may be stored in a special directory for that programming project. You should know what it is named, and where to find it. At least well enough that you can recognize it when you do a file search.

You also may end up in a situation where you don't have the IDE but want to get something done. If you've taken a copy of your program to a friend's system, you should know how to run the program without the IDE. You should know which file is the source code and which is the compiled version that you want to actually run. And, since you're doing it with someone looking over your shoulder, you'll want to be able to do it without a lot of hemming and hawing and trying to remember how to start the program. Which means you'll want to be familiar with how it's done. You will also want to know how to check which version of Java is on the system, so if they're running a JVM from the days of the cavemen, you'll know. (And wouldn't it be nice to know how to install a newer one for them without any trouble?)

So don't let the command line put you off. Even if you've started with an IDE, go ahead and use the command line sometime to do the basic tasks of showing your source file's contents, compiling your source file, and running it.
StumbleUpon

Tuesday, July 22, 2008

eBook Recommendation: Java Programming for Kids, Parents and Grandparents by Yakov Fain

Java Programming for Kids, Parents, and Grandparents by Yakov Fain is a neat little ebook that provides a brief introduction to Java. It has some great exercises in it, and if you're doing an install of the SDK to a Windows system it gives directions in a fashion that is somewhat more direct than the ones from Sun.

While my preference is to introduce graphics before getting into flow control, the book puts flow control first. However, the material goes so quickly, and the program exercises are so much fun that it doesn't matter much here. The final exercises in the book are a couple of simple graphical video games, and it doesn't take too long to get to them.

I haven't tested the book on any real students yet, but I probably will. Once I do I'll post a more in-depth article on this book. The writing style is light, occasionally a bit condescending, but the material itself is well done.

Thumbs up to those resposible for writing and distributing Java Programming for Kids, Parents and Grandparents. A body of good material like this is what makes programming accessible to ordinary folks who might otherwise think you need to live like some sort of egghead monk to learn this stuff.

The contrast between the approach in this ebook with the first edition of Java Programming for Dummies (the Aaron Walsh version, not the fine book by Brad Burd) is striking. Essentially, the first Java for Dummies book told you "Java is hard, you're a Dummy. Since Java is too complicated for a Dummy like you, we're going to teach you JavaScript instead, even though you thought you bought a book on Java."*

The Fain book didn't bother to tell me what I can't do. It was too busy telling me what I can do. On top of that, Yakov Fain's book is a free ebook, so it cost me $25 less than the Dummies book. (Yeah, I still feel burned on that one. ;) )

* It wasn't bad at all as a book on JavaScript, BTW. But it wasn't being sold as a book on JavaScript. It even has a short section on Java applets and chapter titles that refer specifically to Java inside to confuse the issue for those who see the cover screaming "Java" and take the time to flip through it. This book put me off Dummies books for about ten years, and only the excellence of many of their current books brought me back.
StumbleUpon

Sunday, July 20, 2008

Controlling Java's Graphics: paintComponent() and repaint()

Why do we put all our graphical drawing code into a paintComponent() method? It seems odd, since it would seem we should be able to simply stick some simple graphics commands into our main() method in a Java application and just get the drawing done. Where does paintComponent come from? If we never call it in our code, how does it get executed?

It seems like magic, doesn't it? You just sort of set it up and somehow it happens. Hopefully when and how we want it to. It seems like a vaguely disquieting form of magic, perhaps.

When Java does graphics, suddenly you're not in the strict control of the program that you are with command line applications. With graphics, your program is now interacting with the other parts of your computer's operating system. It's not just running in its own little corner of the machine. Now it's got a window out on that shared resource, the display, and the window has to interact properly with everything else that's on the display.

Think of it this way, if you are just driving around on private property all by yourself you don't have to worry about traffic. Off on your own stretch of road, with an unused parking lot or two to tool around in, you don't have to worry about sharing. You can cross the center line, pull on and off the road without signalling, you don't even need a license so long as you don't go on a public road.

But once you head for the public roads and freeway, you've got to share. The rules matter. It gets more complicated than buzzing around in a go-cart or whatever on private property. And things happen that you don't have any direct control over, like red lights and merging traffic.

When you move your program on to the display in Java, you don't have to do everything on your own as you would have to in a car. Java's graphics system takes care of a lot for you. Unfortunately this means your code starts looking like magic. Methods get called without you doing the calling. But it's OK. All you need to know is what to expect.

The paintComponent() method redraws your graphics area. In our examples so far this has been a JPanel. There are two ways paintComponent() can get called. One is automatic, the other is up to you.

The automatic way is what we've used so far. The computer's window manager automatically calls for your program to redraw its graphics whenever a window it owns appears to need redrawing. The window manager can decide this for any of a number of reasons. Such as when the window initially appears on screen. Or if the window has been covered up in part or in whole by another window on screen, and the covered part has just been uncovered. Maybe the window had been minimized, and has just been restored.

When these sort of things happen, the Java Runtime Environment calls the paint() method for your container. In our examples so far, our container has been a JFrame. It will be a "heavyweight" component (see the JFrames article for a brief discussion on this.) Once the container redraws itself, it'll pass the command down to its children, that is, the lightweight components that live inside it. A lightweight component from the Swing package uses the paintComponent() method to redraw itself. So that's what gets called. Shazam! It's like magic!

This means you want to set up paintComponent() to draw things the way you want them when it gets called. If you're doing drawings that don't change, like the examples we've done to date, then you don't need to look up any information. If you're doing anything animated or that otherwise changes over time, you need to have paintComponent() be able to look things up at the time of drawing to properly reflect conditions in the drawing.

Now, let's say you've changed something in your program and you want to redraw to show the change. You probably don't want to wait until the window manager thinks your window needs redrawing. If nobody is changing things on the screen otherwise, it may not redraw until way too late!

Does that mean you put a call to paintComponent() in your program? No! You would be taking a chance of breaking something if you did. You want to start from the top, like the Java Runtime Environment did. In your case, you want to call repaint(). This will take things from the top. It also handles some possibilities that jumping in and calling paintComponent() on your own will not.

Like, let's say both you and the window manager decide to redraw at the same time. If you bypass repaint() you'll be slowing down your program by making it repaint twice when it really only needs to redraw once. When you call repaint(), Java catches this for you and saves you some computer time by only redrawing once. It'll also catch redraw requests made while the redrawing is going on and deal with them appropriately. Your paintComponent() method will get called in its own turn when you use repaint().

So, if you have new information you want depicted on screen, use repaint().

Put all your drawing inside paintComponent() and let the system take care of knowing when to call it otherwise. Give paintComponent() the ability to get the information it needs to draw things the way you want them now. If you're getting ahead of what I've written here, and aren't sure how to get through the Object Oriented barriers, look up "inner classes" for a start. It gives you a way to get the information where you need it when you need it.
StumbleUpon

Saturday, July 19, 2008

Very Basic Java Graphics: 3 Examples

We're going to build up a graphics app from something so basic it doesn't really work, like the example from Java Graphics--Start with a JFrame and building to something more sophisticated. In the JFrame article and in A Most Basic Graphics App I've avoided the use of comments in the code to keep it shorter. In these examples I'm going to include comments in the code to describe what's happening. So don't be scared of the length of these examples, most of what's there is just comments, which Java ignores. They're there just for humans.
/* BasicFrame.java

This is a really simple graphics program.
It opens a frame on the screen with a single
line drawn across it.

It's not very polished, but it demonstrates
a graphical program as simply as possible.mag-27Apr2008
*/

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

public class BasicFrame extends JFrame{

// Create a constructor method
public BasicFrame(){
// All we do is call JFrame's constructor.
// We don't need anything special for this
// program.
super();
}

// The following methods are instance methods.
/* Create a paint() method to override the one in JFrame.
This is where the drawing happens.
We don't have to call it in our program, it gets called
automatically whenever the frame needs to be redrawn,
like when it it made visible or moved or whatever.*/
public void paint(Graphics g){
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
}

public static void main(String arg[]){
// create an identifier named 'window' and
// apply it to a new BasicFrame object
// created using our constructor, above.
BasicFrame frame = new BasicFrame();

// Use the setSize method that our BasicFrame
// object inherited to make the frame
// 200 pixels wide and high.
frame.setSize(200,200);

// Make the window show on the screen.
frame.setVisible(true);
}
}

This example draws a line on the JFrame. The window decorations take up some of our drawing space, so the title bar may cover some of our line. With some JVMs the background area of the JFrame won't be cleared before you draw. Also, when you close the window using the close button, the application doesn't shut down. For many applications on Mac OS X this is normal behavior, but on other OSes, and even many applications under OS X it's normal to expect an application to close down completely if you click the close button on the last open window (for applications that have multiple windows) or the close button on the main window for other applications.

So here's our next example, where we take care of that last problem:
/* CloseFrame.java
This is a really simple graphics program.
It opens a frame on the screen with a single
line drawn across it.

We're starting to add a little bit of polish
here--we make the program close nicely when
the close box is clicked, rather than just
sort of hanging around half-dead.
mag-28Apr2008
*/

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

public class CloseFrame extends JFrame{

// Create a constructor method
public CloseFrame(){
// All we do is call JFrame's constructor.
// We don't need anything special for this.
super();
}

// The following methods are instance methods.

/* Create a paint() method to override the one in JFrame.
This is where the drawing happens.
We don't have to call it in our program,
it gets called automatically whenever the
frame needs to be redrawn, like when it is
made visible or moved or whatever.
*/
public void paint(Graphics g){
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
}

public static void main(String arg[]){
BasicFrame frame = new BasicFrame();
// This uses a constant EXIT_ON_CLOSE that's a member of JFrame.
// The constant is passed to the setDefaultCloseOperation method
// of our frame object, which is a CloseFrame object,
// which inherits the method from its parent JFrame.
// It makes the program exit (close completely) when we click
// the close button.
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(200,200);frame.setVisible(true);
}
}

The magic line that makes the application exit when we click the close button is the one that reads: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);. We can tell that EXIT_ON_CLOSE is a type of variable called a "constant" because the name follows the convention of being written in all capital letters. So we're not YELLING when we say "EXIT_ON_CLOSE" we're using the value stored in EXIT_ON_CLOSE as part of the JFrame class.
A JFrame has this constant available because it implements the interface WindowConstants. By implementing this interface, in essence, the JFrame class of objects promise to do the right thing if one of these constants is passed to a method that handles it, in this case setDefaultCloseOperation.

Our final example for this entry goes one big step further:
/* BasicJPanel.java
This is a somewhat more sophisticated drawing program.
It uses a new child of JPanel as the drawing surface
for a JFrame, to avoid the problems with drawing
directly on a JFrame.

A custom JPanel child class called BasicJPanel is created
with its own paintComponent method, which contains our
drawing code.

A generic JFrame is then created to hold the BasicJPanel
object, the BasicJPanel is created, made into the JPanel's
content pane, and our paintComponent method is called
automatically. *Whew!*
mag-28Apr2008
*/

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

public class BasicJPanel extends JPanel{

// Create a constructor method
public BasicJPanel(){
super();
}

// The following methods are instance methods.

/* Create a paintComponent() method to override the one in
JPanel.This is where the drawing happens. We don't have
to call it in our program, it gets called automatically
whenever the panel needs to be redrawn, like when it is
made visible or moved or whatever.
*/
public void paintComponent(Graphics g){
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
}

public static void main(String arg[]){
JFrame frame = new JFrame("BasicJPanel");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(200,200);

// Create a new identifier for a BasicJPanel called "panel",
// then create a new BasicJPanel object for it to refer to.
BasicJPanel panel = new BasicJPanel();

// Make the panel object the content pane of the JFrame.
// This puts it into the drawable area of frame, and now
// we do all our drawing to panel, using paintComponent(), above.
frame.setContentPane(panel);
frame.setVisible(true);
}
}

Here, we've added a JPanel inside the drawable area of our JFrame. This means that if we start drawing at 0,0 we'll actually be drawing somewhere we can see it, it won't be hidden by the window decorations.

The other big change is the change of our drawing method's name from paint() to paintComponent(). This is because we changed from a JFrame to a JPanel. If you take a look at JPanel in the API Specification you'll see that it extends JComponent. This family of objects uses paintComponent() to manage drawing.

This last example is a good starting point for any graphical operation. In future examples, I'll be extending it further to add additional features.
StumbleUpon

Thursday, July 17, 2008

Stars in import Statements

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

These are some representative import statments. Each one has an asterisk (or "star") at the end of it. What does that mean?

The asterisk is a special pattern-matching character. It matches any combination of characters (letters, numbers, or special characters.) In other words, it will match any name of any class in the package. Let's say we want to import Frame, Panel, Component, Color, Dialog, Dimension, Graphics and Image from the java.awt package for a program we're writing. We could have the following import statements:
import java.awt.Frame;
import java.awt.Panel;
import java.awt.Component;
import java.awt.Color;
import java.awt.Dialog;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Image;

Since star can take the place of any name, we can replace all of those import statements with one:
import java.awt.*;

This imports every class in java.awt. It also imports all the interfaces, exceptions, and errors defined in java.awt. It makes absolutely everything in the java.awt package available to our program.

OK, then why do we need to do this?
import java.awt.*;
import java.awt.event.*;

If the * makes us get everything in java.awt, why do we need to then go an import java.awt.event.*?

The reason is that java.awt.event is a different package than java.awt. The stuff in java.awt.event isn't actually in java.awt. With package names, the dot notation is just a way of letting us know that the stuff in java.awt.event is related to the stuff in java.awt, and that we'll probably want to use the stuff in these packages together. But java.awt.event isn't in java.awt, the way that System.out is in the class System.

Just remember, every package with its own name is a totally different package. You can tell a class name from a package name by whether it is capitalized:
import java.awt.Color;

Color is a class in the java.awt package. This is one of the reasons we follow the convention of using a capital letter at the start of a class's name. Whereas this:
import java.awt.color.*;

is an import of the classes in the java.awt.color package. These classes are not in java.awt, so you can't import them using "import java.awt.*;"

The asterisk is a "regular expression" character. It and a number of other characters are a way of building up what are called regular expressions, which are a way of matching things without using the precise name. The asterisk is a "wildcard," it can stand for any character, or any number of any characters.
StumbleUpon

Tuesday, July 15, 2008

Drawing Lines

In A Most Basic Graphics App we had the framework of a simple graphics application. We trimmed it down a little, too much really, in Start With a JFrame. The JFrame alone doesn't accomodate graphics as well as we would like. The "window decorations"--the title bar, the frame around the window, close button and so on--all cover part of our drawing area. Likewise, there are other problems that crop up on different JVMs.

So we'll use the BasicPanel.java program from A Most Basic Graphics App to build on now.

We're going to concern ourselves with the part of the program that does the actual drawing:
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)

In particular, we're going to focus on those four numbers inside the parentheses. What are they? Where do they come from? How can we pick numbers that will let us draw what we want, and what are the limits on what we can put in there?

First, let's look at what our limits are. At the low end, we have the number zero. Computers start counting at zero, and that's the low end number for what we can enter here and expect results. You can put a negative number in here, but unless you do some other things we're not going into here, negative numbers aren't going to do you any good.

For the high number, you can go up to the limits of the type, if you like. In this case we're calling drawLine(int, int, int, int), so we can go up to the limits of an int, or 2147483647, and not cause a problem so far as Java is concerned. We humans like to see our results, though. There's another line of BasicPanel we need to consider. That's this one:
frame.setSize(200,200);
This is setting the size of our JFrame (creatively named "frame") to 200 pixels wide and 200 pixels high. Since the JPanel we're drawing to is inside this JFrame, we know that the highest point we're going to see is less than this. How much less varies. It's based on how wide big the window decorations are on the JFrame, and this varies by operating system, and by the user's settings. But we definitely know that anything over 200 on the high end is going to be invisible. Higher numbers won't affect Java or your computer. You won't have a line that shoots out of its window and across your desktop if you make the numbers too high. You just won't see anything outside the JPanel area on which we're drawing.

We can find out exactly how large our drawing area is by using the getClipBounds() method of the Graphics class. Feel free to experiment with it, but for now let's get back to talking about the four numbers we use with drawLine and what they do. Just saying we have a high limit of 200 on those numbers is good enough for now.

OK, so we can use numbers from 0 to somewhere short of 200 in any of those four locations and expect results.

A Pair of Pairs

The four numbers in drawLine aren't just four numbers, they're two pairs of number. The first two numbers are the first pair, the third and fourth numbers are the second pair. Each pair of numbers is a Cartesian coordinate. If you don't remember or haven't studied this in Geometry class, don't sweat it. We'll suss things out well enough here.
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
Notice how in the comment I say we're drawing a line from (10, 10) to (150, 150). Notice the first two numbers in g.drawLine() are 10 and 10, and the second two numbers are 150 and 150. This Means Something. ;)

The first pair marks the starting point for our line, the second pair marks the ending point.

The first number in each pair says how far left or right we want that point. The second number in each pair says how far up or down we want that point.

On left and right, 0 is all the way to the left. The higher the number, the farther over to the right we'll be. In our case, we can go up to 200 (almost.) A number of about 190 will probably take us all the way to the right of our drawing area.

On up and down, 0 is all the way to the top. The higher the number, the lower we'll go. A number of about 185 or so will take us all the way to the bottom of our drawing area.

If we want to draw a line all the way across our drawing area, instead of just partway across, we can replace
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
with
g.drawLine(0,0,200,200);
This will actually "go over" the edge of our drawing area, but it won't matter. Open up BasicPanel in your editor, make this change, compile it and run it.

Fine, we've mastered drawing a line from the top left to the bottom right. We're not exactly drawing starships yet, are we?

What if we change the pairs of numbers around? Open up your editor and make this change to the drawLine() statement:
g.drawLine(200,200,0,0);
Once you compile and run, what do you see? It looks the same, right? That's because we drew a line between the same two points, we just drew from bottom right to top left this time. OK, I hear you saying "Borrrringgg!" Let's move on.

Horizontal Lines

If we want a line to be horizontal, both the up-and-down numbers need to be the same. This means the second number in each pair, the second and fourth numbers. Add the following line to BasicPanel right after your other drawLine() statement:
g.drawLine(10,50,200,50);
Compile and run, and now you have a horizontal line. Notice the second and fourth numbers are the same. If you want to move the horizontal line up or down, change the number in the second and fourth position:
g.drawLine(10,20,200,20); // A higher horizontal line
g.drawLine(0,0,200,200); // A lower horizontal line
The higher the number you put in the second and fourth positions the lower the horizontal line will be. Go ahead and add these lines to your program, one at a time, and compile and run.

Vertical Lines

Now let's try vertical lines. For these, the first and third numbers (the left-right numbers) need to be the same:
g.drawLine(50,0,50,200); // A vertical line.
Change the 50s to some other number to move the vertical line left or right.

Starting and Ending

Now we can draw multiple lines to build up objects. By starting and ending the lines at the same points, we can make them meet up, and use the individual lines to build up objects. using our vertical and horizontal lines, we can make up squares and rectangles, or draw pictures that look like they're off an Etch-a-Sketch. ;)

Open up BasicPanel and replace all the existing drawLine() statements with the following:

g.drawLine(50,20,150,20); // Draw a horizontal line from (50,20) to (150,20)
g.drawLine(150,20,150,150); // Draw a vertical line from (150,20) to (150,150)
g.drawLine(150,150,20,150); // Draw a horizontal line from (150,150) to (20,150)
g.drawLine(20,150,50,20); // Draw a vertical line from (20,150) to (50,20)
Notice how the points we use match up (look at the pairs in the comments.) The last point is the same as the first to close the box.

Now, if we just wanted to draw boxes Java actually has a way to do this more efficiently. But what we're focusing on here is coordinates and how to use them.

Play around with different points and see what effect you get. Try drawing a triangle. Try drawing different sloping lines, both ones that slope down from left to right and ones that slope up. Remember, when you slope up the point on the right is going to have a second (up-down) number lower than the point on the left.

Once you play around for a while, you'll get the hang of it. If you want a larger screen area to play with, enlarge the numbers in the setSize() statement. Try this for a start:
frame.setSize(480,480);
This will give you more room to play it. Now you can take numbers up to about 480 before they go out of view. Try using getClipBounds() to find out just how large a number you can get. If you can't get it, don't sweat it, I'll cover it in a future post, or you can do an internet search to find an example in someone else's program, or jump into a Java newbie forum and ask.
StumbleUpon

Friday, July 11, 2008

The Java Virtual Machine: Adapter Cables for Your Computer's Insides

One of the problems programmers have is that different computer systems all require different ways to program them. Each computer has its own way of doing graphics and sound, its own way to talk to the keyboard and mouse, and so on. So a program written for one system wouldn't run on another.

We used to have this problem with the hardware on computers, too. If you had a Windows computer and an Apple display, they wouldn't hook up to each other. Apple computers and PCs used different video connectors. The keyboards and mice also had different connectors. The same was true of Unix workstations. They had their own connectors for their monitors, keyboards, and so on, and the connectors for Sun workstations were different from those for HP workstations.

While the outsides of computers are pretty standard now--you can hook up a PC monitor to a Mac and vice versa, the same for USB keyboards and mice--the insides are still just as weird as the outsides used to be. Each computer maker has their own connection for programs that want to talk to graphics, sound, keyboard and mouse, and so on.

Back in the old days we could hook up hardware from different manufacturers sometimes using adapter cables. In other cases, we had adapters that not only connected from one connector to another, but also translated the electronic signals.

For programmers that want to write programs that run on lots of different computer systems, the Java Virtual Machine (JVM) is like a bundle of adapter cables between your program and the computer system it's running on. No matter what system you are on, the JVM makes it look the same to your program:

The JVM gives your program access to the host's native resources.

This is why it's called a "virtual" machine. Java provides a sort of make-believe computer that we can program for. Then the JVM makes other computer systems pretend to be that make-believe computer. So programs written for that make-believe computer will run on any computer that has the JVM on it.

In this way the JVM acts like a whole bunch of adapter cables. On a Windows system it takes the oddball connector from its graphics system and adapts it to your program so that you can use familiar graphics objects and their methods. Similarly, it adapts the sound from OS X to your program, so that you can play music or sound effects. It adapts the filesystem from Unix so that you can read and write files using the same objects and methods as you would use on Windows or OS X. And so on. The JVM adapts all the major parts of a computer to your program, so that you can wrote one program and have it run on all major computer systems, rather than having to spend your time writing it over and over for different systems.

The system isn't perfect. The biggest problem has to do with how programs are "packaged" on each of the different systems. Your program will be the same, but the way you get it to act like a native program on each system for the user varies. The program itself will be the same, but it may need a "helper" file or some other item on each host system to make it look just like a program written directly for that system.

This will typically not be a concern for you as a programmer when you're starting out. And packaging your programs for each operating systems is a lot less work than learning all the ins and outs of how to program each system (or even just one of the systems.)

The JVM is such a useful tool that languages other than Java are being written to take advantage of it. Jython, for example, is a version of the python language that's written to use the JVM. It lets you write python programs that will run on any system with a JVM on it. Groovy is another such language. There's a long list of languages that run on the JVM in addition to Java.
StumbleUpon

Thursday, July 10, 2008

The void Type

'Pierre


void can be the most confusing type. It's an odd word to start with. It's part of the long string of words that appear before the word main in the declaration of that method.

Void means 'empty' or 'nothing'. In the case of a Java method, it means that that method returns nothing:

public void drawTriangle(){ ...

This is as opposed to a method with another type, which returns an object of that type:

public int sum(int a, b){
return a + b;
}

This returns an int object to the caller:

int count1, count2, amt;
...
amt=sum(count1, count2);

Why would you want a method that returns nothing? Because often you have methods that do something that doesn't affect the state of the program itself. Drawing something is an example of this. A method that draws something makes its results obvious in what it draws. It doesn't need to pass any information back to the other parts of the program. Instead it is expressing the state of the program to the outside world.
StumbleUpon

Tuesday, July 8, 2008

The Code Code: Source, Object, and Byte Code

So what are all these "codes" that keep getting discussed? Here's a guide:

Code: a general term to refer to the program text. When it isn't preceded by a word like 'object' or 'byte' it usually refers to the human-readable code, also called 'source code.'

Source Code: The human-readable stuff you type in. Well, sort of human-readable if you ignore all the odd punctuation that makes your Java files look like something written in one of those languages that includes clicks, grunts, and squeals. Java source code lives in files with .java on the end.

Object Code: Normally this refers to a program in a form that the host system can run directly. For example, C source code is fed into a C compiler/linker which produces an object code file that can be run on the host system directly (No virtual machine like Java's JVM.) In the case of Java, however, the term tends to get used to refer to Bytecode. This use of the word "object" has nothing to do with Objects in Java or object-oriented programming.

Byte Code or Bytecode: This is what the javac compiler produces. It is code in a form runnable by the Java Virtual Machine (JVM.) The host computer can't run it directly (unless you've got a really specialized computer system.) It lives in files with .class on the end.

In Java, the stuff you write and give to the compiler is source code.

The stuff the compiler writes out (if your program has no errors) is bytecode.

StumbleUpon

Monday, July 7, 2008

Java Graphics--Start with a JFrame

Jerry introduces Pierre to the JFrame
In A Most Basic Graphics App I presented a skeleton program that's suitable as a starting point for a graphics application. It deserves some explanation before we add more to it.

There are two graphics "components" that appear in this program, a JPanel and a JFrame. Why use both? If we want a really basic graphics app, why isn't one or the other enough?

If we're going to choose between the two, we'd have to take the JFrame. A Frame component is a special graphics component that lives on top of the host computer's graphics system. In Java it's called a "heavyweight" component. The "backboard" on which you draw, or place other components, has to be a heavyweight component. Only a heavyweight component can be guaranteed to be drawn correctly when placed directly on the user's display. Lightweight components have to be placed on top of a heavyweight component.

Since JPanel is a lightweight component, we can't use it without a heavyweight like JFrame to place it on. So if we're just picking one component, it's going to be the JFrame:

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

public class JustaFrame extends JFrame{

public JustaFrame(){
super();
}

public void paint(Graphics g){
g.drawLine(10,10,150,150);
}

public static void main(String[] arg){
JustaFrame frame = new JustaFrame();

frame.setSize(200,200);
frame.setVisible(true);
}
}

You'll notice a problem here if you run the program. The "window decorations" for the title bar, window borders, and so on take away a piece of the space from the drawing area. Unless you've got pretty narrow title bars on your system, the line drawn by this program will start up underneath the title bar.

It's possible to find out how much space these items take up, and compensate. Or you can add another component in the visible drawing area as I did with the JPanel in the original program.

There's another difference here. The drawing is done by a paint() method, rather than a paintComponent() method. This is part of the difference between different types of components. If you change paint() into paintComponent() this program will compile and run, but it won't draw the line.

Later, we'll talk about the magic behind the paint() and paintComponent() methods and some of the other hidden mysteries of Java's graphics.
StumbleUpon

Sunday, July 6, 2008

Parens and Brackets and Braces, Oh My!

If you paid attention in English class when they were discussing the use of parentheses, curly braces, square brackets and so on I'm afraid it won't do you much good in Java. Java has a specific use for each of these, and it definitely pays to get then sorted out.

Knowing the names for each of the symbols is a good starting point:

{ } are curly braces.
( ) are parentheses (one is called a parenthesis.) Parens or paren for short.
[ ] are square brackets.
< > are called angle brackets. They're the same characters as the less than and greater than signs.

The first one of any pair is called the "opening" item; opening curly brace, opening parenthesis, etc. The second of a pair is called the "closing" item; closing square bracket, closing paren, and so on.

{ }
We discussed curly braces in Code Blocks, and mentioned briefly that they are a form of divider in Java in Those Pesky Semicolons. Curly braces mark the start and end of a code block.

Hold the phone! There's another use of curly braces. They can also be used to enclose a list that is used as an array initializer. For example:
int nums[] = {1, 2, 3};
This line declares an array named nums[] and initializes its first three elements to values 1, 2, and 3.

( )
Parentheses happen a lot in Java. They mark the start and end of the parameter list of a method. This includes both constructor methods and instance methods. The parameter list contains the information that is passed to the method to let the method do its job. If the method doesn't need any information, the parens are still there, there's just nothing between them: println(). A pair of parens at the end of a name is an easy way of identifying a method.

[ ]
Square brackets are used to enclose the "indexing expression" of an array. If you see square brackets, it's an array.

< >
When <> are not playing the part of "less than" and "greater than" they enclose the indexing expression of a collection. Collections are like arrays but considerably more flexible in the things they can do. Consider them as a sort of "super array."

There you are. Now you're prepared to punctuate your Java programs with the best of them, and hopefully you'll be able to read Java programs more easily. If you get into a dispute with your English teacher over these symbols, though, you're on your own!
StumbleUpon

Thursday, July 3, 2008

Constructor Methods

A constructor method is a method that creates an object. To create the object, it uses the class as a sort of blueprint for what member variables the object has, what instance methods, and so on.

The name of a constructor method is the same as the name of the class. For example, if we have a class named Dragon its constructor will be named Dragon as well:
public class Dragon{

  public Dragon(){
    super();
  }
}

There are a couple of things to notice here. One is that, unlike a regular method, the first character is upper-case, just like the class name. The constructor name must exactly match the class name. While it is only a convention that classes (and therefore, their constructor methods) start with a capital letter, it is an iron-clad requirement that the constructor name match the class name.

The other thing you'll want to notice is that there's no type given in the method declaration. A normal method (called an instance method, if we want to get formal) has a type provided in its declaration, just as a variable has a type in its declaration:
public void dragon(){ }    // Instance Method.
public int dragonCount;    // Instance Variable.
public class Dragon{ }    // Class.
public Dragon(){ }    // Constructor.
In the constructor's declaration, there's a scope called out (public) but no type. This is because, as a constructor for the object, it will be returning an object of the type it is a constructor for. OK, that sounds worse than it is. Let's try again...

A Dragon constructor returns a Dragon object. A String constructor returns a String object. That's what it constructs, so that's what it returns. Declaring a type would be redundant:
public Dragon Dragon(){ }    // This is NOT correct code, just an example of silliness!

A Subtle Error

If you accidentally have a typo in your program that results in your class and constructor having different names, the compiler will complain that you've got a method without a type declaration. You'll look at the code and say "Hey! That's a constructor. It doesn't need a type declaration! What is my compiler smoking?"
public class Dragon{

public Dragin(){
super();
}
}

Dragon.java:3: invalid method declaration; return type required
public Dragin(){
^
1 error

What's happening here is that the compiler sees that the name of the method is different from the name of the class. Aha, it says, this isn't a constructor since it doesn't have the same name as the class. So it must be an instance method. Hey, instance methods need a type! There's no type! Then it prints the error message.

Note that spelling errors include capitalization. So having a class named Dragon with a constructor called dragon() would cause the same error.

For more about constructor methods, see Multiple Constructor Methods.
StumbleUpon

Wednesday, July 2, 2008

A Most Basic Graphics App

Here's a simple graphics application in Java. It's about as simple as you can get while doing graphics.


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

public class BasicPanel extends JPanel{

// Create a constructor method
public BasicPanel(){
super();
}

public void paintComponent(Graphics g){
g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150)
}

public static void main(String arg[]){
JFrame frame = new JFrame("BasicPanel");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(200,200);

BasicPanel panel = new BasicPanel();
frame.setContentPane(panel);
frame.setVisible(true);
}
}

Key points to note:
The line that reads g.drawLine(10,10,150,150); // Draw a line from (10,10) to (150,150) is the line that does the actual drawing. If you want to draw something else, or draw more things, replace this line with your own statements or add additional statements after this line. To see what you can do, check out the Graphics class in the Java API reference.

All of the items in blue,BasicPanel, need to match. You can just as well make it Foodle, but all of these need to match since this is the name of your class (and program.) Note that if you change it to Foodle, you need to save it in a file called Foodle.java, just as the file above needs to be saved in a file named BasicPanel.java

If you want to change the size of the window, change the 200,200 in the line reading frame.setSize(200,200); to some other number. Smaller numbers will make a smaller window, bigger numbers make a bigger window. The first number is how many pixels across it will be, the second number is how many pixels high it is.

Enjoy!

Technorati Profile
StumbleUpon

The Basic Program Skeleton

The basic skeleton of a Java application goes as follows:

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

Your Program Goes Here

}
}

YourProgramName gets replaced by your actual program's name. The program must be stored in a file named YourProgramName.java

The actual code for your program goes in place of Your Program Goes Here.

More complicated programs have more to them than this. For example, you should have your own classes in their own files that contain most of your program logic if you are writing a long program. But this is the most direct and basic structure for a Java program.

The word arg can be whatever you choose to make it, by the way. If your program needs to get information from the system environment, just make sure that the name is the same as what you use in your program.
StumbleUpon

Tuesday, July 1, 2008

Mini-Review: Beginning Programming in Java for the Absolute Beginner, 2nd edition, by John P. Flynt, Ph.D.




For non-programmers looking to make the transition to becoming a programmer, this book is a fine place to start. It works well as both a self-study text, and as a classroom textbook.

There aren't a lot of Java books out there written to teach the language to non-programmers. In many ways the Java language was created for C programmers, and most of the available books are written for the same audience--programmers familiar with C or C++. To my knowledge, there are presently only two books that are generally available intended to teach Java to the non-programmer. Edit: since this was written, several more books of this type have come out. The situation is far better now!

The First Step is Always the Hardest

As appropriate for a beginner's book, this book starts with a fair amount of detail on how to get set up and get started. It's challenging to strike the right balance with this material, some beginners get up and running with a minimum of effort, others run into trouble from unanticipated sources--leaving them in a position where almost no amount of information seems like enough. I think this book strikes a good balance, referring to external sources for supplemental material. Best of all, it maintains a platform-agnostic approach. You would think this is a given in a book teaching a platform-agnostic language, but it's not.

As appropriate for a beginner's book, the book teaches the principles of programming first, and Java second. The exercises of the seven chapters take the form of console, or command-line applications. Graphical applications are introduced about 2/3rds of the way through the book, in chapter 8. Most of the examples take the form of simple games.

The book teaches the basics of programming--variables, operators, flow control and such--in the first four chapters. The pacing of this material is very good, it teaches enough to not only cover the absolute core but some of the extra twists, and moves through it before it becomes tedious. Chapters five through seven get into object-oriented programming. The placement of this material in the book is great, going any further without introducing the material would be a bad idea, and any sooner would have been confusing to non-programmers.

Comprehensive Coverage

Overall the book covers a lot of ground. Someone working through this book from beginning to end is going to come out with a strong knowledge of a lot of Java. Each chapter ends with a number of exercises, which are essential additions to the examples in the text for the student to have the ability to really synthesize the information and go from program copier to a writing their own programs.

The breadth of the coverage is one of the books' strongest points. The material is well-paced, and the many complete examples of working programs are a huge advantage over the snippets that many books rely on. Exception handling, class creation, and many other subjects are covered. About the only thing I could ask for that isn't here is a brief introduction to threads, but I wouldn't even consider the idea of adding this if the book wasn't already so comprehensive.

Errata

One of the problems this book has is the typos in the program text. They are not numerous, and often even beginners can see the flaws once they know to look for them. They aren't common, only a few of the programs have errors in them. But they can be frustrating when they occur for those who are learning on their own.

Reaching Too Far?

Some of the examples try to do a bit too much, too. Rather than concentrating on one key point they add several new items at once. The centerpiece of each program is always the subject of the lesson, but additional little items get slipped into the examples. It's also worth noting that the examples that use special characters don't account for the configuration of the Terminal in Mac OS X that interferes with using these characters in the same fashion as on other platforms.

The later examples in the book also tend to get quite long. This results in a lot of typing by the beginner before they see any results. Likewise, this ties into the problem with many exercises not concentrating on the specific subject of the lesson. Particularly when graphics are introduced, I would have liked to see very short, focused examples that do only the absolute minimum to open a window and do some drawing, then add other interaction (such as the mouse, keyboard shortcuts, widgets, etc.) piecemeal. I ended up using my own example programs in my class to introduce graphics, and it went considerably smoother than I have had it go with students that followed the book alone. (I will be posting these examples in this blog when I get into graphics.) I would also like to have seen graphics introduced earlier in the book, allowing more examples to use graphics. This would also start the student making what look like "real applications" in the modern environment earlier in the learning process.

Summary

I feel this is a great book for a new programmer. Further, Java is a great language for a new programmer. Groovy may be better, but the resources available for a beginning programmer are still slim at this point, and I haven't actually had the experience of teaching it to beginners yet. Edit: There are many other languages that run on the JVM now, the others that can access the graphics and sound facilities natively (rather than through special calls to access Java syntax) would also be good candidates.

Final Grade: 85%, B

Pros:
Good material and pacing, (mostly) fun examples.
Covers lots of Java, and does it well.
Platform-agnostic.

Cons:
Typos in examples.
Discussion gets dry in places.
Examples in the later parts of the book are long and do too much at once.

Recommendation:
Buy if you're a non-programmer looking to become a programmer and want to do it with just one book. If you're willing to work out of more than one book, you may also want to consider Beginning Programming with Java for Dummies by Brad Burd (I'll be posting a mini-review of this book soon.) This also makes a good textbook for teachers looking for a class textbook thanks to the organization of the book and the chapter exercises.

StumbleUpon