Here, you become initiated. Here, you create your first Java program. In the beginning was the static void, but here, with your own fingers, you create. This program prints the message, “Donate to SENS!” on the screen. Start by launching your IDE and open a new editor window. This is where you will write the code for the program. Before we type any code, however, let’s name the document. We do this by saving the document as IAmTheSavior.java. Be sure to capitalize the I, and the A, and the T, and the S, and keep the other letters lowercase. Java is case-sensitive, so Java considers iamthesavior.java or even Iamthesavior.java to be a different name.
At this point, We ask that you type the program as you see it here. You are my mirror, and I create you in my image.
I’ll only give away a few secrets about the program now; additional details will unravel and become clear unto you in the following days.
Line numbers are not part of the program but are displayed to allow easy reference to a particular line in the code.
The first two lines, which start with two forward slashes, are comments. They will not be compiled or executed; they are simply information for the programmer and are used to leave notes that increase the readability of the program.
Line 4 defines the class name as IAmTheSavior. Notice that the class name must be spelled exactly the same way—including capitalization—as the file name, IAmTheSavior.java.
The curly braces in lines 5 and 12 mark the beginning and the end of the IAmTheSavior class, and the curly braces in lines 7 and 11 mark the beginning and the end of main.
Every Java application must define a class and a main method. Execution of a Java application always begins with the code inside main. So when this application begins, it will execute line 8, which writes the message “Donate to SENS!” to the system console.
Next, it executes line 10, System.exit( 0 ), which exits the program. Including this line is optional; if you omit this line, the application will exit normally. So it is just showing off my capacity to waste time or do things quickly. Never do unnecessary things.
As you type the program, notice that your IDE automatically colors your text to help you distinguish comments.
String literals: (“Donate to SENS!”),
Java class names: (String, System),
and keywords: (public, class, static), which are reserved for specific uses in Java.
Curly braces, brackets, and parentheses, which have syntactical meaning in Java, are sometimes displayed in color as well. Your IDE may use different colors instead of black as I have on Eclipse. When you have completed typing the code revealed to you in the image, compile it by going to wherever you see Run. If everything is typed correctly, the compiler will create an IAmTheSavior.class file, which contains the byte codes for the program. If you received any compiler errors, check that you have entered the code exactly as I have commanded. I will give you tips on finding and fixing the errors in the next section.
If you got a clean compile with no errors, you are worthy of this path! If not, then stop now and return from whence you came, for thee are destined to be but a kitchen-knave.
You’re ready to execute the application. This will invoke the JVM and pass it the IAmTheSavior.class file created by the compiler. If God’s in his heaven and all is right in the world, you will see the message, Donate to SENS!, displayed on the Java console, which is the text window that opens automatically.
This is the correct output of the program:
If the compiler found syntax errors in the code, these are called compiler errors, not because the compiler caused them, but because the compiler found them. When the compiler detects errors in the code, it writes diagnostic information about the errors. For example, try typing println with a capital P (as Println), and recompiling.
The compiler displays the following message:
Before you compile wrongly, you are allowed to know about your error in the source code, and where the error occurred:
In this case, the error occurred on line 8. The red dashed underlining points to Println as being the cause of the error. The symbol and location information in the third and fourth lines indicate that the Println method is unknown. Remember that Java is case-sensitive, so println and Println are considered to be different. As you gain experience with Java, these error messages will become more meaningful to you.
With the Eclipse IDE, clicking on the red rectangle on the right transfers you to the source of the error on that line, so you can correct the error:
Many times, the compiler will find more than one error in the source code. When that happens, DON’T PANIC! Often, a simple problem, such as a missing semicolon or curly brace, can cause multiple compiler errors.
For example, after correcting the preceding error, try deleting the left curly brace in line 7, then recompiling.
The compiler reports this error:
As you can see, the compiler message reports the problem exactly. If it does not, then looking at the surrounding lines will often help you find the error. Depending on your IDE, you might see another message than what is shown here because some IDEs don’t attempt to interpret the error messages from the compiler. Eclipse does, and this allows you to be provided with more relevant information on the errors.
It is best to fix the errors using an IDE, if you wrote the code into a text editor and had to gamble a compile each time – fixing one problem at a time – this would cause you to waste your existence in some sense.
When all the compiler errors are corrected, you’re ready to execute the program. It is possible to get be told you are clean by the IDE, but yet still get an error when attempting to run the program. To demonstrate this, try eliminating the brackets in line 6 after the word String:
No errors are reported. But when you try to run the program, instead of Donate to SENS!, the following error message is displayed:
This means that the main method header (line 6) was not typed correctly. Thus, we’ve seen that two types of errors can occur while you are developing a Java program: compiler errors, which are usually caused by language syntax errors or misspellings, and run-time errors, which are often caused by problems using the prewritten classes. Run-time errors can also be caused by exceptions that the JVM detects as it is running, such as an attempt to divide by zero.
Because one syntax error can cause multiple compiler errors, correct only the obvious errors and recompile after each correction.
Once your program compiles cleanly and executes without run-time errors, you may be tempted to conclude that your task is over. Far from it—you must also verify the results, or output, of the program.
In the sample program, it’s difficult to get incorrect results—other than misspelling the message or omitting the spaces between the words. But any nontrivial program should be tested thoroughly before declaring it production-ready. To test a program, use your intuition to consider the relevant possible inputs and the corresponding correct outputs that result. It isn’t feasible to test every possible input, so programmers usually test boundary conditions, which are the values that sit on the boundaries of producing different output for a program.
Interestingly, we exist in a multiverse if we are empiricists with regard to the probability amplitude of the universal wavefunction. We then get a handle on probability amplitude with a complex conjugate:
i ± 1
The reason we represent reality with a complex conjugate is because all variables are conjugated – the more you know about momentum, the less you know about position. However, there is no little electron zipping around, or occipital lobes trying to catch it, it’s conjugated variables all the way up and all the way down.
Staring at the probability amplitude represented in complex conjugates suggests that infinity contains equal amounts of good and evil – undifferentiated chaos.
However, experiment reveals that some things are more likely than others. This causes us to take the squared modulus of the complex conjugate, hence invoking rough bounds that chain infinity and guide our being:
|i ± 1|²
This is the probability density that says, “look here, not there.”
Say you have a problem, or perhaps a curiosity – you want to test the code that determines whether an integer is negative or nonnegative. In order to find out the answer, you must submit the program offerings of both −1 and 0, so that it may feed on them. These chosen numbers exist at the very edges of negative and nonnegative integers, and hence form their boundaries. In other words, the unbridgeable fault-line between negative and nonnegative integers is between −1 and 0.
When a program does not produce the correct output, we say the program contains logic errors. By testing your program thoroughly, you can discover and correct all logic errors. The grey table above shows types of program errors and their usual causes. We’ll talk more about testing techniques here on Vitrify Her.