[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic Proxy Classes



On Tue, 11 Jul 2000, Johann Romefort wrote:
> Hi Ozonies,
> 
> There is a new Dynamic proxy class API in JDK1.3
> that could be interesting for generating Ozone Proxies
> on the fly.
> 
> Here is the Sun's doc url:
> 
> http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html
> 
> To quote the doc:
> 
> "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. "
> 
> If the idea seems doable and interesting may be we could
> provide both way to generate Proxy (OPP and this waty)
> at least until everyone has switched to JDK1.3

The JSD1.3 proxies are very interesting but so far I don't think that we should
drop the ozone proxies immediately. They are faster than jdk proxies. opp
generates proxy code that is optimized for the needs of ozone. opp of ozone
0.5 distinguishes between proxy invocation from the client and inside the
server. Inside the server the generated proxy code *directly* invokes the
target method. Here is some opp generated code:

   public java.lang.Integer age () throws java.lang.Exception {
      try {
         Object target = link.fetch (this, Lock.LEVEL_READ);
         if (target != null) {
            return (java.lang.Integer)ResultConverter.substituteOzoneCompatibles (((AutoImpl)target).age());
            }
         else {
            Object[] args = {};
            Object result = link.invoke (this, 0, args, Lock.LEVEL_READ);
            return (java.lang.Integer)result;
            }
   ...

If the link.fetch() returns an object then we are inside the server. For this
case opp has generated a direct call to the age() method of the target. In case
we are outside the server we are sending the method index and the server will
invoke the target method via Method.invoke, just like jdk proxies.

This is way faster than searching the corresponding Method object and calling
via Method.invoke().

The disadvantage of the current ozone solution is that the proxies have to be
generated 'by hand'. But this is not related to the ozone proxies technology
itself. It was just the first solution that came in our minds when we started
to implement this. Proxy generation cold also tke place on the fly. Should be
no problem to implement this.


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
SMB GmbH                                   http://www.softwarebuero.de