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