This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: java.util.Date.toString() really slow?


On 4 Jun 2002, Tom Tromey wrote:
> Bryce> Presumably it would be reasonable to cache negative results for
> Bryce> resource bundle (and class?) lookups. People don't expect to be
> Bryce> able to dynamically add new resource bundles to a running
> Bryce> application, right?
> 
> I wonder.  Maybe someone could test the JDK and see what it does.  You
> could imagine wanting to dynamically add resource bundles to some
> long-running application like a web server -- it isn't a completely
> absurd idea.

My thoughts:

- Dynamically replacing locale data or other system bundles isn't likely
to happen, so Per's suggestion of caching the default locale bundle is a
good idea.

- Reloading application bundles can be useful, just as reloading classes.  
However a bundle should live as long as the classloader that loads it.
Testing for addition or modification of a bundle on each call will be
expensive.  (This is my opinion, I have no idea what the JDK does.)

- A well-designed web server will allow an administrator to manage
classloaders, so that classes and resources can be added/modified on the
fly.  (Some implementations try to auto-reload classes, that turns out to
be less successful than it might seem.)

So the decision to cache the resource might best be left with the
classloader, and the system classloader might as well cache its results
forever.  (Mine's a pragmatic view not necessarily based on fact, but on
real experience with sometimes ill-behaved web applications.)

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]