Proxy Class (for compiling purpose)?
Since JDK 1.3, there is a Proxy class that allows us to dynamically generate Java object classes from scripts. We can use it to implement interface functions etc and calls to these functions would be redirect to a hook.
My question is, will Sun consider to extend this functionality to compiled Java classes using some mechanism?
For instance, I would like to statically link to some JavaScript functions or read the variables of some JavaScript objects. That is a lot easier than calling some long functions to access the variable/functions.
The problem is the compiler would not understand such need unless the variables/functions are present in the statically compiled class files.
Would it possible to a compile time class executed by the compiler to generate a list of variables/functions and types accessible.
For example:
// resource/test.js needs to be in the class path
import javascript.ProxyClassHandler("resource/test.js");
publicclass Foo
{
publicstaticvoid main ()
{
// javascriptobject is the package of the object generated from resource/test.js
javascriptobject.Test = (javascript.Test)JavaScript.eval ("resource/test.js");
new Thread (Test.getRunnable ()).start ();
System.out.println (Test.foo);
}
}
In the example above, the function getRunnable () and the field foo are statically linked at coimpile time.
This capability can be useful because it allows Java to have better mixing with other scripting engines running on top of JVM.
Currently, except the variable part which is not being handled by Proxy class, there is a workaround by generating an actual interface that correspond to javascript.Test. And then use that for the compiling purpose. The problem is that it is a two step process and does not handle variables. When we are dealing with heavy mixing of scripts and Java code, it can become a serious pain.
What do you think of this idea?
Message was edited by:
coconut99_99
# 1
probably not. it promotes poor programming practices, such as not coding to an interface. it sounds like it would be handy, but in reality you'll find you mostly don't need it.
another problem with it is that the proxy class would have to extend the real class, and to do that, the real class would have to be loaded in order to extend it, and if you had any static initializers, they would be run
if you really want to proxy classes, there are libraries that will do it for you, such as CGLIB, BCEL or ASM
# 2
Well, interface simply cannot solve all the problems. When one deals with scripting engine a lot, it is the general case that it is much easier to access fields and functions of Java objects, but extremely painful to access fields and functions of the script objects. Every scripting engine has its own way of how to getting the scripted objects exposed.
Proxy of JDK1.3 alleviate the problem somewhat, but it is still problematic overall. Even if we use interfaces, we would have to "cast" the object returned from the scripting engine anyways, already "violating" the OO principle ^_^ Besides, scripts can generate GUI components and sub-classing them within scripting engine just fine, how to return the script object?
If scripting engines, such as BeanShell and Rhino JS are capable of generating class byte codes, why not have a convenient way of importing these classes (having two steps complicates maintainence), and thus being able to access/link to the exposed script object statically. This way, we can discover problems at compile time rather than having to run the actual code and discover (if we ever) the runtime exceptions.
Here is another case where it would be immensely useful.
Say there is an XML parser that generate classes dynamically, and inserting class members as attributes as were read from an XML. Currently, there are two ways of accomplishing the similar thing. One is through JAXB or similar, which is known for slowness, requiring XML Schema, and generating classes. These three reasons remove JAXB from general use. Another is through DOM, which is used in general. However, this does not mean to say it is simple to use DOM. It is very wordy. One has to use myDomTree.getAttribute ("abc") to access an attribute, while on the other hand in other languages such as Python and JavaScript, one could potentially access DOM tree in the form of myDomTree.abc. With import method described in the original post, we would be able to access the fields, which is somewhat like auto importing the result from JAXB class generated. Compiler may maintain the generated class cache as needed if we are compiling many classes.
Of course this still does not give us full power of meta objects of what Python/JS provides, they have their own problems having such flexibilities in general, but it could provide Java such capability when there is such needed.
