LiveConnect JavaScript to Java Data Type Conversion Error



17 years ago
8 years ago


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


Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
steps to reproduce
1.start the Netscape 7.06_OEM 
3.Open javaScript console.

Error: testcases[tc] has no properties
Source File:
Line: 105
Error: Unable to convert JavaScript value NaN to Java value of type long
Source File:
Line: 33

The Conversion should be pass and NaN should be conversed to 0

Comment 1

17 years ago
I take it
Assignee: rogerl → joshua.xia
OS: Windows 2000 → All


17 years ago

Comment 2

17 years ago
Created attachment 96143 [details] [diff] [review]
NaN becomes zero when converted to integral value


Would you like to check this one?

Thanks a lot!

Comment 3

17 years ago
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)

Comment 4

17 years ago
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.

Comment 5

17 years ago
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 =

Attachment #96143 - Flags: needs-work+

Comment 7

17 years ago
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?


Comment 9

17 years ago
Created attachment 96263 [details]
Reduced HTML testcase

Comment 10

17 years ago
The reduced testcase contains the heart of jstojava/long-003-n.js :

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));

The result is: -9223372036854775808
(and no error in the JS Console)

(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.


Comment 12

17 years ago
Same result as in my current Mozilla build:

(no output)
Error: Unable to convert JavaScript value NaN to Java value of type long

Comment 13

17 years ago
content=javascript.html 's "Core JavaScript Guide" 's "Java to JavaScript 
Conversions", it point out that Conversion rule is "NaN values are converted to 

and the testcase 's EXPECTED result is:

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

Comment 14

17 years ago

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


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/ 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 -

Comment 15

17 years ago
Here is a more exact URL to the documentation Joshua found on
JavaScript to Java data type conversions:

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?


Comment 17

17 years ago
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)

js> java.lang.Double.toString(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: 


Comment 18

17 years ago
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 


//    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:


Comment 19

17 years ago
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.


Comment 21

17 years ago
I caught a wrong bug.
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 22

17 years ago
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

See " Testcases with filenames ending in -n". This page also contains
a link explaining our new shell test driver, which is what I use:

The output of our negative tests when run in a browser may
be misleading to the user; I will have to look into that -


8 years ago
Component: Java: Live Connect → Java: Live Connect
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.