Presently javac rejects == and != operators involving either or both operands that are statically discernible to be value instances. This behavior has been carried over from the original VVT prototype.

This ticket is to track any changes that may be required in this space.

At runtime, if the acmp operation is to encounter one or more value operands, its semantics is being defined to evaluate to succeed/fail based on:

• if_acmpeq succeeds if and only if value1 = value2 and neither is an instance of a value class.
• if_acmpne succeeds if and only if value1 ≠ value2 or either is an instance of a value class.

Given that, we have three choices at compile time:

(a) mimic the runtime behavior and fold the == or != into false/true at compile time.
(b) forbid the operation as ill conceived operation
(c) lower it into acmp and let the vm handle it - this would be "sub-optimal" in some sense.

(b) is the present behavior and I don't see a strong reason to change it ATM, but this ticket is a place holder for tracking any changes.

It is likely that status quo is a good enough place to be.

Javac compiler playing the bad cop (by harshly rejecting == and != involving at least one statically discernible value operand) as opposed to the JVM playing the good cop (by being gentle and forgiving of acmp attempts involving at least one value operand - evaluating to true/false) has a precedence in how instanceof works:

i.e:

boolean b = "hello" instanceof Integer; // rejected harshly by javac.

vs

boolean b2 = ((Object) "hello") instanceof Integer; // handled gently by vm by evaluating to false.

So, likely this ticket should be closed as won't fix with no change.