Well, I think what Kevin suggests to improve the java.util.ResourceBundle impl. itself? Exception handling is not a good scenario to cite here. Web applications might be a better scenario, as they usually load a lot of (localized) messages. Fortunately many Web applications will load all the messages into memory during startup, so they won't need to read messages from disk files again and again. I guess this should be a best practise for developers in case their applications need to read many messages repeatedly.
-Jack 2008/11/21 Tony Wu <[EMAIL PROTECTED]> > Keivn > > Sorry for different idea. > > First, I dont think exception handling is a right place to talking > about performance. It's a self-contradictory story. > If you think it is a good place to improve the performance, there must > be many exceptions thrown at runtime. But I dont think there should > be, because to use try/catch as condition judgment itself is a > performance killer. My understanding is that in the most cases when we > need to get a localized message, it's time for vm to exit. And why we > should take care the performance when exit? > > Furthermore, resource bundle is designed for decoupling the localized > messages from logic. It's not a good idea to couple them again with > hashtable. You can not ask translater to modify the java source code, > compile, build, and test it ;-) > > On Fri, Nov 21, 2008 at 1:34 PM, Jack Cai <[EMAIL PROTECTED]> wrote: > > I agree with Kevin that this might be a place that we could possibly > > improve. But we should be careful when using a cache, as it always > > introduces lots of complexity, like cache invalidation and reload. In the > > case of ResouceBundle, same thing here. What happens if the resource > files > > gets updated? This will be a common scenario in long-running Java > process, > > e.g., the JEE server environment. > > > > - Jack > > > > 2008/11/20 Jim Yu <[EMAIL PROTECTED]> > > > >> Hi Kevin, > >> Making a cache for all the message loaded from ResourceBundle will bring > >> huge overhead if only few message would be used in an application. Only > in > >> some specific scenarios where lots of duplicate message is needed would > >> application benefit from such caching mechanism. But I don't think such > >> case > >> would be very common. Could you prove your idea by running some > benchmarks? > >> My another concern is that it doesn't make sense to use a hashtable to > >> store > >> the locale dependent message. How do you define the key for the entry? > E.g. > >> "K0046" would not be qualified since no locale info is included. And > even > >> if > >> you find a good method to solve this, the overhead would be incredible > if > >> lots of locales need to be supported for the message. > >> 2008/11/20 Kevin Zhou <[EMAIL PROTECTED]> > >> > >> > Jim Yu wrote: > >> > > >> >> In addition, using ResourceBundle in Harmony can make the message > output > >> >> be > >> >> easily localized into different languages. And it is very convenient > to > >> >> support more locales in the future. > >> >> > >> >> 2008/11/20 Sean Qiu <[EMAIL PROTECTED]> > >> >> > >> >> > >> >> > >> >>> We can benefit from it when exceptions are thrown many times. > >> >>> But we rarely encounter this situation in our application :) > >> >>> To save the memory, space outweigh time in this case. > >> >>> > >> >>> Correct me if I'm wrong. > >> >>> > >> >>> 2008/11/20 Kevin Zhou <[EMAIL PROTECTED]> > >> >>> > >> >>> > >> >>> > >> >>>> Hi, > >> >>>> I read some code in LUNI module of Harmony. > >> >>>> (org.apache.harmony.luni.util.Msg/MsgHelp and > >> java.util.ResourceBundle) > >> >>>> I found that Harmony uses ResourceBundle to load messages from > >> external > >> >>>> properties file. > >> >>>> e.g. Once it requires a message "K0046", it will always use > >> >>>> ResourceBundle to go through the > >> >>>> org.apache.harmony.luni.util.ExternalMessages.properties file to > >> search > >> >>>> > >> >>>> > >> >>> it. > >> >>> > >> >>> > >> >>>> I think such redundant and repeated I/O operations may degrade our > >> >>>> performance. > >> >>>> > >> >>>> Why not use a hashtable to store all the external messages? It only > >> >>>> requires several I/O operations initially! > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>> -- > >> >>> Best Regards > >> >>> Sean, Xiao Xia Qiu > >> >>> > >> >>> China Software Development Lab, IBM > >> >>> > >> >>> > >> >>> > >> >> Hi Jim, > >> > I think that you misunderstand. > >> > I don't mean to discard using ResourceBundle for localization. > >> > I just suggest that we should use ResourceBundle to load all the > external > >> > properties and store them in a hashtable initially. > >> > Then you don't need to repeat calling ResourceBundle to scan property > >> files > >> > any more, but turn to the hashtable. This may improve performance. > >> > > >> > Hi Sean and Regis, > >> > I think that external messages are not only designed for exceptions > >> > handling. > >> > Some may also use such a useful mechanism in their applications. > >> > > >> > Let's assume that one application execute on HARMONY. > >> > As a side effect, all jars on the bootpath will be loaded to search > for > >> the > >> > ResourceBundle class the first time an external message is required. > >> > Obviously, application have to wait utill ResourceBundle class is > loaded > >> > and it successfully finds the required message, which takes seconds. > >> > > >> > Note that if we can initially load all of the external properties > before > >> > the first application class is loaded. > >> > This can provide a faster startup time and quick responses when it > >> requires > >> > any external messages. > >> > > >> > > >> > >> > >> -- > >> Best Regards, > >> Jim, Jun Jie Yu > >> > >> China Software Development Lab, IBM > >> > > > > > > -- > Tony Wu > China Software Development Lab, IBM >
