Maven integration

[Julien Nicoulaud]

2013/5/6 Julien Nicoulaud <julien.nicoulaud at gmail.com>

>
>
>
> 2013/5/6 Aleksey Shipilev <aleksey.shipilev at oracle.com>
>
>> On 05/04/2013 03:22 PM, Julien Nicoulaud wrote:
>> > First of all thanks for this great tool, this is a real game changer.
>>
>> Thanks for the feedback!
>>
>> > I started working on a Maven plugin for JMH, but a few things complicate
>> > JMH embedding:
>>
>> Good, although I would puritanically back off letting people to run
>> performance benchmarks in the course of the build.
>>
> Yes, I understand your point, but on other hand microbenchmarks are closer
> to "performance unit tests" than real performance tests, so I think there
> is a use case for this. I'm pretty sure people will want to do this :)
>
>
>> >    - Arguments parsing: it would be great if there was a version
>> >    of HarnessOptions with setters
>>
>> Note of warning: you will rely on the internal APIs, which are not
>> guaranteed to stay the same. We are actually contemplating the proper
>> Java API to get access JMH without messing with the command line
>> options.
>>
>> But meanwhile, assuming you are using the new Runner(harnessOptions) as
>> your entry point, I had changed the *Option fields to "protected", so
>> you have the opportunity to subclass them and access the plain fields.
>> This makes things relatively isolated without exposing the setters.
>>
> OK, great, thanks.
>
One last thing: can you also set the constructor protected ?


>
>> >    - Classloading: JMH's ClassUtils.loadClass() manually builds an
>> >    URLClassLoader, which breaks classloader inheritance, but I don't
>> know if
>> >    there is a better option.
>>
>> Yes, that allows us additional degree of isolation for the
>> microbenchmarks. But then again, this isolation is not perfect, and we
>> must instead rely on forking to segregate the microbenchmark effects.
>> Hence, I pushed away from that and jmh instead does the plain class
>> loading (with the option to revert back to separate classloader).
>>
> Thanks, I will study the best option in case microbenchmarks run in
> non-fork mode.
>
>>
>> -Aleksey.
>>
>> P.S. Please consider filling out the OCA on the chance you would like to
>> push the patches to JMH at some point:
>>  http://openjdk.java.net/contribute/
>>
>
>