到目前为止我理解的是：
Java bean只是为了帮助其他事物（视觉事物？）与您的代码进行交互。我认为这主要是针对UI的东西，因为它更容易在视觉上进行设计。将Java bean用于非UI事物是不好的做法吗？
Java bean具有getter和setter方法（糟糕的OOP实践）并且是可序列化的。
就注释而言，我认为用户定义的注释不提供任何功能。某些注释如@depretiated会引发编译器警告。用户定义的注释可以以某种方式执行此操作吗？用户定义的注释是否适用于除文档之外的任何其他内容？我该如何使用它们？ eclipse或intellij是否有一些涉及注释的功能？
周末愉快。
杰克
更新：开始变得更有意义了。有人可以向我推荐一个例子，说明何时使用java bean格式是合适的，何时不适用？
此外，我在某处读到了几个类可以是bean，它是一种打包类的方法。
只是为了澄清一件事。我95％肯定作为一个java bean有点像单身（或其他模式）。它不会影响编译器的功能。
答案 0 :(得分：6)
注释是declaritive programming的一种形式。首先，在注释的实用性变得清晰之前，您必须了解声明式编程的好处。实质上，您可以通过“声明”它具有某种特征来向代码块添加功能或行为。这与实际编写一系列语句以应用或设置相同的行为形成对比。
JPA annotations是添加注释功能的示例。我不知道“用户创建”的例子在我的头顶，但JPA注释的实现与你或我的完全相同。
就Java Beans而言，它们最初的用途是用于GUI编程。使用JavaBeans的“简单”方法是使用命名约定来定义bean的“属性” - 因此是getter和setter。据我所知，JavaBeans最初是基于GUI的表单和UI编辑的实现。因此，getter和setter使UI软件可以轻松发现用户可查看或可编辑的属性。使用Bean描述符，您可以更改描述符的工作方式......
他们坚持到今天的原因是他们提供了事实上的方法来检查公开暴露的物业的对象。在GUI之外使用JavaBeans是一种不错的形式。 Java中的偏好似乎是使用no arg构造函数然后注入您的依赖项而不是使用RAII编程风格（不是它严格可用）......
实际上这很常见，特别是如果对象将被不知道它将要操作的对象的代码操纵（看一下Hibernate的好例子）。
答案 1 :(得分：2)
我怀疑你是混淆Java bean和EJB（Enterprise Java Beans） - 这些是不同的概念。实际上它们现在差不多了，但并非总是如此 - 历史相当令人困惑。
James对Java bean的历史给出了很好的解释 - 它们比注释（Java 1.5中引入的）更早。 EJB也更老了，但它们已经彻底修改，现在基本上是Java bean，在EJB容器中运行特殊注释。
这实际上是注释有用的完美示例。
“旧式”EJB（在规范的第3版之前）对代码来说是可怕的。您需要定义（IIRC）两个接口，一个实现类（实际上没有实现接口）和一个将它们链接在一起的XML描述符。如果你在任何地方发错字，那就没有编译器错误 - 只是一个完全神秘的运行时错误，它无法帮助你缩小问题范围。
为什么会这样？因为它允许EJB容器控制实际实现代码的调用方式，并透明地执行访问控制，事务和复制等操作。
在EJB 3.0规范中，这是根本简化的，所以现在你只需要一个类（在实体bean的情况下可以是“经典”Java Bean），它实际上实现了EJB的逻辑 - 以及注释告诉EJB容器如何处理它。而不是单独的XML文件，有关代码的信息紧跟在同一文件中的代码本身旁边，并且由于编译器检查了注释语法，因此在编译时捕获了许多潜在的错误。
答案 2 :(得分：1)
JUnit使用自JUnit版本4以来的注释。这是用户定义注释的示例。您将@ Test-annotation添加到方法中，JUnit框架会识别它并将该方法作为测试执行。
一些框架将使用Bean来处理其他未知对象。我想到的一个例子是持久性框架，它们将一些已注册的对象复制到数据库中并使用bean属性。