7
  • 原语值得保留吗？
  • 是否应该删除所有已弃用的内容？
  • 我们需要 2 个 GUI 框架吗？
  • ...
4

15 回答 15

11

正如我已经提到的，即使在其How and When To Deprecate APIs中，也没有提及有关实际删除已弃用 API 的政策......

基于旧 JVM（例如 1.4）的应用程序数量仍然很重要，部分原因是应用程序服务器需要很长时间才能使用新版本的 JVM 验证自己......

实际在生产中运行的应用程序数量之多意味着这种“向后兼容”策略可能不会很快被打破。

于 2009-01-14T09:01:56.340 回答
7

向后兼容有几种类型：

  1. 旧的源代码可以用新的编译器编译吗？

    这可以使用将旧结构转换为新结构的工具或类似“source 1.6”的工具来处理；文件顶部的指令。

  2. 旧的类文件可以在新的 JVM 中运行吗？

    在我的世界里，这是一个完整的表演终结者。我们使用了如此多的第三方库，因此强制同时升级所有这些库的成本太高。

    这也是不删除已弃用的类和方法的驱动程序，但程度较轻。

  3. 旧的类文件可以调用用新编译器编译的代码吗？

    由于回调，这是#2 的重要部分。

  4. 新编译的代码可以从旧的类文件中调用代码吗？

    #2 的另一个重要部分。

  5. 代码看起来与开发人员大体相似吗？

    这对于训练和处理尚未完全转换的大型代码库很重要。一个更微妙的方面是在混合代码库中可以使用多少新功能。如果你打破了这一点，你就会得到类似 Scala 而不是 Java++ 的东西。

以这样的方式添加了泛型以保留所有这些类型的兼容性。我认为对 Java 的任何不兼容更改都必须至少保留 2、3 和 4 才能有机会被接受为Java。处理 #1 的工具也是最低要求。

于 2009-01-14T11:18:40.027 回答
4

您可以使用业余爱好 (Ruby)、低实现 (Python) 语言来做到这一点，但您无法想象全世界有多少应用程序是用 Java 编写的。只需检查freshmeat 或sourceforge。而这只是一部分。所以不，这不是一个好主意。实际上，这将是一个非常愚蠢的想法。

没有两个 GUI 框架。Swing 依赖并使用 AWT 作为它的基础。

于 2009-01-14T09:15:05.660 回答
3

如果某些已弃用的功能被删除，我会非常高兴——例如，如果Date对象真的是不可变的，我会非常高兴。事实上，如果你正在编写一个不可变的类，你不能假设 Dates 是不可变的，并且必须防御性地复制它们，例如，你不能可靠地将它们用作 Hashmaps 中的键（因为在这两种情况下，其他代码无论方法是否被注释为已弃用，都可以改变日期）。

当谈到添加新的语言特性时，我并不完全理解向后兼容的口头禅。在我看来，如果为以前的版本编写的代码需要一些调整才能在以后的版本中运行，这没什么大不了的。事实上，无论如何，这都是有先例的。在 1.5 和 1.6 之间，向 ResultSet 接口添加了额外的方法，因此可以在 Java 1.5 下编译和运行的代码甚至无法在 1.6 下编译。

考虑到遗留应用程序，有人期望 5 年内未更新的应用程序在最新版本的 JVM 上完美运行是否合理？如果组织仍在使用 Java 1.4 和为其编写的应用程序，他们真的关心 Java 7 中的内容吗？破坏向后兼容性并不意味着所有先前版本的 JVM 也会被破坏。如果应用程序针对的是早期版本，则可以在该版本的 JVM 上运行它而无需担心。

最重要的是，随着时间的推移和人们使用 Java，错误和功能差距变得明显，纠正/实施这些将是一个重大的福音。在尝试改进语言时被束手无策，因为不幸的是之前发生的事情，在我看来这不是基本要求。

当然，需要对升级路径进行一些思考。例如，突然将 int 更改为 Integers 将需要为每个人进行大量繁琐的代码更改（以及必须添加额外的 null 检查等）。然而，添加一个碰巧破坏向后兼容性的新特性（例如闭包），或删除已被弃用多年的方法，对现有代码几乎没有影响。（如果您一直在使用不推荐使用的方法，那么您之前应该删除它们，但现在您被迫这样做！）

于 2009-01-14T10:35:27.633 回答
3

出于兼容性原因，他们不能使用标准 Java 版本来做到这一点。现在有太多的 Java 软件在生产中，你根本无法用一个新的版本来打破它，消除所有的垃圾。

