The Date class represents time as a long integer which is the number of milliseconds measured from January 1, 1970 00:00:00.000 GMT. This starting point is called the epoch. The long value used to represent a point in time comprises both the date and the time of day. The Date class provides the following constructors:

Some selected methods from the date class are shown below. The Date class has mostly deprecated methods, and provides date operations in terms of milliseconds only. However, it is useful for printing the date value in a standardized long format, as the following example shows:

The Date class is not locale-sensitive, and has been replaced by the Calendar and DateFormat classes. The class overrides the methods clone(), equals(), hashCode(), and toString() from the Object class, and implements the Comparable<Date> interface.

Example 12.2 illustrates using the Date class. The toString() method (called implicitly in the print statements) prints the date value in a long format. The date value can be manipulated as a long integer, and a negative long value can be used to represent a date before the epoch.

A calendar represents a specific instant in time that comprises a date and a time of day. The abstract class java.util.Calendar provides a rich set of date operations to represent and manipulate many variations on date/time representation. However, the locale-sensitive formatting of the calendar is delegated to the DateFormat class (see Section 12.4).

The following factory methods of the Calendar class create and return an instance of the GregorianCalendar class that represents the current date/time.

Interoperability with the Date class is provided by the following two methods:

Information in a calendar is accessed via a field number. The Calendar class defines field numbers for the various fields (e.g., year, month, day, hour, minutes, seconds) in a calendar. Selected field numbers are shown in Table 12.5. For example, the constant Calendar.Year is the field number that indicates the field with the value of the year in a calendar.

The get() method returns the value of the field designated by the field number passed as argument. The return value of a field is an int. Table 12.6 shows some selected field values that are represented as constants. The first day of the month or year has the value 1. The value of the first day of the week depends on the locale. However, the first month of the year, i.e., Calendar.JANUARY, has the value 0.

We have added 1 to the month in the last statement, before printing the date.

Particular fields in a calendar can be set to a specific value, or they can be cleared. Many set operations can be done without recomputing and normalizing the values in a calendar. In the code below, the values in the calendar are first recomputed and normalized when the get operation is performed in (3). Note how the day and the month has changed from the values in (1).

Since not all locales start the week on the same day of the week, the Calendar class provides methods to set and get the first day of the week in a calendar.

The following code illustrates how the add() method works. Note how, when we added 13 months to the calendar, the number of months is normalized and the year has been incremented, as 13 months is 1 year and 1 month.

The following code illustrates how the roll() method is different from the add() method. Note how, when we added 13 months to the calendar now, only the number of months is normalized but the year is not incremented, i.e., the roll() method does not recompute larger fields as a consequence of normalizing smaller fields.

Example 12.3 shows further examples of using the methods in the Calendar class. It is instructive to compare the code with the output from the program.

For dealing with text issues like formatting and parsing dates, time, currency and numbers, the Java Standard Library provides the java.text package. The abstract class DateFormat in this package provides methods for formatting and parsing dates and time.

See also the discussion in Section 12.7, Formatting Values, p. 593.

The class DateFormat provides formatters for dates, time of day, and combinations of date and time for the default locale or for a specified locale. The factory methods provide a high degree of flexibility when it comes to mixing and matching different formatting styles and locales. However, the formatting style and the locale cannot be changed after the formatter is created. The factory methods generally return an instance of the concrete class SimpleDateFormat, which is a subclass of DateFormat.

A date/time formatter can be applied to a Date object by calling the format() method. The value of the Date object is formatted according to the formatter used.

Example 12.4 shows the result of formatting the current date/time with the same formatting style for both the date and the time, according to the US locale.

Although we have called it a date/time formatter, the instance returned by the factory methods mentioned earlier is also a parser that converts strings into date/time values. Example 12.5 illustrates the parsing of strings to date/time values. It uses the Norwegian locale defined at (1). Four locale-specific date formatters are created at (2). Each one is used to format the current date and the resulting string is parsed back to a Date object:

The string is parsed according to the locale associated with the formatter. Being lenient during parsing means allowing values that are incorrect or incomplete. Lenient parsing is illustrated at (6):

The string "32.01.08|" is parsed by the date formatter according to the Norwegian locale. Although the value 32 is invalid for the number of days in a month, the output shows that it was normalized correctly. A strict formatter would have thrown a ParseException. Since the string was parsed to a date, default values for the time are set in the Date object. Also, trailing characters in the string after the date are ignored. The formatting style in the date formatter (in this case, DateFormat.SHORT) and the contents of the input string (in this case, "32.01.08") must be compatible with each other. Note that in the print statement, the Date object from the parsing is converted to a string according to the default locale:

Each date/time formatter has a Calendar that is used to produce the date/time values from the Date object. In addition, a formatter has a number formatter (NumberFormat, Section 12.5) that is used to format the date/time values. The calendar and the number formatter are associated when the date/time formatter is created, but they can also be set programmatically by using the methods shown below.

The NumberFormat class provides factory methods for creating locale-sensitive formatters for numbers and currency values. However, the locale cannot be changed after the formatter is created. The factory methods return an instance of the concrete class java.text.DecimalFormat or an instance of the final class java.util.Currency for formatting numbers or currency values, respectively. Although we have called the instance a formatter, it is also a parser—analogous to using a date/time formatter.

