Why JDK-8157181 conditional in JDK 9 EA ?

[David Holmes]

Hi Evgeny,

On 12/12/2016 7:58 AM, Evgeny Mandrikov wrote:
> Hi,
>
> Rory O'Donnell gave me an advice [1] to provide our concerns about
> JDK-8157181 [2] here. But excuse me if this is wrong place or too late.
>
> In JaCoCo project [3] we accidentally discovered JDK-8157181 [2], which
> revealed that we were generating bytecode that violates JVMLS [4]. What was
> a bit surprising - is a conditional behavior of verifier based on bytecode
> version. At a time of discovery we had no ability to compile into bytecode
> version 9 given the state of tools in build stack (minifiers, verifiers,
> etc) and had only ability to execute with JDK 9 EA. I guess that many
> projects might relatively easily start testing 9 EA just as runtime
> environment, while change of a target still might require bigger investment
> as was the case for us. From there, I wonder why this logic was was not
> made unconditional as was discussed in JDK-8157181 [2], especially in
> presence of tickets for backporting [5]. Or maybe this happened, but we
> just didn't noticed since bug on our side was fixed? The verification
> itself is great and IMO might reveal bugs in tools that generate bytecode.

My comment in the bug report sums up the situation:

"If this is a long standing non-compliance with the JVMS then its impact 
can not be considered high. The longer the VM and spec do not match the 
more likely we adjust the spec to match the VM behaviour. When that is 
not feasible then the usual approach is to enforce the correct rules as 
of the current classfile version, otherwise we risk introducing 
compatibility issues. Even if we make the correct behaviour the default, 
we will usually provide a flag to enable the old behaviour for 
compatibility purposes. Only if this is a security concern would we 
force the change to the new behaviour. "

After much (mostly internal) discussion the compatibility argument won 
out. The backports exist to put in the change that causes the JIT to 
detect the "illegal" assignments and disable aggressive optimization of 
the final field.

Regards
David

> Best regards,
> Evgeny Mandrikov
>
> [1] https://groups.google.com/d/msg/jacoco-dev/sRXi8TD96js/w4T8DpffAwAJ
> [2] https://bugs.openjdk.java.net/browse/JDK-8157181
> [3] http://www.jacoco.org/jacoco/index.html
> [4] https://github.com/jacoco/jacoco/pull/434
> [5] https://bugs.openjdk.java.net/browse/JDK-8161987
>