@Param support for enum

[Joe Kearney]

Interesting point about ordering; I hadn't expected that you'd place any
guarantees on it. Do you know of any use cases which would be order
dependent? The analogy that comes to mind is unit tests, in which order
dependency is strongly discouraged.

In any case, the Comparable ordering for booleans would seem to be the
natural choice.

List<Boolean> bools = Arrays.asList(Boolean.FALSE, Boolean.TRUE);
Collections.sort(bools);
System.out.println(bools);

[false, true]

I imagine this would be easy to add in the same places as the
@Param-for-enums changes, generalising isEnum/getEnumConstants to something
like isAutoParam/getConstantNames.


On 23 June 2014 19:32, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 06/14/2014 11:27 PM, Martin Grajcar wrote:
> > On Sat, Jun 14, 2014 at 8:38 PM, Aleksey Shipilev
> > <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>>
> wrote:
> >
> >     (on vacation, asking briefly)
> >
> >     In JMH 0.9+, @Param(<enum>) already has the value set with all enum
> >     constants. Are you saying you want parameter-less @Param(<boolean>)
> >     to implicitly have ("false", "true") value set?
> >
> >
> > Thanks, I wasn't sure about the current state. And yes, @Param for
> > booleans working out of the box would be nice, too.
>
> On a second thought, this seems to introduce yet another special case in
> our @Param rules. The exception for enums is largely caused by the
> problem for converting the enum value set into String[]. Is the same
> problem present for booleans? E.g. does it really bother people to write
> this:
>
>  @Param({"true", "false"})
>  public boolean paramVal;
>
> ...instead of this?
>
>  @Param
>  public boolean paramVal;
>
> Note that the constant order is something we are after: it strictly
> defines the order in which the parameter values are explored, which may
> be useful for some users.
>
> Thanks,
> -Aleksey.
>