JSAPI User Guide

Este documento explica como incorporar SpiderMonkey, o motor JavaScript do Mozilla, em seu programa na linguagem C ++.

JavaScript é amplamente utilizado para se executar scripts do lado do cliente que rodam no navegador. Mas motor de JavaScript da Mozilla é uma biblioteca que pode ser lincada a qualquer programa C ++, e não apenas em um navegador. Muitas aplicações podem se beneficiar disto. Estes programas podem executar código JavaScript através da linguagem C ++ usando a API do SpiderMonkey.

Oque o SpiderMonkey faz

O motor de JavaScript compila e executa scripts que contêm instruções e funções de JavaScript. O motor lida com a alocação de memória para os objetos necessários para executar scripts, e ele tabém limpa o lixo e recolhe os objetos que já não necessita.

A palavra JavaScript pode trazer na mente  características como manipuladores de eventos (como onclick), objetos DOM, window.open e XMLHttpRequest. Mas no Mozilla, todos esses recursos são efetivamente prestados por outros componentes, e não pelo SpiderMonkey em si. SpiderMonkey fornece alguns tipos dados do núcleo do JavaScript como números, strings, arrays, objetos, e assim por diante, e alguns métodos, como Array.push. Também torna mais fácil para cada aplicativo  expor alguns de seus próprios objetos e funções no código JavaScript. Browsers expoem objetos DOM. O aplicativo irá expor objetos que são relevantes para o tipo de script que você desejar escrever. É até o desenvolvedor do aplicativo para decidir quais objetos e métodos serão expostos nos scripts.

Hello world

Usando a biblioteca SpiderMonkey

Para construir SpiderMonkey a partir do código fonte, consulte SpiderMonkey Build Documentation.

Alguns sistemas (como o Debian) fornecem SpiderMonkey como um pacote pré-construído, porém construí-lo a partir do fonte tornará o seu programa mais fácil de depurar.

Os código em linguagem C++ acessam o SpiderMonkey via JSAPI, ao incluir o cabeçalho "jsapi.h". Uma visão geral da funcionalidade da JSAPI virá a seguir. Para mais detalhes, consulte a Referencia JSAPI .

O Universo SpiderMonkey

A fim de executar qualquer código JavaScript em SpiderMonkey , um aplicativo deve ter três elementos-chave : a JSRuntime , um JSContext e um objeto global. Esta seção descreve o que são essas coisas. A próxima seção explica como configurá-los , usando as funções JSAPI .

Runtimes . A JSRuntime , ou execução, é o espaço no qual as variáveis ​​de JavaScript , objetos , scripts e contextos usados ​​pelo seu aplicativo são alocados . Cada JSContext e cada objeto em um aplicativo vive dentro de uma JSRuntime . Eles não podem viajar para outros tempos de execução ou ser compartilhado entre os tempos de execução . A maioria dos aplicativos só precisa de um tempo de execução.

Contextos. A JSContext , ou contexto, é como uma pequena máquina que pode fazer muitas coisas que envolvem código JavaScript e objetos. Ele pode compilar e executar scripts, obter e definir propriedades do objeto, chamar funções JavaScript , converter os dados em JavaScript a partir de um tipo para outro , criar objetos , e assim por diante . Quase todas as funções JSAPI exigem um JSContext * como o primeiro argumento , assim como a maioria das funções <stdio.h> requerem um arquivo * .

Existe uma estreita associação entre contextos e threads. Simples, aplicações single-threaded pode usar um único contexto para tudo. Mas cada contexto só pode fazer uma coisa de cada vez , de modo que em um aplicativo multithread , apenas um thread por vez deve usar um determinado contexto. Esse pedido normalmente tem um contexto por segmento. JavaScript objetos , por outro lado , não são permanentemente associado com o script , linha, ou o contexto que os criou. Eles podem ser compartilhados entre muitos scripts ou até mesmo muitos segmentos , como mostrado na figura abaixo .

A Figura 1.1 ilustra a relação de scripts para o tempo de execução , os contextos e objetos.

Objetos Globais . Por fim, o objeto global contém todas as classes, funções e variáveis ​​que estão disponíveis para o código JavaScript para uso. Sempre que o código JavaScript faz algo como window.open ("https://www.mozilla.org/"), ele está acessando uma propriedade global, nesta janela caso. Aplicações JSAPI tem total controle sobre o que os scripts propriedades globais podem ver. A aplicação começa com a criação de um objeto e preenchê-lo com as classes padrão do JavaScript, como matriz e objeto. Em seguida, adiciona os classes personalizadas, funções e variáveis ​​(como a janela) a aplicação quer oferecer, ver objetos personalizados abaixo. Cada vez que o aplicativo é executado um script JS (usando, por exemplo, JS_EvaluateScript), ele fornece o objeto global para esse script de usar. Como o script é executado, ele pode criar funções globais e variáveis ​​próprias. Todas essas funções, classes e variáveis ​​são armazenados como propriedades do objeto global.

Um pequeno exemplo

Cada um dos três elementos-chave descritos na seção anterior requer algumas chamadas JSAPI:

