我们需要Java ++吗？

Question

在我看来，在某种程度上，Java就是C在一段时间之前的地方。两者都是当时相当简约的语言，具有相对干净，简单的内核。 （我指的是这里的核心语言，不是库。）两者都非常受欢迎。两者都是通用语言，包含大量遗留代码。两者都缺乏一些现代生产力功能，其他语言的程序员经常会错过这些功能。两者似乎都非常惯性，并且很难适应不断变化的世界。

在我看来，创建一个大致是Java的超集的Java ++是合理的，因为C ++是C语言。这样的语言会试图将Java从其经历的相对停滞中解脱出来，仅打破向后兼容性只有在绝对必要的情况下，才能通过一些小的方式添加许多普通旧Java缺少的现代功能，并在以后担心标准化。可能是个好主意的功能包括：

1. 头等职能，代表。
2. 闭包。
3. 静态类型推断，类似于C＃中的var或D中的auto。
4. 运营商超载。
5. 构造为与类不同的值类型，如C＃和D.
6. 属性。
7. 忽略已检查例外的选项。
8. 在文件中声明多个顶级公共类的功能。
9. 更强大的内置数组，允许附加内容。
10. 更好的仿制品/真实模板。
11. 类似于C＃4.0的动态关键字，它允许在必要时以常用的静态语言进行鸭子输入。
12. 由于Java主要是一种VM语言，可能还有一些硬核元编程功能，例如为某些事情即时生成代码。

你认为会有这种语言的需求吗？你觉得这样的事会成功吗？

编辑：我不是在谈论运行时/字节码级别的兼容性，我在讨论源级别的兼容性w / Java。此外，是的，Java 7可以添加其中一些，但似乎向Java添加功能的“官方”过程非常保守。真正的观点是将Java分支成一个分支的想法是关注创新而不是稳定性/标准化。

Answer 1

比如说，Scala或更好的Groovy自称是java的动态版本？

Answer 2

由Java粉丝为此向下投票，但作为同时编写Java和C＃的人我会说C＃与你将要获得的Java ++一样接近。

从程序到面向对象，C到C ++是一种范式转换，他们保留这个名字的唯一原因就是让C程序员认为它是同一种语言导致了一堆非常糟糕的C代码伪装成C ++

Java不断扩展，Sun正在迅速整合越来越多的功能，因此Java 7或8很可能是您的Java ++

Answer 3

我认为“我们需要Java ++吗？”的答案取决于“我们”是谁（我不确定“我们“是一个类的所有实例;-)。 The Java Posse已不止一次讨论过这个问题。

Java的大型企业用户倾向于更加保守。他们拥有大量的开发人员和大量现有代码。因此，语言或库的变化存在很高的感知成本和风险（培训，维护，现有代码的破坏等）。

另一方面，有许多小型，轻松的开发团队（开源或其他），他们随时准备在编程中锁定下一个伟大的想法。我不清楚一个答案会让每个人都满意。

我建议不断增长的基于JVM的语言生态系统可能有助于解决这种紧张局势。如果较新的语言（Scala，Fan，JRuby，JavaFxScript等）提供第二组所需的符号特征（和新颖性），同时保持与现有Java（可以更稳定的速度移动）的互操作性，也许两个组都可以有他们选择的蛋糕风味。

我对有些人似乎想要一种真实语言的程度感到有些困惑。在当天，听到每种语言（符号）都具有适用性的“甜蜜点”的想法是很常见的;有时，正确的解决方案是用适当的语言编写系统的每个部分并将它们链接在一起。

回到未来，有人吗？

Answer 4

目前在Java中有许多解决方法，这使得更难以引入更自然的方式来做这些事情。

  

  
1. 头等职能，代表。
  

大多数情况下使用反射较短。 （但不太自然）

  

0.4。结构作为与类不同的值类型，如C＃和D.

我同意这一点。

  

0.5。属性。

现在可以这样做，但需要付出一些努力。适当的内置支持会更好。

  

0.6。忽略已检查异常的选项。

你现在可以这样做，但它是一个黑客。注意：已检查的异常是编译时功能。

我非常怀疑这是一个好主意，除非人们真正理解异常。通常建议这样做的人不喜欢被迫思考错误状况，记录或处理它们。

  

0.7。能够在文件中声明多个类。

你现在可以这样做。只是不超过一个顶级公共课。

  

0.8。更强大的内置数组，允许附加内容。

参见commons ArrayUtils。具有理智toString（）的数组将启动。

  

0.9。更好的泛型/真实模板。

我同意，这取决于你的意思。我认为在改进之前，他们应该首先使用当前的工作。例如因此，可以在没有未经检查的警告的情况下编译Java API。

  

0.10。类似于C＃4.0的动态关键字，它允许在必要时以通常的静态语言进行鸭子输入。

同样，反思会这样做，但它相对丑陋。

  

0.11。由于Java主要是一种VM语言，可能还有一些硬核元编程功能，例如为某些事情即时生成代码。

与JavaCompiler（在Java 6中），脚本支持（在Java 6中），JCI或BeanShell一样。

Answer 5

问题是你如何决定“下一个语言”的内容。只是逐个添加/删除功能将导致一堆垃圾。考虑如何添加或删除这些功能（通常组合使用）会改变您按照新原则编程的方式，这样会好得多。例如，我认为有趣的是，Java闭包提议在很多方面都遭遇了必须处理静态类型而没有丰富的类型推断。有很多动态语言的例子，有很好的闭包 - 那些很好地结合在一起。而Scala和其他语言已经表明，静态类型加上丰富的类型推断也可以使闭包非常漂亮。我的观点是，使用语言X并制作语言X ++可能并不那么有趣。在X中看到问题并创建新语言Y会更有趣。

肯定没有什么能阻止你现在使用Java并将其变成你想要的任何东西（只要你不称它为Java或想要通过测试套件）。如上所述，现在已经有一组令人兴奋的高质量语言正在做这件事，并且现在正在与Java保持互操作性。我主要考虑的是Groovy，Scala，Clojure和Fan，以及较少的JVM先前语言的端口，如JRuby，Jython和Rhino，它们在实现干净的Java集成方面往往更具挑战性。

JSR 292 features中的Java 7很可能会为已经很棒的JVM基础上的语言开发提供更丰富的操场。 CLR + DLR也在推动许多有趣的界限。

越来越多，我认为未来将趋向于为工作选择合适的语言。这要么发生在具有混合传统的语言中（例如Scala是FP / OO的一个很好的例子），要么发生在促进多种语言之间清晰集成的虚拟机（JVM，CLR，BEAM，Parrot等）中。或者最有可能的是，这两者。我认为我们不会倾向于任何一种下一个大语言，它是Java（或其他任何东西）的衍生物。

Answer 6

如果你要做出重大改变，你不想重新开始吗？在Java中修复/删除有很多功能。您不能单独考虑功能 - 它们会以意想不到的方式进行交互。一个庞大而复杂的语言可能是一种糟糕的语言（参见C ++）。

Answer 7

Java++已经在这里......：D

Answer 8

这些看似相当“肤浅”的语言变化主要是出于开发人员的便利而不是从根本上<强烈>改变语言哲学。

在我看来，对语法的微小调整并不能证明批量转移到新语言，特别是如果它意味着丢弃对平台，代码库和开发人员技能组的大量投资。

如果有足够的需求，可以将次要更改添加到Java语言中（在Java 7,8,9 ...中）。然而，对于它们是否合理存在一个真正的问题，因为这样的变化会使语言变得更复杂，因此不同的开发人员开始使用不同的功能子集时，更难以学习和维护代码库。

以C ++为例：理论上它是一种令人惊叹的语言，允许您在任何可能的抽象级别进行编程，同时仍然允许优化代码中的机器代码级性能。在实践中，所有这些语言功能的复杂性意味着很少有人能够理解真正发生的事情，并且大型代码库变得几乎无法维护。

在我看来，唯一可以证明批发“Java ++”的变化是基本的范式转换，它改变了你开发软件的方式。在我看来，使Java成功的基本变化（在1995-2000中超过C ++等）是：

• 字节码在便携式，标准，跨平台运行时环境（JVM / JRE）中执行，无需重新编译
• 一个庞大而强大的标准类库（包括线程，网络，GUI等） - 即认识到平台不仅仅是语言
• 强制收集垃圾

下一阶段基本转变的例子是：

