When you compile your first program, the compiler may seem like a big scary thing, waiting to point out your mistakes and spit on your carefully constructed code. But really, Mr. Compiler is your friend, and he's trying to help you understand how to write better Java code. Unfortunately, he really stinks at the whole explanation thing.
When Mr. Compiler compiles your code without any problem, the result looks like this:
-------------------- Process completed.
In JCreator, this shows up in a pretty little window called "Build Output" which is usually found at the bottom of your screen, unless you moved it.
But when Mr. Compiler doesn't know how to compile your code, he puts information in a window called "Task List" that will look something like this:
The first part is just a big red X, letting you know that there is an error. In the "description" part, Mr. Compiler tries to explain the error. (This is where we see that his explanations aren't always perfectly clear.) The "resource" part tells you which file the error is in, and the "folder" gives more information about where that file can be found. Finally, the "location" part indicates what line he thinks the error is on. Unfortunately, he's not always right, but the line number will often give you a good place to start even if it's not exactly right.
Sometimes, Mr. Compiler may say something that does not start with a big red X, because he likes to provide you with other information, but for today, we will concentrate on the big red X errors
If you are not using JCreator or you just prefer the build output window, the error will look like this, instead:
-------------------- C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Squirrel.java:9: unclosed string literal System.out.println("Wheeee!); ^ C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Squirrel.java:10: ')' expected ^ 2 errors Process completed.
Mr. Compiler is very picky about a lot of things, including what you call your files. Take a look at this message:
class Chipmunk is public, should be declared in a file called Chipmunk.java mean? It means you have the wrong filename! Take a look at the "resource" given: it's called Squirrel.java. Close, but not quite right. You could put a class called Squirrel in that file, but if you want to keep your class called Chimpunk, you have to rename the file.
You might want to notice that the error message mentions that the Chipmunk class is public. This doesn't apply to private classes -- you can hide those wherever you want -- but if the class is public, Mr. Compiler is picky about the filename.
And boy is he ever picky... take a look at this error message:
But wait! What happened here? The file is called chipmunk.java. Why isn't it fine?
Well, here's where Mr. Compiler shows how picky he is. Java is called a "case sensitive" language, and that means that C is considered as a different letter than c. So chipmunk.java and Chipmunk.java are different files, as far as Java is concerned. This is somewhat silly on some platforms, like Windows, which are not case sensitive (so chipmunk.java and Chipmunk.java and CHiPMuNK.JaVa are all the same file), but it makes perfect sense on platforms like Linux where those would all be different files.
Confused? Well, just remember that the Chipmunk class has to be in a file called Chipmunk.java. Mr. Compiler will accept no substitutes.
Perhaps the most frequent error you will get from Mr. Compiler looks something like this:
Chipmunk.java:10: ';' expected
But then you go look at line 10 and it's got a ';' at the end. What's up with that?
Well, it might help if you looked at the error in the build output window:
C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Squirrel.java:10: ';' expected System.out.println(); ^
See how it's indicating the beginning of the line? That's Mr. Compiler giving you a hint, believe it or not, that the error's close to there. And close to there could mean the previous line! So let's look at the previous line, line 9:
I don't see a semicolon. Do you see a semicolon? Nope? Well, there's our error! Put a semicolon (';') at the end of that line and Mr. Compiler will be happy.
Sometimes, you'll get errors like
')' expected. Sometimes, they're just like the ';' missing example above, but sometimes they're more confusing than that. Here's one of those confusing ones now!
Let's see if we can get a better idea by looking at the error in the build window:
-------------------- C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Squirrel.java:9: unclosed string literal System.out.println("Wheeee!); ^ C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Squirrel.java:10: ')' expected System.out.println(); ^ 2 errors Process completed.
How weird: I see a ) on both of those lines, don't you? How can they be mising?
Well, if you disregard that it looks like a big horrible error message, the output from the build window is actually a bunch more useful. It points out line 9, which has a string that got opened, but never closed! We can fix that by putting in another " at the end of the string, like this:
See that second quote there after the exclamation point? Now if you compile again, there won't be any errors, and your chipmunk can say "Wheee!"
But wait, wasn't this lesson about missing ')'s? What happened there?
Well, this is another one of those cases where Mr. Compiler tries to guess at your problem, but he kinda gets it wrong. In fact, there never was a missing ), exactly. What happened was that he thought that your string was
Wheeee!); so he thought, hey, there should be a " there at the end. But if I guess and put a " at the end, then the println() function will still be missing a ), so the statement would have to be
System.out.println("Wheeee!);"). You can easily tell by looking at the code that it's *probably* not what the programmer wanted, but that's because you're smarter than Mr. Compiler, no matter how much of a know-it-all he may seem to be.
Before we move on to another topic, let's look at another snippet of code with an error that relates to missing ')'s. We have code that looks like this:
int numberOfLegs = 4; System.out.println("This chipmunk has " + numberOfLegs " legs");
What we're trying to do it get the code to print out
This chipmunk has 4 legs. But what's happening is that when we compile, Mr. Compiler says:
-------------------- C:\Documents and Settings\Terri Oda\My Documents\Java-tutorials\mrcompiler\Chipmunk.java:11: ')' expected System.out.println("This chipmunk has " + numberOfLegs " legs"); ^ 1 error Process completed.
Remember to look at the build window to get this output! Now, Mr. Compiler seems to think we're missing a ), but anyone can see that there's one at the end of the line. Why does he think it should go after numberOfLegs?
Well, to understand this, you have to think a bit about the string you're trying to print: You're concatenating things together, which means you stick a bunch of things together to make a big string. So you're telling Mr. Compiler that you start with
"This chipmunk has " and then you add in (with that + sign)
numberOfLegs (which we can see is set to 4 if we look at the code), and then we add in... Oh wait, we forgot a + sign! That's why Mr. Compiler is confused. So if you add in a + sign, he'll understand that
" legs" goes with the rest of the string, and he'll see that the ) is there and in the right place. Yeay!
A variable definition looks something like this:
This is like saying to Mr. Compiler, "Get me a bucket that holds a string, and call that bucket
So Mr. Compiler comes back with a bucket:
And then he sticks a label on it so that everyone knows it's called "noise"
Sometimes, we'll want to define a variable and give it a value right away, which would look something like this:
String noise = "Whee!";
Or, in pictures:
There are many different types of bucket, all meant to handle different "shapes" of data:
Each name must be unique, that is, if I ask for a bucket named noise, I can't ask for any other buckets named noise. If I do, Mr. Compiler will be upset. Say we have code like this:
int numberOfLegs = 4; float numberOfLegs = 3.5; // this chipmunk had an accident
Then Mr. Compiler will complain:
numberOfLegs is already defined in main(java.lang.String). So if you want to change number of legs a chipmunk has, you need to get the variable definition right at the beginning, and change the value without making a new definition. That means, if it's possible for a chipmunk to get hit by a car and have half a leg, then you're going to need to have numberOfLegs be a float value, and then change it accordingly without saying "float" again:
float numberOfLegs = 4; numberOfLegs = 3.5; // this chipmunk had an accident