jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Drop Java 6 support for the next release?
Date Thu, 20 Nov 2014 20:00:10 GMT
On 20 November 2014 08:04, Milamber <> wrote:
> On 16/11/2014 03:44, sebb wrote:
>> On 15 November 2014 22:24, Milamber <> wrote:
>>> On 15/11/2014 19:00, sebb wrote:
>>>> On 15 November 2014 18:27, Milamber <> wrote:
>>>>> Hello,
>>>>> I would open the discussion to remove the Java 6 support (End Of Life:
>>>>> Feb 2013) to JMeter for next release (in 2015 I think).
>>>>> I think, now, the Java 7 (or 8) is widespread on computer.
>>>>> For history:
>>>>> JMeter 2.9 (2013-01-28) drop the Java 1.5 support (EOL Oct 2009)
>>>>> JMeter 2.4 (2010-07-12) drop the Java 1.4 support (EOL Oct 2008)
>>>>> Note : Java 7 EOL is April 2015
>>>>> Have you some special objections to remove the Java 6 support to JMeter?
>>>> JMeter is an a stand-alone application, and so other Java code is not
>>>> generally dependent on it.
>>>> This means we have more freedom when deciding the minimum Java version.
>>>> If necessary, JMeter can be installed on a separate system with a more
>>>> recent version of Java.
>>>> I think the main constraint is whether or not the Java version is
>>>> readily available and stable on a wide variety of platforms.
>>>> Having said that, unless a newer version of Java offers significant
>>>> benefits, there is no point in forcing (some) users to upgrade Java.
>>>> So: what are the features of Java 7 and/or 8 that would improve JMeter?
>>> I'm not sure that is the good question.
>> It is the main question we should ask ourselves.
>>> Why Apache JMeter must support the EOL Java versions ? and (second
>>> question) why JMeter must work on a non-supported version of Java by
>>> editor ?
>> I'm not saying it must work on EOL versions of Java.
>> Remember that Java applications are upwards compatible, so we are not
>> stopping it from being used with Java 7,8,9 etc.
>> However, we should not arbitrarily require Java 7 just because Java 6 is EOL.
> Java 6 is EOL since Feb 2013, the next release of JMeter will probably
> release in the 1st or 2nd quarter 2015, so 2 years after the Java 6 EOL.
> That seems give a reasonable time to the users for update their machine
> with Java 7.
> We have already made an implicit (and arbitrary?) decision to keep the
> Java 6 support since the 6 EOL.
>>> For example, the bug 54477 is only fixed by using the Java 7 version. We
>>> can't fix this bug with Oracle (Sun) because the EOL arrived...
>> That is exactly the sort of information that I meant.
>>> I'm made a lot of load testing mission, and I have always the
>>> possibility to install the latest Java version. JMeter isn't a server
>>> process like httpd, the compliant with old version isn't mandatory for
>>> the run test, the load tester (person who make the load test or
>>> functional test) can always impose their requirements (i.e. Java version).
>>> If I follow your logical think, the question is: when the JMeter minimal
>>> Java version must be change? Why wait 4 years to upgrade to Java 5? or 2
>>> years to upgrade to Java 1.4? what is the criteria to upgrade the Java
>>> runtime at this time (2009 / 2008)?
>>> Please, give us the reasons to keep the reason to keep JMeter compliant
>>> with no-support of the Java version by the editor (and the security
>>> issues, bug issue with old version)?
>> I am not saying we have to keep JMeter compliant with Java 6.
>> However I am saying that we should not break compliance merely because
>> Java 6 is EOL.we mu
>> It looks like there are some good reasons for requiring Java 7.
> The EOL seems a good reason + a reasonable time to upgrade seems
> sufficient for me. Why we must have some technical or performance
> reasons only?

As I already wrote, IMO EOL alone is not a sufficient reason to change
the minimum supported Java level for any Java software.

A Java jar compiled with Java 1.5 will still work on Java 6,7,8,9 etc.
That is one of the fundamental aspects of Java - write once, run anywhere.

Just because Java 6 is EOL does not mean that all Java code needs to
be updated to require a minimum of Java 7.

However, if the Java code is being updated to fix bugs or add new
features, there may be valid technical reasons to drop support for
earlier versions of Java - whether these are EOL or not is somewhat
For example, Java 1.5 included major improvements to the Java Memory
model, and made it much easier and cheaper to implement thread safe
This was a compelling reason to update, even before Java 1.4 was EOL
(provided only that Java 1.5 was generally available).

Unless the changes to the code actually require the use of new
features that are only available in Java 7+, there is no need to drop
support for Java 6.
That would be an unnecessary and arbitrary restriction on where the
code can be deployed.

Yes, it might make development a bit more awkward at times, but there
are generally many more users of software than there are developers.
And users generally have far less control over the Java versions that
they can use, particularly in commercial environments, where upgrades
need to be exhaustively tested.
[There are still large numbers of WinXP systems in use commercially.]

Having said that, JMeter is a slightly special case, because it can
(and generally should) be run on its own host.
But that still does not mean we should require a minimum of Java 7 or
8 unless JMeter needs features that those newer versions provide.
We should not force (some) users to update their Java version without
good reason.

There is a recent example which may help explain what I am getting at.

The changes to the SSL recording - i.e. dynamic generation of
certificates - use keytool.
Unfortunately the version of keytool that is provided with Java 6 does
not have the required options to support this.
At this point, we could have required a minimum of Java 7 for all
users, regardless of whether they needed SSL recording or not.
The changes were coded such that JMeter still worked on Java 6, though
of course that specific feature did not work unless run under Java 7+.
As I recall, some extra testing was needed to show that JMeter worked
OK on both 6 and 7, but otherwise it was not difficult to continue to
support Java 6.

> For reference, on the Solr/Lucene project, a vote has been done to the
> upgrade

The thread includes two good reasons why Java 7 is of benefit to Lucene/Solr.
I don't think either of those apply to JMeter, but there may be other
features of Java 7 that are highly desirable for JMeter.

As I wrote earlier, I am not saying we should not move to Java 7, but
there need to be good reasons for doing so.

> Milamber
>> I'm not so sure that there are good reasons for requiring Java 8.
>>> Milamber
>>>>> Milamber
>>>>> [ Oracle Java SE Support Roadmap]
>> .

View raw message