jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: Java8 for 3.1 ?
Date Mon, 12 Sep 2016 15:09:31 GMT
Felix>So it's still nearly one third of our potential users, that are using
java 7. That seems to be a good argument to support it, don't you think?

Felix, I'm afraid you are misreading the data Antonio provides.

Java upgrade for production systems is conservative since not all the
vendors/applications do _support_ Java 8.
For instance, if you have a Weblogic 9 application server, then you cannot
use Java 6 (!) just because:
1) It won't run
2) Vendor (Oracle) does not support that configuration, so if you have any
issues you would have to resolve them on your own

Basically the same thing applies to other software systems, so you cannot
"just use newer java at random".
You must ensure vendor does support that newer java for the particular
product version.

Well, let's come back to JMeter:
1) Nothing stops from using JMeter+Java8 to load test Weblogic 9+Java1.5
application. Even if someone is stuck with Java 1.5+Weblogic 9 in
production, it does not prevent from using Java 8 for JMeter.
2) Most of Java 7 installations have security issues, and I think it is
fair to say that almost noone is paying money for the java that is used for
JMeter. Once again, as we switch to "Java 8 only", we'll eliminate attack
vector from our users' machines (they'll no longer would require to have
java 7 installed).
3) I think most of the development / testing is performed via Java 8, so it
is even hard to predict if JMeter would work at all with Java 7.

To sum up "more than a half of production systems run on top of Java 8",
and JMeter is lagging behind.
That is weird taking into the account that JMeter is a standalone tool.

Felix>It would take no effort, but that was not the point.

As far as I can see, "java 8 only" requires documentation/wiki update, and
an update to build script, so it creates source 1.8, target 1.8 bytecode.


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