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.
Showing posts with label reference. Show all posts
Showing posts with label reference. Show all posts
Sunday, March 20, 2011
Friday, August 13, 2010
Multiple Constructor Methods
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.
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:
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:
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.
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.
Wednesday, July 1, 2009
Greenfoot Java Programming Book
There's a book on programming in Java with Greenfoot coming out soon.
You can see a preview at the book's site, along with resources for students and teachers.
This book isn't just for class use. Greenfoot is a great way to learn to use Java. You can learn the basics of programming with graphics and sound that are far easier to use than in standard Java. Greenfoot and BlueJ both illustrate basic concepts of Object Oriented programming in a way that makes them clearer than any other method I've seen. You can deal with objects as objects, see what their member methods and fields are, and use them outside the program itself.
So, if you're in a class or self-taught, I recommend using Greenfoot along with the online resources, and this book. The book can be completed in a short time and leave you ready to write your own programs with Greenfoot, or move on to using Java without Greenfoot if you wish.
You can see a preview at the book's site, along with resources for students and teachers.
This book isn't just for class use. Greenfoot is a great way to learn to use Java. You can learn the basics of programming with graphics and sound that are far easier to use than in standard Java. Greenfoot and BlueJ both illustrate basic concepts of Object Oriented programming in a way that makes them clearer than any other method I've seen. You can deal with objects as objects, see what their member methods and fields are, and use them outside the program itself.
So, if you're in a class or self-taught, I recommend using Greenfoot along with the online resources, and this book. The book can be completed in a short time and leave you ready to write your own programs with Greenfoot, or move on to using Java without Greenfoot if you wish.
Friday, August 8, 2008
Reference Types: Names and Objects
When we learned about primitive variables we learned that they are a way of storing a simple value, like a number or a true-false state. We give them a name, and whenever we want to get that value we use that name. Whenever we want to change the value that's stored, we set the name equal to the new value:
When we use objects, we're using a more complex kind of variable. We don't do it for the sake of complexity, but because adding some complexity here makes things a lot simpler elsewhere in our program. A lot simpler.
Object variables are called "reference types", the type is actually the class that the object belongs to. The difference between a reference variable and a primitive variable is that a primitive variable actually is a storage location in computer memory that holds the stored information. A reference variable is a name that names a specific type of information. It doesn't actually hold the information, it's just associated with an object that actually holds the information.
This why there's a two step process in creating a Java variable. The first step, declaration, sets up a name we're going to use for a particular type of object. The second step, initialization, associates that name with an object--creating a new object if necessary.
Let's say I'm talking to a friend. I say, "I'm going to get a hamster and call it Wilmot."
"That's nice," says the friend. "Can I see Wilmot?"
"I don't have him yet."
"What color is Wilmot?"
"I don't know, I don't have a hamster yet."
Then I go to the pet store and pick up a hamster. I call him Wilmot, put him in a cage and take him home. I've now initialized the name Wilmot I declared to my friend earlier to point to a specific hamster.
Now when my friend says "Can I see Wilmot?" I can show him a hamster, and say "This is Wilmot." When he wants to know the color, there is an object to get the color of.
In Java terms, if I had a Hamster class, I could declare a name like this:
I now have a name for a Hamster object, but no Hamster. I can initialize the reference variable by getting a new Hamster object using the class's constructor, Hamster():
Now I have a Hamster object associated with the name. The name references the Hamster object that's been created. Hence the term "reference variable".
Now, if I create a new name and make it point to the same Hamster object, it becomes a new name for the same object:
Now, if I make any changes to fluffy they also happen to wilmot. For example, if wilmot's size is 10cm, and I set fluffy's size to 12cm, then get wilmot's size it will be 12cm.
This is different from what happens with primitive variables. If I do the same thing with a pair of primitive variables like this:
Then the output will be:
With a primitive variable, when we set it equal to another primitive we get a copy of the value in that primitive's own storage. When we set a reference variable equal to another reference variable, we are now referring to the same object as the other reference variable. In pet terms, it's like giving our hamster a second name. We might call it wilmot or fluffy, but they're both the same hamster.
If we need to have each name apply to a different hamster, we need to go back to the pet store for another hamster. In Java, we need to use the constructor to get another Hamster object:
But what if we want it to act like a primitive object? What if we want a copy of wilmot to make changes to without affecting wilmot? Then we use a method of the object's class to create a new object that's a copy of that object. Usually this will be clone():
Now fluffy is a copy of wilmot, and we can make changes to fluffy without affecting wilmot. Note: whether a class has the clone() method varies from class to class. Normally, if the class implements the Clonable interface then it has a clone() method that works this way.
int value; //Declare an integer variable named value.
value=100; // Store the number 100 in value.
System.out.println(value); // Print the number in value, "100"
value=20; // Put 20 in value. Over-writes the 100.
count=value; // Gets the number from value and puts
// it in count.
// Assumes 'count' was declared as an int before.
When we use objects, we're using a more complex kind of variable. We don't do it for the sake of complexity, but because adding some complexity here makes things a lot simpler elsewhere in our program. A lot simpler.
Object variables are called "reference types", the type is actually the class that the object belongs to. The difference between a reference variable and a primitive variable is that a primitive variable actually is a storage location in computer memory that holds the stored information. A reference variable is a name that names a specific type of information. It doesn't actually hold the information, it's just associated with an object that actually holds the information.
This why there's a two step process in creating a Java variable. The first step, declaration, sets up a name we're going to use for a particular type of object. The second step, initialization, associates that name with an object--creating a new object if necessary.
Let's say I'm talking to a friend. I say, "I'm going to get a hamster and call it Wilmot."
"That's nice," says the friend. "Can I see Wilmot?"
"I don't have him yet."
"What color is Wilmot?"
"I don't know, I don't have a hamster yet."
Then I go to the pet store and pick up a hamster. I call him Wilmot, put him in a cage and take him home. I've now initialized the name Wilmot I declared to my friend earlier to point to a specific hamster.
Now when my friend says "Can I see Wilmot?" I can show him a hamster, and say "This is Wilmot." When he wants to know the color, there is an object to get the color of.
In Java terms, if I had a Hamster class, I could declare a name like this:
Hamster wilmot;
I now have a name for a Hamster object, but no Hamster. I can initialize the reference variable by getting a new Hamster object using the class's constructor, Hamster():
wilmot=new Hamster();
Now I have a Hamster object associated with the name. The name references the Hamster object that's been created. Hence the term "reference variable".
Now, if I create a new name and make it point to the same Hamster object, it becomes a new name for the same object:
Hamster fluffy;
fluffy=wilmot;
Now, if I make any changes to fluffy they also happen to wilmot. For example, if wilmot's size is 10cm, and I set fluffy's size to 12cm, then get wilmot's size it will be 12cm.
This is different from what happens with primitive variables. If I do the same thing with a pair of primitive variables like this:
int value, count;
value=100; // Initialize value to 100;
count=value; // Set count equal to value.
count=count-20; // Subtract 20 from count.
// We could have said 'count-=20;', too.
System.out.println("value= " + value); // Print value.
System.out.println("count= " + count); // Print count.
Then the output will be:
value= 100
count= 80
With a primitive variable, when we set it equal to another primitive we get a copy of the value in that primitive's own storage. When we set a reference variable equal to another reference variable, we are now referring to the same object as the other reference variable. In pet terms, it's like giving our hamster a second name. We might call it wilmot or fluffy, but they're both the same hamster.
If we need to have each name apply to a different hamster, we need to go back to the pet store for another hamster. In Java, we need to use the constructor to get another Hamster object:
Hamster wilmot, fluffy;
wilmot=new Hamster();
fluffy=wilmot; // fluffy and wilmot are now both names
// for the same Hamster object. Anything we do to fluffy
// will also apply to wilmot, and vice versa.
fluffy=new Hamster();
// Now fluffy applies to a different Hamster object.
// We can make changes to fluffy and
// they won't affect wilmot. We now have two
// Hamster objects, each with its own name
// to refer to it.
But what if we want it to act like a primitive object? What if we want a copy of wilmot to make changes to without affecting wilmot? Then we use a method of the object's class to create a new object that's a copy of that object. Usually this will be clone():
Hamster wilmot, fluffy;
wilmot=new Hamster();
fluffy=wilmot.clone();
Now fluffy is a copy of wilmot, and we can make changes to fluffy without affecting wilmot. Note: whether a class has the clone() method varies from class to class. Normally, if the class implements the Clonable interface then it has a clone() method that works this way.
Friday, July 25, 2008
Killer Java IDEs for Beginners: BlueJ
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.
Friday, June 27, 2008
import Statements
An import statement is a way of making more of the functionality of Java available to your program. Java can do a lot of things, and not every program needs to do everything. So, to cut things down to size, so to speak, Java has its classes divided into "packages." Your own classes are part of packages, too.
No import Needed
The simple Hello.java program we've used as an example so far doesn't have any import statements:
Everything in the program is already available to the compiler. The compiler can access any class in the java.lang package without needing an import statement. It can also access any classes in the "local" package, which is any classes defined in files in the same directory as the program being compiled that aren't part of another package (that is, they don't have a package statement at the start of the file.)
import Required
Anything that isn't in the java.lang package or the local package needs to be imported. An example is the Scanner class. If you look up the Scanner class in the Java API Specification, you'll see that it is in the java.util package. Remember, to look it up you scroll to the class name in the lower left frame then click on it to bring up its definition in the main frame of the browser. Class names are in regular typeface, interfaces are in italics (some classes and interfaces have the same name.)
Here's an example program that uses Scanner, with an import statement:
We imported just the class Scanner from java.util in the import statement in this program. If we'd been using multiple classes from java.util, we could have made all the classes in java.util available to us by using this import statement:
import java.util.*;
The * is a "regular expression operator" that will match any combination of characters. Therefore, this import statement will import everything in java.util. If you have tried entering and running the example program above, you can change the import statement to this one.
If we need multiple classes from different packages, we use an import statement for each package from which we need to import classes (or interfaces, or any other part of that package we need.) It's not unusual to see a series of import statements near the start of a program file:
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import javax.swing.*;
import javax.swing.event.*;
Now, you may wonder why we have statements importing java.awt.* and java.awt.event.*. It seems like if you import java.awt.* that ought to import everything "under" java.awt, right? And the "dot" notation sure makes it look like java.awt.event is under java.awt.
Package Names and Those Misleading Dots
The thing is, each package with its own name is an entirely separate entity. The dot notation and name similarities are just a convention for making it easier to keep track of which packages have functions that are related to each other. One package isn't inside another one. java.awt.event is an entirely separate package from java.awt, it's not inside java.awt.
This can be very confusing, since the other use of the "dot notation" is a way of getting to something that is "inside" or a member of something else. System.out.println() is a way of getting at the println() method that's a member of out which is a member of the System class. But it doesn't work that way with packages. Each package name is a whole different package, and each package needs its own import statement. java.awt.event is entirely different from java.awt.
You can see package names in the API reference in the upper left frame. If you click on a package name, the lower left frame with change to limit what it shows to just the items in the package you've clicked.
No import Needed
The simple Hello.java program we've used as an example so far doesn't have any import statements:
public class Hello{
public static void main(String arg[]){
System.out.println("Hello.");
}
}
Everything in the program is already available to the compiler. The compiler can access any class in the java.lang package without needing an import statement. It can also access any classes in the "local" package, which is any classes defined in files in the same directory as the program being compiled that aren't part of another package (that is, they don't have a package statement at the start of the file.)
import Required
Anything that isn't in the java.lang package or the local package needs to be imported. An example is the Scanner class. If you look up the Scanner class in the Java API Specification, you'll see that it is in the java.util package. Remember, to look it up you scroll to the class name in the lower left frame then click on it to bring up its definition in the main frame of the browser. Class names are in regular typeface, interfaces are in italics (some classes and interfaces have the same name.)
Here's an example program that uses Scanner, with an import statement:
import java.util.Scanner;
public class ScannerTest{
public static void main(String arg[]){
// scanner gets its input from the console.
Scanner scanner = new Scanner(System.in);
String name = "";
// Get the user's name.
System.out.print("Your name, adventurer? >");
name = scanner.next();
System.out.println();
// Print their name in a a message.
System.out.println("Welcome, " + name + " to Javaland!");
}
}
We imported just the class Scanner from java.util in the import statement in this program. If we'd been using multiple classes from java.util, we could have made all the classes in java.util available to us by using this import statement:
import java.util.*;
The * is a "regular expression operator" that will match any combination of characters. Therefore, this import statement will import everything in java.util. If you have tried entering and running the example program above, you can change the import statement to this one.
If we need multiple classes from different packages, we use an import statement for each package from which we need to import classes (or interfaces, or any other part of that package we need.) It's not unusual to see a series of import statements near the start of a program file:
import java.awt.*;
import java.awt.event.*;
import java.util.*;
import javax.swing.*;
import javax.swing.event.*;
Now, you may wonder why we have statements importing java.awt.* and java.awt.event.*. It seems like if you import java.awt.* that ought to import everything "under" java.awt, right? And the "dot" notation sure makes it look like java.awt.event is under java.awt.
Package Names and Those Misleading Dots
The thing is, each package with its own name is an entirely separate entity. The dot notation and name similarities are just a convention for making it easier to keep track of which packages have functions that are related to each other. One package isn't inside another one. java.awt.event is an entirely separate package from java.awt, it's not inside java.awt.
This can be very confusing, since the other use of the "dot notation" is a way of getting to something that is "inside" or a member of something else. System.out.println() is a way of getting at the println() method that's a member of out which is a member of the System class. But it doesn't work that way with packages. Each package name is a whole different package, and each package needs its own import statement. java.awt.event is entirely different from java.awt.
You can see package names in the API reference in the upper left frame. If you click on a package name, the lower left frame with change to limit what it shows to just the items in the package you've clicked.
Monday, June 23, 2008
The Java Language Manual
The Java language itself, as opposed to the classes, interfaces, and so on, is defined in the Java language specification, which can be found online. You can either view the online HTML version, or download a copy to your own system in several formats from this location:
http://java.sun.com/docs/books/jls/
This describes how Java programs are put together. It's not an easy read, it's written for compiler implementors more than it's written for programmers.
Look for "API, Language, and Virtual Machine Documentation", the link to view or download this document is in that section, titled "The Java Language Specification."
There are a few items of clarity in the document, like the section on Blocks (code blocks.)
For most programmers, especially beginners, the time to refer to this document is when you have a specific question in mind about some code you're writing that doesn't seem to want to compile. If you take a look at it occasionally, however, looking up things that you do understand and feel like you've got a handle on, it'll start making sense. Then you'll be able to make more use of it as your Java programming ability grows.
http://java.sun.com/docs/books/jls/
This describes how Java programs are put together. It's not an easy read, it's written for compiler implementors more than it's written for programmers.
Look for "API, Language, and Virtual Machine Documentation", the link to view or download this document is in that section, titled "The Java Language Specification."
There are a few items of clarity in the document, like the section on Blocks (code blocks.)
For most programmers, especially beginners, the time to refer to this document is when you have a specific question in mind about some code you're writing that doesn't seem to want to compile. If you take a look at it occasionally, however, looking up things that you do understand and feel like you've got a handle on, it'll start making sense. Then you'll be able to make more use of it as your Java programming ability grows.
Saturday, June 21, 2008
Java's Reference Manual
Java has a peculiar name for the reference where you look up Java classes and their methods and member variables. It's called the "API Specification." If you want to know what something does, or how to use it, you look it up in the Java API Specification for the version of Java that you're using.
The online home of these Java language reference manuals is at http://download.oracle.com/javase/
Look for the link here to "API Specification."
Here are direct links for several versions of Java in current use:
Java SE 5.0 (a.k.a. Java 1.5.0): http://download.oracle.com/javase/1.5.0/docs/api/
Java SE 6: http://download.oracle.com/javase/6/docs/api/
Java SE 7: http://download.oracle.com/javase/7/docs/api/
Your Java Version
To find the version of Java that you're using, open a Terminal or Command Line window and enter the command "java -version" (without the quotes, of course.) It will print out something like this:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
The key item here is the information in the quotes in the first line, "1.5.0_13". For the purposes of figuring out which version of the API specification we want to be referring to, we look at the digits before the underscore. In this case, "1.5.0" is the part that's important to us. For this version of Java, we'd select the link for J2SE 1.5.0.
Another approach that's simpler is to simply go to the most recent API reference. Within the API reference, it lists what version of Java each feature appeared. You want to check that on each item before you dig into reading about what cool things it can do--it's terrible to spend a bunch of time reading about a class and methods that solve your programming problem only to have your compiler reject it because you're using a version that doesn't have that feature yet!
You also want to make sure that your compiler version matches your JVM version. "java -version" gives you the version of your JVM (Java Virtual Machine) a.k.a. Java Runtime Environment (they're not exactly the same thing, but close enough for this discussion and the terms JVM and JRE tend to get used interchangeably.)
To get your compiler version, enter the command "javac -version" at the Command Line or command prompt of your Terminal window. Some versions may want you to enter "javac --version" instead of "javac -version", so if you get a big long error message instead of a version message, try using two dashes (or read the usage message and see what it says, it may want "javac -v" or something.)
If your compiler version is newer than your JVM version, you'll want to follow the instructions for your system to point it to the newer JVM as a default so that you are interpreting your programs with the same version of Java that you are compiling it with. Your Java compiler may be compiling code that your JVM can't run, otherwise! The Java Development Kit (JDK), which contains the compiler, also has a JRE bundled with it that matches the version of the compiler. So you shouldn't have to download any updates to get a JRE that matches your compiler, you just have to let your system know which version of the JRE you want it to run.
How this is done varies between different operating systems, so consult the online information on how to do this for your OS or distro.
If your JRE is a newer version than your compiler, you'll probably want to update your compiler so that you can take advantage of all the features of your JVM. Once again, this is a system-specific process.
Looking Things Up in the Java API Specification
Once you're at the correct API specification (say language reference manual or library reference in your mind) you can find a list of classes on the lower left hand side (in the frames view.) Chances are you don't know what package the classes are in that you want to look up, at least at first, so scanning through the long alphabetic list of class names is usually the place to start. There are also names in italic, these are names of interfaces.
Let's say we want to look up System.out.println() which has appeared in many of our examples here. The class name is System, so we click on System in the lower left hand frame. This makes the documentation page for System appear on the right side frame.
Above the words "Class System" you'll see the name of the package that System is part of, java.lang. Click on java.lang in the upper left hand frame and you'll see that it updates the lower left frame to show a much shorter list, a list of the interfaces, classes, enums, and errors that are part of the java.lang package. It's worthwhile to remember the package your commonly used classes are part of, for this and other reasons.
We wanted to look up System.out.println(). Back on the main frame on the right side of the window we can scroll down a little to see the Field Summary, where out is listed. This field, or member variable, is System.out. Click on out.
out is a PrintStream object, which means that it has all the methods of the PrintStream class, among other things. Below its verbose description is a set of links to PrintStream methods, including PrintStream.println(). Click on this link now.
This takes you to a list of different versions of the println() method, which do different things depending on what sort of data is inside the parentheses. In the examples we've been using so far, we've been using "System.out.println("Hello")" so we've been putting String data inside the parens ("Hello").
If we scroll down a bit we see println(String x), which tells us what the expected behavior is for a call of println() with a string inside the parens.
Try looking up some other classes and methods. For example, take a look at what the Scanner class can do.
The online home of these Java language reference manuals is at http://download.oracle.com/javase/
Look for the link here to "API Specification."
Here are direct links for several versions of Java in current use:
Java SE 5.0 (a.k.a. Java 1.5.0): http://download.oracle.com/javase/1.5.0/docs/api/
Java SE 6: http://download.oracle.com/javase/6/docs/api/
Java SE 7: http://download.oracle.com/javase/7/docs/api/
Your Java Version
To find the version of Java that you're using, open a Terminal or Command Line window and enter the command "java -version" (without the quotes, of course.) It will print out something like this:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
The key item here is the information in the quotes in the first line, "1.5.0_13". For the purposes of figuring out which version of the API specification we want to be referring to, we look at the digits before the underscore. In this case, "1.5.0" is the part that's important to us. For this version of Java, we'd select the link for J2SE 1.5.0.
Another approach that's simpler is to simply go to the most recent API reference. Within the API reference, it lists what version of Java each feature appeared. You want to check that on each item before you dig into reading about what cool things it can do--it's terrible to spend a bunch of time reading about a class and methods that solve your programming problem only to have your compiler reject it because you're using a version that doesn't have that feature yet!
You also want to make sure that your compiler version matches your JVM version. "java -version" gives you the version of your JVM (Java Virtual Machine) a.k.a. Java Runtime Environment (they're not exactly the same thing, but close enough for this discussion and the terms JVM and JRE tend to get used interchangeably.)
To get your compiler version, enter the command "javac -version" at the Command Line or command prompt of your Terminal window. Some versions may want you to enter "javac --version" instead of "javac -version", so if you get a big long error message instead of a version message, try using two dashes (or read the usage message and see what it says, it may want "javac -v" or something.)
If your compiler version is newer than your JVM version, you'll want to follow the instructions for your system to point it to the newer JVM as a default so that you are interpreting your programs with the same version of Java that you are compiling it with. Your Java compiler may be compiling code that your JVM can't run, otherwise! The Java Development Kit (JDK), which contains the compiler, also has a JRE bundled with it that matches the version of the compiler. So you shouldn't have to download any updates to get a JRE that matches your compiler, you just have to let your system know which version of the JRE you want it to run.
How this is done varies between different operating systems, so consult the online information on how to do this for your OS or distro.
If your JRE is a newer version than your compiler, you'll probably want to update your compiler so that you can take advantage of all the features of your JVM. Once again, this is a system-specific process.
Looking Things Up in the Java API Specification
Once you're at the correct API specification (say language reference manual or library reference in your mind) you can find a list of classes on the lower left hand side (in the frames view.) Chances are you don't know what package the classes are in that you want to look up, at least at first, so scanning through the long alphabetic list of class names is usually the place to start. There are also names in italic, these are names of interfaces.
Let's say we want to look up System.out.println() which has appeared in many of our examples here. The class name is System, so we click on System in the lower left hand frame. This makes the documentation page for System appear on the right side frame.
Above the words "Class System" you'll see the name of the package that System is part of, java.lang. Click on java.lang in the upper left hand frame and you'll see that it updates the lower left frame to show a much shorter list, a list of the interfaces, classes, enums, and errors that are part of the java.lang package. It's worthwhile to remember the package your commonly used classes are part of, for this and other reasons.
We wanted to look up System.out.println(). Back on the main frame on the right side of the window we can scroll down a little to see the Field Summary, where out is listed. This field, or member variable, is System.out. Click on out.
out is a PrintStream object, which means that it has all the methods of the PrintStream class, among other things. Below its verbose description is a set of links to PrintStream methods, including PrintStream.println(). Click on this link now.
This takes you to a list of different versions of the println() method, which do different things depending on what sort of data is inside the parentheses. In the examples we've been using so far, we've been using "System.out.println("Hello")" so we've been putting String data inside the parens ("Hello").
If we scroll down a bit we see println(String x), which tells us what the expected behavior is for a call of println() with a string inside the parens.
Try looking up some other classes and methods. For example, take a look at what the Scanner class can do.
Subscribe to:
Posts (Atom)
Posts
