Quick Summary: We need a convenient way to map from org.w3c.dom.Node to JSNode.

Background and details: In WebKit there are two different sets of C++ classes for DOM types:

The raw DOM types:
WebCore::Node
WebCore::Element (which [indirectly] extends WebCore::Node)
etc

The JavaScript wrapper objects (which are generated):
WebCore::JSNode
WebCore::JSElement which extends JSNode
etc

On the Java side the raw DOM types get mapped to these generated classes:
NodeImpl - which implements org.w3c.dom.Node
ElementImpl - extends NodeImpl and implements org.w3c.dom.Element
etc

The JavaScript wrapper objects get mapped to
JSNode - which extends JSObject

JSNode has a getNode method to get the corresponding NodeImpl instance.

Converting from JSNode to org.w3c.dom.Node is straightforward, since JSNode has a getNode method that does that. However, there is no convenient and direct map to map from a org.w3c.dom.Node to a JavaScript value. It can be done through various convolutions, since the JavaScrpt bridge does handle the mapping - but only "magically" though a special conversion.

Regardless, having to explicitly convert back and both between JSNode and org.w3c.dom.Node may be confusing and inconvenient. An idea would be to combine JSNode and NodeImpl into a single class:

/** Generic wrapper for JavaScript objects. */
public class JSObject extends netscape.javascript.JSObject {
    private long peer; // Cast from a JSObjectRef
}

class JSNode extends JSObject implements org.w3c.dom.Node {
    private long nodePeer; // Cast from WebCore::Node reference
}

class ElementImpl extends JSNode implements org.w3c.dom.Element {
}

So you'd have a single Java instance that provides a wrapper for both the raw DOM instance as well as the JavaScript DOM objects. Hence you have two "peer" references to those C++ objects. The reference to the JavaScript peer should be lazy, so we don't have to create it just because we want DOM access.

A downside is that we pull in a JavaScript dependency: If you just want to manipulate the DOM and don't care about JavaScript, you will still get an object that if you instance it has a bunch of methods for getting, setting, and calling JavaScript.