You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by sebb <se...@gmail.com> on 2015/06/01 15:14:11 UTC
Update to minimum Java 7
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.
Re: Update to minimum Java 7
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 1. Juni 2015 15:14:11 MESZ, schrieb sebb <se...@gmail.com>:
>I think we should require a minimum of Java 7 for the next JMeter
>release.
>(It currently requires 1.6)
+1
>
>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?
- We can drop the thread local random class.
- A few compile warnings in respect to generics can be fixed.
Regards
Felix
>
>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.
Re: Update to minimum Java 7
Posted by sebb <se...@gmail.com>.
Created a Bugzilla to track trhe changes:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57981
On 1 June 2015 at 14:54, Rainer Jung <ra...@kippdata.de> wrote:
> Am 01.06.2015 um 15:39 schrieb Philippe Mouawad:
>>
>> 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_-+Q@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 <ap...@ya.ru> 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.
>
>
> +1: lots of good reasons listed. Only very few users should have problems to
> get Java 7 to their test environments. Mostly some not-well maintained
> enterprise desktops. And I also think for Java 8 it is a bit to early
> (despite Java 7 being EOL quite a few users might have a problem getting
> Java 8 into their environment if it is centrally but not well managed).
>
> Regards,
>
> Rainer
Re: Update to minimum Java 7
Posted by Rainer Jung <ra...@kippdata.de>.
Am 01.06.2015 um 15:39 schrieb Philippe Mouawad:
> 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_-+Q@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 <ap...@ya.ru> 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.
+1: lots of good reasons listed. Only very few users should have
problems to get Java 7 to their test environments. Mostly some not-well
maintained enterprise desktops. And I also think for Java 8 it is a bit
to early (despite Java 7 being EOL quite a few users might have a
problem getting Java 8 into their environment if it is centrally but not
well managed).
Regards,
Rainer
Re: Update to minimum Java 7
Posted by Philippe Mouawad <ph...@gmail.com>.
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_-+Q@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 <ap...@ya.ru> 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.
>
>
Re: Update to minimum Java 7
Posted by Andrey Pokhilko <ap...@ya.ru>.
+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.
Re: Update to minimum Java 7
Posted by Milamber <mi...@apache.org>.
On 01/06/2015 14:14, sebb wrote:
> I think we should require a minimum of Java 7 for the next JMeter release.
Agree.
> (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?
* "fix" this known issue on JMeter:
"With Java 1.6 and Gnome 3 on Linux systems, the JMeter menu may
not work correctly (shift between mouse's click and the menu). This is a
known Java bug (see Bug 54477). A workaround is to use a Java 7 runtime
(OpenJDK or Oracle JDK). "
Milamber
>
> 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.
> .
>