In the past couple of months, I managed to fix a few issues and add some enhancements to HFCD. They are now in the latest HFCD build (2010-09-18). Let me briefly describe what they are:

Exclusion Filters

The default behavior of the HFCD plugin is to upload all of the files in a Flex project to HFCD. This obviously is not ideal because a lot of these files are unnecessary for Flex compilations. So now there is a “Exclusion Filters” preference panel under “HellFire Compiler”. You can specify files and directories that you don’t want to be transferred to HFCD there. The default value is “.svn”, which you all know, is a directory created by Subversion. You could add a few more, e.g. .settings, bin-release, etc.

Launch Server

In order to use HFCD, a developer must start HFCD from Terminal (Mac OSX) or Command Prompt (Windows) before he/she starts Flex/Flash Builder. This is one extra step that some developers would like to skip. They would like to see Flex/Flash Builder to launch HFCD automatically. Well, as you know, the HFCD installer automatically setups a launch configuration in Flex/Flash Builder:

The HFCD plugin could simply launch HFCD based on this launch configuration. So now there is a “Launch Server” preference panel under “HellFire Compiler”. You could specify the name of the launch configuration in this preference panel. The HFCD plugin will take care of starting HFCD when the workbench loads and shutting down HFCD when the workbench closes. If you don’t specify a launch configuration name in this preference panel, it’s okay… that means you prefer to launch HFCD manually.

New <property> Tags in Auto-generated build.xml

Developers can use the “Generate Apache Ant build.xml” function to generate build.xml for their workspaces. It’s great for using such build.xml in CI. The paths in build.xml come from the compiler and therefore they are all fully-qualified paths. Usually, before you can use the build.xml file in your CI environment, you need to fix the paths. But the paths are everywhere in build.xml… making it quite cumbersome to fix. Now, there are 3 new <property> tags (${fb.workspace.dir}, ${user.home} and ${flex.sdk.dir}) for three of the most common paths. Hope this consolidation helps.

Turn Off HFCD Background Build During Debugging

Some developers like to make code changes while debugging. As you know, code changes trigger HFCD background builds. If you’re debugging, the background builds might slow down debugging. Now, the HFCD plugin detects whether debugging is in progress and instructs HFCD not to run background builds after receiving code changes.

HFCD “References” View

The primary function of the Flex compiler is to generate SWF output. But there are so many things that the compiler knows about. For example, given a definition, the compiler knows about its dependencies and its references. The dependencies are not difficult for developers to figure out because one can pretty much see that in the import statement list. However, it’s quite challenging to manually and accurately locate all of the references given a definition. One could use Flash Builder’s “References –> Workspace” feature but it takes extremely long time to execute at times. Now there is a new HFCD “References” View.

You simply open a file (MXML or AS). Set the editor active and open the “References” view. The view would ask HFCD for the dependencies and references for the definitions in the active editor window.

HFCD “ABC” View

And of course the compiler knows the bytecode it generates for the classes in your projects. One way to learn ABC bytecode is to look at what the compiler generates for the code you write. Now with HFCD, if you highlight a few lines of your code in the active editor and open the HFCD “ABC” view, the HFCD plugin would ask HFCD to return the bytecode that corresponds to the code on the highlighted lines.

The screenshot below shows the bytecode for the AS code on line 1445-1451 in UIComponent.as.

The HFCD “ABC” view is work in progress (the output could be better though…).

Many of us on Twitter or following Jesse’s blog regularly should notice his dissatisfaction with Flash Builder in his most recent blog post. If you’re not aware of it, please click here.

I must say that most of us developers are objective about our views on the various Flex IDEs out there. Frankly, some of them are more religious than others. But that’s okay. Let’s just say we’re a bunch of people passionate about the technology we use everyday.

Of course you expect Adobe to respond. The Flash Builder PM chimed in. Everything he said sounded reasonable but I’m concerned about this point of view and I quote:

Firstly, and most importantly, we are making a commitment to invest in coding productivity features in every new release – we don’t believe that you should need to use an add-in to Flash Builder or an alternative tool in conjunction with Flash Builder to get a productive coding environment.

They don’t think you need to use an add-in or an alternative tool with Flash Builder for Flex development. I have to disagree with them here!

First and foremost, let’s be blunt about this – there is no Flash Builder without Eclipse! Eclipse’s highly extensible architecture allows developers around the world to add support for their popular development platforms (look at Java and C++). Adobe and Flex are direct beneficiaries of the Eclipse effort. Some people say Eclipse is crap, so Flash Builder is also crap. Well, I don’t agree and let’s just don’t go there.

However, the Flash Builder product team should realize that as a good citizen in the Eclipse development community, they should consider adding some openness to their IDE (and I already advocated that 2+ years ago in one of my posts about opening up the FB profiler). This makes common sense to me because if they can’t do certain things due to resource constraints, they should leave the door open and let 3rd-party developers do/improve that, e.g. add some extension points, make some API public, etc.

