jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: Timer adjustment feature / Bug 60018 (was Thoughts on 2 proposals)
Date Sat, 03 Sep 2016 09:23:03 GMT
On Sat, Sep 3, 2016 at 11:12 AM, Vladimir Sitnikov <> wrote:

> Philippe>Could we consider introducing Java 8 in immediate next version for
> this feature ?
> As you know, I'm all ears for migrating to Java 8.
> I'm pretty sure this particular issue of "adding behavior to timers without
> breaking compatibility with previous third-party timers" could be solved
> with plain Java 7.

Well since there was no abstract class, I don't see.
We could reserve this behaviour to RandomTimer subclasses, this way we
wouldn't break backward compatibility.
Constant Timer would not be affected, that may be ok , as I suppose
constant is intended so maybe it should not be affected
As for The scriptable Timers (BSF, JSR223 and Beanshell) , we could leave
them as is, or introduce a helper method in JMeterUtils.

Do you have other ideas ?

I just highlight one of the cases where Java 8 shines, so the "backward
> compatibility dance" is much simpler there.
> Philippe>What are the risks of moving to Java8(without immediately using
> all the
> Philippe>syntactic sugar ) ?
> Technically speaking, we might want to make a poll on jmeter-users list.
> For instance, certain platforms might miss Java 8 runtime. I've no idea if
> there are lots of platforms that miss Java 8 and run JMeter at the same
> time.
Frankly I doubt it. At least the platforms usually used for Load Testing
don't have the same constraints as those running J2EE Server can have.

PS : Any chance that you submit your Constant Throughput timer alternative
patch ?

> Vladimir

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message