但是，我确实认为 Sun 可以发布一个“Java X”版本，删除所有笨拙的东西，并添加所有现有但当前未包含的良好和有用的 API（包括替换具有更好替代方案的 Java API，例如， log4j，让我们不要从日期和日历开始）。此版本不会被设计为取代 Java，但可以作为新软件项目的目标存在。我想他们还可以修复语言以包含与最新版本的 C# 等相比使 Java 看起来有点笨拙的缺失功能。如果他们也制作了可以修复或至少添加的代码移植工具“FIXME”到代码库中的所有问题区域......

必须承认，当 .NET 推出时，微软在将人们转移到更新版本的 .NET 方面做得很好。Sun 在这方面完全失败了，考虑到仍然在 1.4 上运行的应用程序的数量，以及许多公司昏昏欲睡的 Java 版本政策（他们似乎很乐意让他们的 .NET 人员以某种方式使用最新最好的版本）。鉴于在一台机器上安装多个 Java 很简单，我认为应该做更多的工作来鼓励公司和软件公司尽快升级。

于 2009-01-14T10:48:05.627 回答
2

我会说打破向后兼容性对于java来说是一件愚蠢的事情。如果是这样，您可以称它为 Java++，它不再是 Java。另一方面，对于 java 的未来版本，它应该向动态语言学习语法简单等特性。由于硬件功能的增长速度如此之快，因此编译语言的抽象级别应该更高。将当前 java 版本的一些特性与动态语言进行比较，过于笨拙和冗长，从而降低了开发效率。似乎 C# 正在成为一种动态语言？

于 2009-01-14T10:37:54.463 回答
2

在 JVM 上有许多很棒的替代语言，我真的不明白为什么。我宁愿拥有一个稳定的 Java，然后继续使用很酷的新东西（并且仍然与 Java 兼容）。

于 2009-01-14T14:34:54.890 回答
1

因为，大部分市场份额仍然使用较旧的 jdk/jre，我认为打破向后兼容性并不实用。

于 2009-01-14T08:58:18.063 回答
0

正如 Pat 所说，采用最新 JDK 版本的速度相当缓慢，而且目前许多应用程序都在使用 Java 的旧（有时真的很旧）版本运行。

因此，我认为不保证向后兼容性并没有真正的好处。

对于您的建议，我并没有真正看到删除原语的兴趣。当然，从 Java 5 开始就有自动装箱。但是原语仍然有他们的兴趣......

于 2009-01-14T09:04:57.193 回答
0

如果 JVM 保持不变，那么破坏兼容性将是有意义的。在这种情况下，“新”Java 将成为在 JVM 上运行的一种新的、不同的语言，例如此处列出的那些。幸运的是，JVM 的设计方式保证了语言和版本之间的互操作性，所以我认为影响是有限的。

于 2009-01-14T09:06:23.507 回答
0

我认为 fork 更适合对语言进行适当的检修。坦率地说，Java 泛型的工作方式开始让我很生气。

于 2009-01-14T09:21:30.793 回答
0

我离开 PHP 的原因是它们在主要版本升级之间改变了 API/可用函数。真正的问题是对于旧脚本，PHP 不能在兼容模式下运行。我不想被迫升级我的代码。

Java 在同一个地方。只要确保你可以在新版本上使用旧的 1.4 的东西。要求新程序使用新的 xyntax 是可以的，但让旧的东西运行！

于 2009-01-14T09:30:24.317 回答
0

关于原语，无论喜欢与否，它们都会一直存在，因为它们是对象的基本构建块。当然，您可以改用包装类，但这只会使编译器过度工作，在大多数情况下最终会转换回原语。

向后兼容性非常重要，正如这里已经提到的，还有很多用户仍在运行 1.3 和 1.4 代码。话虽如此，我认为如果有人仍在某些遗留系统中运行 java 1.0 或 1.1 代码，他们不太可能很快迁移到 Java 7，即使他们这样做了，他们也很可能需要重写他们的反正代码。我认为可以安全地删除 >1.2 版本的已弃用 API。

向后兼容的另一个方面是添加关键字，这总是不鼓励的。在 Java 5 中，主要的语言更改是通过添加一个新关键字“enum”来管理的，甚至这也引起了愤怒，因为现在每段带有名为“enum”的变量的代码都是不兼容的。据我所知，Java 7 中的更改是在没有新关键字的情况下计划的（呸！）。

尤瓦尔=8-)

于 2009-01-14T10:06:44.540 回答
0

这会很好，这取决于 Sun 不会向所有客户端推送新的 JDK 升级。使用旧 API 的人不会升级，会使用旧版本的 JDK 一段时间。

或者，也许，通过实现向后兼容模式。

于 2009-01-14T10:07:01.263 回答
0

我认为应该重写一些 API，例如日期时间。如果当前版本收到 EOL，则应删除旧 API。我们的统计数据显示，我们 99.3% 的客户使用 Java 6 或更新版本。不需要兼容性非常旧的 API。但是，如果要删除 API，则必须有明确的时间范围。

于 2010-07-25T16:13:52.073 回答