Directly initialized final field is not constant folded later when prefix with "this"

[Brian Goetz]

That you can access static members through instances is widely 
acknowledged to be a mistake in the language design (and has caused 
problems as we have evolved the language.)  It is a good example of the 
harm one can do when you design language features with the attitude of 
"well, it's not actually sensible, but we know what the user meant, so 
we'll be nice."  Nothing wrong with being nice, but it creates big 
problems for future generations for the sake of a very small benefit in 
the present.

For example, when we added static methods to interfaces in 8, this 
historical mistake left us with bad choices -- extending this behavior 
to multiple inheritance would have been terrible (multiple inheritance 
of static methods, among other things!), so we pruned this "feature" at 
its then-current boundary.  (But that is also not great, since the 
meaning of `x.m()` now depends on whether the static type of `x` is a 
class or interface, or on whether `m()` is declared in a class or 
interface.)

On 6/29/2020 10:33 AM, Roland Illig wrote:
> Thanks for the explanation, I wasn't aware that this idiom was
> long-discouraged.  I agree that the existing definition of "constant
> variable" and "constant expression" and "final variable" is already
> confusing enough.  It's an interesting detail to remember, though
> probably more suited for the Java Puzzlers book rather than daily
> average code.
>
> On 29.06.2020 16:01, Brian Goetz wrote:
>> [...]
>>
>> Sure, we could patch this particular corner case, but where's the
>> benefit?  So we can encourage people to use this long-discouraged
>> idiom?  [...]
>>
>> On 6/11/2020 3:18 PM, Roland Illig wrote:
>>> > A constant expression is ...
>>> >
>>> > *  Simple names (§6.5.6.1) that refer to constant variables
>>> >    (§4.12.4).
>>> >
>>> > *  Qualified names (§6.5.6.2) of the form TypeName.Identifier
>>> >    that refer to constant variables (§4.12.4).
>>>
>>> I wouldn't have expected that this makes a difference, but since `this`
>>> is not a TypeName, the compiler works as specified.
>>>
>>> This leaves the question why `this.field` was not defined to be
>>> equivalent to the unqualified `field` in the first place? Can anyone
>>> shed a light on this?
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200629/204a1838/attachment-0001.htm>