A number formatter can be used to format a double or a long value. Depending on the number formatter, the formatting is locale-sensitive: either default or specific.

The following code shows how we can create a number formatter for the Norwegian locale and use it to format numbers according to this locale. Note the grouping of the digits and the decimal sign used in formatting according to this locale.

The following code shows how we can create a currency formatter for the Norwegian locale, and use it to format currency values according to this locale. Note the currency symbol and the grouping of the digits, with the amount being rounded to two decimal places.

A number formatter can be used to parse strings that are textual representations of numeric values. The following code shows the Norwegian number formatter from above being used to parse strings. In (1), the result is a long value because the dot (.) in the input string is not a legal character according to the number format used in the Norwegian locale. In (2), the result is a double value because the comma (,) in the input string is the decimal sign in the Norwegian locale. Note that the print statement prints the resulting number according to the default locale.

The following code demonstrates using a currency formatter as a parser. Note that the currency symbol is interpreted according to the locale in the currency parser. In (3), although a space is a grouping character in the Norwegian locale when formatting currency values, it is a delimiter in the input string.

The following methods allow the formatting of numbers to be further refined by setting the number of digits to be allowed in the integer and the decimal part of a number. However, a concrete number formatter can enforce certain limitations on these bounds.

Example 12.6 further demonstrates the usage of number/currency formatters/ parsers. It uses two methods: runFormatters() and runParsers() declared at (1) and(2), respectively. The first one runs formatters supplied in an array on a specified numeric value, and the second one runs the formatters supplied in an array as parsers on an input string. Since the NumberFormat class does not provide a method for determining the locale of a formatter, an array of locales is used to supply this information. Note that the parsing succeeds if the input string is conducive to the locale used by the parser.

