On 24 February 2015 at 20:05, Felix Schumacher <felix.schumac...@internetallee.de> wrote: > > > Am 24. Februar 2015 20:43:28 MEZ, schrieb Milamber <milam...@apache.org>: >>Hello, >> >>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 >>PermSize=64m; >>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" >>fi >> >>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 > >> >>Milamber >> >> >>On 23/02/2015 22:32, Philippe Mouawad wrote: >>> On Monday, February 23, 2015, sebb <seb...@gmail.com> wrote: >>> >>>> On 23 February 2015 at 19:57, Rainer Jung <rainer.j...@kippdata.de >>>> <javascript:;>> wrote: >>>>> Am 23.02.2015 um 19:36 schrieb sebb: >>>>>> The Java version check in JMeter script files is somewhat fragile, >>and >>>>>> 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 >>find >>>>> another problem with it? I suspect you ask, because there's always >>exotic >>>>> systems and writing portable shell scripts is a hard task and one >>can't >>>>> easily test them (because the platforms are not available). >>>> As I recall, the scripts have already had to be updated at least >>twice >>>> to fix bugs in the Java checks. >>>> >>>> The risk is that additional bugs still exist which may mean the >>script >>>> 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 >>that >>>> 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 >>awk >>>> 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 >>JMeter. >>>>> 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 >>info >>>> is >>>>> only on the download page and in the changelog. Maybe it could be >>added >>>> to >>>>> the "a 100% pure Java application" sentence in the landing page and >>in >>>> 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 >>used. >>>> >>>>> So I'm fine with either keeping or removing the check, but I think >>we >>>> should >>>>> place the requirement a little bit more prominent in the docs in >>any >>>> case. >>>> >>>> Agreed. >>> Same opinion >>> I think anyway that command line options where this could be added >>should >>> 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 >>>>> >>> >
