Target of javaPrimitiveWrap in WrapFactory includes not primitive wrapper classes.

[hatanaka-akihiro]

WrapFactory with javaPrimitiveWrap = false does not wrap

• java.lang.String
• java.lang.Character
• subclasses of java.lang.Number
• java.lang.Boolean

I think "subclasses of java.lang.Number" is problem.
Because subclasses of java.lang.Number includes "not primitive wrapper classes" such as java.math.BigDecimal, java.math.BigInteger.

I would like to expect "not primive wrapper classes".
I think suitable javaPrimitiveWrap target is below.

• java.lang.String
• java.lang.Character
• java.lang.Byte
• java.lang.Short
• java.lang.Integer
• java.lang.Long
• java.lang.Float
• java.lang.Double
• java.lang.Boolean

regards.

[gbrail]

So are you suggesting that we change the target to include those specific classes?

That makes sense to me. However I don't know what this might break...

[hatanaka-akihiro]

I would like to exclude java.math.BigDecimal and java.math.BigInteger from target of javaPrimitiveWrap.

In javascript, I want to avoid being aware of java.lang.String.

I think I can use javaPrimitiveWrap to this purpose.

However, I cannot make javaPrimitiveWrap false, because javaPrimitiveWrap targets java.math.BigDecimal and java.math.BigInteger.

[gbrail]

I spent a bunch of time last week trying to build a test case for this and I wasn't able to figure out what the problem is. The interaction between native code being called from Rhino, WrapFactory, and the javaPrimitiveWrap method seems to be pretty complex. If you could supply a test case that shows what you're trying to do then we could see what the options are. Otherwise, the reason why WrapFactory exists and is settable in the Context is so that you can customize the behavior if you wish.

…

On Thu, Sep 21, 2017 at 8:00 PM, 畠中晃弘 ***@***.***> wrote: I would like to exclude java.math.BigDecimal and java.math.BigInteger from target of javaPrimitiveWrap. In javascript, I want to avoid being aware of java.lang.String. I think I can use javaPrimitiveWrap to this purpose. However, I cannot make javaPrimitiveWrap false, because javaPrimitiveWrap targets java.math.BigDecimal and java.math.BigInteger. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#295 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAf0a1oxrfan6-wjpSFbMW7xU3C3pD7dks5skyLQgaJpZM4LrznX> .

[hatanaka-akihiro]

I wrote Test class.

RhinoTest.java.txt

I think there is sense of unity in case of javaPrimitiveWrap = false.

[gbrail]

Thanks for the test case -- that makes it much clearer. Here is a PR that includes a fix, plus your test code.

#339

Unfortunately the decision as to the result of "typeof" on a BigInteger or BigNumber is happening somewhere else, not in WrapFactory. I'm not sure where that is yet, or whether changing it also would cause big problems for existing code -- I'm kind of inclined to say that we shouldn't change that now.

Please let me know if it's OK to include your test code in the project.

[hatanaka-akihiro]

Of cause, OK. Please use my code.

[gbrail]

OK -- fixed that. I'm not sure about the other problem -- BigInteger instances being shown as a "number" type - that may be a more intrusive change.

#339