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. Vladimir
