频繁被吐槽的Java依然强大!

百家 作者:CSDN 2022-10-09 12:51:49

【CSDN 编者按】提到 Java,批评声从未中断,无论是“已死”还是“即将衰亡”,总有开发者唱衰 Java。然而与批评不同的是,本文作者是Java的忠实粉丝,他对控诉Java劣迹的特性进行一一反驳。

原文链接:https://debugagent.com/the-reason-java-is-still-popular

声明:本文由 CSDN 翻译,未经允许禁止转载。

作者 | Shai Almog
译者 | 弯月
出品 | CSDN(ID:CSDNnews)

最近,Java 19正式发布。Java仍然是我挚爱的编程语言,但前一段时间有人在帖子中控诉Java的种种“劣迹”(原文链接:https://medium.com/codex/i-finally-gave-up-on-java-5187947bef1b)。

在此,我想对其进行逐一反驳。


Getters and setters


首先,那篇帖子中抱怨了 getter 和 setter。但实际上,在现代 Java 中,getter 和 setter 不是必需的。我们从 Java 14 开始就有记录,在我看来Lombok很好。我们唯一需要 getter/setter 的地方是在一些特定的设置(例如 JPA)中,而且 Lombok 也完美地解决了这个问题。

那篇帖子反复诉说 Java 缺乏语法糖特性。但实际上这是有意为之。如果你对最新的语法细节感兴趣,则可以看一看 Kotlin。Java 的发展“缓慢而稳定”,这是一件好事,也是 Java 长寿的主要原因。


语法糖和运算符重载


现代 Java 包括 switch、var、多行字符串等模式,还有一些即将推出的功能,包括字符串模板。字符串模板的支持还需要一段时间,因为 Java 想要“正确地实现”。API 级别有一些此类的支持(而且已经有一段时间了),但性能不是很好。字符串模板的目标是创建一种语法以支持以下写法:

ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}";

注意,这里的 name 是一个变量,编译器需要动态地检查并从作用域中获取!

DB 可以由开发人员自定义实现,不需要“内置”,因此你可以构建复杂的模板。

话虽如此,我们还是先把 Java 未来的规划放在一边,只看看现在的Java。

近十年来,我们一直不推荐使用 String 的 append,因为使用+的性能更高,而且更易于阅读。

实际上,运算符不能重载是一个巨大的好处。如果看到 a + b,那么我就知道这是一个字符串或一个数字,而不是一些不为人知的方法。这是 Java 最大的优势之一,也是它流行了近 30 年而其他语言却被抛弃的原因之一。Java的语法设计考虑到了大规模的代码阅读。当项目的代码规模高达百万行,甚至是十万行时,你将会面临完全不同的问题。此时,如果你发现模块X中的程序Y错误地重载了某个运算符,那么调试就会非常困难。语法应该尽量简单,最初节省的任何小成本将来都要 10 倍偿还。随着代码越来越复杂,时间越来越久,简单的定义也会发生变化。再加上工具的强大功能可以大规模解析严格的简单代码,由此带来的好处也数不胜数。


检查型异常


检查型异常不是必须的,但这是 Java 最优秀的特性之一。代码发生异常的事情太常见了。作为个人娱乐项目,出现异常也没问题,但如果要构建专业的应用程序,那么就必须处理每个错误。检查型异常可以避免发生意外情况。人们讨厌检查型异常,只是因为他们懒。而 Java 不让你偷懒。

对于建立网络连接、数据库连接、打开文件等操作,不处理异常是不可能的。就算我想偷懒,检查型异常也会强迫我在某个地方处理异常。这个特性非常好。


依赖


我对于 Maven 和 Gradle 的意见颇多。但跟其他依赖系统相比,它们还算不错。虽然二者的确存在一些问题,但拿它们跟 cargo 这种年轻的包管理器做比较是不公平的,再说后者几乎没有任何可用的包。Maven 中心库拥有 27TB 的jar 包,每个月有 4960 亿次请求。它依然能正常工作,而且基本上没有宕机时间。

其他工具,比如 NPM,也衬托了 maven 的强大之处。如果说 maven 中的依赖是一个问题,那么 NPM 的问题岂不是有 100 倍,而且还无人管理。这些问题会变得越来越复杂,特别是当市场上存在多个版本的 maven 时。但是,maven 和 gradle 这样做的原因之一是工具。许多情况下,IDE 都能解决并自动修复这些问题。

Java 的文化问题


这篇文章(https://alexn.org/blog/2022/09/19/java-cultural-problem/)中提到了关于 Java 的一些文化问题,我同意。Java 开发者倾向于把每个问题都变成更复杂的问题。有时候,这是必要的,毕竟 Java 是个超级庞大的怪物,它的解决方案通常都有过度设计的问题。这肯定要比设计不足要好,但的确要付出一定的代价。


为什么使用注释进行验证


我想起了下面这个例子,看似“正确”,但其实有问题:

@NotNull @EmailString noReplyEmailAddress
作者认为这样不对,应该写成下面这样:
public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); }}

这段代码当然可以这么写,但有几个问题,因此我们需要使用 Bean 验证:

  • 这种写法无法被优化。而Bean验证可以被框架移动到更高的层次,甚至可以由客户端代码进行验证,因为它是声明式的API。这里我们不需要执行构造函数来进行验证;

  • 声明式的注释可以向下层移动,无缝地应用到数据库约束上;

  • 可以同时应用多个注释;

  • 语法更简洁。

因此,尽管这里的注释看起来有点奇怪,而且不会强制检查类型,但能极大地提升性能,而且很强大。这种用法背后有很多考量。


总结


本文花了很多篇幅来反驳其他文章,下面我想提出一些自己的看法。Java 已有近 30 年的历史了,很多功能仍然能与 Java 1.0 兼容,这一点就非常了不起!

Java 采取保守路线的好处之一就在于,可以“私下里”进行优化,而使用者甚至注意不到。Java 9 完全改变了字符串在内存中的表示方式,从而极大地降低了内存使用,但这个改动对外部没有任何影响。与之类似,Loom 提高了 Java 同步应用的吞吐量,Valhalla 进一步改善了集合的性能,统一了对象和基本类型的触发。Panama 让我们摆脱了 JNI,降低了与原生代码打交道的难度。

如果你不喜欢Java,也许可以试试 Kotlin 或 Scala。JVM 无所不包,其带来的优势普遍适用,而且上面我提到的那些好处能让整个生态系统受益。

— 推荐阅读 —

上班时间做“副业”被抓,程序员惨遭解雇,还要退还所有工资
痛心!华为高管丁耘去世,享年 53 岁
云原生时代的DevOps平台设计之道

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接