Java 程序员是否应该放弃属性setter方法，并对其领域对象进行不可变的建模？
Java首席语言架构师Brian Goetz认为：“问题中隐含的非此即彼，这会暗示只有一种正确的方法可以对程序中的数据进行建模，这有点误导。(banq注：是误导还是判断误导的依据已经过时？)，我们的同事 Alex Buckley，Java 语言和 JVM 的规范负责人，喜欢说令人惊讶的事情之一是 Java 设法将所有默认设置都弄错了，但仍然成功了（banq注：都做错了，却成功了，只能说明运气好，上下文为王，时势造英雄，矮子里面选将军，如果Go语言同时与Java诞生，则结果不一定如此）。”
Goetz 认为：在 Java 中：可变性的默认设置是错误的；可访问性的默认设置是错误的；类是否可扩展的默认设置是错误的。然而，不知何故，我们设法在这些错误中幸存下来了。
JavaBeans 命名约定有点不幸，对于通用开发来说，这是一个糟糕的约定。这是在可视化编辑器中命名可视化组件的一个相当有针对性的约定，您可以将按钮和标签之类的东西拖放到画布上，并且您有可以编辑前景色和字体等内容的属性表有你，可以通过反思发现。（banq注：终于承认JavaBeans过时了，其诞生的上下文是为了前端显示GUI，但是Java现在只能用在后端，谁还在浏览器里运行JavaFX或Applet？）
命名约定是构建这些 UI 组件的好方法——结果证明这种GUI不是一个关键的 Java 用例。然而，不知何故，我们继续使用该命名约定，即使它与大多数业务领域对象的匹配度如此差。
由于这些约定，可变性被大大过度使用和高估，不变性是管理复杂性的工具，因为它让我们可以将注意力集中在项目中实际上必须复杂的部分。
解决答案是记录Record：记录是一种语言特征，它认识到不变性的重要性，记录使将数据建模为数据变得更容易，并且密封sealed类型和模式匹配正在将 Java 推向更多面向数据的编程模型。
随着我们使用越来越多的小型服务、微服务和功能即函数，程序变得越来越小。更多的代码更接近网络边际，开发人员将处理不再是 Java 对象，而是一些未绑定的 XML 或 JSON 或其他字符串的数据。我们想将该数据建模为普通数据。Java 语言正朝着更容易做到这一点的方向发展。