为什么有些框架拒绝放弃对旧 Java 版本的支持？
当我坐在这里修改 PircBot 时，我刚刚注意到整个后端都已编写支持 Java 1.1。它有一个自定义队列实现，使用哈希表，基于 wait() 和 notification() 信号的自定义生产者/消费者实现等。甚至 Commons-lang 也缺乏对 Java 5 带来的泛型等内容的任何支持。您可以举出许多非常流行的框架的其他示例，这些框架尽最大努力支持 1.1。
我的问题是为什么？为什么 Java 社区的某些部分拒绝支持新版本？我遵循这个理论：旧版本使用旧版本的框架和旧的 JVM，新版本使用升级的框架和 JVM。您可以使用软件升级一切。
现在我可以部分理解人们仍在运行 Java 1.5，但是 1.1 呢？如果您在此之前运行过任何内容，那么您显然不会升级 JVM，因为愚蠢的策略/害怕未知的情况，因此不会升级到较新版本的软件。那么为什么我们仍然支持他们呢？
与此相关的是，如果您正在编写一个新框架，您是否应该支持 <1.5 的任何内容？您是否应该尝试分叉现有框架，将其升级到 1.5，然后与维护人员讨论如何使用它？
更具体的讨论（这是关于一般支持的）： 还有充分的理由支持 JDK 1.4 ?
As I'm sitting here modifying PircBot, I've just noticed that the entire backend was written to support Java 1.1. It has a custom queue implementation, uses hash tables, custom producer/consumer implementations based on wait() and notify() signaling, etc. Even Commons-lang lacks any support for things that Java 5 brings to the table like generics. You can pull a bunch of other examples of very popular frameworks that try as hard as they can to support 1.1.
My question is why? Why are certain parts of the Java community refusing to support new versions? I go by this theory: Old versions use older versions of frameworks and older JVMs, newer versions use upgraded frameworks and JVMs. You upgrade everything with the software.
Now I can partially understand people still running Java 1.5, but 1.1? If your running anything before that then your obviously not upgrading the JVM because of stupid policies/scared of the unkown, and therefor aren't going to upgrade to newer versions of software. So why are we still supporting them?
On a related note, if you are writing a new framework should you support anything <1.5? Should you try forking existing frameworks, upgrading it to 1.5, then talk to the maintainers about using it?
Much more specific discussions (this is about support in general):
Is there still a good reason to support JDK 1.4?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
因为它很容易！从 Java 1.1 到 Java 1.4，只引入了一些微小的语言特性（例如
strictfp）。那么，如果不需要的话，为什么要限制自己呢？因此，假设您编写了一个 StringUtil 类或解析了 Word 文件，那么这根本不重要。从 Java 5 开始，语言就得到了改进，当然还有从 Java 1.0 到 Java 1.1 的内部类。这仅适用于语言，而不适用于库。当然还有一些有趣的补充。
Because its easy! From Java 1.1 to Java 1.4 just tiny language features were introduced (
strictfpfor example). So why restrict yourself if you don't need to. So lets say you write aStringUtilclass or you parse Word files then is simply does't matter. Just starting with Java 5 you have language improvement and from Java 1.0 to Java 1.1 of course inner classes.This is just for the language and not so much for the libraries. There are interesting additions of course.
我认为最常见的原因是，后来版本中引入的新功能无论如何都没有被使用。我的意思是，如果一个库不使用泛型或高级并发功能等新功能，则根本不存在兼容性开销。
I think the most common reason is, that new features introduced in later versions are not used anyway. I mean, if a library does not use new features like generics or advanced concurrency features, there is no compatibility overhead at all.
向后兼容？
更改 JVM 支持级别应该需要发布一个主要版本。即版本 1.x 到 2.x 表明了这一点。
另外，我相信您已经读过，要获得手机的最大覆盖范围，您需要以 1.1 为目标。但这可能已经很旧了。
Backward compatability?
Changing the level of JVM support, should warrant a major release. I.e. version 1.x goes to 2.x to indicate this.
Also I believe to have read that to get most coverage in mobile phones, you need to target 1.1. That may be old though.
我知道至少有一家商业企业决定永远不会超越 1.1，以便可以使用相同的源代码在 java JVMS 和 .NET 上永远运行。
I know of at least one commercial enterprise that decided they would never move beyond 1.1 so that they could run forever on both java JVMS and .NET with the same source code.