Nashorn caching of processed scripts?

[David P. Caldwell]

For what it's worth, I've learned a bit more about my problem with scopes.

I have a set of unit tests that exercise my system, and as such, they
are very scope-intensive, because they use scopes as the mechanism for
mocking and dependency injection when running the unit tests.

They always pass under Rhino.

Under Nashorn, these tests intermittently failed because of various
mistakes having to do with scoping. In my current tip I believe I've
worked around all the unit test failures that are "common" but it's
too early to be sure.

So, I have a lot of constructs like this:

var someFunction = function() {
  // omitted
}

this.somePublicFunction() {
  someFunction();
  // ...
}

What I can tell you is:

* The unit tests are continually creating and using scopes to mock the
execution context, and they re-enter Nashorn via the non-public
evaluateSource(Source,ScriptContext,ScriptContext) and then invoking
functions like somePublicFunction() above.
* Sometimes, in a non-deterministic way, in scripts like the above,
"someFunction" evaluates to undefined inside somePublicFunction.
* I can fix the problem in various ways, including making someFunction
a property of this or moving it inside somePublicFunction.

Given that it's non-deterministic, my suspicion is some kind of race
condition or concurrency problem.

I mentioned earlier that I thought the problem would occur when I
modified code and then stop occurring. It's possible I imagined this
pattern, or it's possible that CPU temperature and throttling is what
caused it (repeatedly running a large test suite may have affected the
concurrency stuff).

If I thought about it carefully, I could provide an executable test
case based on a previous revision of the code. The good news is, it
would just involve checking out some public code at a given revision
and running a single command to start the tests. Three pieces of bad
news: 1. it's non-deterministic, 2. it's obviously big and tangled so
you'd have to figure out how to catch the problem, and 3. I'm using a
non-public API (which I am calling from script, no less), so I can't
guarantee that's not related to the problem.

But with those three caveats, if you're interested, let me know and
I'll assemble something.

-- David P. Caldwell
http://www.davidpcaldwell.com/