Closed
Bug 41111
Opened 24 years ago
Closed 22 years ago
java.lang.String vs. primitive string type
Categories
(Rhino Graveyard :: Core, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
1.5R4
People
(Reporter: norrisboyd, Assigned: norrisboyd)
Details
rubys@us.ibm.com wrote: That code snippet below is actually the same test as the one that I said that works. Sorry. I misread your note. Note that there actually are three cases. (1) java.lang.String, (2) org.mozilla.javascript.NativeString, and (30 org.mozilla.javascript.NativeJavaObject wrappered java.lang.String. It is the third case that is not handled well. If org.mozilla.javascript.NativeString were enhanced to support all of the neccessary functions and attributes of java.lang.String, and the code were more consistent on how it chose to wrapper String objects, then you could eliminate a source of confusion while retaining backwards compatibility. Another solution would be to find all cases where strings are handled (e.g., ScriptRuntime.toNumber(Object)) and add specific code to handle NativeJavaObject wrappered Strings as well. That sounds like a reasonable approach. I'll open a bug for it and look into it once we finally wrap up the 1.5 final. - Sam Ruby Norris Boyd <nboyd@atg.com> on 05/30/2000 04:06:31 PM To: Sam Ruby/Raleigh/IBM@IBMUS cc: Rick Rineholt/Raleigh/IBM@IBMUS Subject: Re: java.lang.String vs. JavaScript "string" Actually, now that I think about it, we did make a change not too long ago that increases the priority of a [[DefaultValue]] conversion of a wrapped java.lang.String to a JavaScript primitive string. So that fixes the code snippet below: js> foo = "5"; 5 js> foo - 3 2 There are still some instances where problems may crop up, but they should be less with this change. I'm trying to post a new zip file for Rhino, but have discovered that I don't have access anymore to post. I'm working to get around that. --N rubys@us.ibm.com wrote: > In exploring code written using Rhino (and Rick's VB like front end), we > find that there are a number of differences in ways that these two types of > strings are handled. It would seem to me that these differences would be > confusing to an end user. In particular, the following works: > > var foo = "5"; > var bar = foo - 3; > > However, if foo is set as the return from a liveConnect type of call (i.e., > it gets a true java.lang.String), then the user sees an error message that > the object does not have a "toDouble" method. At a minimum, a more > specific error message would be appropriate. > > A simple fix would seem to me to keep Strings always in their JavaScript > format. In particular, if the following call in NativeJavaMethod were > changed from: > > Object wrapped = NativeJavaObject.wrap(scope, retval, staticType); > > to > > Object wrapped = ScriptRuntime.wrap(scope, retval, staticType); > > Then I think cases like these would be handled more intuitively. Similar > cases occur in JavaMembers, NativeJavaArray, and others. > > - Sam Ruby
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 1•22 years ago
|
||
I suggest to close the bug as fixed as since 1.5R2 one can use omj.WrapHandler to explicitly control mapping of Java String to JS one and in Rhino 1.5R4 one will be able to alter the behavior via simple contextInstance.getWrapHandler().setJavaPrimitiveWrap(true)
Comment 2•22 years ago
|
||
OK, resolving as FIXED -
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•