poking objects into context?
Jim Laskey (Oracle)
james.laskey at oracle.com
Fri Oct 25 04:23:51 PDT 2013
On Oct 24, 2013, at 11:49 PM, Michael Roberts <mike at 7f.com> wrote:
> I had another couple of basic questions.
>
> 1) If my script is "pure" javascript provided by someone else, and I don't
> want to interfere with the script by pre-pending some java objects into it,
> what's the prescribed way for getting said objects into the execution
> context. I'm thinking about substitutes some commonly used browser objects
> like console in the first case, but also potentially objects which enable
> communication back into the wider environment I would be using the scripts
> in. Of course, I can declare references to said objects in the script, but
> external insertion would I think be more elegant.
There are two approaches;
1) You can first read/eval your predefines from another script and then read/eval from the your script. Objects are kept across evals. If you are using the jjs command line, then just add your predefines script on the command line prior to your script.
2) Use the load function in your script to load the predefines; load("predefines.js");
>
> 2) If I have a lot of instances of the same script running in different
> places in my java environment, is there a way to (a) get the script from
> one ScriptEngine and place the compiled form into another (thus avoiding
> the overhead of a second compilation) or (b) create a secondary instance of
> the same (I assume) ScriptObject which does not share state with the
> original instance.
>
Compilation is a fuzzy term in Nashorn, but in general, if you use the same engine, you get code caching for free. Almost. Recent work on javascript engines (or any modern JIT) have focused on lazy compilation and partial evaluation. What that means is that code generation is tailored to use patterns. So a function that is called from different locations in your script, may actually have several versions of code, each customized for the types of arguments passed or number of times it is called. The cost of compilation is very small compared to gains in performance.
> thanks in advance
>
> M
More information about the nashorn-dev
mailing list