ADDITIONAL SYSTEM INFORMATION :
Any OS, on JDK 8

A DESCRIPTION OF THE PROBLEM :
JS ArrayBuffer allows the usage of j.n.ByteBuffer as a constructor argument, in this case this buffer will become the underlying buffer to be used by the typed arrays in nashorn. This only works for JDK >=9 as for 8 the argument is silently ignored.

The issue here is that if there is no way to specify the underlying buffer the performance boost of typed arrays in a script is totally ignored as in the end, the end user must perform a non optimized and slow copy byte by byte of the buffer to a JS array and then cast it to a Java Array to finally convert it back to a buffer...

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
In a nashorn shell or embedded script:

// create a j.n.ByteBuffer
var bb = java.nio.ByteBuffer.allocateDirect(10)
// here is the issue, nashorn allows specifying a bb as underlying buffer for ArrayBuffer
var ab = new ArrayBuffer(bb)
// if we now wrap this as a typed array
var ia = new Int8Array(ab)
// the test
print(ia.length)
print(ab.byteLength)


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
// we expect that the length and content of the buffer are visible, but...
print(ia.length) // expected 10
print(ab.byteLength) // expected 10

ACTUAL -
// we expect that the length and content of the buffer are visible, but...
print(ia.length) // prints 0, expected 10
print(ab.byteLength) // prints 0, expected 10


CUSTOMER SUBMITTED WORKAROUND :
backport the fix from the current JDK:

https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArrayBuffer.java#l99

to

https://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeArrayBuffer.java#l51

FREQUENCY : always