harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] internationalization
Date Thu, 13 Jul 2006 15:56:40 GMT
Geir Magnusson Jr wrote:
> 
> Alexey Petrenko wrote:
>> Geir,
>>
>> I've reread your email in the morning :)
>>
>> Internationalization classes auto-generation is really good idea. We
>> can apply it for method described here and for "new Eclipse" method.
> 
> I'll settle for it being "an idea".  Not sure if it's a good one.   Tim
> has been working in this area, and I'm interested to hear what he thinks.

I'm inclined to agree -- though I haven't really got a good technical
argument, so I'll admit to falling back onto gut feel on this one.

Eclipse is going to be using lots of messages in the UI etc., whereas we
are using them in exception strings -- I think it is a quite different
usecase.  Diverting from the 'normal' way of doing this with resource
files without having a problem at the moment feels like a premature
optimization to me (I know that's a bit woolly).

I would like to avoid introducing new non-Java API dependencies between
modules in order to achieve the internationalization if we can avoid it.

Regards,
Tim

>> In the first case "generator" will insert correct resource bundle and
>> package name. In the second one we can generate the supporting class
>> from the resource bundle file.
>>
>> There will be 2 big differences between this two methods:
>> 1. Initialization time: much faster for the "first" method
>> 2. Run time access time: much faster for the "second" method
>>
>> So if we will have situation with the big resource file and small
>> number of accesses to it then the "first" method will be faster. In
>> the case with large number of accesses the "second" method will be
>> more preferable.
> 
> Can you quantify what "much faster" is for both cases?
> 
>> Probably we should think about using both methods depends on the purpose.
>>
>> For example. For UI application we have a huge number of messages
>> which are widely used during normal run (menu items, user messages
>> etc) and in this case the "second" method seems better.
>> Otherwise for the code without user interaction the messages from the
>> bundle will be mostly used as error messages for the throwing
>> exceptions. We hope that exceptions will not happen very often. And we
>> know that throwing an exception is rather long operation. So in this
>> case the "first" method seems better.
>>
>> Hmm... It looks like I've found an argument for using traditional
>> method in class library :)
> 
> :)
> 
>> SY, Alexey
>>
>> 2006/7/11, Geir Magnusson Jr <geir@pobox.com>:
>>>
>>> Tim Ellison wrote:
>>>> Ilya Okomin wrote:
>>>>> I'd like to be a volunteer for that.
>>>> I just started working in this area (for SQL), maybe that is what
>>>> prompted you...<g>
>>>>
>>>>> IMHO it's reasonable to use framework presented in luni module with
>>> some
>>>>> modifications.
>>>>> To avoid duplication of Msg class I'd suggest use slightly modified
>>> Msg
>>>>> class named let say
>>>>> o.a.h.luni.utils.ExtMsg.
>>>>> ExtMsg has the same methods as Msg, the difference is only these
>>> methods
>>>>> are
>>>>> non static,
>>>>> also specific external messages resource bundle will be initialized
>>> by name
>>>>> in the constructor.
>>>>> Each module will have class o.a.h.<module>.MsgUtils with static
>>> field 'msg'
>>>>> that is the instance of ExtMsg
>>>>> initialized with the name of the external messages resource bundle
>>> related
>>>>> to this module.
>>>>> Thus external message for e.g. security module could be obtained
>>> using next
>>>>> call:
>>>>>
>>>>>
>>> "org.apache.harmony.security.internal.MsgUtils.msg.getString("security.1");"
>>>
>>>> I see your point, and considered doing it that way too.  I'm not overly
>>>> concerned about the duplication, they are trivial helper methods
>>> anyway,
>>>> and we all know that singletons are evil ;-)
>>> I don't understand this, given you have one...
>>>
>>>>> And at last, place to keep resources with external messages I
>>> suppose to be
>>>>> o.a.h.<module>.internal.
>>>> I went for o.a.h.<module>.internal.nls just to keep them tidy.
>>>>
>>>>> If all these thoughts sounds reasonable, I'd like to implement
>>> framework
>>>>> mentioned above and send you a patch.
>>>> The real work is going through and externalizing all the messages, and
>>>> if I were to be really ambitious to add messages to all the exceptions
>>>> that we throw that don't have anything right now.
>>>>
>>>> Patches are always welcome.  We can work on that that as we finalize on
>>>> the framework.
>>> Have you had any thoughts about a 'common' code set, that is copied and
>>> modified at build time, setting the right package name and bundle name
>>> by convention?  That would remove the need to duplicate the code.
>>>
>>> geir
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message