1.6 better than Rhino

T

Timasmith

I've been using Rhino for a while with java 1.5. Now having spent a
couple of hours troubleshooting why the script was converting my Long
object into a double value, I would consider changing to 1.6 to avoid
scripts messing with my data type objects.

Any ideas if Java 1.6 has an improved integration with Java in this
area?

thanks

Tim
 
T

Tom Hawtin

Timasmith said:
I've been using Rhino for a while with java 1.5. Now having spent a
couple of hours troubleshooting why the script was converting my Long
object into a double value, I would consider changing to 1.6 to avoid
scripts messing with my data type objects.

Any ideas if Java 1.6 has an improved integration with Java in this
area?

The implementation is pretty much identical to Rhino 1.6R2. In fact, you
don't get the source if you download the JDK source. The most
significant difference is the package name.

Tom Hawtin
 
K

Knute Johnson

Tom said:
The implementation is pretty much identical to Rhino 1.6R2. In fact, you
don't get the source if you download the JDK source. The most
significant difference is the package name.

Tom Hawtin

What's a Rhino?
 
C

Chris Uppal

[Since I've alreay emailed this directly to Tim by mistake once, /and/ reposted
it here, but in the wrong thread, why no just post it again ? Maybe I'll post
it lot's of times. Maybe I'll spam the world....]
I've been using Rhino for a while with java 1.5. Now having spent a
couple of hours troubleshooting why the script was converting my Long
object into a double value, I would consider changing to 1.6 to avoid
scripts messing with my data type objects.

As far as I know, the only numeric type ECMAScript has is 64-bit floating
point. So there's very little else a JavaScript interpreter is allowed to
do.

Of more practical value to you, I imagine, is to know why Rhino makes your
long (when converted to floating point) behave and/or look like a floating
point value instead of coyly pretending to be an integer. I can only guess
that the original value is outside some range. For instance ECMAScript's
built in Number -> String conversion will only represent "integer" Number
values as if they /are/ integers if they lie within some range -- the rules
are a little complicated, but I think that range is +/-1.0e21.

What is the value of the original long ? And what are you doing with the
resulting JavaScript number to be able to see that it has "turned into"
floating point ?

-- chris
 
T

Timasmith

[Since I've alreay emailed this directly to Tim by mistake once, /and/ reposted
it here, but in the wrong thread, why no just post it again ? Maybe I'll post
it lot's of times. Maybe I'll spam the world....]

Timasmithwrote:
I've been using Rhino for a while with java 1.5. Now having spent a
couple of hours troubleshooting why the script was converting my Long
object into a double value, I would consider changing to 1.6 to avoid
scripts messing with my data type objects.

As far as I know, the only numeric type ECMAScript has is 64-bit floating
point. So there's very little else a JavaScript interpreter is allowed to
do.

Of more practical value to you, I imagine, is to know why Rhino makes your
long (when converted to floating point) behave and/or look like a floating
point value instead of coyly pretending to be an integer. I can only guess
that the original value is outside some range. For instance ECMAScript's
built in Number -> String conversion will only represent "integer" Number
values as if they /are/ integers if they lie within some range -- the rules
are a little complicated, but I think that range is +/-1.0e21.

What is the value of the original long ? And what are you doing with the
resulting JavaScript number to be able to see that it has "turned into"
floating point ?

-- chris

The original value was only 1000013 and was passed as a Long object
using this (simplified) Java:

<pre>
Context cx = Context.enter();
Scriptable scope = new ImporterTopLevel(cx);

Object ctx = Context.javaToJS(new Long(1000013), scope);
ScriptableObject.putProperty(scope, "longID", ctx);

result = cx.evaluateString(scope, script, "<>", 0, null);
return Context.jsToJava(result, javaclass);
Context.exit();
</pre>

The script puked due as I use the script to pass the value along to a
query. The Hibernate query died as it found a double value 1000013.0
being bound to a long parameter.

<pre>
qry = new MyQuery();
s = "from MyTableObject v"
+ " where v.id = :longID";

qry.addParam(new QryParam("longID",longID));
qry.addParam(new QryParam("startDATE",startDATE));

</pre>

What is frustrating is that QryParam takes parameters (Object, Object)
so there was no need at all for the script to change the Object to a
double value. I pass object parameters all the time for real java
objects, but for some reason it bastardized my Long. The Calendar
subclass was fine.
 
C

Chris Uppal

Timasmith said:
The original value was only 1000013 and was passed as a Long object

Then I'm afraid I have no idea what would be causing the problem.

Sorry....

-- chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top