jruby/docs BETA
Navigation

Version

Packages 113

JRuby

org.jruby.embed 16
E AttributeName
I EmbedEvalUnit
I EmbedRubyInstanceConfigAdapter
I EmbedRubyInterfaceAdapter
I EmbedRubyObjectAdapter
I EmbedRubyRuntimeAdapter
C EvalFailedException
A Extension
C InvokeFailedException
C IsolatedScriptingContainer
E LocalContextScope
E LocalVariableBehavior
C ParseFailedException
E PathType
E PropertyName
C ScriptingContainer
LocalContextScope — members 6+
F SINGLETON() LocalContextScope
F SINGLETHREAD() LocalContextScope
F THREADSAFE() LocalContextScope
F CONCURRENT() LocalContextScope
M value_of(name) LocalContextScope
M values() LocalContextScope[]
from Enum
M compare_to(arg0) int
M declaring_class() Class<E>
M describe_constable() EnumDesc<E>>
M equals(arg0) boolean
M hash_code() int
M name() String
M ordinal() int
M to_string() String

org.jruby.embed.LocalContextScope

enum final 6 members

LocalContextState defines four scopes to maintain LocalContext.

A single ScriptingContainer can be configured to act as a facade for multiple Ruby runtimes (or really multiple Ruby VMs, since each Ruby instance is a Ruby "VM"), and this enum controls that behaviour. (this behaviour is bit like that of ThreadLocal — it changes its behaviour silently depending on the calling thread, an act of multiplexing.)

When you think of this multiplexing behaviour, there are two sets of states that need separate attention. One is Ruby instance, which represents the whole VM, classes, global variables, etc. Then there's attributes and so-called variables, which are really a special scope induced by the scripting container for better JSR-223 interop. In this documentation, we refer to the former as "the runtime" and the latter as "the variables", but the variables shouldn't be confused with the global variables in Ruby's semantics, which belongs to the runtime.

Constants

constanttypenote
SINGLETON LocalContextScope Uses a "global" singleton runtime and variables. All the ScriptingContainers that are created with this scope will share a single runtime and a single set of variables. Therefore one container can set a value and another container will see the same value. The global runtime comes from org.jruby.Ruby#getGlobalRuntime(), which initializes or retrieves a Ruby instance in a static field on org.jruby.Ruby. All singleton context scopes will reuse this instance. When any singleton-based scripting container is torn down (ScriptingContainer#terminate()), the global runtime will also be torn down and cleared. Subsequent singleton containers will see a new runtime. Note that unlike the other modes, containers created with singleton context scoping will not tear down the associated JRuby runtime upon finalization.
SINGLETHREAD LocalContextScope ScriptingContainer will not do any multiplexing at all.

ScriptingContainer will get one runtime and one set of variables, and regardless of the calling thread it'll use this same pair.

If you have multiple threads calling single ScriptingContainer instance, then you may need to take caution as a variable set by one thread will be visible to another thread.

If you aren't using the variables of ScriptingContainer, this is normally what you want.
THREADSAFE LocalContextScope Maintain separate runtimes and variable maps for each calling thread.

Known as the "apartment thread model", this mode makes ScriptingContainer lazily creates a runtime and a variable map separately for each calling thread. Therefore, despite the fact that multiple threads call on the same object, they are completely isolated from each other. (the flip side of the coin is that no ruby objects can be shared between threads as they belong to different "ruby VM".)
CONCURRENT LocalContextScope Use a single runtime but variable maps are thread local.

In this mode, there'll be a single runtime dedicated for each ScriptingContainer, but a separate map of variables are created for each calling thread through ThreadLocal. In a situation where you have multiple threads calling one ScriptingContainer, this means ruby code will see multiple threads calling them, and therefore they need to be thread safe. But because variables are thread local, if your program does something like (1) set a few variables, (2) evaluate a script that refers to those variables, then you won't have to worry about values from multiple threads mixing with each other.

Class Methods

value_of

LocalContextScope value_of ( String name )
Java: valueOf(String name)

values

LocalContextScope[] values ( )
Java: values()

Inherited

from Enum

compare_to

int compare_to ( E arg0 )
Java: compareTo(E arg0)

declaring_class

Class<E> declaring_class ( )
Java: getDeclaringClass() · also: get_declaring_class

describe_constable

Optional<Enum.EnumDesc<E>> describe_constable ( )
Java: describeConstable()

equals

boolean equals ( Object arg0 )
Java: equals(Object arg0)

hash_code

int hash_code ( )
Java: hashCode()

name

String name ( )
Java: name()

ordinal

int ordinal ( )
Java: ordinal()

to_string

String to_string ( )
Java: toString()