Thanks, Attila. I'm still in the "bootstrapping" process with Nashorn so I haven't gotten to the point where I can run my scripts in a visual debugger, build and run Nashorn myself, etc. As I advance undoubtedly I'll acquire more tools and be able to further describe problems like the two noted above.
I've already solved Error B: a local variable declared inside an object created by new was somehow getting shared across instances of the object (so a generalization of the problem I ran into earlier, where a constructor argument was being shared). Again, assigning the local variable to the object -- to 'this' -- and then using the object property fixed the problem. So if at some point I can narrow down why this is happening I'll let the list know. -- David P. Caldwell http://www.davidpcaldwell.com/ On Wed, Apr 30, 2014 at 10:42 AM, Attila Szegedi <[email protected]> wrote: > Hi David, > > no, there's no such caching in the currently released version. Compilation > happens on the thread that invokes the relevant javax.script API (e.g. > ScriptEngine.eval or Compilable.compile), so there's no asynchrony involved > either. The behavior you describe is indeed baffling, but I don't have an > explanation for it within the Nashorn compilation pipeline. > > Attila. > > On Apr 30, 2014, at 4:04 PM, David P. Caldwell > <[email protected]> wrote: > >> Does Nashorn do some kind of background incremental compilation and >> caching of compiled scripts somewhere in the local file system? Is it >> possible to disable it? >> >> I'm porting a very complex Rhino-based system -- complex in terms of >> scope and 'this' management in particular -- to Nashorn and I'm >> running into behavior consistent with that, so I'm wondering (and I'm >> wondering whether I can disable it temporarily or force it to run >> synchronously or in advance). >> >> The reason I ask is that after I make a code change I tend to get an >> initial error (A) until I run the tests 1-3 times, and then that error >> disappears and I get a different error (B). The fact that error A >> seems to be triggered by changing one of the scripts in the system -- >> I haven't figured out which one, or ones -- leads me toward the theory >> that there is a background process that leaves a mark on disk at work. >> >> I don't yet know what is really going on with Error A is because it's >> harder to reproduce than Error B -- after 1-3 runs I can reproduce >> Error B so I will surely figure that one out first. >> >> Error B, for what it's worth, seems to have to do with a reference to >> an argument being lost inside one of the scopes of an object. So a >> named argument essentially acquires a different value: >> >> var Constructor = function(parameter) { >> this.doIt = function() { >> parameter.doSomething(); >> } >> } >> >> In that usage, the parameter reference is somehow being lost (and ends >> up referring to a value from a different call to the same >> constructor). I was able to fix one occurrence of this by replacing >> the construct above with: >> >> var Constructor = function(parameter) { >> this.parameter = parameter; >> >> this.doIt = function() { >> this.parameter.doSomething(); >> } >> } >> >> If I nail down why this is happening at some point I'll report it, but >> right now there's so much surrounding code that I can't easily provide >> a reproduction case or nail down the root cause. And it may not even >> qualify as a "bug" because (a) it is possible that somewhere some >> threading rule is being violated in my code, and (b) I am already >> using a non-public Nashorn API >> (jdk.nashorn.internal.runtime.Context.evaluateSource(Source,ScriptObject,ScriptObject)) >> to replicate things the Rhino-based system was able to do with its >> custom embedding. >> >> I sort of doubt the threading explanation because as this is a test >> suite it is mostly single-threaded, but it's possible I'm missing >> something. >> >> So anyway, back to my question -- is there caching of some kind of >> code transformation, and if there is, can I disable it so I can narrow >> down on error A? Or force it to happen synchronously so that I can >> work around error A? >> >> -- David P Caldwell >> http://www.davidpcaldwell.com/ >
