I mostly agree. The point is that in 1.4 you can’t use the language features introduced in Java 5 and 6. With the consumer JRE a good reason (among a lot other ones) to force this version in a game is that your can code to the latest advances given in this JRE and this doesn’t hurt the user because of the benefit of the kernel VM, deployment improvements, start-up speed, etc.
Well, theres always Retroweaver…
(Which I really must try one of these days, but I have no idea how it’ll interact with Eclipse, and I don’t like the prospect of converting all my old pre-generics code).
Wow, great! I didn’t imagine such product would exist.
I assume you mean post-generics code? If so, there are no generics at the bytecode level, so you wouldn’t even need to run retroweaver, probably only change the binary version embedded in the header somewhere.
And why would you need to make retroweaver interact with Eclipse? You just export your usual JAR, and retroweave it.
Well I’d probably end up with Eclipse compiling and running 1.6 code for general development and only apply retroweaver for final 1.4 compatible releases. Which means that Eclipse is likely to issue tons of warnings about raw/non-generic code use in all my old code. Plus theres always the danger of accidentally using classes only available in 1.6 which wouldn’t be picked up until I do a 1.4 build.
Not insurmountable problems, but they’re big enough to make me put it off until I’ve got a bit more spare time.