The notation [] can be used to define a pattern that represents a set of characters, called a character class. Table 12.9 shows examples of such patterns. A ^ character is interpreted as a metacharacter when specified immediately after the [ character. In this context, it negates all the characters in the set. Anywhere else in the [] construct, it is a non-metacharacter. The pattern [^aeiouAEIOU] represents the set of all characters that excludes all vowels, i.e., it matches any character that is not a vowel.

The - character is used to specify intervals inside the [] notation. If the interval cannot be determined for a - character, it is treated as a non-metacharacter. For example, in the pattern [-A-Z], the first - character is interpreted as a non-metacharacter, but the second occurrence is interpreted as a metacharacter that represents an interval.

Except for the metacharacter which retains its meaning, the other metacharacters $, ., ?, *, +, (, ) and | are recognized as non-metacharacters in a [] construct.

Table 12.10 shows a shorthand for writing some selected character classes. Note that a character class matches one single character at a time in the output, and not a sequence of characters (unless it has only one character). The metacharacter . should be paid special attention to, as it will match one occurrence of any single character.

Here is another example, using a predefined character class in a pattern to recognize a date or time format:

Sometimes we are interested in finding a pattern match at either the beginning or the end of a string/line. This can be achieved by using boundary matchers (also called anchors), as shown in Table 12.11. Here is an example of a simple pattern to determine if the input ends in a ? character. We have to escape the ? character in order to use it as a non-metacharacter in the pattern. Note that, except for the ? character at the end of the input, the other ? characters in the input are not recognized.

Table 12.12 shows logical operators that we can use to create more complex regular expressions. The logical operators are shown in increasing order of precedence, analogous to the logical operators in boolean expressions. Here is an example that uses all three logical operators for recognizing any case-insensitive occurrence of Java or C++ in the input:

A regular expression can be specified as a string expression in a Java program. In the declaration below, the string literal "who" contains the pattern who.

The pattern d represents a single digit character. If we are not careful in how we specify this pattern in a string literal, we run into trouble.

The escape sequence d is invalid in the string literal above. Both string literals and regular expressions use a backslash () to escape metacharacters. For every backslash in a regular expression, we need to escape it in the string literal, i.e. specify it as a backslash pair (\). This ensures that the Java compiler accepts the string literal, and the string will contain only one backslash for every backslash pair that is specified in the string literal. A backslash contained in the string is thus interpreted correctly as a backslash in the regular expression.

If we want to use a backslash as a non-metacharacter in a regular expression, we have to escape the backslash (), i.e use the pattern \. In order to escape these two backslashes in a string literal, we need to specify two consecutive backslash pairs (\\). Each backslash pair becomes a single backslash inside the string, resulting in the two pairs becoming a single backslash pair, which is interpreted correctly in the regular expression, as the two backslash characters represent a backslash non-metacharacter.

Below are examples of string literals for some of the regular expressions we have seen earlier. Each backslash in the regular expression is escaped in the string literal.

The two classes Pattern and Matcher in the java.util.regex package embody the paradigm for working efficiently with regular expressions in Java. It consists of the following steps:

The approach outlined above is recommended, as it avoids compiling the regular expression string repeatedly, and it is specially optimized for using the same pattern multiple times on the same input or different inputs. When used on the same input repeatedly, the pattern can be used to find multiple matches.

As mentioned above, the input must be of type CharSequence, which is a readable sequence of char values. The interface CharSequence is implemented by such classes as String and StringBuilder.

With the setup outlined above, it is possible to use the same pattern with different engines. The bookkeeping for doing the actual pattern matching against some input is localized in the matcher, not in the pattern.

The two methods below can be used to compile a regular expression string into a pattern and to retrieve the regular expression string from the pattern, respectively.

The matcher() method returns a Matcher, which is the engine that does the actual pattern matching. This method does not apply the underlying pattern to the specified input. The matcher provides special operations to actually do the pattern matching.

The Pattern class also provides a static convenience method that executes all the steps outlined above for pattern matching. The regular expression string and the input are passed to the static method matches(), which does the pattern matching on the entire input. The regular expression string is compiled and the matcher is created each time the method is called. Calling the matches() method is not recommended if the pattern is to be used multiple times.

The normal mode of pattern matching is to find matches for the pattern in the input. In other words, the result of pattern matching is the sequences of characters (i.e., the matches, also called groups) that match the pattern. Splitting returns sequences of characters that do not match the pattern. In other words, the matches are spliced out and the sequences of non-matching characters thus formed from the input are returned in an array of type String. The pattern is used as a delimiter to tokenize the input. The token in this case is a sequence of non-matching characters, possibly the empty string. The classes StringTokenizer and Scanner in the java.util package also provide the functionality for tokenizing text-based input. See the subsection The java.util.Scanner Class, p. 571.

The example below shows the results from splitting an input on a given pattern. The input is a ‘|’-separated list of names. The regular expression string is "\|", where the metacharacter | is escaped in order to use it as a non-metacharacter. Splitting the given input according to the specified regular expression, results in the array of String shown below.

The split() method can be called on a pattern to create an array by splitting the input according to the pattern. Each successful application of the pattern, meaning each match of the pattern delimiter in the input, results in a split of the input, with the non-matched characters before the match resulting in a new element in the array, and any remaining input being returned as the last element of the array.

The number of applications of the pattern is controlled by the limit value passed to the method, as explained in Table 12.14. The code below will result in the array shown earlier:

Using the split() method is illustrated in Example 12.7. The doPatSplits() method at (1) creates a Pattern at (2) and calls the split() method at (3) on this pattern. Partial output from Example 12.7 is shown below. Limit value 1 does not split the input, limit value 2 splits the input once, and so on. Limit value greater than 3 does not change the results, as the input is exhausted at limit value 3. A non-positive limit value splits the input on the pattern as many times as necessary, until the input is exhausted.

If we change the input above to the input shown below, we see how empty strings come into the picture. The empty string is returned as a token to “mark” the split when the delimiter is found at the head of any remaining input, or at the end of the input. Five applications of the pattern were necessary to exhaust the input. Note that the limit value 0 does not return trailing empty strings.

The String class also has a split() method that takes the regular expression string and the limit as parameters. Given that the reference input is of type String, the call input.split(regexStr,limit) is equivalent to the call Pattern.compile(regexStr). split(input, limit). The doStrSplits() method at (4) in Example 12.7 uses the split() method in the String class. Here is another example of using the split() method from the String class:

We will not split hairs here any more, but encourage experimenting with splitting various input on different patterns using the code in Example 12.7.

The main steps of successive matching using a matcher are somewhat analogous to using an iterator to traverse a collection (p. 786). These steps are embodied in the code below, which is extracted from Example 12.8.

Once a matcher has been obtained, the find() method of the Matcher class can be used to find the next match in the input (called target in the code). The find() returns true if a match was found.

If the previous call to the find() method returned true, and the matcher has not been reset since then, the next call to the find() method will advance the search in the target for the next match from the first character not matched by the previous match. If the previous call to the find() returned false, no match was found, and the entire input has been exhausted.

The call to the find() method is usually made in a loop condition, so that any match found can be dealt with successively in the body of the loop. A match found by the find() method is called the previous match (as opposed to the next match which is yet to be found). The characters comprising the previous match are called a group, and can be retrieved by calling the group() method of the Matcher class. The group’s location in the target can be retrieved by calling the start() and the end() methods of the Matcher class, as explained below. The two methods find() and group() are called successively in lockstep to find all matches/groups in the input.

Once pattern matching has commenced, the matcher can be reset. Its target and pattern can also be changed by passing the new target to the reset() method and by passing the new pattern to the usePattern() method, respectively. The reset() method resets the search to start from the beginning of the input, but the usePattern() method does not.

Example 12.8 is a complete program that illustrates successive matching. In fact, the program in Example 12.8 was used to generate all examples of regular expressions in the subsection Regular Expression Fundamentals, p. 554. Again, we recommend experimenting with successive matching on various inputs and patterns to better understand regular expressions.

In this mode, the matcher allows the matched characters in the input to be replaced with new ones. Details of the methods used for this purpose are given below. The find() and the appendReplacement() methods comprise the match-and-replace loop, with the appendReplacement() method completing the operation when the loop finishes.

Note that these methods use a StringBuffer, and have not been updated to work with a StringBuilder.

Example 12.9 illustrates the match-and-replace loop. Non-matching characters in the input and the replacements of the matches are successively added to the string buffer in the loop at (1), with the call to the appendTail() method at (3) completing the operation. The same operation is repeated using the replaceAll() method at (4).

Using the replaceAll() method replaces all matches with the same replacement, but the match-and-replace loop offers greater flexibility in this regard, as each replacement can be tailored when a match is found.

Tokenizing is analogous to successive matching (p. 567), involving reading of the characters in the source, and recognizing tokens in the source. Example 12.10 shows a bare-bones tokenizer that tokenizes a string, but it embodies the paradigm for constructing more sophisticated scanners. The rest of the subsection will present variations on this tokenizer.

1. The source for the input to the scanner must be identified. The example shows a String as the source, but we can also use other sources, such as a File, an InputStream or a BufferedReader.

2. A scanner is created and associated with the source that is passed as argument in the constructor call. The Scanner class provides constructors for various kinds of sources.

3. The bulk of the work of a scanner is done in a lookahead-and-parse loop.

The condition of the loop is a call to a lookahead method to see if an appropriate token can be identified in the remaining source. The Scanner class provides lookahead methods named hasNextType to determine whether the next token in the source is of the appropriate primitive Type. Note that the scanner reads the characters from the source sequentially.

The call to the hasNext() method at (3) returns true if there is a (String) token in the source. The loop terminates when the hasNext() method returns false, meaning that the source string has been exhausted, i.e., there are no more tokens.

Each successive call to a lookahead method causes the scanner to advance and look for the next token in the source.

4. If a lookahead method determines that there is a token in the source, the token can be parsed in the loop body. The Scanner class provides parse methods named nextType to parse the next token in the source to the appropriate primitive type. The call to the next() method at (4) parses the next token to a String. In the example, the parsed value is printed, but it can be stored and used as desired. Also in the example, the scanner uses the default delimiters (whitespace) to tokenize the string.

A lookahead method and its corresponding parse method are used in lockstep to ensure that characters in the source are matched and parsed to a token of an appropriate type.

5. A scanner whose source has been explicitly associated in the code, should be closed when it is no longer needed. This also closes the source, if that is necessary.

A scanner must be constructed and associated with a source before it can be used to parse text-based data. The source of a scanner is passed as an argument in the appropriate constructor call. Once a source is associated with a scanner it cannot be changed. If the source is a byte stream (e.g., an InputStream), the bytes are converted to characters using the default character encoding. A character encoding can also be specified as an additional argument in an overloaded constructor, except when the source is a String.

The Scanner class provides two overloaded hasNext() methods that accept a regular expression specified as a string expression or as a Pattern, respectively. The next token is matched against this pattern. All primitive types and string literals have a pre-defined format which is used by the appropriate lookahead method.

All lookahead methods return true if the match with the next token is successful. This means that we can safely call the corresponding parse method to parse the token to an appropriate type. Note that a lookahead method does not advance past any input character, regardless of whether the lookahead was successful. It only determines whether appropriate input is available at the current position in the input.

A scanner uses white space as its default delimiter pattern to identify tokens. The useDelimiters() method of the Scanner class can be used to set a different delimiter pattern for the scanner during parsing. Note that a scanner uses regular expressions for two purposes: a delimiter pattern to identify delimiter characters and a token pattern to find a token in the input.

A scanner is able to read and parse any value that has been formatted by a printf method, provided the same locale is used. The useLocale() method of the Scanner class can be used to change the locale used by a scanner.

The delimiters, the locale, and the radix can be changed any time during the tokenizing process.

The Scanner class provides methods to parse strings and values of all primitive types, except the char type.

Corresponding to the hasNext() methods, the Scanner class provides two overloaded next() methods that accept a regular expression as a string expression or as a Pattern, respectively. This pattern is used to find the next token.

It is important to understand how a parse method works. A call to a parse method first skips over any delimiters at the current position in the source, and then reads characters up to the next delimiter. The scanner attempts to match the non-delimiter characters that have been read against the pattern associated with the parse method. If the match succeeds, a token has been found, which can be parsed accordingly. The current position is advanced to the new delimiter character after the token. The upshot of this behavior is that if a parse method is not called when a lookahead method reports there is a token, the scanner will not advance in the input. In other words, tokenizing will not proceed unless the next token is “cleared.”

A scanner will throw an InputMismatchException when it cannot parse the input, and the current position will remain unchanged.

Example 12.11 illustrates parsing of primitive values (and strings) from formatted data. To parse such values, we need to know what type of values occur in what order in the input so that an appropriate lookahead and a corresponding parse method can be used. We also need to know what locale was used to format them and which delimiters separate the individual values in the input. This is exactly the information accepted by the parse() method at (1).

The order in which the different type of values occur in the input is specified by the vararg parameter tokenTypes, whose element type is the enum type TokenType. A call to the method parse(), such as the one shown below, thus indicates the order, the type and the number of values to expect in the input.

Example 12.11 can be used as the basis for experimenting with a scanner for parsing primitive values in the formatted input.

The skip() method can be used to skip characters in the input during the course of tokenizing. This operation ignores delimiters and will only skip input that matches the specified pattern. If no such input is found, it throws a NoSuchElementException.

The match() method can be called after the value of a token has been returned. The MatchResult interface provides methods to retrieve the start index, the end index, and the group of the token. For example, after parsing a floating-point number in the input, a MatchResult can be obtained by calling the match() method, which can then be queried about the location of the characters comprising the value, etc.

When the source is an input stream (e.g., a File, an InputStream, a Reader), a read operation can throw an IOException. If this exception is thrown in the course of a lookahead method call, it is not propagated by the scanner and the scanner assumes that the end of the input has been reached. Subsequent calls to a lookahead method will throw a NoSuchElementException. To determine whether processing terminated because of a genuine end of input or an IOException, the ioException() method can be called to verify the situation.

Closing a scanner is recommended when the client code has explicit control over the assigning of the source. Calling a scanning method on a closed scanner results in an IllegalStateException.

Example 12.12 is the analog of Example 12.8 that uses a scanner instead of a matcher. The thing to note about Example 12.12 is the loop at (4). The method call hasNext() looks ahead to see if there is any input. The method call hasNext(pattern) attempts to match the pattern with the next token (found using the delimiters). If the attempt is not successful, the method call next() returns the token, which is ignored, but advances the scanner.

The split() method (p. 563) in the Pattern and the String classes can also tokenize, but is not as versatile as a scanner. The example below shows the difference between a scanner and a matcher. In the tokenizing mode, a scanner tokenizes and then attempts to match the token with the pattern. A matcher does not tokenize, but searches for the pattern in the input. The results below make this difference quite apparent in the number of matches the two approaches find in the same input.

Results from a scanner (see Example 12.12):

Results from a matcher (see Example 12.8):

If the input is line-oriented, the scanner can be used to perform search in the input one line at a time. The methods hasNextLine(), findInLine(), and nextLine() form the trinity that implements the multi-line mode of searching the input with a pattern.

Example 12.13 illustrates the basics of the multi-line use of a scanner. The program processes a text file line by line, printing the names found in each line. The program essentially comprises two nested loops: an outer loop to access the input one line at a time, and an inner loop to search for all names in this line. The name of the source file is specified as a program argument at (1). The pattern that defines a name is specified at (2), and a scanner with the text file as the source is created at (3).

The call to the lookahead method hasNextLine() at (4) checks to see if there is another line of input. If that is the case, the findInLine() method is called at (5) to find the first match. All characters in the line are treated as being significant by the findInLine() method, including the delimiters that are set for the scanner. If a call to the findInLine() method results in a match, it advances the search past the matched input in the line and returns the matched input. The value returned by the findInLine() method can be used as a condition in an inner loop to successively find remaining occurrences of the pattern in the line at (8).

If no match is found in the line, the findInLine() method returns the value null and the search position remains unchanged. The findInLine() method never reads past a line separator. This means that the scanner does not budge if a match cannot be found in the line or if it has reached the end of the line. A call to the nextLine() method at (9) reads the rest of the line, i.e., any characters from the current position to the end of the line, including the line separator. The scanner is thus poised to process the next line.

Since the findInLine() method only recognizes the line separator as a delimiter, absence of line separators in the input may result in buffering of the input while the scanner tries to match the search pattern.

12.7 Which statements are true about the following target string?

Select the three correct answers.

(a) The regular expression a+ will match two substrings of the target string.

(b) The regular expression aa+ will match two substrings of the target string.

(c) The regular expression (aa)+ will match two substrings of the target string.

(d) The regular expressions aa+ and (aa)+ will match the same two substrings of the target string.

12.8 Which statements are true about the following target string?

Select the three correct answers.

(a) The regular expression a? will match five non-empty substrings of the target string.

(b) The regular expression aa? will match two non-empty substrings of the target string.

(c) The regular expression (aa)? will match two non-empty substrings of the target string.

(d) The regular expressions aa? and (aa)? will not match the same non-empty substrings of the target string.

12.9 Which statement is true about the following target string?

Select the one correct answer.

(a) The regular expression a* will match three non-empty substrings of the target string.

(b) The regular expression aa* will match at least two non-empty substrings of the target string.

(c) The regular expression (aa)* will match two non-empty substrings of the target string.

(d) The regular expressions a* and aa* will match the same non-empty substrings of the target string.

(e) All of the above.

12.10 Which statement is true about the following target string?

Select the one correct answer.

(a) The pattern d will match 0.5, 7, and 4 in the target string.

(b) The pattern d will match 0, ., 5, 7, and 4 in the target string.

(c) The pattern w will match UP and me in the target string.

(d) The pattern s will match 0.5, 7UP, and _4me in the target string.

(e) The pattern . will match the . character in the target string.

(f) The regular expression [meUP] will match UP and me in the target string.

(g) None of the above.

12.11 Which statements are true about the following program?

Select the two correct answers.

(a) Only in the statements at (1) and (2) will the compiler report an invalid escape sequence.

(b) Only in the statements at (3) and (4) will the compiler report an invalid escape sequence.

(c) Only in the statements at (1) and (3) will the compiler report an invalid escape sequence.

(d) The statements at (2) and (4) will compile but will throw an exception at runtime.

(e) After any compile-time errors have been eliminated, only one of the statements will print true when executed.

(f) None of the above.

12.12 Given the following code:

Which declarations, when inserted independently at (1), will make the program print:

Select the four correct answers.

(a) int i = 0;

(b) int i = 1;

(c) int i = 2;

(d) int i = 3;

(e) int i = 4;

(f) int i = 5;

(g) int i = 6;

12.13 Given the following code:

Which identifiers, when filled in the blanks in the order they are specified, will make the program print:

Select the one correct answer.

(a) Pattern, pattern, target, regex, find, start, end, group

(b) Matcher, pattern, regex, target, hasMore, start, end, element

(c) Matcher, pattern, regex, target, hasNext, start, end, next

(d) Pattern, regex, pattern, target, find, start, end, group

(e) Pattern, regex, pattern, target, hasNext, start, end, next

(f) Pattern, regex, pattern, target, find, start, end, result

12.14 What will the program print when compiled and run?

Select the one correct answer.

(a) |JAVA|JaVa|java|jaVA|

     |JAAAVA|JaVVa|jjaavva|ja VA|

(b) |JAVA|JaVa|java|jaVA|

     |

     |JAAAVA|JaVVa|jjaavva|ja VA|

(c) |JAVA|JaVa|java|jaVA|

     |JAVA|JaVa|java|jaVA|

     |JAAAVA|JaVVa|jjaavva|ja VA|

(d) |JAVA|JaVa|java|jaVA|

     |JAVA|JaVa|java|jaVA|

     |JaVVa|jjaavva|ja VA|

(e) The program will throw an exception when run.

12.15 What will the program print when compiled and run?

Select the one correct answer.

(a) | To be |

     |or not to be|

(b) | To be |

     |or not     to be|

(c) | To be |

     |or  not  to be|

(d) | To be | |or not to be|

(e) | To be ||or not to be|

(f) | To be ||or not to be|

(g) The program will not compile.

(h) The program will throw an exception when run.

12.16 What will the program print when compiled and run?

Select the one correct answer.

(a) |Xyz|Xyz|Xz|

     |XyzXyz|Xz|

     |Xyz|Xyz|Xz|

     |Xyz|Xyz|

(b) |XyzXyz Xz|

     |XyzXyz Xz|

     |Xyz|Xyz|Xz|

     |Xyz|Xyz|

(c) |XyzXyz Xz|

     |XyzXyz|Xz|

     |XyzXyz Xz|

     |XyzXyz|Xz|

(d) The program will throw an exception when run.

12.17 What will the program print when compiled and run?

Select the one correct answer.

(a) No 7Up 4 _U Too!

(b) No 7up 4 _u Too!

(c) No 7Up 4 _u Too!

(d) No 7up 4 _U Too!

(e) The program will throw an exception when run.

12.18 What will the program print when compiled and run?

Select the one correct answer.

(a) |Smile|and|the|world|smiles|with-you|

(b) |Smile|and|the|world|smiles|with-y|u|

(c) |Smile|and|the|world|smiles|with|you|

(d) |Smile|and|the|w|rld|smiles|with|y|u|

(e) The program will not compile.

(f) The program will compile and will throw an exception when run.

(g) The program will compile and will execute normally without printing anything.

12.19 Which statements are true about the Scanner class?

Select the 3 correct answers.

(a) The Scanner class has constructors that can accept the following as an argument: a String, a StringBuffer, a StringBuilder, a File, an InputStream, a Reader.

(b) The Scanner class provides a method called hasNextBoolean, but not a method called hasNextChar.

(c) The methods hasNext(), next(), skip(), findInLine(), and useDelimiters() of the Scanner class can take a Pattern or a String as an argument.

(d) The situation where the scanner cannot match the next token or where the input is exhausted, can be detected by catching an unchecked NoSuchElementException in the program.

12.20 Given the following code:

Which print statements, when inserted independently at (1), will not make the program run as follows (with user input shown in bold):

Select the three correct answers.

(a) System.out.println(lexer.nextByte());

(b) System.out.println(lexer.nextShort());

(c) System.out.println(lexer.nextInt());

(d) System.out.println(lexer.nextLong());

(e) System.out.println(lexer.nextDouble());

(f) System.out.println(lexer.nextBoolean());

(g) System.out.println(lexer.next());

(h) System.out.println(lexer.nextLine());

12.21 Given the following code:

Which pattern strings, when inserted at (1), will not give the following output:

Select the two correct answers.

(a) "[0\.]+"

(b) "[0.]+"

(c) "(0|.)+"

(d) "(0|\.)+"

(e) "0+(\.)*"

(f) "0+\.*0*"

12.22 What will the program print when compiled and run?

Select the one correct answer.

(a) .-.),.-.(

(b) -),-(

(c) .-),-(.

(d) .-),.-(

(e) The program will not compile.

(f) The program will compile and will throw an exception when run.

12.23 Given the following code:

Which declaration statements, when inserted at (1), will give the following output:

Select the one correct answer.

(a) String regex = "\d+\.?";

(b) String regex = "\.?\d+";

(c) String regex = "\d+\.\d+";

(d) String regex = "\d*\.?\d*";

(e) String regex = "\d+\.?\d*";

(f) String regex = "(\d+\.?|\.?\d+|\d+\.\d+)";

(g) The program will not compile regardless of which declaration from above is inserted at (1).

(h) The program will compile and run, but will throw an exception regardless of which declaration from above is inserted at (1).

12.24 What will the program print when compiled and run?

Select the one correct answer.

(a) <B4>< we were><8><:-)><2C><1>

