IcedTeaNPPlugin LiveConnect Design

Plugin Architecture

• Divided into C++ and Java components
• • C++ side talks to the browser
  • Java side talks to the JVM
  • Linked via a FIFO link
  • Common string exchange format (UTF-8)
• Over 95% of changes in NPPlugin have been on the C++ side
• Java side has been reused as much as possible to re-use the proven stable code

C++ Architecture

• Encompassing classes from the LiveConnect engine (which previously resided in Mozilla and was exposed via OJI)
• Each JavaScript var corresponding to a Java object has a corresponding IcedTeaScriptableJavaObject
• Engine controls the object life and services all requests (get field, set field, invoke method, etc.)

C++ Architecture (Browser Interface)

• Browser interface consists primarily of IcedTeaScriptableJavaPackageObject, IcedTeaScriptableJavaObject and IcedTeaPluginRequestProcessor.
• Above classes are unaware of Java interactions and delegate to the Java interfaces for Java interaction.
• They process all requests coming from the browser and going to the browser (getMember, call, eval, etc.)

C++ Architecture (Java Interface)

• Java interface consists primarily of IcedTeaJavaRequestProcessor.
• This class has full knowledge of how the Java side works, and constructs appropriate requests to get all information from Java.
• The class processes all requests to the JVM.

Java Architecture

• Java side has two core classes aside from helpers: PluginAppletViewer and PluginAppletSecurityContext.
• PluginAppletViewer is an interface to NetX and processes JS-related requests to and from NetX (the applet).
• PluginAppletSecurityContext is a direct reflection-based interface to the VM. It processes all LiveConnect requests to and from the JVM.
• Request processing is asynchronous, with scalable generic request processing workers.

Java Architecture (PluginAppletViewer)

• Control of applet (initialize, resize, destroy, etc.) from browser.
• Access to JavaScript from the applet (getMember, setMember, call, eval, etc.)

Java Architecture (PluginAppletSecurityContext)

• Direct access to the JVM from the browser (LiveConnect) via reflection.
• All reflection is built-in, so C++ side never needs to be aware of the complexities, unlike how OJI was.
• All VM calls are inside a sandbox, so JavaScript can not do things that the default sandboxed VM can't.

MessageBus Architecture (C++)

• The link to Java is exposed to the rest of the code via a uniform "MessageBus" interface.
• Since the code is unaware of the link specifics and has no synchronicity guarantee, the communication medium can be switched relatively easily.
• Classes interested in the messages implement a BusSubscriber class and subscribe to the bus of interest.
• When messages come in, the bus notifies all subscribers.

Example JS->Java Workflow

• Example shows how NPP_HasProperty() works
• Browser has a link to an IcedTeaScriptableJavaObject representing a Java object instance.
• It call IcedTeaScriptableJavaObject::HasProperty()
• HasProperty() creates an IcedTeaJavaRequestProcessor ("Java processor")
• The Java processor exposes all necessary APIs to the VM, including hasProperty (called hasField for Java naming consistency).
• Before making a hasField request, the processor subscribes itself to the "from Java" bus, so that it can read the response.
• The hasField request is made by the processor and posted to the "to Java" bus.
• The processor waits for either a response or a timeout.
• Once a response is received, the processor unsubscribes itself from the "from Java" bus, performs post-processing and returns.
• The IcedTeaScriptableJavaObject object reads the response and sends it to the browser.

Example Java->JS Workflow

• All access to JS is via JSObject instances as defined in the LiveConnect specification.
• If an applet wants to access a member of JSObject, "window" for example, it will call getMember on the window's JSObject.
• getMember calls a similarly named function in PluginAppletViewer.
• PluginAppletViewer constructs a request for the C++ side and posts it on the FIFO link.
• On the C++ side, IcedTeaPluginRequestProcessor (the plugin processor) is always subscribed to the "from Java" bus.
• When the getMember request comes through, the plugin processor gets notified.
• The embedded request