ClassCastException NativeRegExpExecResult cannot be cast to NativeArray

Sundararajan Athijegannathan sundararajan.athijegannathan at
Thu Dec 17 12:47:57 UTC 2015

Hi  Stijn,

We *suspect* a bug fix ( that is in jdk9 may 
fix the one you describe as well.  We'd want to backport to a jdk8u 
after due backport process. FYI.


On 12/15/2015 9:54 PM, Jim Laskey (Oracle) wrote:
> At first glance it doesn’t seem to be thread related.  We’ll poke at it but it would be helpful if you reduced the problem.
> — Jim
>> On Dec 15, 2015, at 11:53 AM, Stijn de Witt <stijndewitt at> wrote:
>> Dear fellow developers,
>> First of all thank you for your work on Nashorn. I am pretty excited at the possibilities of being able to integrate my two favorite languages, Java and Javascript.
>> I have two concrete questions and a problem (which caused the questions):
>> 1. Can a Nashorn engine be used across threads (using ScriptContext or Bindings for isolation)?2. Is there a good example of using Nashorn from a Servlet Filter?
>> My problem:
>> I am struggling with server-side rendering of React components using Nashorn. I am deploying to OpenShift and whenever I try to make my app listen to the rout route, I run into a weird ClassCastException somewhere inside the Nashorn code. I now think this is due to a heartbeat request OpenShift's haproxy is doing on my app that is causing (relatively) high load and triggering a concurrency problem... This leads me to believe I am doing something wrong in the way I create the script engine and using script contexts in a ThreadLocal to isolate the different threads.
>> I have formulated my question, including logs and relevant code, on
>> Could one of you maybe have a look at my situation, specifically my servlet filter code and tell me if I am doing it wrong and if so, what I should change?(I tried instantiating a different engine per thread and saving them in a ThreadLocal, but this leads to OutOfMemory errors quickly)
>> Thank you for any tips, pointers to docs etc that you could spare.
>> With kind regards,
>> -Stijn
>> Stijn de Witt

More information about the nashorn-dev mailing list