United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6674870 Common DOM implementation is severely deficient
JDK-6674870 : Common DOM implementation is severely deficient

Details
Type:
Bug
Submit Date:
2008-03-13
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-05-28
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b23)

Related Reports
Relates:

Sub Tasks

Description
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.

                                    

Comments
SUGGESTED FIX

webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6674870.2
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6674870/
                                     
2008-04-18
EVALUATION

The following bugs were fixed:

  - The implementation was changed to take advantage of the types that
    are implicit in the structure of the DOM. The DOMObjectFactory was
    changed to not rely on the printed output of the JavaScript
    objects to infer what Java object to instantiate, but instead to
    call down to the JavaScript engine and its DOM implementation to
    query things like the node type and element tag name to determine
    which Java-side wrapper to instantiate. Calling code now calls the
    type-specific factory method. Null checks and type checks were
    pushed into the DOMObjectFactory to reduce duplicated code.

    Note that this change obsoletes the BrowserService.mapBrowserElement
    API and a significant amount of code in the old IE plugin, but it
    was decided not to delete this code at this time, because doing so
    will make it more difficult to make comparisons between the old
    plugin's source code in 6u10 and earlier releases. When the old
    plugin is removed from the source tree, these methods can be
    deleted, and a note has been left to that effect in the
    Applet2BrowserService.

  - Generally, the various nodes' implementations were reduced to be
    thin wrappers on top of the underlying JavaScript objects. There
    were areas such as in the CSS package where Java code was written
    where simple JavaScript calls should have been made instead. The
    DOMImplementation was changed to delegate to the browser's
    underlying JavaScript object for hasFeature() and other queries.
    Many operations which were previously unsupported for apparently
    arbitrary reasons have been implemented by calling down to
    JavaScript.

  - The code was filled out in certain key areas. NamedNodeMap, which
    provides access to tags' attributes, was implemented along with a
    few other classes.

  - Bugs were fixed throughout the preexisting code, including several
    bugs in the core Node class.

  - A new entry point,
      public static void
        com.sun.java.browser.plugin2.DOM.getDocument(Applet applet);
    has been added to bootstrap the DOM manipulation and querying
    process to address both architectural and implementation flaws in
    the previous code in the j2se workspace under
    com/sun/java/browser/dom. This will be documented in the release
    notes for the new Java Plug-In.

A simple test applet has been written which descends recursively into
the DOM of the page it is on using the Common DOM API and prints a
representation of the page to System.out. This is the first proof of
concept that the new implementation is working -- the previous
implementation was broken in at least two key areas for even this
simple test (asking a Node whether it has children, and fetching the
attributes for a Node).
                                     
2008-04-18



Hardware and Software, Engineered to Work Together