John O'Conner

Updating timezone data in older Java VMs

Wouldn't it be nice if you could install the latest version of the JDK or JRE in your production environment? But maybe you just can't do that because of your company policy, testing cycles, or adoption process. Unfortunately, whether you can update or not, things change. Some things affect your application whether you want them to or not. For example, as timezone data changes, software must change to keep pace. Wouldn't it be great if you could update just the timezone data in your existing vm...might be easier to get approval for that instead of approval to replace your complete JDK/JRE.

The Timezone Updater Tool allows you to update timezone data in older JDK/JREs. Using the updater tool, you're able to update the data without updating the entire JDK/JRE. You can learn more about this product from the online article Timezone Updater Tool.

Posted at 09:52PM Apr 10, 2008 by John O'Conner in Java  | 

Internationalization improvements in Java SE 6

One important strength of the Java Platform, Standard Edition (Java SE) has always been its internationalization and localization support. The platform continues to evolve, and Java SE 6 provides developers even more control over how they access and use locale-sensitive resources in their applications. Java SE 6 provides the following major enhancements to its internationalization support:

• Resource control and access
• Locale-sensitive services
• Text normalization
• International domain names
• Japanese calendars
• New supported locales

Find out more about these features and more by reading the online article Internationalization Enhancements in Java SE 6.

Posted at 12:12AM Apr 01, 2008 by John O'Conner in Java  | 

Working with months in Java Calendar

Earlier I mentioned that many of the Date constructors and methods are deprecated. You shouldn't use them. Someone immediately wondered how they were supposed to find out what the date actually meant...what year is it? month? day? If you can't ask the date object directly, what should you do?

Posted at 09:29AM Mar 28, 2008 by John O'Conner in Java  | 

Finer control with a Resource Control

Storing localized resources for your Java applications usually means creating a .properties file or a ResourceBundle subclass. You don't usually have a lot of control over how the resources are cached or how they're stored.

Here's an example. The enforced caching of resources was a common complaint for server applications. Can you imagine your app being up for 299 straight days without a hitch...something perhaps to brag about...but now you have to bring it down because you want to change a single localized resource bundle that's stuck in the JRE cache?

Now you don't have to bring down an application to update resources. You have more control over how your applications cache resource bundles. You no longer have to store them as .properties or ResourceBundle subclasses either. If you want an XML format, sure, you can have it. Don't like files at all? Want to retrieve the resources from a db? You can have that too. Oh, you don't like storing bundles with locale prefixes (MyBundle_fr, MyBundle_en_US, etc)? OK. You don't have to anymore.

How is that possible? Why is ResourceBundle so flexible now? It's all about control, which you now have. That's ResourceBundle.Control actually. This new class allows you to control practically every aspect of how bundles are searched, loaded, and cached. Create your own Controlsubclass, provide it to the ResourceBundle.getBundle method, and now you're in the driver's seat. The new class provides several methods that you can override to affect caching, naming, searching, defaults, fallbacks, etc. You control it all.

You can read about ResourceBundle.Control in its online javadocs. Or check out this and other new internationalization features in Java SE 6 by reading International Enhancements in Java SE 6. Let me know what you like in that overview, and maybe I can cover it in more detail here.

Posted at 08:00AM Mar 27, 2008 by John O'Conner in Java  | 

International Domain Names

The internet's core infrastructure, including domain name servers and name resolvers just doesn't handle non-ASCII characters very well. That's why java.net.IDN is so useful.[Read More]

Posted at 10:03PM Mar 26, 2008 by John O'Conner in Java  |