Closed Bug 163817 Opened 22 years ago Closed 22 years ago

LiveConnect JavaScript to Java Data Type Conversion Error

Categories

(Core Graveyard :: Java: Live Connect, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: joshua.xia, Assigned: joshua.xia)

References

()

Details

Attachments

(2 files)

steps to reproduce
1.start the Netscape 7.06_OEM 
2.Surfing http://www.mozilla.org/quality/browser/front-
end/testcases/oji/jstojava/jstojavatest10.html
3.Open javaScript console.

ERRORS ON JAVASCRIPT CONSOLE:
_____________________________________________________________________________
Error: testcases[tc] has no properties
Source File: http://www.mozilla.org/quality/browser/front-
end/testcases/oji/jstojava/browser.js
Line: 105
Error: Unable to convert JavaScript value NaN to Java value of type long
Source File: http://www.mozilla.org/quality/browser/front-
end/testcases/oji/jstojava/long-003-n.js
Line: 33

The Conversion should be pass and NaN should be conversed to 0
I take it
Assignee: rogerl → joshua.xia
OS: Windows 2000 → All
Status: NEW → ASSIGNED
Brendan,

Would you like to check this one?

Thanks a lot!
can you get the \'s to all line up? (indentation appears to be 4 space *except*
for the last level of indentation on java_value->j = 0; which is 3 space)
What specification states that NaN becomes 0 in a long context?  If no
specification states that, why would it be a reasonable thing to do?  Why is
raising an exception the wrong thing to do?

If this is specified somewhere, don't waste your time explaining it--I'd be
happy with a URL to the document stating it.
My mistake.  I now see the precedent in that.  Ignore my previous comment.
Comment on attachment 96143 [details] [diff] [review]
NaN becomes zero when converted to integral value

1) fix the indentation to use four spaces, as timeless pointed out.

2) else after break is a non-sequitur (so was else after goto in the old code).

3) Wouldn't it be better to set member_name = (member_type) 0; and not break,
falling through to the code in the macro that sets java_value->member_name =
member_name?

/be
Attachment #96143 - Flags: needs-work+
I have the same question as in Comment #4 above: 

> What specification states that NaN becomes 0? 

The testcase jstojava/long-003-n.js was written before I got here.
But notice the name of the test includes "-n". This means it is
supposed to produce an error: that is the criterion for the test 
passing! The error Joshua got,

"Error: Unable to convert JavaScript value NaN to Java value of type long"

is the EXPECTED result of this test. When I run it in the standalone
LiveConnect shell, I get the same error, and the test driver records
the test as having passed. 

Was this test written in error? At some point, someone expected
this conversion to fail. Has some standard changed on this point?
There's no written-in-English standard.  What did 4.x do for the NaN-as-int
case, Phil, can you test?

/be
Attached file Reduced HTML testcase
The reduced testcase contains the heart of jstojava/long-003-n.js :

<script>
document.write('<br>Testing java.lang.Long.toString(NaN)<br>');
document.write('If you do not see the result below, look in the JS Console<br>');
document.write('The result is: ' +  java.lang.Long.toString(NaN));
</script>


OUTPUT IN NN4.7
The result is: -9223372036854775808
(and no error in the JS Console)

OUTPUT IN MOZ
(no output)
Error: Unable to convert JavaScript value NaN to Java value of type long
Yuck, 4.x was just broken.  What did 6.x do?

I smell an INVALID coming up for this bug.

/be
Same result as in my current Mozilla build:

OUTPUT IN NN6.2 RTM
(no output)
Error: Unable to convert JavaScript value NaN to Java value of type long
In http://developer.netscape.com/docs/manuals/index.html?
content=javascript.html 's "Core JavaScript Guide" 's "Java to JavaScript 
Conversions", it point out that Conversion rule is "NaN values are converted to 
zero",

and the testcase 's EXPECTED result is:

typeof (java.lang.Long.toString(NaN)) = object               PASSED!
String(java.lang.Long.toString(NaN)) = 0                     PASSED!
Joshua: 