I’m fortunate that there is a stable and public API (the Flex Compiler API) that allows me to build an out-of-process Flex compiler (a.k.a. HFCD). I made sure everyone understood before I left Adobe that this compiler API must be backward compatible. So far so good, Flex/Flash Builder 2, 3 and 4 all use the same API to invoke the compiler. And very soon, FDT4 from Powerflasher will be out and their IDE will use the Flex Compiler API. That instantly makes HFCD compatible with FB3, FB4 and FDT4!

My point here is to make a direct rebuttal against the idea that Flash Builder customers should never need to use an add-in. HFCD is an add-in to Flash/Flex Builder and developers find it useful (check here)!

Hello, my name is Jeremy Petersen. I’m the Vice President of Technology at School Improvement Network, and I wanted to take a moment to write a review of my experiences with HFCD 4.

Let me start with a little background. The School Improvement Network http://www.schoolimprovement.com provides the solutions, products, and services that help teachers and educators increase student achievement. Our flag ship product is a large Adobe Flex application called PD 360. PD 360 is an on-demand professional learning system for teachers and educators, with a series of tools built around a library of video segments.

PD 360 started out as a simple on demand video player application back with Flex 2.0 in the fall of 2006. The application has followed the maturing of the Flex platform with a full Flex 3 rewrite, and is now in the process of a full Flex 4 rewrite. Along with the obvious advances and growth inherited in keeping up with latest versions of Flex/Flash Builder, the application has also grown exponentially in complexity, size, and features. In fact, our Flex 4 rewrite has a (insert expletive) 42 modules! The project has also gone from a couple of developers that tinkered on it in their spare time to team comprising of 4 full time Flex engineers, and 2 full time ColdFusion engineers.

Let me start out by saying that we love Flex 4, but after making the switch from Flex 3 and having rearchitected our application from the ground up (enter the 42 modules), we definitely noticed a HUGE hit in compile times. All of our engineers have very capable hardware (Corei7 etc). But to even change the text on a single button in the application would result in a 4-5 minute compile time. Talk about a drop in productivity.

Now, enter HFCD 4. One of our engineers read about it on a blog and decided to try it out. His results were too good to be true. After waiting a couple of weeks to make sure he did not have any issues, the rest of the team changed over on 30 day trial licenses to test things out. Remember that 4-5 minute compile time from before? With HFCD 4 , making changes to a single module, that compile time is down to 4-5 seconds! Granted changes to code that is linked in to multiple modules (say our controller etc) still take a couple of minutes to compile, but for most of the work our team is doing we are officially back in business of writing code and not reading blogs or firing up World of Warcraft in between every single run/ compile.

So it goes without saying that we love this product! But my review does not stop here. I have one other thing to comment on. The support of Clement Wong (HFCD creator). Clement went above and beyond our expectations in support and answering questions. For some reason my personal install had some issues (it ended up being Eclipse problems). Clement not only helped me via email, but even offered to do a phone call to get me up and running. In addition, he is very responsive to feature requests and suggestions.

HFCD comes with a free 30 day trial, so grab a copy and try it out. You have nothing to lose and everything to gain!

Recently I’ve received an email from a Flex developer. He told me that his development team has been using HFCD for Flex development. What impressed me was his team hardware setup. Basically, his team of developers connect Flex Builder running on their laptops to multiple instances of HFCD running on a powerful LAN server. He is quite happy about the improved development experience.

The server we’re sharing for compilation is a Dell box with basic hardware config:

There is a new compiler argument in Flex 4.x. It’s –tools-locale. For example, specifying –tools-locale=en would instruct the compiler to output errors/warnings in English. The following is the output of “mxmlc -help tools-locale”:

-tools-locale <string>
specifies the locale used by the compiler when reporting errors and warnings.

Of course, the compiler, by default, uses Locale.getDefault() (i.e. most of the time, JVM -Duser.language). Having this compiler argument is useful for tool integration because a tool could use the OS default language but the compiler could output English errors/warnings.

But why wouldn’t developers choose to read compiler errors/warnings in their native languages and would like to have a way to configure the compiler to output in e.g. English? Is it because the translations are not good? Can someone please comment on the qualities of the non-English compiler error/warning messages?

HFCD for Flex 4.1 is now available. Sorry for the delay. I thought it would take me a week or two to release it. But I wasted a little bit of time working on the wrong Flex SDK revision! Boo…

The good news is that there is no Flex Compiler API changes in Flex 4.1. However, there will be some new methods added to the API in the upcoming Flex 4.5.

I think the most notable fix in the compiler in 4.1 is SDK-25206. If you occasionally switch between airglobal.swc and playerglobal.swc in your Flex Builder workspace, you may run into this issue. But this is a good fix and helps build performance too.