Dangers of setTimeout in Flex

So, after fighting a memory leak in Flex for the last week, I have learned a valuable lesson that hopefully will help. The setTimeout method in Flex is dangerous. It turns out that it is not automatically garbage collected when your Flex app is in operation (indeed, I don't even know of a manual way to force it to be garbage collected). Here was my situation:

I needed a clock that would increment itself every second. To do this, I created a little method called runClock that simply updated the time on the clock face and then had a setTimeout(1000, runClock). Without realizing what I had done, I was now creating a new Object every second that was never reclaimed by the Flex garbage collection process.

What I should have done (and what I now have) is a Timer. I have simply set my Timer to fire every 1000 ms, to call runClock and to run indefinitely. Problem solved and memory leak patched!

A Pragmatic look at the Groovy-ness of Groovy

So, now that I've been familiar with Groovy for a while, I figured that I would post a blog about my opinions of it from a pragmatic perspective.

First off, I think that Groovy is an awesome language, and development in it allows code to be much more streamlined, and it is wonderful to finally be able to give up on some of the nuisances of Java. My favorite part is the ?, but I also enjoy only writing try-catches when I actually intend to catch an Exception, not writing getters and setters, and the metaClass ability is like finding a superpower. However, life is not all good in Groovy-land.

There is another tool in my development arsenal that is at least as powerful as Groovy, and which also enhances my development speed. This tool is code complete. Unfortunately, these two tools are currently mutually exclusive. I know that Groovy is dynamic, but when I specifically set a variable type declaration, you would think that my IDE should at least be able to kick into Java mode and tell me what the methods of String are without me having to type them manually or look up the oft-forgotten ones in the JDK. But lo and behold, it appears that none of the IDEs have found a way around this hicup yet.

The grand conclusion! Again - I like Groovy. But in a real world environment, before I develop a new class, I have to look at which tool will help me develop my code faster and maintain it more easily in the long run. So far, it appears that the main purpose of Groovy in my life will be to writing very brief classes, writing unit tests, and working with XML. Hopefully my IDEs will develop, and I'll be able to use both of these tools at the same time sometime in the near future.