【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)。
在此,我想对其进行逐一反驳。
首先,那篇帖子中抱怨了 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 都能解决并自动修复这些问题。
这篇文章(https://alexn.org/blog/2022/09/19/java-cultural-problem/)中提到了关于 Java 的一些文化问题,我同意。Java 开发者倾向于把每个问题都变成更复杂的问题。有时候,这是必要的,毕竟 Java 是个超级庞大的怪物,它的解决方案通常都有过度设计的问题。这肯定要比设计不足要好,但的确要付出一定的代价。
我想起了下面这个例子,看似 ” 正确 “,但其实有问题:
@NotNull @EmailString noReplyEmailAddress
作者认为这样不对,应该写成下面这样:
public record EmailAddress ( String value ) { public EmailAddress { // We couldve 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 无所不包,其带来的优势普遍适用,而且上面我提到的那些好处能让整个生态系统受益。
声明:本文部分素材转载自互联网,如有侵权立即删除 。
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需!
7. 如遇到加密压缩包,请使用WINRAR解压,如遇到无法解压的请联系管理员!
8. 精力有限,不少源码未能详细测试(解密),不能分辨部分源码是病毒还是误报,所以没有进行任何修改,大家使用前请进行甄别
丞旭猿论坛
暂无评论内容