我是 Agorava 的技术主管，一个有助于消费社交网络数据的框架。
今天，Agorava 基于 CDI 构建，以简化其在 Java EE 堆栈中的使用，但我们希望提供 Dagger 的实现，以便为 Android 提供更轻量级的解决方案。
我的问题是:我们可以在 CDI 和 Dagger 实现之间共享通用的 JSR 330 兼容代码吗？换句话说，是否可以使用 Dagger 在包含 JSR 330 注释的 jar 中编译代码，并在 Dagger 特定 Jar 中扩展或使用此代码的源代码(使用 @Provides,@Modules 和其他 Dagger 特定项目)？
如果答案是否定的，使用 Dagger 编译器编译我的通用 JSR 330 jar 并在我的 CDI 实现中使用它是否有任何问题？更准确地说，@Inject、限定符和其他 JSR 330 细节在运行时仍然可用，并且带有这些注释代码的类是否不会受到 Dagger 编译器的影响？最后是否有一种针对 Dagger 生成的代码(类名、注释)的跟踪器来允许 CDI 检测并忽略它？
最佳答案
您可以在 Dagger 和任何其他 JSR-330 实现之间共享客户端代码，只要您的代码不实现与 Dagger 不兼容的行为即可。例如，Dagger 1.0 不支持方法注入(inject)。 Dagger 2.0 使用组件接口(interface)而不是注入(inject)器，因此您的代码不必关心这一点。
@Inject 和其他 JSR-330 API 元素仍将在运行时出现。 Dagger 不会在运行时访问它们，而是在编译时创建生成的代码以在运行时解释这些注释。但对于任何 JSR-330 应用程序来说，这些类仍然是有效的符合 JSR-330 的可注入(inject)类。
可能有问题的是，Dagger 将生成这些额外的类，您必须对 jar 进行后处理，或者重新配置构建系统，以便删除生成的代码，并将它们移动到补充 jar 中。但这是一个构建系统配置问题，并且 dagger 对此是不可知的，只要生成的代码在运行时在使用 dagger 的应用程序中可用即可。
一个构建时选项是使用 -proc:none 运行编译器，并在第二个配置中使用 -proc:only 运行编译器，并将后者的输出通过管道传输到另一个输出文件夹中，并将其打包。这可以在 Maven 中通过对 maven-compiler-plugin 进行不同的执行来完成。
Dagger 生成的类都应该有 @Generate(即将推出)，但也都继承自 dagger.internal.ModuleAdapter、dagger.internal.Binding 或 dagger.internal.StaticInjection。非 Dagger 框架可以安全地忽略这些子类。事实上，他们可以被亲防走。
关于java - 是否可以在 Dagger 和 CDI 之间共享通用的 JSR 330 代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18636579/