(b) <B4>< we were><m8s><:-)><2C><THR>

(c) <B4><we were><8><:-)><2C,><1>

(d) <B4>< we were><8s><2C1><><THR>

(e) The program will not compile.

(f) The program will compile and will throw an exception when run.

12.25 What will the program print when compiled and run?

Select the one correct answer.

(a) The program will not compile.

(b) The program will compile and will throw an exception when run.

(c) The program will compile and will go into an infinite loop when run.

(d) The program will compile, run, and terminate normally, without any output.

(e) The program will compile, run, and terminate normally, with the output Trick!.

(f) The program will compile, run, and terminate normally, with the output Trick!Trick!.

(g) The program will compile, run, and terminate normally, with the output Trick!treat!.

12.26 Given the following code:

Which code, when inserted independently at (1), will not print one of the lines shown below:

Select the three correct answers.

(a) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
lexer.useDelimiter(",");
while(lexer.hasNext())
  System.out.print(lexer.next() + "|");

(b) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("\s*,\s*");
 while(lexer.hasNext())
  if(lexer.hasNextDouble())
    System.out.print(lexer.nextDouble() + "|");
  else
    lexer.next();

(c) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("\s*,\s*");
 while(lexer.hasNext())
  if(lexer.hasNextDouble())
    System.out.print(lexer.nextDouble() + "|");

