为什么 Java 7 中不会有原生属性？
是否有任何合理的理由，为什么 本机属性 不会成为 Java 7 的一部分？
Is there any rational reason, why native properties will not be part of Java 7?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当然，有一些与日程和资源相关的高层原因。 属性的实现以及理解与其他语言功能的所有分支和交叉点是一项艰巨的任务，类似于各种 Java 5 语言更改的规模。
但我认为 Sun 不推动属性的真正原因与闭包相同：
1）对于实现应该是什么样子没有达成共识。 或者更确切地说，有许多相互竞争的替代方案，并且对财产充满热情的人们对实施的关键部分存在分歧。
2）也许更重要的是，对于是否需要该功能，人们严重缺乏共识。 虽然很多人想要属性，但也有很多人认为它没有必要或有用（特别是，我认为服务器端人员认为属性对他们的日常生活远没有 Swing 程序员那么重要）。
此处的属性历史记录：
There are some high-level reasons related to schedule and resources of course. Implementation of properties and understanding all of the ramifications and intersections with other language features is a large task similar to the size of various Java 5 language changes.
But I think the real reason Sun is not pushing properties is the same as closures:
1) There is no consensus on what the implementation should look like. Or rather, there are many competing alternatives and people who are passionate about properties disagree about crucial parts of the implementation.
2) Perhaps more importantly, there is a significant lack of consensus about whether the feature is wanted at all. While many people want properties, there are also many people that don't think it's necessary or useful (in particular, I think server-side people see properties as far less crucial to their daily life than swing programmers).
Properties history here:
在 Java 中“正确”地处理属性并不容易。 Rémi Forax 的工作在弄清楚这可能是什么样子以及揭示许多必须处理的“陷阱”方面尤其有价值。
与此同时，Java 7 已经花了太长时间。 关于关闭的争论是一个巨大的、有争议的干扰，浪费了很多本来可以用来开发得到广泛支持共识的功能（如属性）的精力。 最终，决定限制模块化的重大变化（Project Jigsaw）。 该语言仅考虑“小改动”（在 Project Coin 下）。
JavaFX 具有良好的属性支持，因此 Sun 清楚地了解属性的价值并知道如何实现它们。 但由于被 JavaFX 属性宠坏了，开发人员不太可能满足于 Java 中不成熟的实现。 如果它们值得做，就值得做对。
Doing properties "right" in Java will not be easy. Rémi Forax's work especially has been valuable in figuring out what this might look like, and uncovering a lot of the "gotchas" that will have to be dealt with.
Meanwhile, Java 7 has already taken too long. The closures debate was a huge, controversial distraction that wasted a lot of mind-power that could have been used to develop features (like properties) that have broad consensus of support. Eventually, the decision was made to limit major changes to modularization (Project Jigsaw). Only "small change" is being considered for the language (under Project Coin).
JavaFX has beautiful property support, so Sun clearly understands the value of properties and knows how to implement them. But having been spoiled by JavaFX properties, developers are less likely to settle for a half-baked implementation in Java. If they are worth doing, they are worth doing right.
默认情况下，任何给定的事情都是“未完成”的，因此不需要任何特殊原因来保持未完成的事情。 相反，需要一些令人信服的理由才能将某件事从“未完成”转变为“已计划”或“已完成”。 对于这种语言特性，目前还没有足够令人信服的理由。
Any given thing is "not done" by default, so no particular reason is needed for something to remain not done. Rather some compelling reason is needed to move something from "not done" to "planned" or "done". No sufficiently compelling reason has yet arisen for this language feature.
在任何语言中避免使用属性还有两个原因：
属性不是非常面向对象的。 让它们易于编写会鼓励这样一种模式：对象只提供其内部状态，而调用者则对其进行操作。 该对象应该提供更高级别的方法并保持其内部私有。 下次当您繁琐地实现 getter 时，请考虑调用者将如何处理数据以及您是否可以直接提供该功能。
属性鼓励可变状态（通过设置器），这使得程序的可并行性降低。 随着核心数量的增加，我们都应该尝试使对象不可变，以使并发推理变得更容易。 下次当您繁琐地实现 setter 时，请考虑将其删除并使对象不可变。
There are two more reasons to avoid properties in any language:
Properties are not very object-oriented. Making them easy to write encourages the pattern where the object just serves up its internal state and the caller manipulates it. The object should provide higher-level methods and keep its internals private. Next time you're tediously implementing a getter, consider what the caller will do with the data and whether you can just provide that functionality directly.
Properties encourage mutable state (through setters), which makes a program less parallelizable. As the number of cores goes up, we should all be trying to make our objects immutable to make concurrent reasoning easier. Next time you're tediously implementing a setter, consider removing it and making the object immutable.