Java（特别是该语言）发生了什么？
早在 2000 年（当 .NET 向我们 IIRC 释放时），它是一种创新的前沿语言（我上次使用它是 2003 年）。
但据我了解，Sun 对该语言的发展速度极其缓慢。 我什至读到，在语言发展的地方，例如添加泛型，开发人员抱怨实施不佳。
这些看法是否准确？如果是，有什么想法说明其原因吗？特别是在来自 C# 的看似明显的竞争的情况下？
Back in 2000 (when .NET was unleashed upon us IIRC) it was an innovative cutting edge language (last time I used it was 2003).
From what I read though, Sun has only evolved the language exceedingly slowly. I've even read that where the language has evolved, such as the addition of Generics, developers have complained about poor implementation.
Are these accurate perceptions, and if so, any thoughts on why, particularly with the seemingly obvious competition from C#?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
从企业的角度来看，发展一种语言并不是一件好事，实际上是相当糟糕的。
这就是为什么你会听到像 cobol、fortran 甚至 C 这样的老语言在它们后面写上年份数字——许多企业都坚持使用这一年份。
最重要的是，更大的团队意味着团队中的某人更有可能做其他人不理解的事情，因此保持语言简单和干净有一个重要但被低估的价值。 这意味着不要添加太多替代的做事方式。
我与 Ruby 一起工作，并且对这种语言很感兴趣，但从企业的角度来看，它绝对是一种可怕的语言。 我无法计算一个糟糕的程序员可能会用多少种方式搞乱一个大团队，迫使他们花几天时间来解决几分钟内造成的混乱。
有些公司因为泛型的复杂性而拒绝使用java 5.0。 （我们仍在开发 1.3x，但这是出于另一个原因）。
老实说，大多数“改进”给你带来的好处很少。 一些语法更改，能够删除几级大括号。
我想不出 Java 强迫我重复业务逻辑的情况（这就是当我试图使我的代码“DRY”时我担心的）——它是一种足够干净的语言，可以完全 DRY，如果你是一个很好的程序员。
例如，您可以使用闭包执行的任何操作都可以使用子类执行，而无需重复业务逻辑 - 由于大括号/额外的类定义层，您最终得到的结果看起来更糟，但通常更可重用（您可以扩展该类）你用来实现你的回调，但你不能扩展一个闭包方法，你必须重写它。）
在我职业生涯的前几十年里，我对代码没有这种感觉（我喜欢语言技巧，越时髦更好），但现在我已经这样做了很长时间 - 这可能是我的年老潜入，或者它可能是经验，但现在我看到简单，明确，稳定的代码的巨大好处（由一种语言提供）不会让你玩花样）并且无法真正找到许多替代方法的单一优势，即使它们节省了一两行打字。
但是，如果您正在寻找 Java 升级，请查看 Scala。 它非常神奇，仍然在 JVM 上运行，与 Java 交互等等。
From an enterprise point of view, evolving a language is not a good thing, it's actually pretty bad.
That's why you hear older languages like cobol, fortran and even C written with year numbers after them--many enterprises stick with that year.
On top of that, larger teams means more of a chance that someone in your team will do stuff others don't understand, so there is an important but under-rated value in keeping a language simple and clean. This means not adding too many alternative ways to do things.
I worked with Ruby and had a ball with the language, but looking at it from an enterprise point of view, it was an absolutely terrifying language. I couldn't count the ways a bad programmer could mess up a large team, forcing them to spend days untangling a mess created in minutes.
There are companies who refuse to go to java 5.0 because of the complexity of generics. (We're still working on 1.3x but that's for another reason).
And honestly, most "Improvements" buy you very little. Some syntax change, the ability to remove a few levels of braces.
I can't think of a single case where Java has forced me to repeat business logic (Which is what I worry about when I'm trying to make my code "DRY")--it's a clean enough language to be completely DRY if you're a good programmer.
For instance, anything you can do with a closure you can do with a subclass without repeating business logic--what you end up with looks worse because of layers of braces/extra class definitions, but is often more reusable (You can extend the class you use to implement your callback, but you can't extend a closure method, you have to rewrite it.)
I didn't feel this way about code for the first few decades of my career (I LOVE language tricks, the funkier the better), but now I've been at this a long time--It could be my old age sneaking in, or it could be experience, but now I see huge benefits to simple, explicit, stable code (offered by a language that won't let you play tricks) and can't really find a single advantage to many alternative methods, even if they save a line or two of typing.
If you are looking for a java upgrade, however, look at Scala. It's pretty freaking amazing, still runs on the JVM, interacts with Java, etc.
大多数语言的起源和演变都有一只强大的力量参与。 想想：Larry Wall/Perl、Guido/Python、Matz/Ruby、Odersky/Scala、Hickey/Clojure 等。这些人都是出色的语言专家。 我愿意献出我的左臂，让其聪明程度只有他们中的一半。
事实上，Java 的独特之处在于，它不仅有一个人，而且有一系列令人惊叹的语言专家在掌舵——从 Gosling 开始，但我也想到了 Guy Steele、Bill Joy、Gilad Bracha、Neal Gafter 等——所有这些人都是了不起的人。 这实际上是一件好事（我认为）。 它使语言变得更好，但避免了停滞。
但在过去的几年里，语言领导力确实出现了真空。 目前，没有人在意这家商店。 没有人会做出关于什么适合 Java 模式以及添加（或更重要的是不添加）有意义的艰难决定。 我不知道这意味着什么。 我希望 Java 的巨大普及和影响力以及 JVM 的强大基础意味着这个真空太有吸引力，无法在某个时刻被填补和给予指导。 但我只是抱着谨慎的希望，因为我不知道那个人会是谁。
John Rose 是 JVM 方面的那个人。 不过，如果我只能在其中一项获得创新，那么无论如何我现在都会选择 JVM。 :)
Most languages have one strong hand involved in their origin and evolution. Think: Larry Wall/Perl, Guido/Python, Matz/Ruby, Odersky/Scala, Hickey/Clojure, etc. These guys are all brilliant language dudes. I'd give my left arm to be half as smart as any of them.
Java has actually had the distinction of having not just one but a series of amazing language guys at the helm - starting with Gosling, but I also think of Guy Steele, Bill Joy, Gilad Bracha, Neal Gafter, etc - all amazing guys. That actually has been a good thing (I think). It's made the language better but prevented stagnation.
But for the last couple years, there's been a real vacuum of language leadership. At the moment, no one's minding the store. No one's making the hard decisions about what fits with the Java mold and makes sense to add (or more importantly to not add). I don't know what that means. I'm hopeful that the enormous popularity and reach of Java and the strong base of the JVM mean that this vacuum is too attractive not to be filled and given direction at some point. But I'm only cautiously hopeful because I don't know who that will be.
John Rose is that dude on the JVM side. Though if I can only get innovation in one or the other, I'd take JVM right now anyways. :)
Java 的发展确实非常缓慢 - 特别是如果将它与 C# 和 VB 进行比较。 我个人认为，他们在以执行时安全性和效率为代价来保持向后兼容性方面对泛型做出了错误的决定。 在我看来，.NET 方法在几乎所有方面都表现得更好。
Java 7 有一个一长串潜在功能 - 包括语言和平台 -但它的制作已经花了很长时间，而且许多功能仍然存在很大的问号。
然而，我不想对为什么会发生这种情况进行任何“指责”。
Java has certainly been evolving very slowly - especially if you compare it with C# and VB. I personally feel that they made the wrong decision with generics in terms of keeping backward compatibility at the cost of execution-time safety and efficiency. The .NET approach works a lot better in almost every way, IMO.
Java 7 has a long list of potential features - both language and platform - but it's been an awfully long time in the making, and there's still significant question marks over many of the features.
I wouldn't like to place any "blame" on why this has happened, however.
Java 语言的发展一直很缓慢，但这是故意的。
泛型提供了一个很好的例子。 与 Java 早期版本的兼容性是一项要求。 考虑到项目的目标，泛型实现完全按照设计执行非常有用的功能。 然而，它并没有满足许多开发人员对具体化泛型行为的期望。
另一方面，JVM 的创新非常迅速，常常引领其他虚拟机的发展，并促进性能领域的竞争。
在我看来，Java语言应该尽可能稳定。 我喜欢闭包的想法，但我不认为 Java 是适合闭包的语言。 （如果必须添加某些内容，我更喜欢保守的 FCM。）我与需要培训的开发人员团队合作，构建和维护复杂的生产应用程序。 Java 语言为我们提供了功能和结构的完美结合。
其他语言，如 Scala 和 Groovy，以及 Ruby 和 Python 等 JVM 的移植，将继续为 Java 平台带来活力，即使 Java 语言本身已经走上了 COBOL 的道路。
The evolution of the Java language has been slow, but deliberately so.
Generics provides a good example. Compatibility with prior versions of Java was a requirement. Given the goals of the project, the generics implementation performs a very useful function exactly as designed. However, it doesn't meet the expectations of many developers that expected the behavior of reified generics.
Innovation in the JVM, on the other hand, has been extremely rapid, often leading the way for other VMs, and promoting competition in the performance arena.
In my opinion, the Java language should be as stable as possible. I like the idea of closures, but I don't believe Java is the language for them. (If something must go in, I'd prefer the conservative FCM.) I work with a team of developers that need training, to build and maintain a complex production application. The Java language gives us a nice blend of power and structure as it is.
Other languages, like Scala and Groovy, and ports to the JVM like Ruby and Python, will continue to give life to the Java platform, even after the Java language itself has gone the way of COBOL.
目前，Java 与 .Net 存在不同的问题，导致了不同的选择。
.Net 相对较新，并且有机会避免 Java 的一些错误，因此有机会以不同的方式做事。 这给它带来了两个主要优势：
这两件事共同作用使得 .Net 语言（目前）能够更快地进步。 然而，正如我已经说过的，我们也开始看到这些效果也赶上了 .Net。
Java has different problems then .Net at the moment, resulting in different choices.
.Net, being relatively new and with a chance to avoid some of Java's mistakes has the chance to do thing differently. This gives it two main advantages:
Those two things conspire together to make it possible (at the moment) for the the .Net languages to advance more quickly. However, like I've already said we're starting to see these effects catch up with .Net as well.
我认为 Sun 现在很保守，并确保他们在做出一些糟糕的决定后做出正确的决定。
此外，在 Java 1.5 发布之前，还存在很多政治活动和混乱。 许多公司都在使用像 Generic Java 这样的第三方 hack，因为这些核心语言功能虽然不可用，但却非常需要。
我认为自 1.5 以来，它们再次加速了，1.7 即将到来，而且看起来它们都提供了非常有用的新功能。 该语言的开源也很好。
不管有些人怎么说，保留向后兼容性一直是 Java 语言的一个非常重要的特性。
我想说，.NET 已经让 Sun 的屁股开始运转，并且它们都存在是件好事。
I think that Sun are now being conservative and ensuring they make the right decisions after making a few poor ones.
In addition there was a lot of politicking and messing around before Java 1.5 came out. Many companies were using third party hacks like Generic Java, because these core language features weren't available but strongly desired.
I think they have sped up again since 1.5, with 1.7 on the horizon, and it looks like each of these has delivered very useful new features. The open sourcing of the language is good as well.
And whatever some people say, retaining backwards compatibility has been a very important feature in the Java language.
I would say that .NET has kicked Sun's arses into gear, and that it is good that they both exist.
长期以来，Java（无论好坏）更喜欢通过框架而不是语言本身引入新功能。
例如，您可能会说，编写 Spring/Hibernate/Struts 应用程序的人实际上是用 Java 的专门方言编写的，因为如果没有框架执行的所有反射/注入/检测魔法，他们的代码将基本上无法操作。
就我个人而言，我希望该语言能够进一步发展，并且框架作者不再通过字节码操作来胡闹语言语义。
附带说明一下，我也强烈反对 Sun 在泛型实现中使用类型擦除的决定。 据说，他们想要确保向后兼容性，但对我来说这似乎完全是虚假的，因为注释（在 Java 5 中同时添加）创建了他们自己的一组不兼容性。 无论如何，为 Java 5 编译的代码永远无法在早期的 JVM 上执行，因此向后兼容性声明对我来说似乎非常可疑。
For a long time, Java has (for better or for worse) preferred to introduce new functionality through frameworks, rather than in the language itself.
You could argue that, for example, someone writing a Spring/Hibernate/Struts application is actually writing in a specialized dialect of Java, since their code will be largely inoperable without all the reflection/injection/instrumentation magic performed by the frameworks.
Personally, I'd prefer for the language to evolve a little bit more, and for the framework authors to quit monkeying with the language semantics via bytecode manipulation.
As a side note, I also strongly disagree with Sun's decision to use type erasure in their implementation of Generics. Supposedly, they wanted to ensure backward compatibility, but to me that seems totally spurious, since Annotations (added at exactly the same time, in Java 5) created their own set of incompatibilities. At any rate, code compiled for Java 5 can't ever be executed on an earlier JVM, so the backward-compatibility claim seems very dubious to me.