RFR: Options rework

Sergey Kuksenko sergey.kuksenko at oracle.com
Wed Aug 28 02:49:16 PDT 2013


Reviewed!
Accepted the changeset.

Minor comments are below (related to the mail, not to the changeset).
On 08/27/2013 07:06 PM, Aleksey Shipilev wrote:
> Hi,
> 
> This is one of many changes towards the JMH API. This time, we revisit
> our Options. At this point, we have very strong ties to arg4j to parse
I strongly vote for killing arg4j dependency in the future (hard to
maintain).

> the command line options. We also have two separate option versions, one
> accepted by the host (harness) VM, and the second one by the forked VMs.
> We translate the former to later for the forked runs, and that costs us
> lots of scaffolding.
> 
> All this complicates the code significantly: making custom Options is
> the error-prone and messy endeavor.
> 
> The cleanup is in this webrev:
>   http://cr.openjdk.java.net/~shade/jmh/options-rework-1.webrev/
> 
> High-level view:
>  - extracted Options interface; JMH core is now oblivious of the exact
> Options implementation
>  - forked VM uses the binary link (already established for pulling the
> data back from the forked VM) to pull the options from the host VM;
> forked VM does not use any complex argument parsing anymore
that is cool.

>  - various API touchups
>  - sample API demo to demonstrate the OptionsBuilder
> 
> The normal use should not be affected, the changes are mostly
> undercover. Please review!
> 
> Thanks,
> -Aleksey.
> 


-- 
Best regards,
Sergey Kuksenko


More information about the jmh-dev mailing list