JW Player Plugins: Dynamic Linking and Class Conflicts

The JW Player allows developers to greatly expand its functionality by loading plugins at runtime. This loading mechanism, built into the Flash platform, carries with it some complexity. Certain issues, like cross-domain security restrictions, are fairly well understood. However, some developers have run into an issue with the way Flash handles conflicts between classes that share the same name, and since this can have an impact on how plugins interact with the Player, we'll document it here.

When an ActionScript program is compiled into a SWF, any classes it references are discovered by the compiler and included in the binary. If the resulting SWF loads another SWF, it is possible that the two programs reference the same class (e. g. com.company.package.Class1), and it's possible that the two classes are either different versions of the same class, or completely different classes that happen to have the same package and class names.

When a conflict like this arises, Flash resolves the issue by discarding any classes for which it already has a copy in memory for a particular (fully qualified) class name. This has the effect of preferring the loading SWF's version of its classes, but it can also effect two SWFs that are both loaded by a parent SWF.

What this means for JW Player plugins is that if a plugin refernces a class defined in the Player (com.longtailvideo.jwplayer.utils.Strings, for example) Flash will use the version that was compiled in that player. Any changes to Strings that the plugin developer may have made, or that might have occurred in the player itself from one version to another, will be dropped.

Similarly, if two plugins use the same class definitions, the plugin that happens to complete loading first will override the conflicting classes in the second plugin.

Since these conflicts may have undesirable consequences, we recommend that plugin developers always use a unique package structure for each plugin they write, ensuring that nothing will override the needed class definitions. If the plugin need a particular class from the player (but not specified in the API), the class should be moved into the plugin's unique package structure.

Adobe has written some  additional documentation on this issue.