geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Wright <>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 27 Aug 2003 03:10:01 GMT

Alex Blewitt wrote:

> On Tuesday, Aug 26, 2003, at 18:54 Europe/London, Cabrera, Alan wrote:
>> I want a fast and enjoyable experience too, it does not stop me from 
>> writing
>> comments and javadocs or trying to format the code in a legible way.
>> One thing that I know for sure, either Geronimo puts it in early on 
>> or, let
>> us not kid ourselves, it will most likely never happen.
> Absolutely. Indeed, the main reason for it not being in most products 
> is that it is very difficult to retrofit at a later stage. At least if 
> we start off with good intentions, it makes it easier in the long run.

This is particularly true when it comes to javadocs.
You should write class headers etc. to ensure that what
you are doing can be explained.

You should immediately write unit tests for similar reasons.

> Note that this doesn't necessarily apply to just Exceptions; we need 
> to find a solution for i18n in other parts of the code too. And by 
> having this discussion and passing around helpful suggestions and 
> comments we can find a good goal, and then people involved in it can 
> put up a page explaining how it can be done easily for the future.
> I don't think this discussion ever intended to be a case of 'You are 
> not allowed to write code until this problem is sorted'; more, it was 
> a case of bouncing ideas about a good way to go so that we can achieve 
> a common goal subsequently.

Yes, so here's my 2p before we sleep on it...

A disadvantage of coding descriptive names in static finals,
type-save enums or wide and deep exception heirarchies is
that it is difficult to do well. You end up wondering
whether to live with a bad name or incur the costs of a global

If there is one exception message resource bundle per package
then it is actually very convenient to look up the message for
an exception code in the language of your choice. These can
be freely edited and so good messages will evolve. Translation
is also relatively convenient.

Note that if you get it wrong (e.g. number of message parameters)
then you can avoid editing a message in N languages by
adding a new code - numbers are almost free.

So I suggest using integer codes in exception constructors
and adding english messages to the default resource bundle
in order.

This means less code needs to be written and maintained.


Recently completed - Child Brain Injury Trust Admin System

Urgently seeking paid work
Java, Linux, XML and much more.

View raw message