java.lang.String vs. primitive string type

VERIFIED FIXED in 1.5R4

Status

P3
normal
VERIFIED FIXED
19 years ago
15 years ago

People

(Reporter: norrisboyd, Assigned: norrisboyd)

Tracking

other
1.5R4
x86
Windows NT

Details

(Assignee)

Description

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

19 years ago
Status: NEW → ASSIGNED

Comment 1

16 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

16 years ago
OK, resolving as FIXED -
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 3

16 years ago
And marking Verified -
Status: RESOLVED → VERIFIED

Comment 4

15 years ago
Targeting as resolved against 1.5R4
Target Milestone: --- → 1.5R4
You need to log in before you can comment on or make changes to this bug.