On Sat, Sep 3, 2016 at 11:12 AM, Vladimir Sitnikov < sitnikov.vladi...@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.
