Denis Kishenko wrote:
> Hi all !
>
> I would like to take part in internationalization discussion.
>
> I agree with Alexey Petrenko that traditional way is better for work with
> exception messages.
>
> Yes, Eclipse method has much faster access but needs to load ALL module
> messages at once. Exception messages are used rarely, so it's too expensive
> to keep all of them in memory. As Alexey said exception is a long
> operation,
> so don't pay attention to access speed so much.
When you load the messages using a ResourceBundle they also get loaded
all at once though, right?
Regards,
Tim
> 2006/7/12, Alexey Petrenko <[EMAIL PROTECTED]>:
>>
>> 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.
>>
>> 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.
>>
>> 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 <[EMAIL PROTECTED]>:
>> >
>> >
>> > 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: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>> --
>> Alexey A. Petrenko
>> Intel Middleware Products Division
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
