在“强制性”中并不重要。这是一种不同的可能性，有力量和弱点。
优点：
- 编译时检查：用Java编写（而不是Xml）在IDE中是非常用户友好的。 在启动应用程序时没有发现错别字（增量编译），而不是记住（完成）......
- 使用代码（类级别）进行本地化：不必打开两个文件（java和xml）来获取完整的故事，使用一个带注释的java文件，只打开一个文件。从长远来看，这种重复性较低，速度更快。
- 使用代码（方法或字段级别）进行本地化：因为注释是在方法（或字段）上进行的，所以无需指定它所属的方法。没有给出重新生成信息，这些信息更短，并且总是连贯的（即使在例如代码重构之后）。维护速度要快得多。
- 工具（javadoc，使用反射的其他工具）可以使用注释来满足其他一些要求。
- 注释比xml更新，团队使用他们当时收到的输入来提供更好的默认值。 Xml有一些，但由于兼容性原因不能改变太多。通常，使用注释技术，您根本不编写注释，并且它可以正常工作。想象一下节省时间，特别是在开发过程中。
我不明白所有围绕注释的炒作，我更喜欢HBM，原因如下（这些原因否定了错字，例如拼写错误，编译时检查我）：
- 分离问题/单一责任：使用HBM，您可以获得HBM中所有与ORM相关的内容。 java类中的实体和域逻辑（独立于表结构）。您的DB和java类可以单独更改（只需要更新HBM）。
- 您的代码不会被注释混乱。我更喜欢看域逻辑。注释会增加很多噪音。
如果HBM组织良好（每个java类一个HBM，一致命名），则可以轻松地在两者之间导航。 Junit测试和一些规则将消除编译时间检查的需要。至于默认值，我认为如果hibernate完全没有注释，它应该能够完全不使用XML（从概念上讲 - 不知道这是不是现实）