(d) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("[,\- .a-z]+");
 while(lexer.hasNext())
  if(lexer.hasNextInt())
    System.out.print(lexer.nextInt() + "|");
  else
    lexer.next();

(e) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("[,\- .\d]+");
 while(lexer.hasNext())
  if(lexer.hasNextBoolean())
    System.out.print(lexer.nextInt() + "|");
  else
    lexer.next();

(f) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("[,\- .\d]+");
 while(lexer.hasNext())
  if(lexer.hasNextBoolean())
    System.out.print(lexer.nextBoolean() + "|");
  else
    System.out.print(lexer.next() + "|");

(g) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("[,\- .]+");
 while(lexer.hasNext())
  if(lexer.hasNextDouble())
    System.out.print(lexer.nextDouble() + "|");
  else
    System.out.print(lexer.next() + "|");

(h) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.useDelimiter("[,\- .]+");
 do {
  if(lexer.hasNextInt())
    System.out.print(lexer.nextInt() + "|");
 } while(lexer.hasNext());

(i) Scanner lexer = new Scanner("2007, -25.0,mp3 4 u , true, after8");
 lexer.reset();
 do {
  if(lexer.hasNextInt())
    System.out.print(lexer.nextInt() + "|");
  else
    lexer.next();
} while(lexer.hasNext());

