Adobe Open Sources Flash ActionScript VM

Adobe today announced that we have contributed the source code to the ActionScript Virtual Machine, a key component of Flash Player, to a new project Tamarin hosted by the Mozilla Foundation, that will make both future browser JavaScript and Flash ActionScript compatible with the forthcoming 4th generation of the ECMAScript standard. This is a fantastic move for Adobe and the developer community, as well as a positive development for Publishing 2.0.
For publishers, the standardization of a capable scripting language and associated open-source runtime should provide increased confidence in embedding interactivity into next-generation content experiences. There are still issues to be dealt with, including API standardization for archivable interactivity: Flash and the browser still utilize separate DOM interfaces and have other API and capability differences. But there’s no doubt that this is a major advance. It also marks a major step forwards in Adobe’s engagement with the open source and open standards communities. This is not the first and certainly not the last open source contribution by Adobe, but it is definitely the most fundamental so far, and opens the door to other win-win engagements in the future.
The bigger picture is that Tamarin will deliver significantly improved performance and capabilities for JavaScript (aka ECMAScript) support within Firefox, as well as enhanced standards-compliance for the ecosystem of Flash developers. Adobe has been breaking ground with ActionScript 3, which supports key features planned for the forthcoming 4th edition of ECMAScript standard, including name spaces, classes, and strong types, as well as a high-performance JIT (Just-In-Time) compiler that delivers performance many times faster than traditional JavaScript interpreters.
“Least common denominator” browser-based JavaScript is very limited in capabilities and performance. The Tamarin activity should raise this bar considerably. Microsoft’s JavaScript interpreter in Internet Explorer already has been beefed up in various proprietary ways, and hopefully Tamarin and associated standardization within ECMA will push them towards standards compliance. Flash developers who’ve begun using ActionScript 3 and Flex 2 have already realized that the new ECMAScript-4 language is far more suitable for complex component development, supporting strong architectural design patterns and team development, while still being far more approachable than Java or C++.
In many respects, the future JavaScript standard embodied in ActionScript 3 could be viewed as a “Java Lite” – the inheritance model and core syntax is now quite similar, but ActionScript/JavaScript loses threads and other complexity-inducing language features, and the large-scale class library that greatly steepens the Java learning curve. And, of course, Java suffers from the JVM client bloat and adoption issues – whereas Flash Player 9 packages both ActionScript 3 and strong multimedia capabilities into a svelte 1.3 MB download that’s being rapidly.proliferated across the world. Adopters of Flex 2 today can be confident that their new skills will be in demand down the road: for Flash development, future AJAX development ,and no doubt additional server and client systems.
More on the announcement here from Emmy Huang, Flash Player product manager.
On an unofficial and strictly personal note, I really wish we could unify the confusing names “ActionScript”, “ECMAScript”, and “JavaScript”. As I understand it, this all stemmed from James Gosling’s about-face and subsequent stubborn resistance to the name “JavaScript”, which Sun originally OKed Netscape using. Much as I admire James and appreciate Java, it’s just too confusing. Especially so now that we layer in numeric confusion – “ActionScript 3” = “ECMAScript 4”, and is in some ways more closely akin to “J2ME minus” than browser JavaScript of yore. I’m not sure if there’s a good answer – or even what Adobe’s public position is on this issue – I just think it’s a mess. Can’t we just pick one name and move on? “JavaScript 4” gets my vote but really I’d settle for anything (even, holding my nose, ECMAScript). Let’s call it JavaLite if it makes Sun happy, heck let’s just call it something, rather than having three different names like a character in a Tolstoy novel.

3 Responses to Adobe Open Sources Flash ActionScript VM

  1. Jim Ray says:

    I’m curious about the addition of a JIT compiler and what advantages that has for Javascript and web developers. It’s my understanding that JIT works best for applications that are compiled to bytecode, which are then translated to machine code at runtime, like Java and SWF files.
    However, since Javascript is never compiled, what’s the advantage here? I admit, my knowledege of what happens at the browser level is pretty scarce, so I’m honestly just looking to know more about this. Is JS compiled by the browser at some step? Will the next version of JS be compilable?

  2. Bill McCoy says:

    Jim, there’s two separate issues: where the compilation of text into bytecodes takes place and how instructions are interpreted.
    Browser JavaScript is transported as source text and typically compiled into bytecodes on the fly. The source form makes it convenient for dynamically-generated content and facilitates “monkey-see monkey-do” code reuse.
    Flash VM, like Java VM, does contain the compiler to turn source-form text into bytecodes, but instead relies on a pre-compilation process. This makes it easier to do static error checking to minimize the need for runtime debugging, and makes it easier to protect code from unwanted borrowing.
    The existing JavaScript engine in Firefox (Spidermonkey)in effect sits in a loop interpreting the bytecodes it has created from source JavaScript, which limits performance. The original JVM has a similar interpreter loop model, as did the Flash VM until FlashPlayer9’s ActionScript3, aka JavaScript4, engine (confusingly called AVM2).
    JIT compilation enables translating certain sequences into native CPU instructions. This would not be so valuable with today’s browser JavaScript or ActionScript2, since there is no strong typing everything has to be checked dynamically anyway, but with JavaScript-4 (aka ActionScript-3) strong types, a JIT compiler can generate very efficient primitive instructions. As modern Java VMs show, JIT compilation can achieve near-native performance, in some cases even exceeding compiled C++.

  3. Baczek says:

    Dynamic typing doesn’t necessarily make JIT compiling useless, the compiler can infer that some variables in a given program don’t change type and compile them efficiently.