Re: [platform-core-dev] New platform NLS support

[Mazen Faraj <mfaraj@xxxxxxxxxx>]

John, 
is there a document that explains what
the issue was with using ResourceBundles like we did today? what part of
that class design was the memory drainer? 
And just out of curiosity, why didnt
you do a custom java.util.ResourceBundle? meaning implement ListResourceBundle
or ResourceBundle and the implementation can still prime fields (just like
in the current proposal).? Rationale: using a JDK class is familiar territory,
and you may still be able  to bypass today's overhead. 

Mazen.

John Arthorne/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

02/23/2005 01:49 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-core-dev] New platform NLS support

That's a bit tricky because you would then have multiple classes with the
same name, loadable by the same class loader.  Special magic in the
platform class loaders would probably be needed.  It's certainly possible
with the new scheme to assign the field ahead of time and avoid the initialization
that currently happens on load - for example if you were already shipping
different versions of your product for each language. I think a major value
of plug-ins using an Eclipse NLS API, is that if we come up with further
optimizations later on, they can be applied to the immediate benefit of
all with little further effort. 

Also keep in mind that if you have no attachment to the .properties file
format, java.util.ResourceBundle allows you to use a pure class-based system
that does a language-specific class lookup to load the bundle, as you suggest.
 The Eclipse API is a middle ground that has very good runtime memory
characteristics but still retains the .properties file format that is familiar
and often favoured by translators. 


Bob Foster wrote on 23/02/2005 01:12:08 PM:

> Did you consider allowing the message class to be loaded dynamically
at 
> startup, like fragment classes? This would require that translators
run 
> the tool and compile a class per properties file, but would reduce
the 
> need for runtime interpretation to zero. (The default class, if loaded,
> would simply do what it does now.)
>