As per dev mailing list thread which could have been reused for this: - http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3ccaogo0vb1ffpuipcc0flqhfn2oyhvtss2r90ntgm7gqsh2m_...@mail.gmail.com%3E
+1 for me. Among additional reasons to what has been exposed: 1/ There is a new method in Java 7 that is interesting for performances ( http://download.java.net/jdk7/archive/b123/docs/api/java/net/InetSocketAddress.html#getHostString%28%29) instead of getHostName() which makes a reverse lookup, see http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201302.mbox/%3C1360057832.23610.6.camel@ubuntu%3E. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54449 And I noticed sometimes this method could slowdown JMeter startup in certain network conditions, until the reverse lookup timeouts 2/ Better String implementation (We need to take care) => http://java-performance.info/changes-to-string-java-1-7-0_06/ 3/ We have a copy of Doug Lea's class for Random that is in JDK7 4/ We can expect our dependencies to drop JDK6 support in near future 5/ Better NIO support in recent JDK versions which we could use in some features discussed in RoadMap thread Regards @philmdot On Mon, Jun 1, 2015 at 3:17 PM, Andrey Pokhilko <[email protected]> wrote: > +100500 > > Andrey Pokhilko > > On 06/01/2015 04:14 PM, sebb wrote: > > I think we should require a minimum of Java 7 for the next JMeter > release. > > (It currently requires 1.6) > > > > This is because: > > - Java 7 supports proper certificate generation for the HTTP recorder. > > It will probably allow some code simplification. > > - the Javadoc vulnerability CVE-2013-1571 has been fixed since Java 7 > > update 25 (June 2013). We could drop the patch. > > - any others? > > > > Of course Java 7 is just about EOL, but I've not yet seen any > > compelling reasons to require a minimum of Java 8. If there are such > > reasons (other than Java 7 is EOL) please raise them here. > > > > A very minor consideration is that Javadoc 7 seems to have been fixed > > to generate lower-case HTML tags - e.g. <table> rather than <TABLE>. I > > assume that will remain the case. So there will be a once-off SVN > > difference when older API docs are replaced with new ones. > >
