我应该在同一个JAR中捆绑源文件和类文件吗？

Question

独立罐子

创建JAR文件时，我始终将源保持独立，并将其作为可选附件提供。

例如：

• foo.jar中
• 富-source.jar

这似乎是做事的明显方式，而且很常见。优点是：

1. 保持二元罐小
2. 来源可能不公开/公开
3. 更快的类加载器？ （我不知道，只是猜测）

单罐

我开始怀疑这些优势是否总是值得的。我正在开发一个开源的 tiny 组件。我上面列出的优点都不是这个项目中的问题：

1. 课程+来源仍然很小（并将保持这种方式）
2. 来源已开启
3. 此jar的类加载速度无关紧要

保持源代码确实带来了新的优势：

1. 单一依赖
2. 源和类之间的版本不匹配问题
3. 使用此jar的开发人员将 始终 拥有手头（调试或检查）

这些新优势对我来说真的很有吸引力。是的，我可以只是将源代码，类甚至javadoc压缩成zip文件，并让我的组件的客户决定他们想要使用哪些（比如Google对guava库的处理）但是真的值得吗？

我知道这与传统的软件工程逻辑有点不同，但我认为单个jar文件的优点超出了替代品的范围。

我错了吗？还有更好的方法吗？

Answer 1

  

是的，我可以将源代码，类甚至javadoc压缩成一个zip文件，并让我的组件的客户决定他们想要使用哪些（比如谷歌使用番石榴库），但它真的值得吗？

当然值得！这需要大约2秒钟，或者只需几分钟就可以更改构建脚本。

这是分发源和二进制文件的大多数人处理此问题的方式。

修改

您需要考虑的不是您的观点。您必须从部署/使用您的软件的人员的角度来考虑这一点。

• 他们不会在部署平台上使用源代码。
• 因此，将源代码放在二进制JAR中会浪费磁盘空间，从而减慢部署速度并减慢应用程序启动速度。
• 如果他们想对此采取行动，他们就会遇到问题。他们如何重建JAR文件以摆脱源代码？他们怎么知道什么是安全的遗漏？

从部署者/用户的角度来看，没有积极因素，只有负面因素。

最后，关于人们无法跟踪源版本与二进制版本的观点并不能真正保持水资源。大多数对源代码感兴趣的人完全有能力做到这一点。此外，您可以采取一些简单的方法来解决此问题，例如使用包含软件版本号的JAR文件名，或将版本号放入清单中。

Answer 2

如果您希望其他人测试并检查/改进您的代码，那么您可以使用二进制文件获取源代码。如果没有，请将光源远离罐子。

Answer 3

我刚刚在一个jar中遇到了java +类的潜在缺陷。

如果你在jar中有java文件，那个jar包含在后续javac执行的类路径中，你必须确保java文件的时间戳小于类文件的时间戳。

当您在打包为jar之前复制/移动java或类文件时，可能会发生这种情况。

如果java文件比类更新，那么即使在类路径上找到java文件（而不是javac的参数），javac也会尝试编译该java文件，然后可能会出现重复的类错误在编译阶段。

出于这个原因，我建议将源保存在一个单独的jar文件中。

请注意，javac中的相关标记不允许您更喜欢类而不是源：http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#searching

Answer 4

小有多小？为什么您的罐子与其他罐子有所不同？

除非您有充分的理由说明jar应该具有源，而不仅仅是调试，而是专门针对此jar的某些东西，然后我会说不，选择是最好的。

我之所以这样说是因为，如果您的罐子与其他罐子没有什么不同，那么您必须假设其他人应该做与您相同的工作。如果是这样，罐子的大小并不重要，因为它在所有“小”罐子中都是重复的。然后，我的WAR远远超出了需要，这无疑不是一个大问题，但是当我可以轻松地在DEV中下载源代码时，我就不会选择将其用于生产。

Answer 5

我更喜欢'独立罐'。

因为二进制类jar用于在JVM上运行，但源不是。源控制系统（SVN）应仔细维护源。如果source需要释放，请将其压缩在单独的jar中。许多开源分类类jar和源类。