what to do with java.lang.reflect.Proxy ???

[snatchitup]

I have 'foo'led around with java.lang.reflect.Proxy, additionally,
have done plenty with Cass.getClasses() and invocation. I'm in the
J2EE world, and WebServices.

Basically, I haven't come up with an "Original Thought" on how to use
this to make my job of writing applications easier. I want it to do
my work for me.

I've learned in the past that the lesser used portions of a language
that implement some sort of indirection is where the hidden gems are;
that can lead to productivity enhancements by building tools such as
code generators.

I've used getClasses(), getMethods(), and invoke() to do some
automating the process of generating data objects from beans.

Is there something I'm missing on the usefulness of Proxy to an
application developer. I'm not looking to write a "logging" tool.

The main drawback I see with Proxy, is that I should re-engineer alot
of the code to make more extensive use of interfaces.

 

[Filip Larsen]

I have 'foo'led around with java.lang.reflect.Proxy, additionally,
have done plenty with Cass.getClasses() and invocation. I'm in the
J2EE world, and WebServices.

Basically, I haven't come up with an "Original Thought" on how to use
this to make my job of writing applications easier. I want it to do
my work for me.

Like most other reflection functionality, Proxy objects really shine in
application frameworks and tools, and not so much in application code
itself. In fact, I would go so far as to say that application code
should be mostly free of reflection code. If you feel the need to use
reflection, chances are you are trying to write framework functionality
and not application functionality.

As an example of how Proxy could be used, consider a tool that given an
object can return a new object with the same interface, but where all
methods are synchronized (kind of a generalization of the
Collections.synchronizedCollection family of methods). The
implementation of such a tool would be very easy using the Proxy object.
Local application code can then use the tool to privately implement the
functionality of giving synchronized access:

public class Tool {
public static Object synchronizedObject(Object obj) {
... // Proxy to obj is made and returned
}
}

public interface AppThingy {
...
public AppThingy synchronizedThingy();
}

public class MyAppThingyImplementation
implements AppThingy {
...
public AppThingy synchronizedThingy() {
return (AppThingy) Tool.synchronizedObject(this);
}
}


Other examples of Proxy usage could be:

- to turn local method invokations into remote method invokations,
- to schedule method invokations on a background thread (I actually use
this),
- to provide a security check and context for method invokations,
- to log invokations and their return.

Off the top of my head I would venture to say that the Proxy class can
be used in cases where you want a general implementation for some of the
parts in a solution that uses the Proxy pattern. And with the Proxy
pattern being fairly common, the Proxy class can potentially be very
useful.


Regards,

 

[Dale King]

I have 'foo'led around with java.lang.reflect.Proxy, additionally,
have done plenty with Cass.getClasses() and invocation. I'm in the
J2EE world, and WebServices.

Basically, I haven't come up with an "Original Thought" on how to use
this to make my job of writing applications easier. I want it to do
my work for me.

I've learned in the past that the lesser used portions of a language
that implement some sort of indirection is where the hidden gems are;
that can lead to productivity enhancements by building tools such as
code generators.

I've used getClasses(), getMethods(), and invoke() to do some
automating the process of generating data objects from beans.

Is there something I'm missing on the usefulness of Proxy to an
application developer. I'm not looking to write a "logging" tool.

The main drawback I see with Proxy, is that I should re-engineer alot
of the code to make more extensive use of interfaces.

It would be rare to use it in normal application code. A good example of how
it can be used is EasyMock which can generate "Mock" objects that implement
some interface which are very useful for writing unit tests.

 

[Larry A. Barowski]

I have 'foo'led around with java.lang.reflect.Proxy, additionally,
have done plenty with Cass.getClasses() and invocation. I'm in the
J2EE world, and WebServices.

Basically, I haven't come up with an "Original Thought" on how to use
this to make my job of writing applications easier. I want it to do
my work for me.

I've learned in the past that the lesser used portions of a language
that implement some sort of indirection is where the hidden gems are;
that can lead to productivity enhancements by building tools such as
code generators.

I've used getClasses(), getMethods(), and invoke() to do some
automating the process of generating data objects from beans.

Is there something I'm missing on the usefulness of Proxy to an
application developer. I'm not looking to write a "logging" tool.

The main drawback I see with Proxy, is that I should re-engineer alot
of the code to make more extensive use of interfaces.

One thing missed in the previous replies: Proxys are great for
using
functionality that is not available on all targets. For example, a Proxy

implementing MouseWheelListener can be used to support the
mouse wheel on Java 1.4, for code that must also run on Java 1.3.
And any serious Java application should at least support an
MRJQuitHandler so the application menu "Quit" item will work under
Mac OS X (the default behavior is just to kill the application).
You can do the same thing using stubs, but you never know when
a JVM is going to try to load an "usused" class. I've seen stubs that
work fine on one target fail on another - I'm not sure why, maybe
the unused classes are needed by the JIT compiler.

-Larry Barowski