Adobe today announced that it has contributed the Flash VM source code to the Mozilla Foundation. To host Adobe's contributed code, the Mozilla Foundation set up a new open-source project, Tamarin. Source code for the Flash VM was made available via the Tamarin source code repository Monday night.

Adobe's Flash VM is among the most widely used pieces of Internet client technology, with about 98% of Web browsers having a recent Flash plug-in, according to the company.

While Flash is Adobe's proprietary client technology, the Flash VM is an execution environment for Adobe's branded version of the EcmaScript standard, ActionScript. Other versions of EcmaScript are known as JavaScript and JScript. The Tamarin project's aim is to define a common JavaScript and Flash runtime, shared by future generations of Mozilla and Adobe products.

Artima spoke with Dan Smith, Adobe's Director of Engineering, who also serves as Tamarin project lead:

The Flash engine, which is what we contributed to Mozilla, is the language runtime for executing ActionScript 3. We are not open-sourcing the Flash player, just very specific pieces of functionality: the virtual machine, the bytecode verifier, the garbage collector, and a partial implementation of an EcmaScript 4 compiler, written in EcmaScript 4. Mozilla will take those pieces, and inject the source for Tamarin into SpiderMonkey. [Editor's note: SpiderMonkey is Mozilla's JavaScript engine.]

Smith explained that ActionScript and JavaScript are closely related:

Some people think that Flash has its own little scripting language that we wrote in-house and created on our own. That's not the case... Both ActionScript and JavaScript are based on EcmaScript, Edition 3, and they are essentially the same language in terms of language features and syntax.

ActionScript 3 is a superset of the EcmaScript 3 specifications. We've taken some features we knew would be coming in EcmaScript 4, and put them into ActionScript 3, like classes and name spaces, optional type settings and variables. But it's our own branding of the language.

It's the environment and the libraries that differentiate how people view these languages. JavaScript is generally deployed within a browser. Within a browser environment, the document object model [offers] things that [make sense] within a browser—windows, and text, and those kinds of things. In Flash, we care about things like animations, movies, and sounds, and our DOM reflects those. We're using the same language, but on top of that, we have different supporting libraries, and a different DOM.

Adobe for several years has been using ActionScript in the Flash player. So we have a common runtime that will be shared between the Flash Player and SpiderMonkey, Firefox, and other products that want to use that. Through SpiderMonkey, that work will probably come back to Adobe in the future, into Acrobat Reader and other products.

Smith noted that the goal of the Tamarin project is to create the best possible execution environment for EcmaScript 4 and, by extension, for JavaScript:

It's about coming up with the absolute best implementation we can have. We expect other people to contribute to the [source code] base, and grow it to make it into the best engine... We've been working with Mozilla, along with Yahoo, Microsoft, and others, on the EcmaScript working group on the standard. It's a good idea for us now to work together with Mozilla on the implementation.

You will be able to run Ajax on top of this, and there will be a new language on top of it also that we refer to as JavaScript 2, which will be the EcmaScript 4-version of the [JavaScript] language. While we have different names for things—ActionScript is just a re-branding, just as Microsoft uses the name JScript—these are all based on the same common standard.

Smith also highlighted key benefits of a top-notch VM shared between Adobe's Flash product-line and Mozilla's browsers:

We now have an implementation of ActionScript 3, and we saw about a ten-times increase in performance [from ActionScript 2]. That made a tremendous difference for us. You get a much faster execution time. You will also have a very secure system. We have bytecode verifiers in place within the code...

We also hope to be able to shrink the size of SpiderMonkey and Firefox as well. One of the things we pride ourselves in ... is the ability to squeeze a lot of functionality into a small space. We are obsessed with download size. We also are able to share those with the SpiderMonkey folks. And we also expect that the memory consumption will drop for SpiderMonkey.

To what extent do you think a fast, secure, and highly reliable, JavaScript implementation will impact rich-client application development? What are the most important JavaScript implementation problems you'd like the Tamarin project to solve?