@Param support for enum
Aleksey Shipilev
aleksey.shipilev at oracle.com
Wed Jun 25 13:24:40 UTC 2014
On 06/24/2014 02:35 PM, Joe Kearney wrote:
> 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.
Yes, from the performance standpoint, the runs with different parameters
values are distinct in either case. But, humans expect the parameter
space to be traversed in a particular order for better presentation.
There are basically two things to consider:
a) Users normally expect natural ordering for parameter values. But in
our case, since @Param values in the Java code are Strings, and they are
coerced into the target field type automatically, the natural ordering
is different (e.g. lexicographical vs integer).
b) Users sometimes need the special ordering inconsistent with natural
ordering, to make default text report look good. This is mostly for
String parameters. (Note that in enum parameters, you can rearrange the
constants to set the natural order you like).
Merging these two requirements yield the compromise: maintain the
declared order of parameter values, and let users either put the default
values in their natural order, or make their own. JMH will maintain the
declaration order to make this work.
It was allured in Javadoc:
/**
* Default values for the parameter.
* @return values ***sequence*** to follow.
*/
String[] value() default { BLANK_ARGS };
Updated Javadoc a bit:
http://hg.openjdk.java.net/code-tools/jmh/rev/7ee95e9cf56c
> In any case, the Comparable ordering for booleans would seem to be the
> natural choice.
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.
I am still not convinced we have to make implicit @Param-s for booleans,
as we did with enums. What's the rationale for introducing this exception?
-Aleksey.
More information about the jmh-dev
mailing list