On 16/11/2014 03:44, sebb wrote: > On 15 November 2014 22:24, Milamber <[email protected]> wrote: >> On 15/11/2014 19:00, sebb wrote: >>> On 15 November 2014 18:27, Milamber <[email protected]> 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? For reference, on the Solr/Lucene project, a vote has been done to the upgrade http://www.gossamer-threads.com/lists/lucene/general/225300 Milamber > > I'm not so sure that there are good reasons for requiring Java 8. > >> Milamber >> >> >> >> >> >>>> Milamber >>>> >>>> >>>> [ Oracle Java SE Support Roadmap] >>>> http://www.oracle.com/technetwork/java/eol-135779.html >>>> > . >
