In MULE-637 I suggested we investigate JDK 1.5 as base platform for Mule 2.x, with 1.4 backward compatibility provided e.g. by Retrotranslator (http://retrotranslator.sourceforge.net/). It backports almost all new features in JDK 1.5, provides util.concurrent via the backport library that we use now and also adds any new methods. The bytecode rewriting is done either at build time (rewrite 1.5-classes via ant task into new dir) or at load time (not recommended for obvious class loader issues). Based on some experiments I did with a project using util.concurrent & JNI, all I can say is "it just works". Quick, easily extensible/fixable (drop retroextension on classpath - done!), very well maintained, friendly license. Andrew replied: "I think jumping onto a JDK 5.x wagon would simply cut off most of the enterpise users of Mule (and those, by projects nature, are expected to be the mainstream). It's simply because great number of those are still restricted to 1.3 JDK, and bringing 1.4 into the scene is a feat in itself." This argument really only holds if deployment on 1.4 is abandoned, which I did not advocate. Mule 2.x jars would simply be available in two editions, one for JDK 1.5+ and one "classic". Andrew: "Yes, I know about Retrotranslator, and have used an alternative, Retroweaver before (the latter, IMO, is a more mature product). While they both work, the answer is short - no technical advisor in XXXBank or YYYTelecom, etc. will approve such a schema." Unless you are thinking of retroweaver-ng (which is a complete rewrite and was released only a few days ago?!) I think you are confusing them? The old retroweaver did not rewrite many methods and certainly did not rewrite util.concurrent (according to the site -ng however does and I need to check it out). However, regardless which retrozapper is chosen, my point is that we can probably:

• automate building the "classic" edition as part of the dist target, including all tests
• do not ship a new release unless both the regular and the "classic" edition pass all their tests (or at least both fail exactly the same tests)

Again, I severely doubt anybody will ever know or care that the classic edition was retrozapped from a JDK 1.5 build - as long as all tests pass and no compatibility regressions can be observed, there is effectively no discernible difference between compiling for 1.4 or retrozapping. Added bonus: at least Retrotranslator's newly introduced code is sometimes more efficient than the workarounds required for JDK 1.4. Q: what happens when we do indeed find that something works on 1.5 and fails on 1.4? A: I'll think about that when we come there, OK? If organizations want or need to build mule they can always do so with 1.5 (any dev should be able to do that, even in a bank and then retrozap themselves before testing - so it really needs to be part of the build+test suite. I don't think that would overstrain anybody. There is no reason why an OSS project should by slowed down by an organization's backwardness which is often based on arbitrary policy. In the long term moving to JDK 1.5+ is unavoidable anyway so why fight?