Home arrow Java arrow Page 3 - Formatters and Java Print Streams

Formatters and Java Print Streams

Last week, we discussed Java print streams, concluding with the format method and formatter objects. This week, we pick up from where we left off. This is the second part of a three-part sereis. It is excerpted from chapter seven of Java I/O, Second Edition, written by Elliotte Rusty Harold (O'Reilly, 2006; ISBN: 0596527500). Copyright © 2006 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

Author Info:
By: O'Reilly Media
Rating: 4 stars4 stars4 stars4 stars4 stars / 8
June 21, 2007
  1. · Formatters and Java Print Streams
  2. · Character Sets
  3. · Locales
  4. · Format Specifiers
  5. · Floating-point conversions

print this article

Formatters and Java Print Streams - Locales
(Page 3 of 5 )


Character sets are not the only localization issue in the Formatter class. For instance, in France, a decimal comma is used instead of a decimal point. Thus, a French user running the earlier degree table example would want to see this:

  0,0   0,0   0,0
  1,0   0,0   1,1
  2,0   0,0   2,2
  3,0   0,1   3,3
  4,0   0,1   4,4

Sometimes Java adapts the format to the local conventions automatically, and sometimes it doesnít. For instance, if you want decimal commas, you have to write%,5.1finstead of%5.1f. The comma after the percent sign is a flag that tells the formatter to use the local conventions. (It does not actually say to use commas.) Java will now use commas only if the local conventions say to use commas. On a typical U.S. English system, the local convention is a decimal point, and thatís what youíll get even if you format numbers as%,5.1f.

Of course, sometimes you donít want a program to adapt to the local conventions. For instance, many companies use PCs adapted to local languages and customs but still need to produce English documents that use American formats. Thus, as an optional third argument to the constructor, you can pass ajava.util.Localeobject:

  public Formatter(String fileName, String characterSet, Locale locale)
   throws FileNotFoundException
  public Formatter(File file, String characterSet, Locale locale)
   throws FileNotFoundException
  public Formatter(OutputStream out, String characterSet, Locale locale)

For example, to force the use of American conventions regardless of where a program is run, youíd construct aFormatterlike this:

  Formatter formatter = new Formatter("data.txt", "ISO-8859-1", Locale.US);

You can also specify a locale when writing to anAppendableobject or aStringBuilder:

  public Formatter(Appendable out, Locale locale)
  public Formatter(Locale locale)

Character encodings donít matter for these two cases because bothAppendableandStringBuilderare defined in terms of characters rather than bytesóthereís no conversion to be done. However, locales can change formatting even when the character set stays the same.

On occasion, you might wish to change the locale for one string you write but not for other strings (in a mixed English/French document, perhaps). In that case, you can pass a locale as the first argument to theformat()method before the format string:

  public Formatter format(Locale locale, String format, Object... args)

You can do the same thing with theprintf()andformat()methods in thePrintStreamclass:

  public PrintStream printf(Locale locale, String format, Object... args)

Finally, Iíll note that thereís a getter method that returns theFormatterís current locale:

  public Locale locale()

Error Handling

The Formatter class handles errors in much the same way PrintStream does. That is, it sweeps them under the rug and pretends they didnít happen. Notice how none of the methods mentioned so far threwIOException?

To find out if theFormatterhas encountered an error, invoke itsioException()method:

  public IOException ioException()

This returns the lastIOExceptionthrown by the underlying output stream. If there was more than one, only the last one is available.

This is marginally better thanPrintStreamís booleancheckError()method. At leastFormatter will tell you what the problem was. However, it still wonít tell you unless you ask. For simple cases in which you donít have to write a lot of data before closing theFormatterand checking for any errors, this may be adequate. However, programs that need to write for an extended period of time should probably create strings using aFormatterbut write them using a regularOutputStream. That way, if an I/O error does happen, youíll find out soon enough to do something about it.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials