javac生成的class文件总是一样的吗? [英] Is the class file generated by javac always the same?

问题描述

目前，我们正在为一个大型项目(大约 2000 个源文件)重新编写所有构建系统的脚本，并且一直在谈论对文件进行二进制比较以确保一切正确，从而导致以下问题:javac 的输出是否保证在编译时相同，或者是否可以更改?

Currently we are in the process of re-scripting all of our build system for a large project (around 2000 source files) and there has been talk of doing a binary comparison on the files to ensure that everything is correct which leads to the following question: Is the output of javac guaranteed to be same across compilations or could it be subject to change?

另一个问题 暗示常量池可能有不同的顺序，但假设我们能够控制进入 javac 调用的文件的顺序，那么仍然存在对于差异?我们将使用 Ant 和 Maven 作为构建的一部分，如果这也会影响事情的话.

Another question implied that the constant pool could have a different order, but assuming we are able to control for the order of the files going into the javac call is there still a potential for differences? We are using Ant and Maven as part of the build if that may influence things as well.

推荐答案

字节码绝对不保证相同；一方面，允许编译器执行不影响任何保证行为的优化.Java 语言规范甚至在一些地方提到了编译器可能执行的优化；例如，字符串连接运算符+，它注意到:

The bytecode is absolutely not guaranteed to be the same; for one thing, compilers are allowed to perform optimizations that don't affect any guaranteed behaviors. The Java Language Specification even mentions, in a few places, optimizations that a compiler might perform; for example, of the string concatenation operator +, it notes that:

一个实现可以选择在一个步骤中执行转换和连接，以避免创建然后丢弃一个中间 String 对象.为了提高重复字符串连接的性能，Java 编译器可以使用 StringBuffer 类或类似的技术来减少中间 String 对象的数量，这些对象是通过评估一个表达.

An implementation may choose to perform conversion and concatenation in one step to avoid creating and then discarding an intermediate String object. To increase the performance of repeated string concatenation, a Java compiler may use the StringBuffer class or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression.

[链接]

这篇关于javac生成的class文件总是一样的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！