Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
Hybrid. Despite its difficulty, I chose Hybrid to give you a taste of the Java language. TEXTBOX: TEXTBOX_HEAD: Non-object-oriented language basics: Read the whole series!
Java merges various language entities -- such as data types, literal values, identifiers, and comments -- with syntax rules that explain how to legally combine those entities to create meaningful programs. The Java compiler, responsible for enforcing these rules, reads a Java source file, which contains zero or more lines of ASCII text that constitute a program. (I will let you decide if an empty file constitutes a program -- sort of like the mathematical concept of an empty set. To play with this idea, create a file with no content. Are you able to compile that file? What is the result?) Each line may be of arbitrary length and is terminated by a carriage return character (ASCII 13), a new-line character (ASCII 10), or a carriage return followed by a new line.
Once the compiler reads a line, its preprocessor translates each of the line's ASCII characters (whose 7-bit numeric values are stored in 8-bit bytes) into equivalent Unicode characters (whose 16-bit values are stored in two adjacent 8-bit bytes). To translate, the compiler prefixes nine zeroes to the 7-bit ASCII value and stores the result in a 16-bit memory location. For example, 1000001 (41 hexadecimal, the ASCII value for an uppercase A) would translate to 0000000001000001 (0041 hexadecimal, the Unicode value for uppercase A). Compilation begins after every ASCII character on every line has been translated.
Although the preprocessor typically translates a single ASCII character into a single Unicode character, it can also render
several ASCII characters as one Unicode character. This situation arises when the preprocessor encounters a Unicode escape sequence: a character sequence in the form \uxxxx, where each x represents a hexadecimal digit. When the preprocessor encounters a Unicode escape sequence, it converts the sequence's six
ASCII characters into a single Unicode character. For example, if the preprocessor finds \u20ac -- six ASCII characters that represent a single Unicode character denoting the euro, the European Union's currency symbol
-- it would convert these six characters into a single Unicode character, and store the resulting 16-bit value in memory.
As you read this article, you'll find out when Unicode character sequences can come in handy.
Now let's dive into the Java language and examine a few of Java's non-object-oriented programming language entities. Let's look at comments first.
Suppose you are working in the IT department of a large company, and your boss instructs you to write a program consisting of a few thousand source code lines. After a few weeks, you finish the program and deploy it. A few months later, users begin to notice that the program occasionally crashes. They complain to your boss, and he orders you to fix it. After searching your files, you come across a bundle of paper that lists the program's source code. Unfortunately, because of the way you wrote the program, the source code makes little sense. You've worked on other projects since creating this one, and you just can't remember why you wrote code to do this or that. It could take you hours or even days to decipher your code, but your boss wanted a solution yesterday. Talk about major stress! What do you do?
The solution is to get into the habit of documenting source code. In other words, insert human-understandable descriptions into the source code. Though usually overlooked, documenting source code while writing a program's logic is one of the developer's most important tasks. If not properly documented, even the original author might not understand the source code.
Computer languages support source code documentation by providing special symbols that signal the beginning and end of source code descriptions. The symbols and descriptions are collectively known as comments.
Java supports three styles of comments: multiline, single-line, and doc. The first two styles originated from C and C++; the doc style is unique to Java.
A multiline comment begins with /*, can span multiple lines, and ends with */. The compiler ignores all characters from /* to */ (inclusive). The following code fragment is a multiline comment:
/* multiline comment */
Multiline comments are useful for documenting methods. For example, consider this method:
public void main (String [] args)
{
}
What does this method do? What is the purpose of args? And what, if anything, does this method return? (It's probably fairly clear that this method is the entry point to a program,
args is an array of command-line arguments, and void indicates that this method doesn't return a value. However, main() is a simple, well-defined method; not every method can be understood this easily by looking at the method header.)
We can clarify main()'s purpose, along with args and void, by placing a multiline comment before the method, as demonstrated by the following code fragment:
/*
public void main (String [] args)
Program entry point.
Parameters:
args - an array of String objects, with each object representing a command-line argument
Return value:
none
*/
public void main (String [] args)
{
}
As you can see, a multiline comment makes a method more readable.
Unlike the C and C++ languages, Java prevents the nesting of multiline comments -- you can't place comments inside each other like Russian dolls. If the Java compiler encountered the following comment, it would generate an error.
/* /* nested comment */ */
Unlike multiline comments, a single-line comment begins with // and continues to the end of the current line. The compiler ignores all characters between // and the end of that line (inclusive). The code below demonstrates a single-line comment: