> > To really improve performance we will need to assess
> > different tradeofs:
> > * central cache bottleneck
OK, this is alleviated with the local cache (L1)
> > * per-request cache overhead
OK, this has been clarified, acts as a L1 to the global L2 cache.
I could maybe think of some ways of squezing some more juice out of this one.
> > * compiled methods (e.g. SDK1.3 reflection proxy classes/templates?)
>
> Tell me more about this...
>From the SDK1.3 documentation on new features since 1.2:
"Reflection Enhancements
A new API for dynamic proxy classes has been added to the Java 2 Platform.
A dynamic proxy class is a class that implements a list of interfaces
specified at runtime such that a method invocation through one of the
interfaces on an instance of the class will be encoded and dispatched to
another object through a uniform interface. Thus, a dynamic proxy class
can be used to create a type-safe proxy object for a list of interfaces
without requiring pre-generation of the proxy class, such as with compile
time tools. Dynamic proxy classes are useful to applications that need to
provide type-safe reflective dispatch of invocations to objects that
present interface APIs. For example, an application can use a dynamic
proxy class to create an object that implements multiple arbitrary event
listener interfaces -- interfaces that extend java.util.EventListener
-- to process a variety of events of different types in a uniform fashion,
such as by logging all such events to a file."
Hmm, this is many words missing a juicy example. I've seen it at
the JDC, under the "Articles"->"Data Types, Structures and Wrappers"->
"Explore the Dynamic Proxy API". At the moment I'm not sure this can be
of use (without additional compilation into memory...).
:) Chirstoph
