Let's establish some facts right away:

1. My first introduction to the Aspect Oriented Programming paradigm was the article Aspect Oriented Programming and Internationalization by Stephen B. Morris, who is probably very knowledgeable about AOP.
2. I know practically nothing about AOP, I am not an AOP guru, and I don't even play one on java.net.

Now that the disclaimers are out of the way, I'll just get right to the meat of today's blog: I don't get that article. Why do I need AOP for internationalization?

Mr. Morris tackles three common internationalization issues with his article and describes how AOP provides a solution. He describes AOP solutions for these typical i18n problems:

1. separation of user-visible text from the application code
2. locale-specific date formatting
3. currency-specific number formatting

I don't doubt that he has good AOP answers, but I wonder why they are even necessary given the fact that the Java class library already provides solutions.

Separation of text

We all know about resource bundles, right? And we know how to retrieve and use one for a specific locale, right? A ResourceBundle searches for a class or property file with localized text. The ResourceBundle documentation describes how to load and use text from a bundle.

Date Formatting

You know about the DateFormat class too. You can create one for a specific locale, and use it to format and parse dates that are easily understood by people in that locale.

Number and Currency Formatting

You can use NumberFormat to format and parse numbers and currencies too. This class works similar to the date formatter. Create one for a specific locale and format any number as either a basic number or as a currency amount.

AOP is more work?

For the date and number formatting, AOP seems like more work. In the AOP solution, it appears that you have to inject a new file for each new locale-sensitive format you want. Using Java's built-in solution, you determine a locale once at startup time for your app, and you can use that locale throughout the app lifetime to create formatters that work for dozens and dozens of locales. No new files, no new classes. Simple.

I feel a little odd responding to the article. One reason is that I don't have any AOP experience, and so it would be easy for me to misunderstand Mr. Morris' article completely. On the other hand, i18n is something I do know something about, and AOP seems like high maintenance for some of the tasks mentioned. Maybe a different example would help me. No doubt, Mr. Morris provided the i18n examples with good intentions. Maybe knowing that good solutions already exist in the Java platform has caused me to miss the article's point.

I believe I need to re-read that article...