confusion about js string vs java string

[heywiki]

When i return a string from a java object i get a java string. I remember that in older versions of rhino this was causing trouble, so we
converted them with + "" to js strings. Now i try to figure out if + "" is still necessary to code with the returned string like it would be a
native rhino js string (currently we are using 1.8).

What i recognized is that i can now use "==" to compare them, don't know if that was always possible, but
if i call functions on them i would suspect that only java functions would work. Interestingly also js functions work on the returned
string. Could you clarify or point me to a documentation on how to handle java strings in rhino?

var pname = jpage.name();  //jpage is an Java object embedded in rhino, therefore it returns a java.lang.String
pl ("|pname|" + pname); //RhinoStringTest
pl("|cname()|" + cname(pname)); //java.lang.String (cname is helper function that gets class name, if obj is a java obj)
pl("|typeof|" + typeof pname);  //object

Comparing (assume pname is "RhinoStringTest")

if (pname == "RinoStringTest")      //matches...
if (pname === "RinoStringTest")      //does not match: java.lang.String vs object

Calling functions

pl("|split()|" + pname.split("."));    //should work since java has a split function, as has js
pl("|slice()|" + pname.slice(0,2));  //should NOT work since java string does NOT hava a splice function, but it WORKS??????

So the last line is actually causing the confusion. What is happening here. Is the object internally converted to a js object? If so,
should then === also work? It would be inconsintant if the one works, the other not.

[aardvark179]

Okay, JS itself is a little confusing here, but let me lay out how it models things, and then we can connect that to what Rhino does.

String values

These are the strings you normally see, and they are also the result of common operations upon strings. So ’’ gives a string values, and so does ’foo’ + ‘bar’.

String objexts

Some operations in JavaScript can only be performed on an object. Looking up properties or calling methods are examples of this. So, if you do ’’.length then, at least in terms of how it is specified, the strong value is converted into a strong object, and then the length property is read from that object.

How Rhino represents this

Values are Java strings, and objects are NativeStrings. There are a couple more subtle corner cases to all this but in general returning strings should work just fine and they will behave as normal JS string values.

[gbrail]

I'd add one thing to @aardvark179's helpful comment: When interoperating between Java and JavaScript, you should be aware that sometimes Rhino represents string values as String, and sometimes as ConsString, which is an optimization when string concatenation is used. This comes up if you are calling a JavaScript function from Rhino -- the result that you get back might be a String or a ConsString, but it'll always be a CharSequence, which is why it's important to always check the result. (Or call ScriptRuntime.toString() if you need to be sure, since technically a JavaScript function can return literally anything, even undefined or NaN.) Similarly, depending on what optimizations were applied, a JavaScript function that "should" return a number might return a Double or an Integer depending on how the code was optimized. I don't think this is explicitly what you were asking but I do think we should get it reflected in the docs somewhere!

…

