经过一堆规范的阅读和思考，我得出的结论是：
在Java 5或Java 6编译器中，这是正确的行为。第16章“ Java语言规范的
绝对赋值，第三版”说：
在访问任何值时，每个局部变量（第14.4节）和每个空白
final
（第4.2.4节）字段（第8.3.1.2节）都必须具有一个
明确分配的 值。对它的值的访问由 变量的简单名称组成，该变量的名称 出现在表达式中的任何位置，但作为简单赋值运算符的左侧操作数除外=。
（强调我的）。因此，在表达式中
2 * this.x，该
this.x部分 不 被视为“ [[
x]]值的访问”（因此不受制于明确赋值的规则），因为
this.x它不是实例变量的简单名称
x。（注意，在上面引用的文本之后的段落中，当发生明确赋值的规则时，
确实 允许类似的操作
this.x =3，并认为
x此后肯定会赋值；只是访问规则不计入
this.x。）请注意，该值的
this.x在这种情况下将是零，每§17.5.2。
在Java 7编译器中，这是一个编译器错误，但是是可以理解的错误。Java 7 SE Edition
Java语言规范的
第16章“定值分配” __说：
每个局部变量（第14.4节）和空白
final字段（第4.2.4节，第8.3.1.2节）在对其值进行任何访问时都必须具有
明确分配的 值。对它的值的访问包括变量的简单名称
（或者，对于字段而言，由限定的字段的简单名称this）出现在表达式中的任意位置，但作为简单赋值运算符的左侧操作数=（第15.26节）。
1）。
（强调我的）。因此，在表达式中
2 * this.x，该
this.x部分 应 被视为“对[
x‘s]值的访问”，并且 应 给出编译错误。
但你没有问 是否 第一个 应该 编译，你问 为什么 它 不 编译（在一些编译器）。这一定是推测性的，但我会做出两个猜测：
- 大多数Java 7编译器是通过修改Java 6编译器编写的。一些编译器编写器可能没有注意到此更改。此外，许多Java-7编译器和IDE仍支持Java 6，某些编译器-编写器可能没有动力去专门拒绝他们在Java-6模式中接受的Java-7模式中的某些内容。
- 奇怪的是，新的Java 7行为不一致。
(false ? null : this).x
仍然允许类似的事情，就此而言，甚至(this).x
仍然允许。受此更改影响的只是特定的令牌序列this
加上.
字段名。当然，这样的不一致已经存在于赋值语句的左侧（我们可以写this.x = 3
，但不能写(this).x = 3
），但这更容易理解：它被接受this.x = 3
为否则被禁止的构造的特殊允许情况obj.x = 3
。允许这样做是有道理的。但是，我认为拒绝将其2 * this.x
作为本来可以允许的特殊禁止建筑案例是没有道理的2 * obj.x
，考虑到（1）可以通过添加括号轻松解决此特殊禁止情况，（2）该特殊禁止情况在该语言的先前版本中是允许的，并且（3）我们仍然需要特殊规则，即final
字段具有其默认值（例如0
一个int
），直到他们被初始化，一方面是因为案件的喜欢(this).x
，因为情况下，像，并this.foo()
在那里foo()
，它是访问方法x
。因此，某些编译器编写者可能没有动力去进行这种不一致的更改。
这两种情况都令人惊讶-
我假设编译器编写者具有有关规范每次更改的详细信息，而根据我的经验，Java编译器通常非常擅长完全遵循规范（与某些语言不同，每个语言都有其各自的编译器自己的方言）-但是，发生了
一些 事情，以上只是我的两个猜测。
