Open tonygermano opened 3 years ago
Would this change any behaviors for things like numeric IDs in strings?
The fact that it's a numeric id shouldn't be relevant. If you are retrieving a numeric id from a java method that returns a java.lang.String, it would instead return a javascript string. You'd likely be using parseInt
if you needed it as a number, which wouldn't be affected. The only thing I can think of that might be an issue is if you are calling a java.lang.String specific method on the value, like matches
to do validation that you really have a numeric id.
Once again, if the optional setting were to cause a problem with a specific channel, you can always manually flip the flag in the script to return to the current behavior for that particular script without preventing everything from using the feature.
Is your feature request related to a problem? Please describe. It's very confusing both to new users and more experienced users when there is a mismatch between java objects and javascript primitives. Strict equality does not work, which also affects switch statements. There are numerous issues reported in the forums and slack on the erratic behavior of the
replace()
method when the user is unaware of which type of string they are calling it on.Rhino already has an option to change this behavior. With the option disabled (it is enabled by default) certain types returned from field access or method calls on java objects will be automatically converted to javascript primitives according to the mappings below.
Describe your use case Demonstrated in rhino shell
Describe the solution you'd like Create a
mirth.properties
setting to control setting the javaPrimitiveWrap property on the context's WrapFactory instance before evaluating the javascript code. This would allow people to keep the current behavior if their code is dependent on it. I recommend making this the default setting on new installations, but not migrations, similar to how ES6 mode was introduced.Describe alternatives you've considered Frequently workarounds are employed to always manually convert input to javascript strings rather than trying to understand all of the situations that may produce one type of string vs the other. Many people still don't realize the same problem can occur with numbers and booleans because it happens less frequently than with strings.
Additional context There is a new quirk that would arise, though I think would be a much less common issue than the current behavior. When explicitly placing java objects into a java collection or map, they will be converted to their javascript cousins on retrieval. The biggest surprise is that all listed subclasses of
java.lang.Number
are treated as javascript numbers, not onlyDouble
. The exception starting in Rhino 1.7.14 is thatjava.math.BigInteger
will be converted to a javascript bigint instead of number.Currently
Byte
is not accounted for and there is a potential loss of precision with includingLong
in the list, both of which I am addressing with the Rhino project.A user that has this new setting enabled, but must maintain the original classes could manually flip the flag for that particular script as I have demonstrated in the example above.