The Common DOM implementation in the Java Plug-In is severely deficient, preventing effective use of Java in web applications. The code is littered with unimplemented operations that are trivial to support simply by calling down into the DOM implementation in the browser. The code should overall be a simple and straightforward Java wrapper of the underlying JavaScript APIs in the browser, but falls far short of this goal, with areas that for unknown reasons were attempted to be implemented without consulting the browser, resulting in large portions of the API that are left unsupported as "too difficult".

The current code relies on being able to infer the type of all DOM-related JavaScript objects including node lists fabricated as the results of certain queries, ignoring the implicit typing in the JavaScript DOM API. This results in a significant amount of unnecessary complexity in the IE Java/JavaScript bridge, mysterious undocumented internal APIs such as "mapBrowserElement", and inefficiencies in wrapping JavaScript objects as Java objects.

The APIs in the com.sun.java.browser.dom package invented for bootstrapping access to the W3C APIs are poorly designed and unnecessarily complex. The underlying JSObject APIs are implicitly thread-safe, so forcing a callback model on users similar to that of the AWT is unnecessary and capricious. The implementation is deficient as well; specification of the so-called DOMServiceProvider is completely ignored, preventing clean and complete replacement of the Common DOM implementation.

The code needs to be scrapped and rebuilt piece by piece, borrowing from the original implementation where possible, and following the design principle that it is intended to simply wrap the browser's underlying DOM without attempting to implement functionality by itself. The current DOMImplementation is an example of where this went badly wrong.