jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
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 <
sitnikov.vladimir@gmail.com> 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
>



-- 
Cordialement.
Philippe Mouawad.

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