This is a cautionary tale of US-only JREs and non-US countries, such as The Lucky Country I call home.
Sun, in their infinite wisdom, provided (until recently) the Java Runtime Environment in two different flavours: US English only, or all languages. Unfortunately, when you place the “US English only” version on a non-US machine, you get some weird errors, like this one (for Australian machines):
// Throws java.text.ParseException, believe it or not. java.text.NumberFormat.getCurrencyInstance().parse("$0.00");
This one is a bugger to reproduce on a developer box, because the developer box will almost certainly have a Java SDK on it instead. However the SDK only comes in the “all languages” variant, which means this code will work as expected.
Furthermore, because the “US English” and international versions are identical, except for the language pack, you can’t tell them apart using ‘java -version’. The only way to tell is to look in the ‘lib/ext’ directory of the JRE. The international version has a ‘localedata.jar’, while the “US English” version does not. Not surprisingly, the localedata.jar has all the resource bundles for different locales.
(For those who want more details… the formatter fails because it thinks that the currency symbol should be ‘AUD’, not ‘$’)
This particular problem had one of the development teams at work tearing their hair out for about 3 days; we’d stared at the code where the ParseException was caught and said “No, that couldn’t be it”, but enhanced the logging anyway (future reference, fellows: You should always log “impossible” exceptions, at least). Even after we proved it was the ParseException, it took a while to pin down the cause.
Sun, again in their infinite wisdom, now only distribute a fully international version. If you want to see this for yourself, compare the downloads of the JRE for a Java 1.4.2 release to the older Java 1.4.1 release.
(This blog entry done on behalf of the team at work; I know you guys will be looking out for it. 😉