Project Goshawk – Apache Flex’s own compiler?

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

Update: Soon after writing this article, my investigations into JavaScript/HTML frameworks made me start to question whether Flex had a future, especially with regard to targeting JavaScript. Then my career changed and I switched (back) to C# development. As a result, it’s safe to assume that Project Goshawk is well and truly dead.

Apache Flex logoYesterday, Adobe published their long-awaited “roadmap” for Flex: Adobe’s view of Flex and its commitments to Flex in the future. Sadly for those of us involved in the Apache Flex podling, the following piece is seriously bad news:

Falcon 1.0 is the next generation compiler for ActionScript and is currently in development. Upon completion of the ActionScript portion of the compiler, Adobe will contribute Falcon 1.0 to the Apache Flex Project, which we expect will be in Q4 2012.

All of the porting to JavaScript and language enhancement work planned for Apache Flex rely on us getting our hands on the Falcon compiler in a timely fashion. “…ActionScript portion of the compiler … which we expect [to release] in Q4 2012.” therefore does not inspire confidence. Searching for a silver lining to this gloomy cloud, at least “Q4” in Adobe-speak means “September to November” as the article was referring to Adobe’s fiscal year. Whilst starting a fiscal year in December seems weird to me, apparently this is common practice for US businesses. Also when the author says “ActionScript portion of the compiler”, this doesn’t mean no MXML support, just alpha-quality MXML support (well that’s all right then <roll eyes/>.)

Even with these clarifications, it’s still very bad news for the future of Flex, especially for those of us with an interest in targeting JavaScript. Businesses want to make the decision now on whether to stick with Flex and whether it has a long-term future. “Well come back in six to eight months and we might be able to tell you whether or not we can start thinking about Flex’s future then” doesn’t sit well with me. I doubt it would impress many managers either.

To my mind, the only sensible way forward is for us to attempt to implement our own Apache Flex compiler. If done right, this should be a “win, win, win” solution for us:

  • If lots of people get involved and we get a good compiler written in a short time, we’ll be able to say “thanks, but no thanks to the Falcon compiler if/when it’s released.
  • If the project never gets finished and Falcon ships on time and is a good product, at least we would have gained some real compiler-writing experience in the meantime.
  • The fact that a bunch of Flex developers start developing an alternative to Falcon might embarrass Adobe into doing the decent thing by donating Falcon to Apache before it’s finished, allowing us to start working with it earlier.

To that end, I’ve kicked off a new Github project: Goshawk. Why not take a look and – if compilers are your thing, or you are a Flex developer who wants to learn new skills – make a fork and get experimenting…

6 thoughts on “Project Goshawk – Apache Flex’s own compiler?

  1. expected Q4 means that it is going to be a long way in the future given Adobe usual deadlines.

    With this in mind I would design the new compiler knowing that key elements are going to change, if you can define some “well defined” abstracts that represent functional areas then there is nothing to stop you making a pluggable compiler that you can make some best guess defaults for and when the real stuff is released you should be able to plug this in without having to go back to the drawing board.

    I know you’ll lose time doing it this way over coding straight from the release, but you’ll lose less time than sitting on your hands till Adobe ordain to release the code.

    If you go the pluggable route there are plenty of IoC frameworks as you well know, so why no leverage what people have solved before like Spring.

    As a side note was it intentional to your github project sound like Gawk (GNU Awk) I doubt it, but that is all I keep seeing when I look at it?!?!?

  2. Hi,

    I’ve never created a compiler, but this does sound like a interesting project. If I can help I’d like too.


  3. We don’t have to wait for Adobe to get their head out of their ass (again). There already is a third-party Flex open-source compiler. Have you checked out Clement Wong’s HFCD (HellFire Compiler Daemon)? And it’s WAY faster than Adobe’s, with multithreading & multiprocessor capabilities. Have not had the chance to use it myself, but I hear it’s pretty awesome.

  4. Standalone product or not, the HFCD is essentially the same garbage compiler Clement Wong created in the first place. A bit harsh, I know, but if you’ve spent any time with the compiler code (like I have) you’ll arrive at the same conclusion.

    As far as developing a new compiler for Flex, I think that’s honestly the best way forward, at this point. The first step for that endeavor, however should be defining an EBNF grammar for both AS3 and MXML. Once those have been defined everything else will almost certainly fall into place. The lack of formal language grammars for both AS3 and MXML has been somewhat of the ‘Achilles Heel’ for compiler development when it comes to Flex and AS3.

  5. true once you have a grammar expressed as BNF you could use any number of a million compiler compilers.

Comments are closed.