ActionScript 2.0 is much more object oriented and Java-like than its predecessor, which makes it easy to learn for Java programmers. Here are some key differences, which may help make the transition easier:

Static Classes

Although AS2.0 does support static classes, a crucial difference from Java is that static members cannot be accessed through instance variables. For example, if we have a Java class Foo that defines a public static field BAR, the following would output the value of BAR:

Foo myFoo = new Foo();
System.out.println("BAR is "+myFoo.BAR);

However, this will not work in AS2.0 since static members can’t be accessed through instance variables. Instead, we’d only be able to access BAR through the static reference Foo.BAR. In my opinion, this is a significant shortcoming that breaks some important design patterns that rely on static members.

No Multithreading

ActionScript is not multithreaded. This relieves us from having to worry about thread management with synchronized blocks. For example, a Singleton can be implemented without concern for multiple threads inadvertently creating more than one initial instance. However, there are still cases in which one must watch out for race conditions, since ActionScript is full of event-driven callback mechanisms in which execution order cannot be known ahead of time (loading external assets and XML data, for example). In other words, while we don’t have to worry about two methods (or statements, for that matter) executing at the same time, or two threads executing the same method at the same time, we do still need to be concerned about the order in which methods execute. As far as I can tell, methods themselves can be guaranteed to execute atomically.

No Method Overloading

In Java, it’s possible to define more than one signature for a given method, varying based on the number, type, and ordering of parameters. In AS2.0, only one signature is allowed per method (including constructors). However, this disadvantage is offset somewhat by the fact that the AS compiler does not require that all parameters be specified when invoking a method; this allows us to write a method in which optional parameters follow required ones. For example, consider the constructor for the built-in Date object:

new Date(year, month [, date [, hour [, minute [, second [, millisecond ]]]]])

The Date constructor is written to accept seven parameters, but they are optional from least to most specific (right to left); that is, one could construct a Date by specifying only year, month, and date. In that case, the constructor would only see values for the first three parameters, and the rest would be undefined.

I’ll add more items to this list as I think of them.