On Sun, Nov 2, 2025 at 12:47 PM Duncan MacGregor ***@***.***> wrote: *aardvark179* left a comment (mozilla/rhino#2153) <#2153 (comment)> Okay, JS itself is a little confusing here, but let me lay out how it models things, and then we can connect that to what Rhino does. String *values* These are the strings you normally see, and they are also the result of common operations upon strings. So ’’ gives a string values, and so does ’foo’ + ‘bar’. String *objexts* Some operations in JavaScript can only be performed on an object. Looking up properties or calling methods are examples of this. So, if you do ’’.length then, at least in terms of how it is specified, the strong value is converted into a strong object, and then the length property is read from that object. How Rhino represents this Values are Java strings, and objects are NativeStrings. There are a couple more subtle corner cases to all this but in general returning strings should work just fine and they will behave as normal JS string values. — Reply to this email directly, view it on GitHub <#2153 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I27UZIJWSGMY534ARC332ZUXPAVCNFSM6AAAAACK5BY7PGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZYGMYDIMZUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[821938089]

Because Rhino has special handling logic for Java string prototypes.

rhino/rhino/src/main/java/org/mozilla/javascript/NativeJavaObject.java

Lines 156 to 163 in f7341b4

	@Override
	public Scriptable getPrototype() {
	if (prototype == null && javaObject instanceof String) {
	return TopLevel.getBuiltinPrototype(
	ScriptableObject.getTopLevelScope(parent), TopLevel.Builtins.String);
	}
	return prototype;
	}

Therefore, it will exhibit some JavaScript string behavior.

If you don't want Java strings, you can set JavaPrimitiveWrap to false in the WrapFactory.

[heywiki]

Thank you all for the clarifications and for tagging it as "docs". This was very helpful. I guess as a simple rule for rhino users you could say:

• If a java embedding returns a string, convert it to a js string with + "", if you want to be absolutely shure that it behaves like a js string
• If comparing, use "==" instead of "===" if you have not previously converted the java string to a js string using the + "" syntax.

Is that correct?

Another note: aardvark179 wrote "JS itself is a little confusing here". When i write JS i mean JavaScript Language (a JavaScript String Object with the Methods and behaviours defined by the JavaScript/ECMA Spec) vs Java Embeddings returning Java Strings with the Methods defined by the Java Language.

What whould be the correct reference or shortcut then? I use JS here in the context of speaking to the language users that in my opinion should not know to much of the the underlying technical implementation details of Rhino. I think they should not need to know them, otherwise the abstraction and therefore simplicity advantage whould get lost.

Ideally however i should not even need to explain the two points above, and i guess the implementation the user "821938089" points out is exactly trying to achive this, but i understand that thats not that easy because there are occasions when you want to treat a java string exaclty like that, because it gives me methods that js does not offer.

[tonygermano]

If a java embedding returns a string, convert it to a js string with + "", if you want to be absolutely shure that it behaves like a js string

If I want to convert a value which may be a java object to a js string, I find the most clear and explicit way to do so is calling the String() constructor as a function.

if (String(someObject) === 'myValue') { /* ... */ }

While I don't like seeing x + "" all over the place, it's also good to be aware that string concatenation using the plus operator (+) will always evaluate to a primitive string, even if you are concatenating two java.lang.Strings.

I think what aardvark179 was pointing out is that standard javascript has both the primitive string type (what you typically deal with) and String objects (see the "Return Value" section in the constructor link above.) When you attempt to access a property on a primitive string, it is implicitly converted to a String object, which provides the prototype chain. Other primitive types (boolean, number, etc..) have similar wrapper classes and behave the same way. Accidentally creating a javascript String object has similar equality issues to a java.lang.String object. You can reproduce this in any javascript engine.

js> var s1 = 'example' // primitive
js> var s2 = String('example') // primitive
js> var s3 = new String('example') // object
js> s1 == s2
true
js> s1 == s3
true
js> s1 === s2
true
js> s1 === s3
false
js> s1 === s3.toString() // String.prototype.toString() returns a primitive string
true

The confusing part about Java interop is that Rhino uses classes such as java.lang.String, java.lang.Boolean, and java.lang.Double internally to represent its primitive types. When something in the javascript environment appears as a java object, it is actually the java class wrapped in a NativeJavaObject. This is how an instance of java.lang.String has access to String.prototype methods, as user 821938089 pointed out.

If you take the suggestion of user 821938089 and turn off javaPrimitiveWrap, all java class methods which return objects that represent js primitives and would normally be wrapped in a NativeJavaObject wrapper will instead not be wrapped, so this setting affects booleans, numbers, and bigints as well as strings. However, the Java object constructors are not affected by this setting. The downside to this is that most of those constructors are deprecated for removal in favor of the static .valueOf() methods, but those methods are affected by the setting.

js> org.mozilla.javascript.Context.currentContext.wrapFactory.javaPrimitiveWrap = false
false
js> var s = new java.lang.String() // constructor value is still wrapped, even though wrap is turned off
js> typeof s
object
js> s.class
class java.lang.String
js> typeof s.toString() // with wrap turned off, the method call returns a primitive string
string
js> org.mozilla.javascript.Context.currentContext.wrapFactory.javaPrimitiveWrap = true
true
js> typeof s.toString() // with wrap turned on, the method call returns a java.lang.String
object
js> org.mozilla.javascript.Context.currentContext.wrapFactory.javaPrimitiveWrap = false
false
js> typeof new java.lang.Integer(1) // is not affected by wrap setting
object
js> typeof java.lang.Integer.valueOf(1) // is affected by wrap setting
number

If comparing, use "==" instead of "===" if you have not previously converted the java string to a js string using the + "" syntax.

That's good advice if not adjusting the primitive wrap setting, but it's important to remember that more than just the === operator uses strict equality comparison. For example, switch statements use strict equality when comparing the expression to the case clauses. Array.prototype methods such as contains and indexOf will also fail to match a java.lang.String to the equivalent primitive string.