有没有合理的理由，为什么native properties不会成为Java 7的一部分？
答案 0 :(得分：18)
当然，有一些与时间表和资源相关的高级原因。属性的实现和理解与其他语言特性的所有分支和交叉是一项大型任务，类似于各种Java 5语言更改的大小。
但我认为Sun没有推出属性的真正原因与闭包相同：
1）对于实施应该是什么样的，没有达成共识。或者更确切地说，有许多相互竞争的选择，对财产充满热情的人不同意实施的关键部分。
2）或许更重要的是，对于该功能是否完全没有达成共识。虽然很多人都想要房产，但也有很多人不认为这是必要或有用的（特别是，我认为服务员方面的人认为房产对他们的日常生活的重要性远远低于摇摆程序员。）
此处的属性历史记录：
答案 1 :(得分：16)
在Java中“正确”执行属性并不容易。 RémiForax的工作特别有助于弄清楚这可能是什么样子，并揭示了许多必须处理的“陷阱”。
与此同时，Java 7已经花了太长时间。关闭辩论是一个巨大的，有争议的分心，浪费了很多心灵力量，可以用来开发广泛的支持共识的功能（如属性）。最终，决定限制模块化的主要变化（Project Jigsaw）。该语言仅考虑“小变化”（在项目硬币下）。
JavaFX具有漂亮的属性支持，因此Sun清楚地了解属性的价值并知道如何实现它们。但是，受到JavaFX属性的破坏，开发人员不太可能满足于使用Java的半生不熟的实现。如果他们值得做，他们值得做对。
答案 2 :(得分：10)
任何给定的东西默认都是“未完成”，所以没有特别的理由需要保留未完成的东西。相反，需要一些令人信服的理由将某些东西从“未完成”转移到“计划”或“完成”。这种语言特征尚未出现足够令人信服的理由。
答案 3 :(得分：5)
还有两个理由可以避免任何语言的属性：
属性不是面向对象的。使它们易于编写可以鼓励对象只提供其内部状态并且调用者操纵它的模式。该对象应提供更高级别的方法并保持其内部私有。下次您繁琐地实现getter时，请考虑调用者将对数据执行的操作以及您是否可以直接提供该功能。
属性鼓励可变状态（通过setter），这使得程序不易并行化。随着核心数量的增加，我们都应该尝试使我们的对象不可变，以使并发推理更容易。下次你繁琐地实现setter时，请考虑删除它并使对象不可变。
答案 4 :(得分：3)