On 7/12/06, Alexey Petrenko <[EMAIL PROTECTED] > 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.
Agree, especially it is right for the eclipse based approach where we have
to create class with set of fields, whose names are correspond to the bunlde
keys.
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.
I also thought in this way...if exceptions thrown not so often then we can
easily use "first" method. It will keep us
from the loading of all messages from bundle during initialization as it is
done in the eclipse approach.
I've tried to implement eclipse approach and meet additional fields
modificators and accessibilty checks during initialization.
It can be avoided if all fields are initialized in static block (as far as
we know their names we can initialize them explicitly without reflection).
Anyway, if these messages are not supposed to be used very often I would
vote for the "first" method, it is simple and clear.
Thanks,
Ilya.
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]
--
--
Ilya Okomin
Intel Middleware Products Division
