Closed Bug 520533 Opened 16 years ago Closed 6 years ago

adapter for Java interface implementation can yield fixed/default result values

Categories

(Rhino Graveyard :: Core, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: theobald3, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Creative ZENcast v1.02.12 Build Identifier: - JavaScript object implementing a Java interface via an anonymous proxy object - anonymous proxy built in a specific way (cf. code fragement below) - invocation of Java interface function yields wrong, fixed result In debugging, I got the impression that problematic result was eventually computed in "org.mozilla.javascript.ScriptRuntime.toBoolean(Object)" when entering the Scriptable case instead of accessing the actual boolean value. It is thus likely that the issue occurs with any type, not just with boolean. Reproducible: Always Steps to Reproduce: Execute the following program fragment. - Rhino 17.r2 - Java 6 update 16 ------------------------------------------------------------------- function jsBoolean() { return false; } function buildIt( toCall ) { var anonProxy = { _fct0 : toCall, needsGui : function( ) { return this._fct0(); } }; return new java.beans.Visibility( anonProxy ); } var fObj = buildIt( jsBoolean ); print( fObj.needsGui() + "\n" ); ------------------------------------------------------------------- Actual Results: Executing the above with Rhino yields printout 'true'. Expected Results: Behaviour deviates from expectation in two main points: - I expect either an error, or the result 'false'. - When executed via jrunscript from the Java SE 6 distribution, result is 'false'. Different results for JavaScript implementations are not expected. The above is fully synthetical coding, intended to reproduce the issue with as little additional coding/requirements as possible, e.g. I took an arbitrary Java interface from the core JDK in order to avoid additional Java coding. - In particular, the code fragment is basically non-sensical beyond the purpose of reproducing the issue. - For my own usage, the issue is irrelevant/avoided. I report this here to make aware of the issue, not to seek a solution for my case.

Closing. Bug management is now done here:
https://github.com/mozilla/rhino

Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.