我正在考虑用 Java 编写一个开源项目,并且正在激烈争论不支持 JDK 1.4 及更早版本。该框架绝对可以使用较旧的 Java 模式和惯用语编写,但会真正受益于更成熟的 1.5+ 版本的特性,如泛型和注释。
所以我真正想知道的是,在选择框架时,对旧 JDK 的支持是否是一个主要决定因素?
可以理解,有些遗留系统被旧的 JDK 卡住了,但除了后勤问题,有没有人有令人信服的技术理由支持 1.4 JDK?
谢谢,
史蒂夫
我正在考虑用 Java 编写一个开源项目,并且正在激烈争论不支持 JDK 1.4 及更早版本。该框架绝对可以使用较旧的 Java 模式和惯用语编写,但会真正受益于更成熟的 1.5+ 版本的特性,如泛型和注释。
所以我真正想知道的是,在选择框架时,对旧 JDK 的支持是否是一个主要决定因素?
可以理解,有些遗留系统被旧的 JDK 卡住了,但除了后勤问题,有没有人有令人信服的技术理由支持 1.4 JDK?
谢谢,
史蒂夫
我想不出任何技术理由来坚持主流 Java 的 1.4 兼容性,除了特定的移动或嵌入式设备可能例外(参见 Jon 的回答的讨论)。旧版支持必须有限制,而 1.5 已经有将近 5 年的历史了。在我看来,让人们继续前进的更有说服力的理由就更好了。
更新(我睡不着觉):要考虑的一个很好的先例是Spring 3 将需要 Java 5 (pdf)。还要考虑到大公司正在使用的大量服务器正在或即将停产(WAS 5.1自 08 年 9 月起不再支持,JBoss 4.0 支持于 2009 年9 月结束)并且 Java 1.4 本身已停止自 08 年 10 月以来的支持。
有人可能想在黑莓或类似的移动设备上使用它吗?我不相信他们通常支持 1.5。
我们的客户只安装了 1.4 (AS/400),安装较新的 JVM 是一项巨大的繁重任务。所以,我是认为 Java 1.4 兼容性很重要的人之一。
注意:这很可能在编译后使用 Retrotranslator 实现。然后,您将使用带有原始 jar 的 Java 1.5 和带有翻译后的 jar 的 Java 1.4 进行所有测试。
JDK 1.4 早在 2008 年 10 月就停止了 Sun 的支持。我能想到的为什么您应该支持在不支持的 JVM 上运行您的软件的唯一原因是向后兼容性和仍然严重依赖它的客户群。
我认为这取决于您的项目是什么。我们有一个仍然使用 J2SE 1.4(JRun、WebSphere 6)的客户端。
虽然我们的客户端都没有使用 J2SE 1.3,但我们有一些核心组件,我们试图在这些组件上保持 J2SE 1.3 的兼容性(非常基本的、高度可重用的东西)。
也就是说,这可能不是问题。对于我们的客户,我们可以通过Retroweaver运行 JAR/类来使用一些 J2SE 1.5 编译的库。