Hi,<br><br>First of all, I&#39;m new to this project and I&#39;d like to
congratulate you on putting it together with your typical no-nonsense
approach to APIs.  Particular praise is worthy for the IMessageConveyor
interface hiding the ugliness of ResourceBundle and MessageFormat
within a single method with varargs - inspired simplicity!<br>
<br>Secondly, I would like to suggest a use-case that your API does not
(yet?) cover.  Maybe this is an idea you could consider incorporating.<br><br>Within
an enterprise application, especially a web-based application for
example, resources frequently need to be looked up and corresponding
strings returned to the user&#39;s display. But I have found that there are
times in such applications where I would prefer to defer the choice of
locale.  For example, I may have some &#39;library&#39; code not concerned with
the UI yet which produces messages that are fed back to the user. 
These are status messages, error messages etc.  The classic way to deal
with these is to return separate transfer objects and later construct
messages from them, but this can make the parameterisation awkward and
adds complexity.  Maybe it would be simpler to return the message
directly.<br>
<br>The problem with the Cal10n API as it stands is that I need to know
the locale before I can construct a MessageConveyor.  Only then can I
call the <span style="font-family: courier new,monospace;">getMessage(E e, Object... args)</span>
method to get the string, including its formatted parameters.  The
problem with web applications is that only the UI tier knows the
locale.  It is incorrect for other tiers to assume a different locale
and unwieldy to pass the correct locale through as a parameter.  So it
would typically be wrong for the lower tiers to use MessageConveyor.<br>
<br>This is a shame and my suggestion is simply that an additional data
transfer object is required as part of the Cal10n API to fill the gap.
This is essentially a <span style="font-family: courier new,monospace;">Message</span>
class containing the enumeration and the args but without the resource
bundle/message format lookup having yet been performed.  At a later
stage, a <span style="font-family: courier new,monospace;"></span><font style="font-family: courier new,monospace;" size="2">getLocalizedMessage</font><font size="2"><span style="font-family: courier new,monospace;">(Locale locale)</span></font> method will yield the required String for a given locale.<br>

<br>A desirable characteristic of <span style="font-family: courier new,monospace;">Message</span>
is that it be immutable because this would make it safe to hold within
Exceptions or to be shared between threads.  In other words, it would
be better for it not to be a classic mutable JavaBean data transfer
object. Therefore it is arguable that a general interface is not needed
and a concrete and final <span style="font-family: courier new,monospace;">Message</span> class would be completely sufficient.  So here is a possible implementation for <span style="font-family: courier new,monospace;">Message</span>:<br>


<br>

<span style="font-family: courier new,monospace;">public final class Message {</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">    private final Enum&lt;?&gt; e;<br>
  Â  private final Object[] args;</span><br style="font-family: courier new,monospace;">

<span style="font-family: courier new,monospace;"><br>
    public Message(Enum&lt;?&gt; e, Object... args) {<br>
        this.e = e;<br>
        this.args = args;<br>
    }<br>
<br>
    public String </span><font style="font-family: courier new,monospace;" size="2">getLocalizedMessage(Locale locale) {<br>
</font><span style="font-family: courier new,monospace;">  Â Â  Â Â  final IMessageConveyor mc = new MessageConveyor(locale);<br>
        return mc.getMessage(e, args);<br>
</span><font style="font-family: courier new,monospace;" size="2">    }<br>
<br>
    @Override<br>
    public String toString() {<br>
        final StringBuilder b = new StringBuilder(&quot;Message(&quot;);<br>        b.append(<a href="http://e.name/" target="_blank">e.name</a>());<br></font><font style="font-family: courier new,monospace;" size="2">
        b.append(&quot;, [&quot;);<br>
</font><font style="font-family: courier new,monospace;" size="2">        if (args != null) {<br></font><font style="font-family: courier new,monospace;" size="2">
  Â Â  Â Â Â Â Â Â  String comma = &quot;&quot;;<br></font><font style="font-family: courier new,monospace;" size="2">
  Â Â  Â Â Â Â Â Â  </font><font style="font-family: courier new,monospace;" size="2">for (Object o : args) {<br>                b.append(comma).append(o);<br>                comma = &quot;, &quot;;<br></font><font style="font-family: courier new,monospace;" size="2">
  Â Â  Â Â Â Â Â Â  }</font><br><font style="font-family: courier new,monospace;" size="2">        }<br>
        b.append(&quot;])&quot;);<br>
        return b.toString();<br>
    }<br>
</font><span style="font-family: courier new,monospace;">}</span><br>
<br>In use, the &#39;library&#39; (non-UI) code will have its own resource
bundle and corresponding enum. It will create instances of Message to
return to the UI tier, where the message string for the appropriate
locale can be looked up and then presented to the user.<br>
<br>It would be beneficial to override hashcode() and equals() methods
appropriately but I haven&#39;t included that here. There may also be some
performance value in holding transient caches of the toString() result
and the hashcode, although I omitted this also.<br>
<br>
I wish the project success and I look forward to recommending it to my clients when it reaches a sufficient level of maturity.<br>
<br>Regards,<br>Rick Beton<br><font color="#888888">-- <br>Big Bee Consultants Limited : Registered in England &amp; Wales No. 6397941<br>Registered Office: 71 The Hundred, Romsey, Hampshire, SO51 8BZ<br></font><br>