• O runtime: Usa JS_NewRuntime para cria-lo and JS_DestroyRuntime para limpa-lo quando finalizado. Quando seu aplicativo é feito com SpiderMonkey completamente, use JS_ShutDown para liberar quaisquer recursos restantes em cache. (Isto é uma mera minúcia se o processo está prestes a sair de qualquer maneira. Mas, como este nem sempre é o caso, chamando JS_Shutdown é um bom hábito se entrar.)

• O contexto: Usa JS_NewContext e JS_DestroyContext. Para O Máximo conformidade com o padrão ECMAScript, aplicativos também devem usar JS_SetOptions para permitir JSOPTION_VAROBJFIX. Para obter os mais recentes recursos da linguagem JavaScript, aplicativos podem usar JS_SetVersion O relatório de erros também é "per-context" e está habilitado usando JJS_SetErrorReporter..

• O objeto global: Para criar este objeto, você primeiro precisa de uma JSClass com a opção JSCLASS_GLOBAL_FLAGS. O exemplo abaixo define um JSClass muito básico (nomeado global_class) sem métodos ou propriedades próprias. Use JS_NewGlobalObject para criar um objeto global. Use JS_InitStandardClasses para preenchê-lo com os os objetos globals JavaScript padrão.

Isto pode parecer um monte de blocos para uma aplicação simples. Isso equivale a cerca de 50 linhas de código, como mostrado abaixo. Mas o JSAPI é projetado para escalar  aplicações que necessitam de muitos fios, muitos contextos, e muitos objetos globais. É uma API refinada, apoiando muitas combinações diferentes de peças, e dando às aplicações um controle preciso sobre como SpiderMonkey se comporta.

Aqui está o código clichê necessário  para uma aplicação JSAPI mínima. Ele contém tudo o descrito acima.

#include "jsapi.h"

/* The class of the global object. */
static JSClass global_class = { "global",
                                JSCLASS_NEW_RESOLVE | JSCLASS_GLOBAL_FLAGS,
                                JS_PropertyStub,
                                JS_DeletePropertyStub,
                                JS_PropertyStub,
                                JS_StrictPropertyStub,
                                JS_EnumerateStub,
                                JS_ResolveStub,
                                JS_ConvertStub,
                                NULL,
                                JSCLASS_NO_OPTIONAL_MEMBERS
};

/* The error reporter callback. */
void reportError(JSContext *cx, const char *message, JSErrorReport *report) {
     fprintf(stderr, "%s:%u:%s\n",
             report->filename ? report->filename : "[no filename]",
             (unsigned int) report->lineno,
             message);
}

int run(JSContext *cx) {
    /* Enter a request before running anything in the context */
    JSAutoRequest ar(cx);

    /* Create the global object in a new compartment. */
    JSObject *global = JS_NewGlobalObject(cx, &global_class, NULL);
    if (global == NULL)
        return 1;

    /* Set the context's global */
    JSAutoCompartment ac(cx, global);
    JS_SetGlobalObject(cx, global);

    /* Populate the global object with the standard globals, like Object and Array. */
    if (!JS_InitStandardClasses(cx, global))
        return 1;

    /* Your application code here. This may include JSAPI calls to create your own custom JS objects and run scripts. */

    return 0;
}

int main(int argc, const char *argv[]) {
    /* Initialize the JS engine -- new/required as of SpiderMonkey 31. */
    if (!JS_Init())
       return 1;

    /* Create a JS runtime. */
    JSRuntime *rt = JS_NewRuntime(8L * 1024L * 1024L, JS_NO_HELPER_THREADS);
    if (rt == NULL)
       return 1;

    /* Create a context. */
    JSContext *cx = JS_NewContext(rt, 8192);
    if (cx == NULL)
       return 1;
    JS_SetOptions(cx, JSOPTION_VAROBJFIX);
    JS_SetErrorReporter(cx, reportError);

    int status = run(cx);

    JS_DestroyContext(cx);
    JS_DestroyRuntime(rt);

    /* Shut down the JS engine. */
    JS_ShutDown();

    return status;
}

Cada JSNative tem a mesma assinatura , independentemente de que argumentos ele espera receber a partir do JavaScript.

Os argumentos de JavaScript para a função que são dadas em argc e vp.argc dizem quantos argumentos reais o chamador passou, e JS_ARGV ( cx, vp ) retorna um array desses argumentos . Os argumentos não têm  tipos nativos C ++ como int e float , mas sim, eles são jsvals , valores de JavaScript. A função nativa usa JS_ConvertArguments para converter os argumentos para tipos C++ e armazená-los em variáveis ​​locais. A função nativa usa JS_SET_RVAL ( cx, vp , val ) para armazenar o valor de retorno JavaScript.

Em caso de sucesso , um JSNative deve chamar JS_SET_RVAL e retornar JS_TRUE . O valor transmitido JS_SET_RVAL é devolvido ao chamador JavaScript .

Em caso de falha , um JSNative chama uma função de erro de comunicação , neste caso JS_ReportError e retorna JS_FALSE . Isso faz com que uma exceção JavaScript seja acionada. O chamador pode capturar a exceção usando uma instrução try / catch em JavaScript.

