[9] RFR(S) 8183401: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/NativeCallTest.java fails with The VM does not support the minimum JVMCI API version requ

[Vladimir Kozlov]

How about next comment?:

// Using Object.equals suppresses Eclipse's "Dead code" warning.
// Unfortunately the @SuppressWarnings("unused") can only be applied at 
the method level.

Thanks,
Vladimir

On 7/4/17 2:37 AM, Doug Simon wrote:
> 
>> On 4 Jul 2017, at 11:15, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>>
>>
>> On 2017-07-04 09:22, Doug Simon wrote:
>>>>> Nit: no need for Objects.equals() for int comparisons.
>>>> Doug, any reason why Objects.equals() is used?
>>> At periods of development, there was no JDK9 EA build compatible with Graal. During these periods we set JVMCI9_MIN_EA_BUILD to Integer.MAX_VALUE:
>>>
>>>      // MAX_VALUE indicates that no current EA version is compatible with Graal.
>>>      // Note: Keep README.md in sync with the EA version support checked here.
>>>      private static final int JVMCI9_MIN_EA_BUILD = 174;
>>>
>>> The code that tests JVMCI9_MIN_EA_BUILD against Integer.MAX_VALUE is effectively constant and Eclipse issues a "Dead code" warning for the "then" branch. Using Object.equals  suppresses this warning. To avoid the boxing, one could refactor the test to an intsEqual helper method.
>>>
>>> -Doug
>>>
>>
>> Ok, maybe could've used a @SuppressWarnings("unused") to satisfy Eclipse,
> 
> Unfortunately the @SuppressWarnings("unused") can only be applied at the method level which is coarser grained than I'd like.
> 
>> but either way it's a branch that we shouldn't ever take.
> 
> Yes, when running on a non-EA VM, we'll never go down this path.
> 
>> I was just curious about the why, since it seemed a bit off.
> 
> Sorry - I should have put a comment in the code originally as I also had to remind myself why I did it this way ;-)
> 
> -Doug
>