The class java.util.Formatter provides the core support for formatted text representation of primitive values and objects through its overloaded format() methods:

The destination object of a formatter is specified when the formatter is created. The destination object can, for example, be a String, a StringBuilder, a file, or any OutputStream.

The classes java.io.PrintStream and java.io.PrintWriter also provide an overloaded format() method with the same signature for formatted output. These streams use an associated Formatter that sends the output to the PrintStream or the PrintWriter, respectively. However, the format() method returns the current Formatter, PrintStream, or PrintWriter, respectively, for these classes, allowing method calls to be chained.

The String class also provides an analogous format() method, but it is static. Unlike the format() method of the classes mentioned earlier, this static method returns the resulting string after formatting the values.

In addition, the classes PrintStream and PrintWriter provide the following convenience methods:

The java.io.Console only provides the first form of the format() and the printf() methods (without the locale specification), writing the resulting string to the console’s output stream, and returning the current console.

The syntax of the format string provides support for layout justification and alignment, common formats for numeric, string, and date/time values, and some locale-specific formatting. The format string can specify fixed text and embedded format specifiers. The fixed text is copied to the output verbatim, and the format specifiers are replaced by the textual representation of the corresponding argument values. The mechanics of formatting values is illustrated below by using the PrintStream that is associated with the System.out field, i.e., the standard output stream. The following call to the printf() method of this PrintStream formats three values:

At runtime, the following characters are printed to the standard output stream, according to the default locale (in this case, Norwegian):

The format string is the first actual parameter in the method call. It contains four format specifiers. The first three are %6d, %8.3f, and %10s, which specify how the three arguments should be processed. Their location in the format string specifies where the textual representation of the arguments should be inserted. The fourth format specifier %n is special, and stands for a platform-specific line separator. All other text in the format string is fixed, including any other spaces or punctuation, and is printed unchanged.

An implicit vararg array is created for the values of the three arguments specified in the call, and passed to the method. In the above example, the first value is formatted according to the first format specifier, the second value is formatted according to the second format specifier, and so on. The '|' character has been used in the format string to show how many character positions are taken up by the text representation of each value. The output shows that the int value was written right-justified, spanning six character positions using the format specifier %6d, the double value of Math.PI took up eight character positions and was rounded to three decimal places using the format specifier %8.3f, and the String value was written right-justified spanning ten character positions using the format specifier %10s. Since the default locale is Norwegian, the decimal sign is a comma (,) in the output. We now turn to the details of defining format specifiers.

The general syntax of a format specifier is as follows:

Only the special character % and the formatting conversion are not optional. Table 12.15 provides an overview of the formatting conversions. The occurrence of the character % in a format string marks the start of a format specifier, and the associated formatting conversion marks the end of the format specifier. A format specifier in the format string is replaced either by the textual representation of the corresponding value or by the specifier’s special meaning. The compiler does not provide much help regarding the validity of the format specifier. Depending on the error in the format specifier, a corresponding exception is thrown at runtime (see Selected Format Exceptions, p. 601).

The optional argument_index has the format i$, or it is the < character. In the format i$, i is a decimal integer indicating the position of the argument in the vararg array, starting with position 1. The first argument is referenced by 1$, the second by 2$, and so on. The < character indicates the same argument that was used in the preceding format specifier in the format string, and cannot therefore occur in the first format specifier. The following printf() statements illustrate argument indexing:

The optional flag is a character that specifies the layout of the output format. Table 12.16 provides an overview of the permissible flags, where an entry is either marked ok or ×, meaning the flag is applicable or not applicable for the conversion, respectively. The combination of valid flags in a format specifier depends on the conversion.

The optional width is a decimal integer indicating the minimum number of characters to be written to the output.

The optional precision has the format .n, where n is a decimal integer and is used usually to restrict the number of characters. The specific behavior depends on the conversion.

The order of the various components of a format specifier is important. More details and examples are provided in the next subsection on formatting conversions.

These general conversions may be applied to any argument type.

The width indicates the minimum number of characters to output. The precision specifies the maximum number of characters to output, and takes precedence over the width, resulting in truncating the output if the precision is smaller than the width. Padding is only done to fulfill the minimum requirement.

Only the ‘-’ flag is applicable for left-justifying the output, requiring a positive width.

The conversions 'b' and 'B' represent boolean conversions. The following printf statement illustrates using boolean conversions. Note how null and non-boolean values are formatted and the effect of precision on the output.

The conversions 'h' and 'H' represent hash code conversions. The output is the hash code of the object:

The conversions 's' and 'S' represent string conversions. The following printf calls illustrates using string conversions. An array is passed as argument in the method call. Note how we can access the elements of this array in the format specifier with and without argument indices. Note also how the precision and the width affect the output.

These character conversions may be applied to primitive types which represent Unicode characters, including char, byte, short, and the corresponding object wrapper types.

The ‘-’ flag is only applicable for left-justifying the output, requiring a positive width.

The width specifies the minimum number of characters to output, padded with spaces if necessary.

The precision is not applicable for the character conversions.

Some examples of using the character conversions are shown below, together with the output:

The 'd', 'o', and 'x' conversions format an argument in decimal, octal or hexadecimal formats, respectively. These integral conversions may be applied to the integral types: byte, short, int, long, and to the corresponding object wrapper types.

Table 12.16 shows which flags are allowed for the integral conversions. The following flag combinations are not permitted: "+ " (sign/space) or "-0" (left-justified/ zero-padded). Both '-' and '0' require a positive width.

The width indicates the minimum number of characters to output, including any characters because of the flag that are specified. It is overridden if the argument actually requires a greater number of characters than the width.

For integral conversions, the precision is not applicable. If a precision is provided, an exception will be thrown.

Some examples of using the integral conversions are shown below, together with the output:

See also Section 12.5, The java.text.NumberFormat Class, p. 546, where formatting of numbers is discussed.

These floating-point conversions may be applied to floating-point types: float, double, and the corresponding object wrapper types.

The conversions 'e' and 'E' use computerized scientific notation (e.g., 1234.6e+00). The conversion 'f' uses decimal format (for example, 1234.6). The conversions 'g' and 'G' use general scientific notation, i.e. computerized scientific notation for large exponents and decimal format for small exponents. The conversions 'a' and 'A' use hexadecimal exponential format (e.g., 0x1.5bfp1, where the exponent p1 is 2¹).

Table 12.16 shows which flags are allowed for the integral conversions. As for the integral conversions, the following flag combinations are not permitted: "+ " (sign/space) or "-0" (left-justified/zero-padded). Both '-' and '0' require a positive width.

The width indicates the minimum number of characters to output, with padding if necessary.

If the conversion is 'e', 'E', 'f', 'a' or 'A', the precision is the number of decimal places. If the conversion is 'g' or 'G', the precision is the number of significant digits. If no precision is given, it defaults to 6. In any case, the value is rounded if necessary.

Some examples of using the floating-point conversions are shown below, together with the output in the UK locale (the default locale in this case).

Here is an example of a table of aligned numerical values:

Output (default locale is UK):

See also Section 12.5, The java.text.NumberFormat Class, p. 546, where formatting of numbers is discussed.

Table 12.18 shows some selected unchecked exceptions in the java.util package that can be thrown because of errors in a format string. These exceptions are subclasses of the IllegalFormatException class.

The destination object of a Formatter, mentioned earlier, can be any one of the following:

The Formatter class provides various constructors that allow mixing and matching of a destination object, a character encoding (i.e., a Charset) and a locale. Where no destination object is specified, the default destination object is a StringBuilder. The formatted output can be retrieved by calling the toString() method of the Formatter class. When no character encoding or locale is specified, the default character encoding or the default locale is used, respectively. The Formatter class also provides the flush() and the close() methods, analogous to those of an output stream, that also affect the destination object. Once a formatter is closed, calling the format() method throws a FormatterClosedException.

Example 12.14 illustrates the use of the format() method from different classes. Using the static String.format() method is shown at (1). The output is printed to the standard output stream, using the default character encoding and the default locale. The PrintWriter.format() method is used at (2). The formatted output is written to the specified file, using the default character encoding and the locale passed to the format() method. The format() method of the System.out field is used to write the output directly to the standard output stream at (3), i.e., the same as using the printf() method.

The Formatter.format() method is used at (4). The formatted output is written to the specified StringBuilder, using the default character encoding and the specified locale. The Formatter.format() method is used at (5) to write to an OutputStream. The formatted output is written to the specified file using the default character encoding and the locale passed to the format() method. The program flushes and closes any streams or formatters that were created explicitly.