Para chamar funções nativas do de JavaScript  pode-se declarar uma tabela JSFunctionSpecs descrevendo as funções . Em seguida, chamar JS_DefineFunctions .

static JSFunctionSpec myjs_global_functions[] = {
    JS_FS("rand",   myjs_rand,   0, 0),
    JS_FS("srand",  myjs_srand,  0, 0),
    JS_FS("system", myjs_system, 1, 0),
    JS_FS_END
};

    ...
    if (!JS_DefineFunctions(cx, global, myjs_global_functions))
        return JS_FALSE;
    ...

Uma vez que as funções são definidas como global, qualquer script que usa global como o objeto global pode chamá-las, assim como qualquer página da web pode chamar uma caixa de alerta. No ambiente que criamos, o script "Olá mundo" ficaria assim:

system("echo hello world");

JSAPI - Conceitos

Esta seção tem como objetivo preencher as principais lacunas no quadro do JSAPI apresentado até agora. Para fazer qualquer coisa útil com SpiderMonkey, você deve ler todas as três seções.

JavaScript Valores

Artigo Principal : JS::Value

JavaScript é uma linguagem de tipagem dinâmica: as variáveis ​​e propriedades não tem um tipo que é fixado em tempo de compilação. Como é possível que uma linguagem de tipagem estática, como C ou C + +, em que todas as variáveis ​​têm tipos, interagir com JavaScript?O JSAPI fornece um tipo de dados, JS::Value (também com um typedef jsval obsoleto), que pode conter valores de JavaScript de qualquer tipo. Um  JS::Value pode ser um número, uma string, um valor booleano, uma referência a um objeto (como um Object, Array, Date, ou Function), ou um dos valores especiais null ou undefined..

Para inteiros e valores booleanos, um jsval contém o próprio valor. Em outros casos, o jsval é um ponteiro para um objeto, string ou número.

JS::Value inclue membros de funções  para testar  tipos de dados JavaScript. Estes são isObject(),isNumber(), isInt32(), isDouble(), isString(), isBoolean(), isNull(), e isUndefined().

Garbage collection

As it runs, JavaScript code implicitly allocates memory for objects, strings, variables, and so on.  Garbage collection is the process by which the JavaScript engine detects when those pieces of memory are no longer reachable—that is, they could not possibly ever be used again—and reclaims the memory.

Garbage collection has two important consequences for JSAPI applications. First, the application must be very careful to ensure that any values it needs are GC-reachable. The garbage collector is rather eager about its job. Any object you leave lying around will be destroyed if you don't tell the JSAPI you're still using it. Second, the application should take steps to reduce the performance impact of garbage collection.

Keeping objects alive

If your JSAPI application crashes, it is likely due to a GC-related error. The application must ensure that the garbage collector can reach all the objects, numbers, and strings that are still being used. Otherwise, the GC will free the memory occupied by those values, leading to a probable crash the next time your program tries to use them.

There are many ways to ensure that a value is GC-reachable.

• If you just need the value to remain reachable for the duration of a JSNative call, store it in *rval or an element of the argv array. The values stored in those locations are always reachable. To get extra argv slots, use JSFunctionSpec.extra.

• If a custom object needs certain values to remain in memory, just store the values in properties of the object. As long as the object is reachable, its properties will remain reachable. If these values must not be accessible from JavaScript, use reserved slots instead. Or store the values in private data and implement JSClass.mark.

• If a function creates new objects, strings, or numbers, it can use JS_EnterLocalRootScope and JS_LeaveLocalRootScope to keep those values alive for the duration of the function.

• To keep a value alive permanently, store it in a GC root.

Still, GC bugs do occur. These two functions, both available only in DEBUG builds, are especially useful for debugging GC-related crashes:

• Use JS_SetGCZeal to enable extra garbage collection. GC zeal usually causes a GC-related crash to occur much sooner (closer to its cause) and more reliably. It's for development and debugging only, because the extra garbage collection makes JS very slow.

• Use JS_DumpHeap to dump the SpiderMonkey heap or specific interesting parts of it.

See SpiderMonkey Garbage Collection Tips for more details.

GC performance

Overly frequent garbage collection can be a performance issue. Some applications can reduce the frequency of garbage collection simply by increasing the initial size of the JSRuntime.

Perhaps the best technique is to perform garbage collection during idle time, when it is least likely to have any impact on the user. By default, the JavaScript engine performs garbage collection when it has no other choice except to grow the process. This means that garbage collection typically happens when memory-intensive code is running, perhaps the worst possible time. An application can trigger garbage collection at a more convenient time by calling JS_GC or JS_MaybeGC. JS_GC forces garbage collection. JS_MaybeGC performs garbage collection only if it is likely to reclaim a worthwhile amount of memory.

Errors and exceptions

The importance of checking the return value of JSAPI functions, of course, goes without saying. Almost every JSAPI function that takes a JSContext * argument can fail. The system might run out of memory. There might be a syntax error in a script. Or a script might explicitly throw an exception.