1. I found the phrase you quote, "NaN values are converted to zero",
under the section JavaScript to Java Conversions, not Java to JavaScript.

Reference:
http://developer.netscape.com/docs/manuals/js/core/jsguide15/lc.html


2. The testcase jstojava/long-003-n.js is a "negative" test; that is
why it has the "-n" in its name. It only passes if it produces an error.


3. I do not normally run this test in the browser, but in the LiveConnect shell
using our Perl test driver (js/tests/jsDriver.pl). It always produces the error
we are seeing, and the test driver always records a pass for this test.


4. Are the following lines in the reference you're using? 

   typeof (java.lang.Long.toString(NaN)) = object               PASSED!
   String(java.lang.Long.toString(NaN)) = 0                     PASSED!

If so, can you give the exact URL for that? There may have been
some confusion on the author's part -
Here is a more exact URL to the documentation Joshua found on
JavaScript to Java data type conversions:

http://developer.netscape.com/docs/manuals/js/core/jsguide15/lc.html#1037125

In the lower half of the page, you will see the phrase, 

           "NaN values are converted to zero"

So either this documentation is incorrect, or else the testcase is -
Phil, what does Flanagan's latest Rhino book say in its LiveConnect data
conversion section?

/be
In the latest edition (Edition 4, January 2002), Flanagan give the same
treatment as in Edition 3. He explains that the JavaScript number type
can convert to Java numerical types like byte, short, int, etc.,
but without mentioning any rules for edge cases like NaN. 


Here is what the LiveConnect shell does on various conversions of NaN.
It errors for Byte, Short, Integer, Long. It succeeds for Float and Double:

js> java.lang.Byte.toString(NaN)
InternalError: Unable to convert JavaScript value NaN to Java value of type byte

js> java.lang.Short.toString(NaN)
InternalError: Unable to convert JavaScript value NaN to Java value of type short

js> java.lang.Integer.toString(NaN)
InternalError: Unable to convert JavaScript value NaN to Java value of type int

js> java.lang.Long.toString(NaN)
InternalError: Unable to convert JavaScript value NaN to Java value of type long

js> java.lang.Float.toString(NaN)
NaN

js> java.lang.Double.toString(NaN)
NaN


Note the the test coverage for this is contained in two directories
in our repository:  mozilla/js/tests/lc2 and lc3. These stand for,
I presume, "LiveConnect 2" and then "LiveConnect 3", although I haven't
been able to tell if there is any practical difference between the 
tests in either directory. The test we've been discussing is in the
lc2 directory: 

           mozilla/js/tests/lc2/JSToJava/long-003-n.js
By doing some archaeology in the js/tests/lc2 directory, I found that
conversion of NaN to a Java Long was deliberately commented out of
the positive test 

           mozilla/js/tests/lc2/JSToJava/long-002.js


//    a[i++] = new TestObject( "java.lang.Long.toString(NaN)",
//                              java.lang.Long.toString(NaN), "0" );


and then added to the negative test we've been discussing:

           mozilla/js/tests/lc2/JSToJava/long-003-n.js
Also note that Java has constants to represent NaN (and other fun non-numbers)
in floats and doubles (Float.NaN and Double.NaN of type |float| and |double|,
respectively); no such constants exist for other numerical types.
This exception throwing rather than silent conversion of NaN to 0 is clearly a
liveconnect feature, and has been for a long while in the modern, post-4.x
world.  4.x is just broken.  I say we mark this bug INVALID.

/be
I caught a wrong bug.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Marking Verified -

Thanks to all who helped on this bug; particularly to Joshua,
who uncovered the documentation error on our own site for this.

I have filed bug 164308 on this:
"Wrong documentation of LiveConnect JS-to-Java conversion of NaN"


NOTE: the role of negative tests in our testsuite is outlined at

         http://www.mozilla.org/js/tests/library.html

See " Testcases with filenames ending in -n". This page also contains
a link explaining our new shell test driver, which is what I use:
http://lxr.mozilla.org/mozilla/source/js/tests/README-jsDriver.html

The output of our negative tests when run in a browser may
be misleading to the user; I will have to look into that -
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: