跳转到帖子
  • 游客您好,欢迎来到黑客世界论坛!您可以在这里进行注册。

    赤队小组-代号1949(原CHT攻防小组)在这个瞬息万变的网络时代,我们保持初心,创造最好的社区来共同交流网络技术。您可以在论坛获取黑客攻防技巧与知识,您也可以加入我们的Telegram交流群 共同实时探讨交流。论坛禁止各种广告,请注册用户查看我们的使用与隐私策略,谢谢您的配合。小组成员可以获取论坛隐藏内容!

    TheHackerWorld官方

频繁被吐槽的Java(Java 19正式发布)


HACK1949

推荐的帖子

最近,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 是个超级庞大的怪物,它的解决方案通常都有过度设计的问题。这肯定要比设计不足要好,但的确要付出一定的代价。


为什么使用注释进行验证
我想起了下面这个例子,看似“正确”,但其实有问题:
@Not @Email

String noreplyEmailAddress

作者认为这样不对,应该写成下面这样:

public record EmailAddress(String value) {

public EmailAddress {

// We Could've used an Either data type, ofc;

Objects.requireNon(value);

// regexp Could be better

if (!value.matches("^[^@\s]+@\S+#34;))

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 无所不包,其带来的优势普遍适用,而且上面我提到的那些好处能让整个生态系统受益。
链接帖子
意见的链接
分享到其他网站

黑客攻防讨论组

黑客攻防讨论组

    You don't have permission to chat.
    • 最近浏览   0位会员

      • 没有会员查看此页面。
    ×
    ×
    • 创建新的...