The JavaScript language has exceptions, and C++ has exceptions, but they are not the same thing. SpiderMonkey does not use C++ exceptions for anything. JSAPI functions never throw C++ exceptions, and when SpiderMonkey calls an application callback, the callback must not throw a C++ exception.

Throwing and catching exceptions

We have already seen one example of how to throw an exception from a JSNative function. Simply call JS_ReportError, with printf-style arguments, and return JS_FALSE.

    rc = system(cmd);
    if (rc != 0) {
        /* Throw a JavaScript exception. */
        JS_ReportError(cx, "Command failed with exit code %d", rc);
        return JS_FALSE;
    }

This is very much like the JavaScript statement throw new Error("Command failed with exit code " + rc);. Again, note that calling JS_ReportError does not cause a C++ exception to be thrown. It only creates a new JavaScript Error object and stores it in the context as the current pending exception. The application must also return JS_FALSE.

Once the C++ function returns JS_FALSE, the JavaScript engine starts unwinding the JavaScript stack, looking for a catch or finally block to execute. But SpiderMonkey's stack unwinding never removes application's C++ functions from the stack. Instead, SpiderMonkey simply returns JS_FALSE or NULL to the application, which can then handle the error as it chooses—or just return JS_FALSE to let it propagate further up the stack.

Several more examples of throwing and catching exceptions can be found in the JSAPI Phrasebook.

Error reports

TODO your custom errorreporter

TODO when errors are reported

Automatic handling of uncaught exceptions

The JS_Compile*, JS_Call*, JS_Execute*, and JS_Evaluate* functions automatically pass exceptions to the error reporter in certain cases. Each of these functions checks, just before it returns, to see if an exception is pending in the current JSContext. If so, it then checks to see if there is any other JavaScript script or function on the stack in that JSContext. If so, then the exception might yet be caught, so SpiderMonkey does nothing and returns JS_FALSE, allowing the exception to propagate. But if nothing is on the JavaScript stack, then the uncaught exception is passed to the error reporter and the pending exception is cleared.

The basic consequence is that top-level application code can just set an error reporter and start calling JSAPI functions. It never has to explicitly handle uncaught exceptions; the error reporter is automatically called. An application can disable automatic uncaught-exception handling using the JSOPTION_DONT_REPORT_UNCAUGHT option, but it must then deal with uncaught exceptions explicitly by calling JS_IsExceptionPending, JS_GetPendingException, JS_ReportPendingException, and/or JS_ClearPendingException whenever a JSAPI function returns JS_FALSE or NULL.

Uncatchable errors

Another way for a JSNative callback to report an error is like this:

    if (p == NULL) {
        JS_ReportOutOfMemory(cx);
        return JS_FALSE;
    }

This does something subtly different from what JS_ReportError does.

Most errors, including those raised by JS_ReportError, are represented as JavaScript exceptions and thus interact with the JavaScript exception-handling language features, try, catch, and finally. However, in some cases we do not want scripts to be able to catch an error; we want script execution to terminate right away. If the system runs out of memory in the middle of a script, we do not want finally blocks to execute, because almost anything a script does requires at least a little memory, and we have none. If a script has been running too long and we want to kill it, it's no good to throw an exception—the script could just catch it and keep going.

Therefore JS_ReportOutOfMemory(cx) does not set the pending exception. It is an uncatchable error.

If SpiderMonkey runs out of memory, or a JSAPI callback returns JS_FALSE without an exception pending, this is treated as an uncatchable error. The JavaScript stack is unwound in the normal way except that catch and finally blocks are ignored. The most recent JSAPI call returns JS_FALSE or NULL to the application.

An uncatchable error leaves the JSContext in a good state. It can be used again right away. The application does not have to do anything to “recover” from the error, as far as the JSAPI is concerned. (Of course, if the error is that the system is out of memory, that problem remains to be dealt with.)

Here is some example code that throws an uncatchable error.

    /* Call the error reporter, if any. This part is optional. */
    JS_ReportError(cx, "The server room is on fire!");
    JS_ReportPendingException(cx);

    /* Make sure the error is uncatchable. */
    JS_ClearPendingException(cx);
    return JS_FALSE;

More sample code

The following examples illustrate how to achieve a few different effects using the JSAPI.

Note that the most important example is in the "A minimal example" section above. More JSAPI code samples appear in the JSAPI Phrasebook.

Defining objects and properties

/* Statically initialize a class to make "one-off" objects. */
JSClass my_class = {
    "MyClass",

    /* All of these can be replaced with the corresponding JS_*Stub
       function pointers. */
    my_addProperty, my_delProperty, my_getProperty, my_setProperty,
    my_enumerate,   my_resolve,     my_convert,     my_finalize
};

JSObject *obj;

/*
 * Define an object named in the global scope that can be enumerated by
 * for/in loops.  The parent object is passed as the second argument, as
 * with all other API calls that take an object/name pair.  The prototype
 * passed in is null, so the default object prototype will be used.
 */
obj = JS_DefineObject(cx, globalObj, "myObject", &my_class, NULL,
                      JSPROP_ENUMERATE);

/*
 * Define a bunch of properties with a JSPropertySpec array statically
 * initialized and terminated with a null-name entry.  Besides its name,
 * each property has a "tiny" identifier (MY_COLOR, e.g.) that can be used
 * in switch statements (in a common my_getProperty function, for example).
 */
enum my_tinyid {
    MY_COLOR, MY_HEIGHT, MY_WIDTH, MY_FUNNY, MY_ARRAY, MY_RDONLY
};

static JSPropertySpec my_props[] = {
    {"color",       MY_COLOR,       JSPROP_ENUMERATE},
    {"height",      MY_HEIGHT,      JSPROP_ENUMERATE},
    {"width",       MY_WIDTH,       JSPROP_ENUMERATE},
    {"funny",       MY_FUNNY,       JSPROP_ENUMERATE},
    {"array",       MY_ARRAY,       JSPROP_ENUMERATE},
    {"rdonly",      MY_RDONLY,      JSPROP_READONLY},
    {0}
};

JS_DefineProperties(cx, obj, my_props);

/*
 * Given the above definitions and call to JS_DefineProperties, obj will
 * need this sort of "getter" method in its class (my_class, above).  See
 * the example for the "It" class in js.c.
 */
static JSBool
my_getProperty(JSContext *cx, JSObject *obj, jsval id, jsval *vp)
{
    if (JSVAL_IS_INT(id)) {
        switch (JSVAL_TO_INT(id)) {
          case MY_COLOR:  *vp = . . .; break;
          case MY_HEIGHT: *vp = . . .; break;
          case MY_WIDTH:  *vp = . . .; break;
          case MY_FUNNY:  *vp = . . .; break;
          case MY_ARRAY:  *vp = . . .; break;
          case MY_RDONLY: *vp = . . .; break;
        }
    }
    return JS_TRUE;
}

Defining classes

This pulls together the above API elements by defining a constructor function, a prototype object, and properties of the prototype and of the constructor, all with one API call.

Initialize a class by defining its constructor function, prototype, and per-instance and per-class properties. The latter are called "static" below by analogy to Java. They are defined in the constructor object's scope, so that MyClass.myStaticProp works along with new MyClass().

JS_InitClass takes a lot of arguments, but you can pass NULL for any of the last four if there are no such properties or methods.

Note that you do not need to call JS_InitClass to make a new instance of that class—otherwise there would be a chicken-and-egg problem making the global object—but you should call JS_InitClass if you require a constructor function for script authors to call via new, and/or a class prototype object (MyClass.prototype) for authors to extend with new properties at run time. In general, if you want to support multiple instances that share behavior, use JS_InitClass.

protoObj = JS_InitClass(cx, globalObj, NULL, &my_class,

                        /* native constructor function and min arg count */
                        MyClass, 0,

                        /* prototype object properties and methods -- these
                           will be "inherited" by all instances through
                           delegation up the instance's prototype link. */
                        my_props, my_methods,

                        /* class constructor properties and methods */
                        my_static_props, my_static_methods);

Running scripts

/* These should indicate source location for diagnostics. */
char *filename;
uintN lineno;

/*
 * The return value comes back here -- if it could be a GC thing, you must
 * add it to the GC's "root set" with JS_AddRoot(cx, &thing) where thing
 * is a JSString *, JSObject *, or jsdouble *, and remove the root before
 * rval goes out of scope, or when rval is no longer needed.
 */
jsval rval;
JSBool ok;

/*
 * Some example source in a C string.  Larger, non-null-terminated buffers
 * can be used, if you pass the buffer length to JS_EvaluateScript.
 */
char *source = "x * f(y)";

ok = JS_EvaluateScript(cx, globalObj, source, strlen(source),
                       filename, lineno, &rval);

if (ok) {
    /* Should get a number back from the example source. */
    jsdouble d;

    ok = JS_ValueToNumber(cx, rval, &d);
    . . .
}

Calling functions

/* Call a global function named "foo" that takes no arguments. */
ok = JS_CallFunctionName(cx, globalObj, "foo", 0, 0, &rval);

jsval argv[2];

/* Call a function in obj's scope named "method", passing two arguments. */
argv[0] = . . .;
argv[1] = . . .;
ok = JS_CallFunctionName(cx, obj, "method", 2, argv, &rval);

JSContext

Because there is a certain amount of overhead associated with allocating and maintaining contexts, a JSAPI application should:

1. Create only as many contexts as it needs at one time.
2. Keep contexts for as long as they may be needed, rather than destroying and recreating them as needed.

If your application creates multiple runtimes, the application may need to know which runtime a context is associated with. In this case, use JS_GetRuntime.

Use JS_SetContextPrivate and JS_GetContextPrivate to associate application-specific data with a context.

Initializing built-in and global JS objects

For a complete list of built-in objects provided by SpiderMonkey, see JS_InitStandardClasses.

The global object that an application provides to scripts largely determines what those scripts can do. For example, the Firefox browser uses its own global object, window. To change the global object for your application, call JS_SetGlobalObject.

Creating and initializing custom objects

In addition to using the engine's built-in objects, you will create, initialize, and use your own JS objects. This is especially true if you are using the JS engine with scripts to automate your application. Custom JS objects can provide direct program services, or they can serve as interfaces to your program's services. For example, a custom JS object that provides direct service might be one that handles all of an application's network access, or might serve as an intermediary broker of database services. Or a JS object that mirrors data and functions that already exist in the application may provide an object-oriented interface to C code that is not otherwise, strictly-speaking, object-oriented itself. Such a custom object acts as an interface to the application itself, passing values from the application to the user, and receiving and processing user input before returning it to the application. Such an object might also be used to provide access control to the underlying functions of the application.

There are two ways to create custom objects that the JS engine can use:

• Write a JS script that creates an object, its properties, methods, and constructor, and then pass the script to the JS engine at run time.
• Embed code in your application that defines the object's properties and methods, call the engine to initialize a new object, and then set the object's properties through additional engine calls. An advantage of this method is that your application can contain native methods that directly manipulate the object embedding.

In either case, if you create an object and then want it to persist in the run time where it can be used by other scripts, you must root the object by calling JS_AddRoot or JS_AddNamedRoot. Using these functions ensures that the JS engine will keep track of the objects and clean them up during garbage collection, if appropriate.

Creating an object from a script

One reason to create a custom JS object from a script is when you only need an object to exist as long as the script that uses it is executing. To create objects that persist across script calls, you can embed the object code in your application instead of using a script.

Note: You can also use scripts to create persistent objects, too.

To create a custom object using a script:

1. Define and spec the object. What is it intended to do? What are its data members (properties)? What are its methods (functions)? Does it require a run time constructor function?
2. Code the JS script that defines and creates the object. For example: function myfun(){ var x = newObject(); . . . } NOTE: Object scripting using JavaScript occurs outside the context of embedding the JS engine in your applications. For more information about object scripting, see the Client-Side JavaScript Guide and the Server-Side JavaScript Guide. Embed the appropriate JS engine call(s) in your application to compile and execute the script. You have two choices: 1.) compile and execute a script with a single call to JS_EvaluateScript, JS_EvaluateUCScript or 2.) compile the script once with a call to JS_CompileScript or JS_CompileUCScript, and then execute it repeatedly with individual calls to JS_ExecuteScript. The "UC" versions of these calls provide support for Unicode-encoded scripts.

An object you create using a script only can be made available only during the lifetime of the script, or can be created to persist after the script completes execution. Ordinarily, once script execution is complete, its objects are destroyed. In many cases, this behavior is just what your application needs. In other cases, however, you will want object persistence across scripts, or for the lifetime of your application. In these cases you need to embed object creation code directly in your application, or you need to tie the object directly to the global object so that it persists as long as the global object itself persists.

Custom objects

An application can create a custom object without bothering with a JSClass:

1. Implement the getters, setters, and methods for your custom object in C or C++.  Write a JSPropertyOp for each getter or setter.  Write a JSNative or JSFastNative for each method.
2. Declare a JSPropertySpec array containing information about your custom object's properties, including getters and setters.
3. Declare a JSFunctionSpec array containing information about your custom object's methods.
4. Call JS_NewObject, JS_ConstructObject, or JS_DefineObject to create the object.
5. Call JS_DefineProperties to define the object's properties.
6. Call JS_DefineFunctions to define the object's methods.

JS_SetProperty can also be used to create properties on an object. The properties it creates do not have getters or setters; they are ordinary JavaScript properties.

Providing private data for objects

Like contexts, you can associate large quantities of data with an object without having to store the data in the object itself. Call JS_SetPrivate to establish a pointer to private data for the object, and call JS_GetPrivate to retrieve the pointer so that you can access the data. Your application is responsible for creating and managing this optional private data.

To create private data and associate it with an object:

1. Establish the private data as you would a normal C void pointer variable.
2. Call JS_SetPrivate, specify the object for which to establish private data, and specify the pointer to the data.

For example:

 JS_SetPrivate(cx, obj, pdata);

To retrieve the data at a later time, call JS_GetPrivate, and pass the object as an argument. This function returns the pointer to an object's private data:

 pdata = JS_GetPrivate(cx, obj);

Special topics

Unicode

To pass Unicode data between JavaScript and native code, represent the data in UTF-16 in memory. JavaScript strings, property names, and programs are all made up of jschars, which are 16-bit unsigned integers.

Many JSAPI functions operate on null-terminated, 8-bit char strings. These functions convert their char * arguments to 16-bit strings by zero-extending each 8-bit char to 16 bits—unless JS_C_STRINGS_ARE_UTF8 is defined or JS_SetCStringsAreUTF8 has been called, in which case each char * string is interpreted as UTF-8 Unicode text.

The JSAPI provides jschar-based versions of many API functions that operate on strings, object properties, and JavaScript code.

jschar-based functions work exactly like their char-based namesakes, except that where traditional functions take a char * argument, the Unicode versions take a jschar * argument, usually with a separate argument specifying the length of the string in jschars.

Compiled scripts

The easiest way to run a script is to use JS_EvaluateScript, which compiles and executes the script in one go.

But sometimes an application needs to run a script many times. In this case, it may be faster to compile the script once and execute it multiple times.

The JSAPI provides a type, JSScript, that represents a compiled script. The life cycle of a JSScript looks like this:

• The application compiles some JavaScript code using JS_CompileScript, JS_CompileUTF8File, or JS_CompileFileHandle. These functions return a pointer to a new JSScript.

• The application calls JS_ExecuteScript (or JS_ExecuteScriptPart) any number of times. It is safe to use a JSScript in multiple different contexts, but only within the JSRuntime and thread in which it was created.

Here is some example code using a compiled script:

/*
 * Compile a script and execute it repeatedly until an
 * error occurs.  (If this ever returns, it returns false.
 * If there's no error it just keeps going.)
 */
JSBool compileAndRepeat(JSContext *cx, const char *filename)
{
    JSScript *script;

    script = JS_CompileUTF8File(cx, JS_GetGlobalObject(cx), filename);
    if (script == NULL)
        return JS_FALSE;   /* compilation error */

    for (;;) {
        jsval result;

        if (!JS_ExecuteScript(cx, JS_GetGlobalObject(cx), script, &result))
            break;
        JS_MaybeGC(cx);
    }

    return JS_FALSE;
}

The lifetime of the compiled script is tied to the lifetime of a JavaScript object, the garbage collector destroys the script when it is no longer reachable. The JSAPI provides this feature via the JS_NewScriptObject function. The life cycle of a script using this feature is like this:

• The application compiles some JavaScript code.

• To protect the compiled script from garbage collection, the application creates a compiled script object by calling JS_NewScriptObject and makes that object GC-reachable using JS_SetProperty, JS_SetReservedSlot, JS_AddRoot, or some other function.

• The application executes the compiled script any number of times.

• As the application progresses, eventually it doesn't need the compiled script anymore, and the compiled script object becomes unreachable.

• The garbage collector then eventually collects the unreachable script and its components.

Here is example code demonstrating the technique—but note that this case is not really complex enough to warrant the use of JS_NewScriptObject. The above example does the same thing more directly.

/*
 * Compile a script and execute it repeatedly until an
 * error occurs.  (If this ever returns, it returns false.
 * If there's no error it just keeps going.)
 */
JSBool compileAndRepeat(JSContext *cx, const char *filename)
{
    JSScript *script;
    JSObject *scriptObj;

    script = JS_CompileUTF8File(cx, JS_GetGlobalObject(cx), filename);
    if (script == NULL)
        return JS_FALSE;   /* compilation error */

    scriptObj = JS_NewScriptObject(cx, script);
    if (scriptObj == NULL) {
        JS_DestroyScript(cx, script);
        return JS_FALSE;
    }

    if (!JS_AddNamedObjectRoot(cx, &scriptObj, "compileAndRepeat script object"))
        return JS_FALSE;

    for (;;) {
        jsval result;

        if (!JS_ExecuteScript(cx, JS_GetGlobalObject(cx), script, &result))
            break;
        JS_MaybeGC(cx);
    }

    JS_RemoveObjectRoot(cx, &scriptObj);  /* scriptObj becomes unreachable
                                             and will eventually be collected. */
    return JS_FALSE;
}

Security

Many applications use SpiderMonkey to run untrusted code. In designing this kind of application, it's important to think through the security concerns ahead of time. Your application will need to do several things.

• Deploy security updates - Firefox automatically installs updates, so security fixes are deployed as soon as they are available. Unless you also regularly deploy SpiderMonkey security updates, a determined hacker could use publicly known bugs in the engine to attack your application. Note that the kind of attack we're talking about here is where a hacker uses JavaScript to attack the C++ code of the engine itself (or your embedding). The rest of the items in this list talk about security issues that arise within JavaScript itself, even if the engine is working properly.
• Block simple denial-of-service attacks - A program like while(true){} should not hang your application. To stop execution of scripts that run too long, use JS_SetOperationCallback. Likewise, a function like function f(){f();} should not crash your application with a stack overflow. To block that, use JS_SetNativeStackQuota.
• Control access to sensitive data - Your application might expose data to some scripts that other scripts should not be able to see. For example, you might let your customers write scripts that operate on their own data, but not other customers' data. These access rules must be enforced somehow.
• Control access to dangerous functionality - Suppose your application has a method deleteUserAccount() which is meant to be used by administrators only. Obviously if untrusted code can use that method, you have a security problem.

The first two problems are important but fairly straightforward and will not be discussed further here. The rest of this section tells how you can control scripts' access to data and functionality.

The best security is no security (really)

Do you ever worry about your snake eating your mouse? No? If you don't have both a snake and a mouse, you don't have this problem.

Likewise, if your application doesn't have both untrusted users (snakes) and sensitive data or dangerous functionality that's exposed to JavaScript (mice), then you don't need to read any further. The functions and objects created by JS_InitStandardClasses are safe. They do not provide access to files, the network, or anything browser-related. The most sensitive information they expose to scripts is the current date and time.

Object-capabilities-based security

One way to keep a snake from eating a mouse is to keep the mouse and the snake in separate cages.

