我们讨厌Java的15件事

我们并不是真的讨厌Java。这是发生在我们身上最好的事情。我们喜欢它的类型检查，腰带和吊带世界的稳定性和普遍性。但这并不意味着我们就不能抱怨一点，也不能发表那些尖锐、古怪的评论，不是吗?这不就是互联网被发明的原因吗?

下面是对Java成为的“一次编写，到处运行”语言的15个抱怨。

通过首字母大写将长句子粘合在一起成为变量名的想法很快就过时了。毫无疑问，它增加了一些自我文档到代码，但它不是更容易读一行说:

我//按第43条规定持有税前利率

而不是:

interestRateHoldingVariableAdjusted ForTaxesAsDefinedByRegulation43

如果有Java和新人之间的一个主要区别，它的标点符号。Java程序都充满了大括号，分号和括号，其他语言如Groovy或Ruby没有做好。这并不是说标点符号爱好者没有与像Python语言是用神秘的白色空间规则表示表达式和块标点符号不会用Java之间的相同的分离，但尽管如此，大多数程序员只是无法忍受的标点符号一个合法的牛肉。他们认为这是视觉噪声 - 对于编译器和叱叱又一个机会。这种脱节意味着有可能会超越让一些人使用Groovy和其他人使用普通的旧式Java不容易解决。至少他们的代码可以编译成相同的JAR。

Java是不是开源的?到底哪些库是开源的呢?该死的，如果我能确定的话谷歌与甲骨文的长期冲突。在大多数情况下，Java程序员不需要担心，因为JREs和jdk是免费可用的。但在我们的内心深处，总会有一种可怕的感觉，就是某个律师不知从哪里冒出来，对我们说:“住手!不知为何，这种法律地位让我们在IBM、甲骨文(Oracle)和谷歌的较量中都成了棋子。

当Java出现时，与许多其他解决方案相比，线程是轻量级的。它们是在相同的内存空间内处理多个任务的一种简单方法。现在，使用Node.js的人总是对着Java服务器平台吐舌头，并暗示Java线程工厂就像一个巨大的养猪场，每当有人点击一个Web链接时，就会向服务器RAM配置文件添加2MB的肥肉。不知何故，使用Java线程模型不再像以前那样轻量级了。(并不是说我们中的任何一个仍然用Java编程的人也是这样，但这并没有使它更易于使用。)

任何尝试过使用Java创建Android应用程序的人都知道模拟器代码在桌面上运行的速度有多慢。这只是让一个Java程序运行起来就像让一个青少年在星期六早起去打扫他们的房间一样困难的最极端的例子。虽然Java应用程序在启动后可以相当顺利地运行，但它们的启动速度要慢于在上坡道路上红灯时超载的18轮大轮。

有什么要抱怨的吗?在继续输入之前，我来检查一下它是否为空。看起来很好。现在我来检查一下键盘是否还在这里没有被空值取代。它还在这里。现在，我将移动我的手指并告诉您为什么空测试是痛苦的。

Java需要无尽的if语句来测试变量是否为null;否则整个线程崩溃nullpointerexception。聪明的开发人员说，一开始没有检查输入是我的错，但在创建库时，这通常是不可能的。如果将来有人拿起这个类文件，您最好再次检查所有的变量，因为您不知道他们将如何重用它。

将所有东西都放到对象中似乎是一种干净的编程方式，直到您意识到创建Java对象的速度有多慢。每个真正想要重新设计代码以加快代码速度的人，都首先尽可能地抛弃面向对象的模型。创建对象的成本相对较高，这也是一些Java代码运行缓慢的主要原因。

Java Collections类和其他数据结构很好，但是它们需要您将基本值包装在对象中才能使用。这意味着一个四字节INT变成一个大胖对象，具有对象的所有权重和创建时间。一些程序员已经用基本原语编写了他们自己的数据结构来避免这个问题，但是对于主流Java来说可能已经太晚了。我们不得不在四字节之间进行区分INT和一个整数对象。

字符串也是另一种对象，但它们不能被改变。你最好在第一次就把它们弄对。如果你想改变一个字节，你需要创建一个全新的对象，然后复制它。此外，它们还增加了一些开销，这对于处理大的文本块来说很好，但对于小字符串来说就很麻烦了。你有选择吗?不。当你剪切和连接的时候，开始点和停止点的开销就派上用场了。

程序员抱怨Java中缺少全局变量有点不真诚，因为他们也很愿意抱怨PHP等其他语言中的全局变量的危险。尽管如此，我们还是不得不通过一些奇怪的障碍来完成全局变量所能给我们的大部分任务。有些人创造了全球类并使用静态变量填充。另一些则使用get例程构建单例对象，get例程总是返回one对象。如果创建单例对象不是充满竞争条件和效率问题，那么这是可以容忍的。

有人说这是不公平的指责的Java的事实，这是一个很大的目标。也有人说是其他平台有更多的安全漏洞，并至少在Java工程师试图建立一个像样的沙箱。还有人说，安全问题是预期，且至少甲骨文公开宣布bug修复，往往在大批量像去年宣布的42项安全修复。

这些都是合理的观点，但是它们并没有使使用Java变得更容易。Java的流行意味着许多黑客会以JVM为目标。Java的安全模型意味着许多程序员会信任JVM，尽管他们不应该盲目地信任它。要是我们能相信这个软件是完美的就好了。

许多语言现在都可以向下编译成Java字节码，这样它们就可以在任何JVM上运行。为了确保兼容性并确保您的代码可以在各种平台上运行，Java团队所做的艰苦工作背后，还有什么更好的方式来进行起草呢?Clojure, Scala, JRuby, Rhino——这样的例子不胜枚举。

这可能是集成Ruby和Java的一个优势，但不可避免地会带来麻烦。突然之间，仅仅确保Java代码与已有的库一起编译是不够的。现在，您必须担心N种语言在同一个JVM中平稳地运行。当它工作时，它证明了Java堆栈的强大功能，但它可能会让每个人都头疼。

自我改进通常是值得庆祝的，但在Java堆栈世界中，它也可能带来困惑和麻烦。我应该使用更新的StringBuilder类还是旧的StringBuffer?还是StringBuilder比较老?它们不是一样的吗?至少可以更容易地记住新的IO类NIO比旧的类更新。如果你能把事情搞清楚的话，你可能会想要使用许多新的和改进过的技术。他们一直在改进Java堆栈，但这只是意味着我们需要重新学习许多以前烙进我们大脑的习惯用法。

官方的Java API的巨大集合和不作为官方从像Apache组的开源软件包使Java - 站在巨人的肩膀上肥沃的土壤。唯一的问题是，你不能忍受的肩膀上，如果你不知道它们的存在。这可能需要数天的工作通过各种API，以找出哪些是真正最适合你想要做什么。然后在另一个隔间家伙似乎总是更好地了解的东西，这始终会在代码审查会议蛇鲨的只是极少量交付的事实。

他们说，Java无处不在。它存在于手机、蓝光光盘、Hadoop云和台式机中。这难道不是值得庆祝的理由吗?这不意味着每个人都喜欢它吗?当然!但它也让憎恨变得更容易，因为所有的成功都让控制仇恨变得更难。只是观察Java世界的发展，这是一项全职工作。快速，当您从1.6升级到1.7时，您需要修复什么?Apache Commons的哪个版本足够好?要成为Java专家是不可能的，这对于那些在Java语言出现时可能成为Java专家的人来说是一个艰难的启示。

•扼杀编程效率的15种最糟糕的方法

•开发解决:向一代又一代计算机程序员致敬

•Java和更多:10个引起轰动的Eclipse项目

•保护你的代码:给开发者的17个安全提示