<div dir="ltr">On Thu, Apr 4, 2013 at 7:08 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div>On Apr 4, 2013, at 4:54 PM, Per Bothner <<a href="mailto:per.bothner@oracle.com" target="_blank">per.bothner@oracle.com</a>> wrote:</div></div><div><blockquote type="cite">
On 04/04/2013 10:21 AM, Oliver Hunt wrote:<br><blockquote type="cite">Supporting V8 places a considerable burden on webkit, there are a number of<br>large, cumbersome and expensive abstractions required for to support multiple<br>
JS engines (see the original discussions on the topic from many years ago).<br></blockquote><br>We at Oracle are working on using WebKit with our own JavaScript engine,<br>Nashorn: <a href="http://openjdk.java.net/projects/nashorn/" target="_blank">http://openjdk.java.net/projects/nashorn/</a><br>
This is for the WebView component of JavaFX:<br><a href="http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html" target="_blank">http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html</a><br>
<br>This is still experimental, and no committed deliverable. However,<br>it is obviously preferable in the eat-your-own-dogfood way that we<br>use our own JavaScript engine, especially once that engine becomes<br>part of the Java distribution.<br>
<br>This is still in pretty rough shape, but we would find it<br>unfortunate if if becomes more difficult to build WebKit<br>with an alternative JavaScript engine. For the Nashorn "port",<br>I created a new WebCore/bindings/nashorn directory in<br>
parallel to WebCore/bindings/js and WebCore/bindings/v8.<br>We generate .java class from the .idl file. No "JavaScript<br>classes" are ever created. Instead Nashorn provides an<br>on-the-fly bridge to the Java objects.<br>
</blockquote><br></div></div><div>I think we'd be pretty reluctant to support this. Supporting multiple JS engines has been a pain, and we only agreed to it because it was a showstopper for Google, and we had the expectation that Google would be a valuable high-volume contributor. Which they were, during their time in the WebKit project. Even so, it caused significant code complexity, divergence of efforts, and friction on architectural direction, because of the differing characteristics of JSC and V8.</div>
</div></blockquote><div><br></div><div style>I'm with Maciej and others. There is a huge opportunity in front us to improve the performance of WebKit by making more aggressive architectural changes if we only had to worry about one JS engine.</div>
<div style><br></div><div style>On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code. For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future.</div>
<div style><br></div><div style>- R. Niwa</div><div style><br></div></div></div>
</div>