在Java中,Collection-interfaces没有扩展Serializable,原因有很多.此外,这些接口的大多数常见实现都实现了Serializable.
因此,实现其中一个Collection-interfaces的对象是可序列化的,如果实现本身是可序列化的(通常是这种情况),并且集合中的对象都是可序列化的.
但我怎样才能确保满足这两个条件？我不想遇到运行时错误,因为编译器可以检查这些条件.我正在考虑一些明显的界面(展示List-interface):
public interface SerializableList<T extends Serializable> extends Serializable, List<T> {}
我想知道是否没有其他人面临这个问题,并提出了这个简单的解决方案.到目前为止,我无法找到任何解决方案,甚至没有对此进行讨论,这让我怀疑我的想法.
我有一个包含在EAR中的应用程序,其中包含许多JAR(包含EJB,库,第三方库,......)和单个WAR(同样包含其他一些JAR).该应用程序部署在JEE7容器(Wildfly 8.0.0.Final)中,并使用CDI(Wildfly随附的Weld 2.1.2.Final).
根据我的理解,Weld在应用程序范围内是活跃的,并且具有单一的应用程序范围视图.所以我想在哪里使用CDI并不重要 - 它有效.
但有一些迹象表明这种情况并非如此.例如,toString所述的-method BeanManager的节目在不同的模块不同的输出:
当BeanManager我在战争中打包的某个模块中使用时,我得到了
Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-webui-frontend-1.0-SNAPSHOT.war/WEB-INF/lib/test-webui-backend-1.0-SNAPSHOT.jar [bean count=76].
如果它在EAR中直接包含的库中使用:
Weld BeanManager for test-ear-1.0-SNAPSHOT.ear/test-ejb3-dao-1.0-SNAPSHOT.jar/ [bean count=224].
所以它们似乎BeanManagers"负责"应用程序的不同部分.这是真的？
在重构过程中，JavaDoc 经常会过时。它描述了不再存在或缺少一些新参数的方法参数，以举例说明。
如果有一个 Maven 插件会自动检查现有的 JavaDoc 并在存在某种“JavaDoc 违规”时停止构建，那就太好了。我见过 Maven-JavaDoc-Plugin 和 maven-doccheck，但两者似乎都只能在发生违规时自动修复现有的 JavaDoc，而不是放弃一些错误或警告。
有谁知道是否有这样的 Maven 插件以及如何存档？