jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <>
Subject Re: Java version check in jmeter script files - is it worth the maintenance effort?
Date Tue, 24 Feb 2015 20:05:21 GMT

Am 24. Februar 2015 20:43:28 MEZ, schrieb Milamber <>:
>Please note, the mean reason to add the Java version check is to avoid
>the Java 8 warning message:
>Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>support was removed in 8.0
>Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
>MaxPermSize=128m; support was removed in 8.0
>Below the code for checking in bin/jmeter:
># Java 8 remove Permanent generation, don't settings the PermSize
>if [ $current_version -lt "8" ]; then
>    # Increase MaxPermSize if you use a lot of Javascript in your Test
>Plan :
>    PERM="-XX:PermSize=64m -XX:MaxPermSize=128m"
>We can remove the Java version check, but the users with Java 8 will
>have the warning message.
>Or remove the permanent size config?

I believe IBMs java would not even start with the perm size option.

And since java 7 will reach its end of live soon (at least the public support from Oracle)
we should consider what to do next with the perm size option. 

I think it would be nice to factor out all memory related options into one variable, that
can be overridden easily by the user. 

On the original question of whether we should keep the logic to determine the java version:
let us keep it, if no one else complains. 


>On 23/02/2015 22:32, Philippe Mouawad wrote:
>> On Monday, February 23, 2015, sebb <> wrote:
>>> On 23 February 2015 at 19:57, Rainer Jung <
>>> <javascript:;>> wrote:
>>>> Am 23.02.2015 um 19:36 schrieb sebb:
>>>>> The Java version check in JMeter script files is somewhat fragile,
>>>>> has to be maintained.
>>>>> Does it really provide enough benefit to keep it?
>>>> IMHO currently there's no real necessity to remove it, or did you
>>>> another problem with it? I suspect you ask, because there's always
>>>> systems and writing portable shell scripts is a hard task and one
>>>> easily test them (because the platforms are not available).
>>> As I recall, the scripts have already had to be updated at least
>>> to fix bugs in the Java checks.
>>> The risk is that additional bugs still exist which may mean the
>>> won't work on some other platform.
>>> Apart from the additional work needed, in the meantime the user may
>>> not be able to use JMeter.
>>> It seems unnecessary effort to maintain a feature of the scripts
>>> is not required for proper operation of JMeter.
>>> As far as I can tell, the only benefit is that users who don't have
>>> the correct Java version on the path will get a nicer error message.
>>> However every time the script is used, there are 4 invocations of
>>> and one of "java -version".
>>> This is rather wasteful.
>> No opinion on this.
>> Seems to me that there are better ways to spend our time maintaining
>>>> Since our requirements are very relaxed (Java 6), there's no big
>use in
>>> the
>>>> version check either. In most cases the condition will be
>fulfilled, so a
>>>> clear documentation statement should suffice. I think currently the
>>> is
>>>> only on the download page and in the changelog. Maybe it could be
>>> to
>>>> the "a 100% pure Java application" sentence in the landing page and
>>> the
>>>> intro page of the users manual without bloating that pages to much.
>>> Yes, that is a much better use of developer time.
>>> Could also document the errors that are produced if the wrong JVM is
>>>> So I'm fine with either keeping or removing the check, but I think
>>> should
>>>> place the requirement a little bit more prominent in the docs in
>>> case.
>>> Agreed.
>> Same opinion
>> I think anyway that command line options where this could be added
>> be isolated in a dedicated page.
>> I always find myself searching for those.
>> New users should find easily:
>> - tool pre requisites
>> - command line options
>>>> Regards,
>>>> Rainer

View raw message