Explicit Casting vs. Using the "as" Keyword

There are (at least) two ways to cast an object in C# and I recently became curious about the difference. Apparently, if an explicit cast fails it will throw an InvalidCastException. Alternatively, if a cast that uses the "as" keyword fails, the target object will be given a null value.

So using the "as" keyword is perhaps slightly riskier since the program will continue on its merry way when there's a failed cast until you try to use your object and find out that it's null. However, I suspect most of the time this won't matter because the object is likely being casted for immediate use. So if for some reason you want your casts to be able to produce a null value upon failure, the "as" keyword is the way to go. Other than that, it seems like the difference will not have severe implications.

Flash Builder 4 "Java heap space" error

While attempting to compile and run a Flash Builder 4 project recently, I was receiving an error titled "Java heap space" with no additional information given. Some searching revealed that the IDE was running out of memory and a configuration file needed to be tweaked to give it more. Several forum posts suggested altering the jvm.config file in the /bin directory for the appropriate SDK such that the line:

java.args=-Xmx384m

has a higher numerical value. From what I understand, this is an argument passed in when opening the IDE that specifies an upper limit on the memory that the Java compiler is allowed to use. Unfortunately, changing this line did not fix the error. After some more searching, I found a forum post from an Adobe employee that suggested changing the eclipse.ini file in my Eclipse install directory so that the line:

-Xmx384m

has a higher value. I bumped this up to 768 and the error vanished. This is the same argument as the one in the jvm.config file but I suspect that the jvm.config argument was being ignored in favor of the eclipse.ini one. I do recall choosing to install Flash Builder 4 as a plug-in to Eclipse rather than a stand-alone application, so that may be the reason it's favoring eclipse.ini.