RFR (M) 8212959: Remove booleans from tests in vmTestbase

David Holmes david.holmes at oracle.com
Wed Jan 9 07:14:26 UTC 2019


On 9/01/2019 4:43 pm, JC Beyler wrote:
> Hi David,
> 
> I was not planning on doing it but we could. This change came from a 
> request to remove the booleans from tests for a prior webrev change. 
> I've seen previous conversations about wanting to test explicitly 
> against JNI_TRUE but thought this was a slightly different case.

The basic hotspot style rule is "avoid implicit booleans".

> Basically, from your comment, it seems I could go three ways for this 
> change:
>    1) Not do it and close the bug as won't fix :-)

Certainly the path of least resistance. :)

>    2) Go the extra step and change the various variables being tested to 
> bool
> 
> My preference is to do (2) as much as possible; any case that cannot be 
> put in a boolean form without having major changes to the code base, I'd 
> leave as is. And then call it a day for this subject.
> 
> What do you think (ie in cases where the variable can be set to a bool, 
> do it and then have the test be an implicit test)?

It's really up to you. It seems a lot of work and I don't know if you 
can actually push this all the way through without needing some 
int<->bool conversion somewhere anyway.

Cheers,
David

> Thanks!
> Jc
> 
> On Tue, Jan 8, 2019 at 10:31 PM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Jc,
> 
>     On 9/01/2019 4:12 pm, JC Beyler wrote:
>      > Hi all,
>      >
>      > Fixing up the tests in vmTestbase to not be testing explicitly
>     against
>      > NSK_TRUE/NSK_FALSE. Here is the webrev to do that:
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959
>      > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/
> 
>     Hold up! We don't do explicit tests when the variable is a bool/boolean
>     but when it is an int, as here, we do.
> 
>     Are you planning on converting everything to use bool?
> 
>     Cheers,
>     David
> 
>      > Thanks,
>      > Jc
> 
> 
> 
> -- 
> 
> Thanks,
> Jc


More information about the serviceability-dev mailing list