FULL PRODUCT VERSION :
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.10586]

A DESCRIPTION OF THE PROBLEM :
When Nashorn calls a Java function that returns a Long number, the type of the value is "object" and the value doesn't compare equal to the corresponding JavaScript number literal.

REGRESSION. Last worked in version 8u91

ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b15, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached program.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
number
true
ACTUAL -
object
false

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package org.lab;

import jdk.nashorn.api.scripting.NashornScriptEngineFactory;

import javax.script.Bindings;
import javax.script.ScriptContext;
import javax.script.ScriptEngine;
import javax.script.ScriptException;
import java.util.concurrent.Callable;

public class Main {

    public static void main(String[] args) throws ScriptException {
        ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine();
        Bindings bindings = engine.getBindings(ScriptContext.ENGINE_SCOPE);

        bindings.put("fun", (Callable<Long>) () -> 42L);

        String script = "print(typeof fun());\nprint(42 === fun());";

        engine.eval(script, bindings);
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The value can be forced to a number through standard JavaScript number coercion (+N or Number(N)), but that's impractical since all exposed client code would have to be changed.