Thanks for pointing out those comments. It's good to have the discussion regardless of what the final outcome ends up being.
First of all, I don't disagree with your points. But I'd like to dig in a bit deeper. So:
Regarding #1: Are you aware of examples where this would be a problem? I can think of a couple of hypothetical ones, but I don't have any real evidence one way or the other. I don't recall any complaints about this on jmeter-user for the release (1.8?) where JMeter did require 1.4 -- I just remember several questions about what JDK level was required, since the error message you got when using an older JDK wasn't at all obvious.
One possible solution (not sure yet if it's practical, as I just thought of it): What if we allowed the Java Sampler to run in a separate JVM which had looser requirements. Perhaps this would mean running a "remote" JMeter engine on the same system as the main JVM and running the threads with that. Or maybe this could be supported by an even more generic sampler which starts up a process (a new JVM, a C program, whatever) with some parameters indicating the number of threads, etc., and let that process handle the data collection...perhaps dumping the results to a socket or a file or something. Obviously that would require some changes to the sampler infrastructure...but that's probably undergoing some changes anyway. Maybe these things are more trouble than they are worth -- right now I'm just trying to get an idea of exactly what the problem is so we can consider alternative solutions.
Or maybe that's more trouble then it's worth.
As you mentioned, perhaps consulting jmeter-user wouldn't be a bad idea.
Regarding #2: In the recent past, I don't think I've logged on to a system that doesn't have a 1.4 JDK. Six months from now, it should be even more universal. If we had to run on just any person's system I could see this as being a problem, but since JMeter is (presumably) being run mainly by Java developers, I would expect that a recent JDK should be available. Personally, I would be surprised to find less than 4 different JDKs on my system at any given time. (A quick count reveals at least 7 right now...perhaps a couple of duplicates, and there are probably a couple others that I forgot to count.) But maybe I'm not normal. :)
Jeremy
Jordi Salvat i Alabart wrote:
Hi Jeremy.
The points I made in http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterDevelopment/Requirements for supporting even 1.2 are still valid:
�
1/ the Java sampler runs the code being load-tested in the same JVM, and may require a specific JVM -- or may have similar portability requirements.
2/ *I* want it to be quickly installable on any system I work with, and being able to use whatever JVM is already available saves one installation step. OK, I'm too lazy -- I would agree to move all but 1.4.1 to a "should" requirement, if it were not for reason 1/
�
In other words: if we consider the Java sampler a relevant functionality (which we may want to drop since >95% of users of JMeter seem to be using it for HTTP testing) we should support any JDK we believe is still in use for products in active development. Maybe we should run a poll in JMeter-user?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
