浏览器的编程接口问题

 可以认为，目前Browser的编程接口有两个：一个是Java script，一个是W3C规定的DOM接口。前者是Browser亲生的，因为Java Script解释器和浏览器的渲染引擎紧密结合在一起，效率高，效果好。而且从商业角度考虑，大多数页面离不开java script，如果对其支持的不好，就会直接影响到Browser的市场前景。后者呢，是W3C制定的标准接口，是Browser抱养的。因此，它的实现相对来说并不理想，使用的人也不是很多。从业务角度考虑，一个浏览器即使不支持它也不会受到太大的市场压力。因此它的质量也可想而知的。另外，W3C目前只规定了HTML的DOM接口，对于Browser的新特性，比如对SVG的支持，对<canvas>标记的支持都办不到。

但是对于希望把浏览器作为应用的一个潜入式组件的开发者而言，DOM接口现状实在是一种噩梦。

这里，我想到这样一种解决方案：现在很多java script都在做js-java的桥接，我想能不能反其道而行之，做java-js的adaptor？我的思路是：把JAVA里DOM多数操作的实现给替换掉，不是让它们真的去操纵浏览器DOM树，而是仅仅生成一段JAVA SCRIPT代码，当遇到set**之类的方法时，通过某种途径执行这些java script代码。这里有两个难点：

一是如何得到并操纵浏览器的JS引擎。对于IE，找不到好的办法；但是对于Firefox/XULRUNNER，我想是可以的，通过装入插件，可以把JS引擎给暴露出来。

二是如何生成JAVA SCRIPT代码。这就需要一些编译的功利了。但是我想既然有那么多闲人有空能去把Swing放到Web容器里；把Eclipse架到Swing上；这个工作肯定也不是什么难事。

好处是什么？可以让java程序对浏览器更好的进行操控。