--- Samuele Pedroni <pedronis@...>
> Leo User wrote:
> > Some minor progress with the PyJavaMethodProxy.
> > developed it to the point where it crashes with
> > exact same stack as the stack printed out for an
> > unmodified jython3005. Not that its good that its
> > crashing, it is good that it is the same crash.
> > A key piece appears to be to be able to just
> > the parameters if the param list matches what Id
> > expect for a python call:
> > method(PyObject args, String kwords)
> > method(PyObject args)
> > this helps in that there doesn't need to be any
> > unpacking or packing of the arguments, or
> > for that matter. I am a little worried about
> > overloads:
> > method(PyObject args)
> > method(int i)
> most of the complexity of the original
> PyReflectedFunction and related
> classes is about properly resolving and converting
> in the presence of
> overloaded Java methods. This is all necessary in
> the general case.
Id be surprised if there ever was a true way to deal
with ambiguous situations well. Maybe there is. Ive
got a couple of ideas to try out to make the situation
simpler further still.
> The necessary logic is involved, and its current
> incarnation still buggy
> (there's a prototype of better rules in the
> sandbox), also is not
> flexible enough to do the right thing in case we had
> Python bool and in
> the presence of int/boolean overloading.
The aim in generation is to do most of the
precomputation at generation time. And if what it
can't do then, try to do as simply as possible during
> This all needs to be cleaned up and fixed before
> thinking about shortcuts.
> Notice also that Jython is supposed to work to some
> extent even in the
> presence of a security manager, this rules out
> approaches purely based
> on generating classes at runtime. This is one of the
> areas for which
> jythonc was most useful, and jythonc code was still
> able to cope with
> arbitrary java classes at runtime because of the
> runtime generally using
Im not sure why this is a negative. Jython already is
defining classes during runtime, so it isn't a foreign
event that is being introduced by generating proxies.
> An adaptive combination of approaches would probably
> be the best solution.
Ive pondered using some form of method invocation
monitoring to decide if the proxy should be reflective
or plain old byte code. On the other hand, cranking
method calls as close to the method as possible in any
situation seems nice.
What will be interesting to see is if the
invokedynamic instruction could simplify this stuff
even further. Ill have to reread the what's out
there, but it seemed like alot of cast checking could
be dispensed with.
Have a burning question?
Go to http://www.Answers.yahoo.com and get answers from real people who know.