I like to think of it as the "StringBuffer" problem. With Java 1.4, the String class gained "append(StringBuffer buf)". Old code that appended a StringBuffer to a String now had a more efficient implementation just by recompiling! However, it also meant that even if a JAR could build against both Java 1.4 and Java 1.3, if you built against the later Java, it might not run on the earlier one, because it wouldn't have the new optimized function. In a componentized world, we potentially have this problem in spades, and not just with a single platform, but every feature we ship.
With Eclipse, fortunately, we have a very rich infrastructure for specifying metadata on individual JAR files, and on features. This metadata holds out the promise of huge advantages. We might, for example be able to determine whether or not we can deploy a feature - if we just get our metadata right.
Yet, if we don't use that same metadata in the build process, there's a small chance that the metadata itself will be a lie, all because of the StringBuffer problem. We could, perhaps, sidestep the problem by always building against a fixed platform. To maintain our development agility, though, we want our build environment to be much more dynamic. This talk discusses the steps that we have taken to dynamically provision a target environment for use in building our software.
This session is part of the curated collection of short talks titled
"You and Your Tools"