"null" value is wrapped as Undefined.
Attila Szegedi
szegedia at gmail.com
Thu Aug 11 15:23:50 UTC 2022
What you are running into is a change where Nashorn used to treat any java.lang.Number implementation as a JavaScript number type, but later became more strict and only considers those built-in number types that can be represented by a double without loss as a number. This is due to the fact that in JavaScript, numbers are always 64-bit floating-point values (that is, doubles.) Nashorn even used to have a special-cased support for longs for a while, but even that was removed as long is also incompatible with double as a double can only accurately represent a long with a magnitude up to 53 bits.
If you evaluate:
typeof(new java.math.BigInteger("1”))
you’ll get “number” on Java 8 and “object” on Java 11. Same would happen for e.g. new java.lang.Long(0): number on Java 8, object on Java 11.
Given how this change occurred somewhere in Java 9 timeframe (released in September 2017), you’re facing a backwards compatibility issue that is half a decade old. It would be unlikely to be addressed even if it were simply a bug, but it was, in fact, a conscious design decision back in the day.
Since BigInteger is treated just like any JavaScript object, the abstract equality comparison operator’s step 1.f. applies (see https://es5.github.io/#x11.9.3) as they are both evaluated to be of type Object, not Number.
Sorry, but I don’t have better news for you than that you’ll have to change your code somehow in the migration. You can still invoke .equals() method on them, for instance:
jjs> var x = new java.math.BigInteger("1")
jjs> var y = new java.math.BigInteger("1")
jjs> x == y
false
jjs> x.equals(y)
true
On an unrelated note, I wanted to point that your examples are also wrong in that in Nashorn you can’t use () operator to get/set map elements. You can however use [] operator for that purpose.
Attila.
> On 2022. Aug 9., at 22:06, Se Hee Lee <tosehee at gmail.com> wrote:
>
> Slightly wrong information.
>
> ar map = new HashMap();
> map("foo") = new BigInteger('1");
> map("bar") = new BigInteger("1");
>
> if (map("foo") == map("bar")) {
> ....}
>
> In Java 1.8.0_91, it evaluates to "true", but in anything above that version, it evaluates to false.....
>
> Technically speaking, I understand that it should be "false", but we have millions of rules that simply returns the numeric value from database (normally returns as BigInteger or Long) and above comparison simply because 1.8.0_91 ALLOWED it.
>
> Now we are trying to upgrade to Java 17 with stand-alone nashorn lib, but we can't due to these incompatibility issues...
>
> If anyone can point me a direction as to what needs to be modified, we can do that in-house..
>
> Any help is greatly appreciated. We really want to upgrade our apps....!
>
>
>
> On Tue, Aug 9, 2022 at 2:36 PM Se Hee Lee <tosehee at gmail.com <mailto:tosehee at gmail.com>> wrote:
> Hey Attila. Not sure where you are with the fix... Any update is really appreciated.
>
> In addition, we found another compatibility issue with nashorn in Java 8 vs stand alone nashorn lib.
>
> var map = new HashMap();
> map("foo") = 1;
>
> if (map("foo") == 1) {
> ....}
>
> Above "If" condition evaluates to "true" in Java 8, but it's evaluating to "false" in stand-alone nashorn lib.
>
> I am guessing map("foo") holds "java.lang.Integer, and autoboxing is not working correctly.
>
> This is actually bigger issue as we now have the rules that are evaluating incorrectly. At least with the previous issue, we got an error and we can workaround. This is serious compatibility issue.
>
>
>
>
> On Sat, Jun 25, 2022 at 12:53 PM Se Hee Lee <tosehee at gmail.com <mailto:tosehee at gmail.com>> wrote:
> Yes we can upgrade to 11
>
> On Sat, Jun 25, 2022 at 12:47 PM Attila Szegedi <szegedia at gmail.com <mailto:szegedia at gmail.com>> wrote:
> I tried this little test program:
>
> (function (y) { "x".contains(y) })()
>
> and it fails for me even on 1.8.0_91-b14 with ClassCastException. Arguably, since undefined is converted to “undefined” string when the target type is String, it would make sense for it to work with CharSequence too.
>
> Bad news is that I can fix this for standalone Nashorn, but you will have to upgrade to at least Java 11 to take advantage of it. (Also, I need to publish the fix too so it too might take few days.)
>
> In the meantime, can you maybe change the signature of isBlank to take a String instead of a CharSequence? I think that’d work.
>
> Attila.
>
> > On 2022. Jun 23., at 17:01, Se Hee Lee <tosehee at gmail.com <mailto:tosehee at gmail.com>> wrote:
> >
> > It's Java
> >
> > public boolean isBlank(final CharSequence cs) {
> > return StringUtils.isBlank(cs);
> > }
> >
> > On Thu, Jun 23, 2022 at 4:45 AM Attila Szegedi <szegedia at gmail.com <mailto:szegedia at gmail.com>> wrote:
> > Hi,
> >
> > I’d like to look into this, but can you tell me how is “$S.isBlank” defined? If it is in Java, what is its method signature?
> >
> > Thanks,
> > Attila.
> >
> > > On 2022. Jun 6., at 19:17, Se Hee Lee <tosehee at gmail.com <mailto:tosehee at gmail.com>> wrote:
> > >
> > > Is there a way to prevent this automatic wrapping?
> > >
> > > In the following line, "oh.customAttribute4" is null, and it's passed into
> > > isBlank() as "Undefined". And that triggers the ClassCastException. This
> > > works fine in JDK 1.8.0_91, but fails in all future versions.
> > >
> > > Is there an optional parameter or flag that prevents this from
> > > happening??????
> > >
> > > We have lots of rules that are based on 'nashorn' scripting engine, and we
> > > cannot upgrade to future JDK due to this issue.
> > >
> > > if (oh.type == "Sales Order" && $S.isBlank(oh.customAttribute4) &&
> > > oh.importType != "Transfer Order" && ol.item.customAttribute1 != "true" &&
> > > $S.containsIgnoreCase(vars.highMovingItems, ol.item.number + ",") ||
> > > $S.endsWithIgnoreCase(vars.highMovingItems, ol.item.number)) {
> > >
> > > Caused by: java.lang.ClassCastException: Cannot cast
> > > org.openjdk.nashorn.internal.runtime.Undefined to java.lang.CharSequence
> > >
> > > --
> > >
> > >
> > > Se Hee Lee / CTO
> > > ------------------------------
> > >
> > > 11605 Haynes Bridge Rd, Suite 200 | Alpharetta, GA 30009
> > > 470-214-3636 | slee at deposco.com <mailto:slee at deposco.com> | www.deposco.com <http://www.deposco.com/>
> > > <https://deposco.com/?utm_source=Email%20Signature <https://deposco.com/?utm_source=Email%20Signature>>
> > >
> > > [image: Twitter] <https://twitter.com/deposco <https://twitter.com/deposco>> [image: Facebook]
> > > <https://facebook.com/deposco <https://facebook.com/deposco>> [image: Google +]
> > > <https://plus.google.com/+Deposco <https://plus.google.com/+Deposco>> [image: LinkedIn]
> > > <https://www.linkedin.com/company-beta/384437/ <https://www.linkedin.com/company-beta/384437/>>
> > >
> > > <https://deposco.com/?utm_source=Email%20Signature <https://deposco.com/?utm_source=Email%20Signature>>
> >
> >
> >
> > --
> > Se Hee Lee / CTO
> > 11605 Haynes Bridge Rd, Suite 200 | Alpharetta, GA 30009
> > 470-214-3636 | slee at deposco.com <mailto:slee at deposco.com> | www.deposco.com <http://www.deposco.com/>
> >
> >
> >
> >
> >
>
> --
> Se Hee Lee / CTO
> 11605 Haynes Bridge Rd, Suite 200 | Alpharetta, GA 30009
> 470-214-3636 <tel:470-214-3636> | slee at deposco.com <mailto:slee at deposco.com> | www.deposco.com <https://deposco.com/?utm_source=Email%20Signature>
>
> <https://twitter.com/deposco> <https://facebook.com/deposco> <https://plus.google.com/+Deposco> <https://www.linkedin.com/company-beta/384437/>
> <https://deposco.com/?utm_source=Email%20Signature>
>
>
> --
> Se Hee Lee / CTO
> 11605 Haynes Bridge Rd, Suite 200 | Alpharetta, GA 30009
> 470-214-3636 <tel:470-214-3636> | slee at deposco.com <mailto:slee at deposco.com> | www.deposco.com <https://deposco.com/?utm_source=Email%20Signature>
>
> <https://twitter.com/deposco> <https://facebook.com/deposco> <https://plus.google.com/+Deposco> <https://www.linkedin.com/company-beta/384437/>
> <https://deposco.com/?utm_source=Email%20Signature>
>
>
> --
> Se Hee Lee / CTO
> 11605 Haynes Bridge Rd, Suite 200 | Alpharetta, GA 30009
> 470-214-3636 <tel:470-214-3636> | slee at deposco.com <mailto:slee at deposco.com> | www.deposco.com <https://deposco.com/?utm_source=Email%20Signature>
>
> <https://twitter.com/deposco> <https://facebook.com/deposco> <https://plus.google.com/+Deposco> <https://www.linkedin.com/company-beta/384437/>
> <https://deposco.com/?utm_source=Email%20Signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nashorn-dev/attachments/20220811/a32ee57f/attachment-0001.htm>
More information about the nashorn-dev
mailing list