jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Java version check in jmeter script files - is it worth the maintenance effort?
Date Wed, 25 Feb 2015 02:03:28 GMT
On 24 February 2015 at 20:05, Felix Schumacher
<> wrote:
> 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.

In which case it would be better to just remove the option.

The -XX options should not be included in the default settings because
-XX is used for non-standard options.

> 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.

The problem is that the Java version determination is expensive, and
it looks like it is not needed now anyway.

> Regards
> Felix
>>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