JDK-6674870 : Common DOM implementation is severely deficient
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-13
  • Updated: 2010-09-08
  • Resolved: 2008-05-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b23Fixed
Related Reports
Relates :  
JDK-6618978 - Plugin2: Some of the CommonDOM functionality is broken in new design
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/
18-04-2008
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).
18-04-2008