> about, we could have the same argument about requiring 1.7 to compile but > supporting binary releases that run on 1.6; or an argument about wether we > should use a commercial tool that commiters have a license for to "build" > java code from a source grammer -- the point is that as an open source > project i think it's really important that *all* our users be allowed to
I think I got lost in this discussion somehow -- users will be able to compile from sources, just not with the 1.5 compiler... But they'd still be able to compile their source code to 1.5 binaries with an open source toolchain. Anyway, to me, the points for 1.6 are: 1) array resizing intrinsics in Arrays.* (at least theoretically, no need for double allocation during array resizing). 2) @Override on interface overriding methods. None of these are critical, but retroweaving back to 1.5 bytecode can provide you a clean way of using both and keep 1.5 users happy. Liked you mentioned -- this probably does come down to the argument of switching to 1.6 as the supported platform; then, 1.5 compatibility backport would be a nice touch for those, who still need it. Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
