I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. Out of a few p

I'm sorry but he said to "backport it to 1.6" which would mean taking code from a more advanced version and making it work on an older codebase. Out of a few possible meanings, you chose the most baroque. When writing portable code, you have a few approaches: 1) Target least-common denominator, and enable advanced features on richer targets ("Graceful Degradation"). 2) Target one platform/version maximally, and bundle your own abstraction layer for incompatible targets (Cygwin.) 3) Create your entire application in an environment created solely from a few, universally available primitives (a la Java Swing) or create your own ultra-portable runtime (java itself, Flash.) 4) Co-bundle a bunch of versions of the app for disparate platforms into one container format (Mac fat-binaries) -- this is the ugliest form of portability, almost analogous to ad-hoc polymorphism. 5) There are also self-improving systems that boot off simple stub code, and load more functionality from remote hosts, possibly compiling themselves on the new host, possibly using partial-evaluation and specialization, etc. As a programmer, your first instinct for making a piece of code portable should be along these lines. The idea of patching the world to accommodate your needs should never cross your mind. I would have loved to make this discussion about Android portability strategies. I mean, if MS-DOS 5 and 6.22 were binary compatible for device drivers, even though they used completely different device "models", then I am sure we can bump heads and exchange tricks for Android, iOS and other mobile OSes that are about to shatter like champagne glass on tarmac.