Subj : Re: Rhino: Wrapping (existing) Java Object (1.5R4)
To   : netscape.public.mozilla.jseng
From : JeremyK@comcast.net (Jeremy)
Date : Thu Nov 20 2003 08:17 am

Igor Wrote:

> You can not replace methods of existing objects in JVM and Rhino could 
> not help here.

While Rhino is amazing, I was not thinking of asking it to do
something that the JVM itself couldn't do ;-)

What I was thinking of was more along the lines of this.  The ability
to pass both an existing Java instance and a JavaScript object to the
JavaAdapter.  Then, have the JavaAdapter operate as follows:

  -- Generate a subclass (as usually)
  -- For methods defined in the JavaScript object, delegate those to
the JavaScript object.
  -- For methods not defined in the JavaScript object, delegate those
to the existing Java object.

This isn't so different from what JavaAdapeter currently does, except
that it completely skips generating methods not in the JavaScript
object, which means they are implicitly inherited from the superclass.

Perhaps the Java class that best illustrates my thought process is
java.io.FilterInputStream.  This class both extends InputStream as
well as "has a" InputStream.  All of the methods in FilterInputStream
simply delegate to the "has a" InputStream.  In some sense, the fact
that the FilterInputStream extends InputStream is irrelevant (I mean,
it's necessary for type compatability, but the FilterInputStream won't
ever use any of the member variables inherited from the InputStream).

> >   2) Is it possible to pass contructors arguments to the JavaAdapter
> > class?
> 
> No, but it should not be that hard to extend JavaAdapter to do that: 
> patches are welcome!
> 

I may give that a try.

> > ...  If, within my JavaScript, I create the Java object, then I
> > can't wrap the existing instance such that I could override one or
> > more of the methods.  (I suppose technically I could: I could write a
> > Java object that overrode *every* method in the Java object.  Then, I
> > could let the JavaAdapter create a new instance of the class, which
> > would really just be a shell that delegated all calls to JavaScript. 
> > The JavaScript could then delegate to the 'real' (original) Java
> > object as required.  While this might work, this is probably ugly
> > enough that I'd just resort to writing the desired code in Java).
> 

Igor Wrote:

> For workaround you do not need to override each and every method in Java 
> class. You can simply create a subclass that has a default constructor 
> in which it calls the super class constructor using static variables to 
> pass necessary arguments. Then you can use JavaAdapter as is against 
> this class: you will just need to fill static variables with necessary 
> values before constructing adapter objects.
> 
> If you can not use static variables, then java.lang.ThreadLocal is your 
> friend.
> 
Upon rereading my original post, I discovered a key typo:

 I suppose technically I could: I could write a Java***** object that
overrode *every* method in the Java object.

The Java***** should have read JavaScript.

What I was trying to express was a "pure JavaScript" workaround to the
situation.  If the user needs to write a Java class, then might just
as well do whatever it was they were trying to do in Java.

Thanks for your reply,

Jeremy

.