Fix for issue #1225 (error printing in memory JVM classes) and additi…

[joelpramos]

Fixing the issue reported on #1225. It's also reproducible using functional interfaces (seems like it's when in-memory JVM classes are used the minidev-json code always tries to instantiate and fails to do so). Also did a minor tweak to be able to pass these classes around and seems like it works using those functions in the Karate DSL.

Description

Thanks for contributing this Pull Request. Make sure that you submit this Pull Request against the develop branch of this repository, add a brief description, and tag the relevant issue(s) and PR(s) below.

• Relevant Issues : (compulsory)
• Relevant PRs : (optional)
• Type of change :
  • New feature
  • Bug fix for existing feature
  • Code quality improvement
  • Addition or Improvement of tests
  • Addition or Improvement of documentation

[ptrthomas]

@joelpramos this is great - and you went deep into Nashorn ! you may have seen the commits I made against #1231 - which is an extra layer of fail-safe. hope I can get your help later when we move away from Nashorn to GraalVM - good news is that I have done some proof-of-concept code, and this time hope to simplify all the JS<-->Java boundary weirdness

[joelpramos]

Do share if you have any code. I just did a quick example and struggled with the backwards compatibility with nashorn methods (like read() etc) but shouldn't take much to reimplement those in Graal to keep Karate backwards compatible.

[ptrthomas]

@joelpramos there's actually a branch from 1.5 years back: https://github.com/intuit/karate/compare/graal - which got all the tests to pass, just to get that confidence. but recently I found a few simpler ways to do some of the things (mainly we need to switch to a ThreadLocal for the JS engine) - so a significant portion of that code will be changed