• 抛弃对象方向，转而使用functional programming
• 取消锁定以支持Software Transactional Memory，以便为大规模多核架构实现高性能，线程安全的并发性
• 在整个语言和类库中用immutable values替换可变变量（以便能够推断出并发状态）
• 将编译时宏元编程作为任何希望为语言添加新语法或创建DSL的通用解决方案

哦是的，并且有一种JVM语言可以完成所有这些 - Clojure

Answer 9

这些东西大多是绒毛。

您需要解决一些更大的问题，例如使并发代码易于设计和推理。

Answer 10

大多数功能已经存在。

该语言是：

groovy http://media.xircles.codehaus.org/_projects/groovy/_logos/medium.png

至于：

  

能够在文件中声明多个类。

从一开始就存在于java中。

Answer 11

Sun的这种努力不会简称为Java 7（或1.7或2.0）吗？其他人/小组的这种努力不会被称为Java以外的东西吗？

Answer 12

如果您将这些结构的支持添加到JVM（必要时，例如，闭包），然后在书面语言和编译器中创建必要的语法糖。当然，如果您希望保持向后兼容性，那么您需要做出设计决策，这就是为什么Java Generics不如以前那么好。你想要摆脱它以获得一个更完美的Java我认为，但是因为兼容性就在那里，所以需求很少。

7可以直接走了。我们没有在软盘上遇到FAT12文件限制。

Answer 13

Java可以而且应该得到改进，但我认为不需要一种语言来满足所有需求。这通常是一个坏主意，就像死星一样。

许多程序员只是懒惰而且不想学习新东西。他们坚持使用过去10年来一直使用的一种语言。

如果你需要速度和对硬件的更多控制，你可以使用像C这样的东西。如果你需要系统管理任务，你可能最终会得到shell脚本或脚本语言，如perl，python或ruby。如果你做了很多数学特定的东西，Matlab是个不错的选择。等等。

使用最佳工具完成任务，无论它是什么语言。一个优秀的程序员应该能够使用任何语言（至于我，我还在努力）。

Answer 14

随着java变得开源，你可以获取源代码（如果全部可用）并创建自己的java版本。如果这得到了广泛的采用，那么很好，如果没有那么它可能不是一组所需的功能。

Answer 15

我建议您查看Beyond Java。

review上有一个很好的Joel on Software。

Answer 16

我实际上真的同意你的观点，因为你遇到了可以通过你的建议缓解的Java问题。

原则上，您可以编写适用于此的javac并使用现有的Hotspot JRE。但是，如果没有Sun的帮助，你真的无法做到这一点。

问题实际上是双重的：1）Sun的方法是支持“Java平台”，并且对新标准有抵抗，甚至是超集和2）要对Java进行任何更改，你必须得到一个JSR发布 - - 这通常需要企业赞助商。公司往往有其他优先事项。

然后再次，我会敦促你推动它。毕竟，直到2007年，许多聪明人几乎从头开始重新编写Java = GNU classpath。因此，“第二类JVM语言”具有必要的才能。

Answer 17

尽管我觉得Java已经过时，但事实是，我认为我们都知道，作为一种语言，它仍然可以很好地运作。当然，我们在其他语言中找到的许多新东西都不存在，但它仍然有效！你仍然可以做任何事情，它有时需要更长的时间并且需要更多的工作。我绝对期待它被取代的那一天，但我只是认为使用Java编写的所有现有代码和应用程​​序，目前还没有办法，（几乎）没有人会转向Java ++。我认为我们正在等待真正的范式转换，比如C ++就是C.也许函数式编程可能是下一个重要的事情，Scala将成为下一个Java。

Answer 18

查看Java 7上提供的信息。我认为您会发现它计划添加每个人都要求的几个功能，最明显的是关闭。

Answer 19

C ++是面向对象的C. Java已经是面向对象的，那么我们将如何进行另一种范式转换，使其成为Java ++？

在某种程度上，我认为这是相反的方式。 Java领先于C ++。 Java具有高级库和框架，而C ++通常仍然是低级的并且与ansi C混合（因为我们可以）。

Java具有良好的单元测试可能性，并且大型社区都指向同一方向。

拥有更多“功能”并不能使语言更好。我认为可能会使情况变得更糟。

最后，将一种语言“置于”另一种语言之前是不会有帮助的。为作业选择最佳工具。我认为Java作为一种语言是非常好的。但是，C ++可以使用一些更好的库，例如Spring的端口。