One way to keep user A from accessing user B's sensitive data or dangerous functions is to keep each user's code in a separate sandbox. That is, create a separate JSContext and global object for each user, and always run each script in the appropriate context. When setting up a new global object, simply don't define any functions the user shouldn't have access to. This approach is called object-capabilities security. To learn more about it, watch the movie or read the book.

The metaphor is misleading in one regard: the snake can't reach the mouse because there's a physical barrier in the way. With SpiderMonkey the situation is more subtle. There's no barrier; there's just no way to get there from here. How can a malicious script get a reference to an object from another sandbox? It might as well be in a parallel universe. Even global variables are per-sandbox. There is no getObjectFromOtherSandbox() function. Your application just needs to take care not to expose any such function to scripts.

In short, never pass one user's data and objects to another user's code, and you'll have no access control issues. SpiderMonkey won't do it if you don't.

Trade-offs. Object-capabilities security is security without run-time security checks. It is easy to implement, easy to reason about, and fast. But in fairness there are some drawbacks. First, the failure mode is pretty severe. If you do accidentally leak an object from one sandbox into another, the genie is out of the bottle. Once a malicious script gets a reference to a single object in a sandbox, it can use that object to get a reference to the sandbox's global object, and from there, almost any other object or function in that sandbox. There is no way to fix it except to destroy both sandboxes and start over. A second drawback is that the system doesn't automatically respond to changes in user privileges. Suppose user A is not an administrator, so you set up sandbox A with no administrator functionality. If you promote user A to be an admin, SpiderMonkey won't magically update sandbox A to have the administrator classes and functions you didn't define before. Your application will have to do that explicitly. Conversely, if you want to strip user A's administrator privileges, but you have already given administrator functions to user A's scripts, that's even worse. You have no choice but to destroy user A's sandbox and start over.

Fine-grained security

Another way to keep a snake from eating a mouse is to watch the snake constantly, and if it tries to eat the mouse, intervene.

SpiderMonkey is designed to support custom, application-defined security models. For example, the Firefox browser has a complex and powerful security model. Some JavaScript code ("chrome") has full access to the system. Scripts from web pages ("content") have very limited access. The same origin policy governs a script's access to data and functions from other web pages.

The SpiderMonkey security model is based on the Java principals security model. This model provides a common security interface, but the actual security implementation is up to you.

To use SpiderMonkey's fine-grained security features:

• Decide what security policy you want to enforce.

• Insert a call to JS_CheckAccess at each point in your application where a security check is necessary. (Some security checks are also built into the JavaScript engine; you must decide what security policy to enforce for each of these checks.)

• Implement one or more JSPrincipals objects in your application. You need one JSPrincipals object for each different set of privileges that a script might have.

• When compiling or executing code, use the JSAPI functions that attach principals to the compiled code. These functions have ForPrincipals in the name. They are listed below. The purpose of using these functions is to ensure that your access check callbacks have accurate information about who is trying to access an object.

  Function	Purpose
  JS_CompileScriptForPrincipals, JS_CompileUCScriptForPrincipals, JS_CompileFileHandleForPrincipals	Compile a script with security information. (To execute a compiled script, use JS_ExecuteScript.)
  JS_CompileFunctionForPrincipals, JS_CompileUCFunctionForPrincipals	Create a JavaScript function with security information.
  JS_EvaluateScriptForPrincipals, JS_EvaluateUCScriptForPrincipals	Compile and execute a script with security information.

• Implement access check callback functions (see JSClass.checkAccess and JS_SetCheckObjectAccessCallback). These will be called from JS_CheckAccess and sometimes from within the JavaScript engine. An access check callback function can use jsdbgapi.h functions such as JS_FrameIterator and JS_StackFramePrincipals to obtain the principals of the code that is trying to perform the checked operation. Then it determines whether to allow the operation to proceed.

Tracing and Profiling

There are features provided by the JSAPI that make it easier to implement JavaScript tracers and profilers.

Function tracing

If you configure with --enable-trace-jscalls, you can use JS_SetFunctionCallback() to set up a C function to be called whenever a JavaScript function is about to be called, or has finished executing:

void funcTransition(const JSFunction *func,
                    const JSScript *scr,
                    const JSContext *const_cx,
                    JSBool entering)
{
  JSContext *cx = const_cast<JSContext*>(const_cx);
  JSString *name = JS_GetFunctionId((JSFunction*)func);
  const char *entExit;
  const char *nameStr;

  /* build a C string for the function's name */

  if (!name) {
    nameStr = "Unnamed function";
  } else {
    nameStr = JS_EncodeString(cx, name);
  }

  /* build a string for whether we're entering or exiting */

  if (entering) {
    entExit = "Entering";
  } else {
    entExit = "Exiting";
  }

  /* output information about the trace */

  printf("%s JavaScript function: %s at time: %ld", entExit, nameStr, clock());
} 

void enableTracing(JSContext *cx) {
  JS_SetFunctionCallback(cx, funcTransition);
}

void disableTracing(JSContext *cx) {
  JS_SetFunctionCallback(cx, NULL);
}