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 <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> wrote:
> Yes we can upgrade to 11
>
> On Sat, Jun 25, 2022 at 12:47 PM Attila Szegedi <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> 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 <[email protected]
> > > <mailto:[email protected]>> 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 | [email protected] <mailto:[email protected]> |
> > > 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 | [email protected] <mailto:[email protected]> | 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> | [email protected] <mailto:[email protected]>
> | 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> | [email protected] <mailto:[email protected]>
> | 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> | [email protected] <mailto:[email protected]>
> | 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>
