[jboss-dev] JBoss Unified I18N Infrastructure

[Max Rydahl Andersen]

>> Did you look at http://www.icu-project.org/ ? It wasn't in the list of 
>> alternatives.
> 
> Yup.  Actually, ICU is where much of the I18N functionality in the JDK
> had been born out of.  Thus, it provides the lower-level functionality
> that is leveraged by JBoss I18N - which has a higher-level
> applicability.

Well Eclipse moved to use icu4j to be more performant (AFAIK) so 
something else must be in icu4j ;)

>> Why would I *ever* want to have localized messages inside my code via 
>> annotations ?
> 
> You don't have to; it is a feature.  If you don't, however, you will
> have to "lookup" your L10N values rather than having them be handed to
> you per the current "LocalizationContext".

But the whole process of having doc writers translate your text would be 
pretty cumbersome with the translations in code and not to talk about 
the amount of extra lines added to the code ...?

>> Why another log framework ?
> 
> I know, I know, I know.  Everyone and their brother has at one time or
> another written a log abstraction framework.  Some of them do some
> pretty cool stuff - Seam's in particular (it handles Component
> interpolation).  The problem is that to log I18N messages, one would
> have to look up the bundle, get out a string, then log it.  With JBoss
> I18N Log, it is one step - just pass in the "code" of the I18N object to
> the log statement (as well as any vararg parameters).  Now, Mazz has a
> SourceForge project that can do this, as does JBoss Transactions - so I
> took the best from both and added it to JBoss I18N.  Again, I'm trying
> to unify everyone's efforts here into something not tied to any one
> particular project.

ok

>> Can I use it/integrate within eclipse plugins ?

> The core JBoss I18N library has no dependencies whatsoever on a
> "container" like an appserver.  So yes, you can use it in standalone
> applications and eclipse plugins (although I haven't tried it via an
> eclipse plugin yet).

What eclipse does is to not do the lookups or injections at runtime but 
when the classes loads and the actual strings are stored into a constant 
string e.g.

class Messages {
    String I18N_JPA_ERROR_MSG;
     ...
}

and then you access that string directly. This "trick" saved several 
megabytes of heap when Eclipse is running plus removes the 
lookup/injection overhead.

/max