我正在考虑用Java编写一个开源项目，并且正在大力辩论不支持JDK 1.4及更早版本。该框架绝对可以使用较旧的Java模式和习惯用法编写，但真正受益于更成熟的1.5+版本的功能，如泛型和注释。
我真正想知道的是，在选择框架时，是否支持较旧的JDK是一个主要决定因素？
可以理解的是，遗留系统仍然存在旧版本的JDK，但除了物流之外，有没有人有一个令人信服的技术理由来支持1.4 JDK？
感谢，
史蒂夫
答案 0 :(得分：12)
我无法想到任何技术理由坚持主流Java的1.4兼容性，可能除了特定的移动或嵌入式设备（参见关于Jon的回答的讨论）。遗产支持必须有限制，1.5已接近5年。在我看来，让人们继续前进的更有说服力的理由。
更新（我无法入睡）：一个值得考虑的好先例是Spring 3 will require Java 5 (pdf)。还要考虑大公司正在使用的服务器很多或者很快将会是EOL（WAS 5.1不支持since Sep '08，JBoss 4.0支持ends Sep '09）并且Java 1.4本身是out of support since Oct '08
答案 1 :(得分：4)
是否有人可能想在Blackberry或类似的移动设备上使用它？我不相信他们一般支持1.5。
答案 2 :(得分：1)
我们的客户只安装了1.4（AS / 400），安装更新的JVM是一项非常繁重的任务。所以，我是那些认为Java 1.4兼容性很重要的人之一。
注意：编译后最有可能通过Retrotranslator实现。然后，您将使用带有原始jar的Java 1.5和带有已转换jar的Java 1.4进行所有测试。
答案 3 :(得分：1)
JDK 1.4在2008年10月失去了Sun的支持。我能想到为什么你应该支持在不支持的JVM上运行的软件的唯一原因是向后兼容性和仍然依赖的客户群在它上面。
答案 4 :(得分：0)
我认为这取决于你的项目是什么。我们有一个仍然使用J2SE 1.4（JRun，WebSphere 6）的客户端。
虽然我们的客户都没有使用J2SE 1.3，但我们有一些核心组件可以保持J2SE 1.3的兼容性（真正基本的，高度可重用的东西）。
那就是说，这可能不是问题。对于我们的客户端，我们可以通过Retroweaver运行JAR /类来使用一些J2SE 1.5编译库。