Migrated from venerable NASHORN-382. Close if you think it is not relevant anymore.

Context class should be broken into codegen and runtime parts. It currently confounds these two roles, making it hard to use for i.e. code generation only. Typical example encountered trying to run nasgen with --specializations:

java.lang.NoClassDefFoundError: org/dynalang/dynalink/RelinkableCallSite
at com.oracle.nashorn.runtime.ScriptObject.<clinit>(ScriptObject.java:885)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.oracle.nashorn.runtime.Context.initGlobal(Context.java:426)
at com.oracle.nashorn.runtime.Context.access$100(Context.java:61)
at com.oracle.nashorn.runtime.Context$4.run(Context.java:225)
at java.security.AccessController.doPrivileged(Native Method)
at com.oracle.nashorn.runtime.Context.<init>(Context.java:222)
at com.oracle.nashorn.runtime.Context.<init>(Context.java:143)
at com.oracle.nashorn.tools.nasgen.Main.generateRuntimeSpecializations(Main.java:77)
at com.oracle.nashorn.tools.nasgen.Main.main(Main.java:69)

As we can see, this causes Nasgen to load Global, but Nasgen is meant to generate the classes required to load Global's environment in the first place! It pulls in ScriptObject too, which activates Linker – these are all things that are specific to run time, not code generation time.

As a workaround, I'll add Dynalink to the path to run-nasgen, but we'll need to fix this eventually. Having a separate codegen and runtime contexts would also provide a natural way for code caching across different runtime contexts, as they could then share the same codegen context.