Hi Sonny,
> I've never used the other methods and I'm not sure how they are used.
Hmm, maybe two little remarks:
* if a shortcoming in the Jython engine has been uncovered and
should be corrected, it would be desirable to correct the
shortcoming wherever it may appear in the Jython engine elsewhere,
o reasoning: you never know how Java programmers will use the
Jython engine, so code that works with "exec(...)" may not
work with "apply(...)" which would baffle BSF users,
* here are the different kinds of script engine invocations in BSF
(cf. e.g.
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/docs/docs.apache.bsf/org/apache/bsf/BSFEngine.html>)
and what they are meant for:
1. "exec(...)": Java coder needs to execute a script, there are
no arguments to be passed to the script nor is there any
return value expected,
2. "eval(...)": Java coder wants to evaluate a script, does not
need to supply any arguments, but expects a return value,
3. "apply(...)": Java coder needs to execute a script, needs to
supply arguments to the script and *is* expecting a return
value,
4. "call(...)": Java coder wants to invoke a method in a
script, supplying arguments and expecting a return value.
So you see, your patch would only alleviate the class reference issue in
the Jython engine for case # 1, where it probably could also help in
cases #2 and #3. (Maybe also for a "compileScript(...)" method if that
makes sense in the context of Jython.)
What do you think?
Regards,
---rony
P.S.: There comes a default implementation for the BSFEngine interface,
which easies the creation of specific BSF engines considerably, cf.
<http://wi.wu-wien.ac.at/rgf/rexx/bsf4rexx/docs/docs.apache.bsf/org/apache/bsf/util/BSFEngineImpl.html>.
