You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Jeremy Arnold <je...@bigfoot.com> on 2003/08/14 23:20:27 UTC
Should JMeter 2.0 require JDK 1.4?
Hello,
A couple months ago we discussed the JDK requirements for JMeter,
because some new code came in with dependencies on 1.4. At the time I
pushed to continue supporting 1.3, largely because these dependencies
were relatively easy to work around and requiring 1.4 did not give us a
huge benefit.
Now that we are setting out on a batch of new features for JMeter
2.0, perhaps it is time to consider this issue again. I believe it may
be worthwhile to require 1.4 with this version of JMeter. 1.4 is well
supported, and by the time JMeter 2.0 actually gets released it will be
even more commonplace. And of course, since JMeter is an application
rather than a library, we don't have to be as conservative as most of
the other Jakarta projects.
I'm aware of three areas in the current JMeter code where we have
changed the implementation specifically to support older JDKs:
1) The date input for the scheduler support (the GUI originally used a
JSpinner but we changed it to multiple text fields)
2) I think there was a slightly more elegant method of getting caller
class information for the Loggers when using 1.4 which we can't use in 1.3
3) There was some minor GUI tweak (on the main frame I think) related to
setting the ratio between two areas of a split pane or something. This
is commented out since the method isn't supported until 1.4.
As before, none of these items are big enough to warrant the
switch. But since we're adding new features, we could also take
advantage of some of these:
1) Use the java.util.prefs API for storing user preferences (probably
wouldn't replace jmeter.properties, but could be used for some GUI
preferences and things)
2) Use the java.nio API for efficient IO to disk -- perhaps we could
write results out to a memory mapped file or something as the run is
still going...this might offer better performance for long runs.
3) Use the Image I/O Framework to save results graphs
4) Use Swing JFormattedTextFields to improve input validation
There are probably other minor things as well.
Anyway, I'm obviously in support of requiring 1.4. If there are any
objections, now would be the best time to voice them -- otherwise, let's
feel free to start taking advantage of whatever 1.4 offers.
Jeremy
http://xirr.com/~jeremy_a
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Should JMeter 2.0 require JDK 1.4?
Posted by ms...@apache.org.
Ya, same way regex patterns are cached,
JMeter is way cool!
On 27 Aug 2003 at 18:26, Jordi Salvat i Alabart wrote:
>
>
> mstover1@apache.org wrote:
> > B)we're caching the results
>
> Are we? JMeter rocks, does it?
>
> :-)
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
mstover1@apache.org wrote:
> B)we're caching the results
Are we? JMeter rocks, does it?
:-)
--
Salut,
Jordi.
Re: Should JMeter 2.0 require JDK 1.4?
Posted by ms...@apache.org.
Which reminds me of another 1.4 advantage: URLEncode supports
different character encodings. The slowness should be alleviated
by the fact that A) we only encode parameters that need it and
B)we're caching the results, so URLEncode.encode() is only being
called the first time through the test.
-Mike
On 27 Aug 2003 at 10:35, Jordi Salvat i Alabart wrote:
> May I list an inconvenience?
>
> URL.encode, which we use heavily, is significantly slower -- see
bug
>
http://developer.java.sun.com/developer/bugParade/bugs/4725737.
html for
> details.
>
> My test (100 threds) runs in:
> 1.3.1: 7.8 s
> 1.4.0: 102.0 s
> 1.4.1: 92.1 s
> 1.4.2: 37.9 s
>
> ... we may need to write our own until this is resolved.
>
> Anyway, you've made me change my mind. +1 to drop 1.3
support.
> Rationale: at the current project stage, making the life of JMeter
> developers easy is a priority.
>
> Salut,
>
> Jordi.
>
> mstover1@apache.org wrote:
> > I think we need to list the advantages to moving to JDK 1.4. As
I see it, they are:
> >
> > 1. Potential for higher IO performance (use nio)
> > 2. Potential for better memory management (using memory
mapped files could alleviate
> > some memory problems)
> > 3. Faster regular expressions: Sun's regex implementation is
entirely faster than Oro's. This,
> > however, is a very minor point.
> > 4. Ends the need to support SSL with jdk1.3 with separate
JSSE libs
> > 5. New GUI components can be used freely (ie date switcher or
whatever it was)
> >
> > Please feel free to add to the list.
> >
> > Another possibility has to do with playing with code versions.
Two possibilities:
> > 1. Split off a JDK1.3 branch in cvs that supports JDK1.3 (I can't
imagine this working)
> > 2. Make releases only of ApacheJMeter_java.jar that people
can use to upgrade v1.9.x (ie,
> > they keep the 1.9.x core, but upgrade the Java Sampler jar
whose code remains compatible
> > with JDK1.3). The rest of JMeter is free to use JDK1.4 only
features.
> >
> > Regarding #2, there is already a 1.9 branch in CVS. If a new
feature in the Java Sampler
> > code necessitates an upgrade of the core, those changes can
always be made in that branch
> > and a new 1.9.x release made. In this way, we might all get
what we want (Well, except it
> > really doesn't solve the Jordi-laziness factor ;-) heh, relax, I'm
way lazier than you).
> >
> > -Mike
> >
> > On 26 Aug 2003 at 0:48, Jordi Salvat i Alabart wrote:
> >
> >
> >>
> >>Jeremy Arnold wrote:
> >>
> >>
> >>>Regarding #1: [...]
> >>>
> >>>Or maybe that's more trouble then it's worth.
> >>
> >>I guess so :-)
> >>
> >>
> >>>As you mentioned, perhaps consulting jmeter-user wouldn't
be a bad idea.
> >>
> >>I will, now.
> >>
> >>
> >>>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.
> >>
> >>I have. Actually, I seldom log into a system which does have it
> >>installed. That's probably because the ATG's products
currently require 1.3.
> >>
> >>
> >>> [...] 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.
> >>
> >>*I*, for one, need to run it on customer's systems. They all
have 1.3
> >>installed (since they need it to run our products), but installing
1.4
> >>would be one extra step -- not a long one, but still...
> >>
> >>Anyway, I agree that my lazyness is not an argument, so let's
stick to
> >>whatever issue #1 recommends.
> >>
> >>--
> >>Salut,
> >>
> >>Jordi.
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
> >>
> >
> >
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
> >
> >
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jeremy Arnold <je...@bigfoot.com>.
mstover1@apache.org wrote:
>Peter, Sebastian, and Elan all got their accounts.
>
>
Great. Welcome guys! (Sorry for not noticing earlier.)
>Regarding the 100 column line, I think most people are apathetic.
>What that means we should decide? I'm not sure :-) And, I wrote
>that bit about disallowing code formatting except at designated
>times so as to avoid conflicts as much as possible.
>
>
I think the lack of interest would usually mean to stick with the status
quo -- 80 columns. Even though I gave it my +1, I keep going back and
forth in my head about it anyway...80 column source code is the standard
for the majority of projects, and while it's sometimes a bit annoying,
it does seem to work reasonably well. So perhaps its best to leave it
alone for now -- if it's annoying enough to change then the topic will
come up again.
Jeremy
Re: Should JMeter 2.0 require JDK 1.4?
Posted by ms...@apache.org.
Peter, Sebastian, and Elan all got their accounts.
Regarding the 100 column line, I think most people are apathetic.
What that means we should decide? I'm not sure :-) And, I wrote
that bit about disallowing code formatting except at designated
times so as to avoid conflicts as much as possible.
-Mike
On 27 Aug 2003 at 22:13, Jeremy Arnold wrote:
> Hello,
>
> Jordi Salvat i Alabart wrote:
>
> > Anyway, you've made me change my mind. +1 to drop 1.3
support.
> > Rationale: at the current project stage, making the life of
JMeter
> > developers easy is a priority.
>
> And you were doing such a good job of making me reconsider the
idea.
> :) But I still think the move makes sense.
>
> Comments/votes from anybody else? I'm not familiar enough
with the
> JMeter/Jakarta/Apache guidelines to know off the top of my head
whether
> an official vote is required for this decision, but it looks like we
> have support from me, Jordi, and Mike.
>
> Speaking of votes, things have been pretty quiet on the 100
> characters/line topic...looks like the vote will fail to pass if we
> don't hear from other committers soon.
>
> Did we finalize the vote on the new committers? Now that I've
read
> Peter Lin's code (in the process of reformatting it), I'll change my
> vote from +0 to +1 -- I was especially impressed by the code
comments
> which acknowledged some areas still in need of work...it's much
better
> to point them out than to pretend they don't exist.
>
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-
unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-
help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jeremy Arnold <je...@bigfoot.com>.
Hello,
Jordi Salvat i Alabart wrote:
> Anyway, you've made me change my mind. +1 to drop 1.3 support.
> Rationale: at the current project stage, making the life of JMeter
> developers easy is a priority.
And you were doing such a good job of making me reconsider the idea.
:) But I still think the move makes sense.
Comments/votes from anybody else? I'm not familiar enough with the
JMeter/Jakarta/Apache guidelines to know off the top of my head whether
an official vote is required for this decision, but it looks like we
have support from me, Jordi, and Mike.
Speaking of votes, things have been pretty quiet on the 100
characters/line topic...looks like the vote will fail to pass if we
don't hear from other committers soon.
Did we finalize the vote on the new committers? Now that I've read
Peter Lin's code (in the process of reformatting it), I'll change my
vote from +0 to +1 -- I was especially impressed by the code comments
which acknowledged some areas still in need of work...it's much better
to point them out than to pretend they don't exist.
Jeremy
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
May I list an inconvenience?
URL.encode, which we use heavily, is significantly slower -- see bug
http://developer.java.sun.com/developer/bugParade/bugs/4725737.html for
details.
My test (100 threds) runs in:
1.3.1: 7.8 s
1.4.0: 102.0 s
1.4.1: 92.1 s
1.4.2: 37.9 s
... we may need to write our own until this is resolved.
Anyway, you've made me change my mind. +1 to drop 1.3 support.
Rationale: at the current project stage, making the life of JMeter
developers easy is a priority.
Salut,
Jordi.
mstover1@apache.org wrote:
> I think we need to list the advantages to moving to JDK 1.4. As I see it, they are:
>
> 1. Potential for higher IO performance (use nio)
> 2. Potential for better memory management (using memory mapped files could alleviate
> some memory problems)
> 3. Faster regular expressions: Sun's regex implementation is entirely faster than Oro's. This,
> however, is a very minor point.
> 4. Ends the need to support SSL with jdk1.3 with separate JSSE libs
> 5. New GUI components can be used freely (ie date switcher or whatever it was)
>
> Please feel free to add to the list.
>
> Another possibility has to do with playing with code versions. Two possibilities:
> 1. Split off a JDK1.3 branch in cvs that supports JDK1.3 (I can't imagine this working)
> 2. Make releases only of ApacheJMeter_java.jar that people can use to upgrade v1.9.x (ie,
> they keep the 1.9.x core, but upgrade the Java Sampler jar whose code remains compatible
> with JDK1.3). The rest of JMeter is free to use JDK1.4 only features.
>
> Regarding #2, there is already a 1.9 branch in CVS. If a new feature in the Java Sampler
> code necessitates an upgrade of the core, those changes can always be made in that branch
> and a new 1.9.x release made. In this way, we might all get what we want (Well, except it
> really doesn't solve the Jordi-laziness factor ;-) heh, relax, I'm way lazier than you).
>
> -Mike
>
> On 26 Aug 2003 at 0:48, Jordi Salvat i Alabart wrote:
>
>
>>
>>Jeremy Arnold wrote:
>>
>>
>>>Regarding #1: [...]
>>>
>>>Or maybe that's more trouble then it's worth.
>>
>>I guess so :-)
>>
>>
>>>As you mentioned, perhaps consulting jmeter-user wouldn't be a bad idea.
>>
>>I will, now.
>>
>>
>>>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.
>>
>>I have. Actually, I seldom log into a system which does have it
>>installed. That's probably because the ATG's products currently require 1.3.
>>
>>
>>> [...] 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.
>>
>>*I*, for one, need to run it on customer's systems. They all have 1.3
>>installed (since they need it to run our products), but installing 1.4
>>would be one extra step -- not a long one, but still...
>>
>>Anyway, I agree that my lazyness is not an argument, so let's stick to
>>whatever issue #1 recommends.
>>
>>--
>>Salut,
>>
>>Jordi.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>
>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
--
Salut,
Jordi.
Re: Should JMeter 2.0 require JDK 1.4?
Posted by ms...@apache.org.
I think we need to list the advantages to moving to JDK 1.4. As I see it, they are:
1. Potential for higher IO performance (use nio)
2. Potential for better memory management (using memory mapped files could alleviate
some memory problems)
3. Faster regular expressions: Sun's regex implementation is entirely faster than Oro's. This,
however, is a very minor point.
4. Ends the need to support SSL with jdk1.3 with separate JSSE libs
5. New GUI components can be used freely (ie date switcher or whatever it was)
Please feel free to add to the list.
Another possibility has to do with playing with code versions. Two possibilities:
1. Split off a JDK1.3 branch in cvs that supports JDK1.3 (I can't imagine this working)
2. Make releases only of ApacheJMeter_java.jar that people can use to upgrade v1.9.x (ie,
they keep the 1.9.x core, but upgrade the Java Sampler jar whose code remains compatible
with JDK1.3). The rest of JMeter is free to use JDK1.4 only features.
Regarding #2, there is already a 1.9 branch in CVS. If a new feature in the Java Sampler
code necessitates an upgrade of the core, those changes can always be made in that branch
and a new 1.9.x release made. In this way, we might all get what we want (Well, except it
really doesn't solve the Jordi-laziness factor ;-) heh, relax, I'm way lazier than you).
-Mike
On 26 Aug 2003 at 0:48, Jordi Salvat i Alabart wrote:
>
>
> Jeremy Arnold wrote:
>
> > Regarding #1: [...]
> >
> > Or maybe that's more trouble then it's worth.
>
> I guess so :-)
>
> > As you mentioned, perhaps consulting jmeter-user wouldn't be a bad idea.
>
> I will, now.
>
> > 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.
>
> I have. Actually, I seldom log into a system which does have it
> installed. That's probably because the ATG's products currently require 1.3.
>
> > [...] 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.
>
> *I*, for one, need to run it on customer's systems. They all have 1.3
> installed (since they need it to run our products), but installing 1.4
> would be one extra step -- not a long one, but still...
>
> Anyway, I agree that my lazyness is not an argument, so let's stick to
> whatever issue #1 recommends.
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
Jeremy Arnold wrote:
> Regarding #1: [...]
>
> Or maybe that's more trouble then it's worth.
I guess so :-)
> As you mentioned, perhaps consulting jmeter-user wouldn't be a bad idea.
I will, now.
> 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.
I have. Actually, I seldom log into a system which does have it
installed. That's probably because the ATG's products currently require 1.3.
> [...] 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.
*I*, for one, need to run it on customer's systems. They all have 1.3
installed (since they need it to run our products), but installing 1.4
would be one extra step -- not a long one, but still...
Anyway, I agree that my lazyness is not an argument, so let's stick to
whatever issue #1 recommends.
--
Salut,
Jordi.
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jeremy Arnold <je...@bigfoot.com>.
Jordi,
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?
>
Re: Should JMeter 2.0 require JDK 1.4?
Posted by Jordi Salvat i Alabart <js...@atg.com>.
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?
--
Salut,
Jordi.
Jeremy Arnold wrote:
> Hello,
> A couple months ago we discussed the JDK requirements for JMeter,
> because some new code came in with dependencies on 1.4. At the time I
> pushed to continue supporting 1.3, largely because these dependencies
> were relatively easy to work around and requiring 1.4 did not give us a
> huge benefit.
>
> Now that we are setting out on a batch of new features for JMeter
> 2.0, perhaps it is time to consider this issue again. I believe it may
> be worthwhile to require 1.4 with this version of JMeter. 1.4 is well
> supported, and by the time JMeter 2.0 actually gets released it will be
> even more commonplace. And of course, since JMeter is an application
> rather than a library, we don't have to be as conservative as most of
> the other Jakarta projects.
>
> I'm aware of three areas in the current JMeter code where we have
> changed the implementation specifically to support older JDKs:
> 1) The date input for the scheduler support (the GUI originally used a
> JSpinner but we changed it to multiple text fields)
> 2) I think there was a slightly more elegant method of getting caller
> class information for the Loggers when using 1.4 which we can't use in 1.3
> 3) There was some minor GUI tweak (on the main frame I think) related to
> setting the ratio between two areas of a split pane or something. This
> is commented out since the method isn't supported until 1.4.
>
> As before, none of these items are big enough to warrant the switch.
> But since we're adding new features, we could also take advantage of
> some of these:
>
> 1) Use the java.util.prefs API for storing user preferences (probably
> wouldn't replace jmeter.properties, but could be used for some GUI
> preferences and things)
> 2) Use the java.nio API for efficient IO to disk -- perhaps we could
> write results out to a memory mapped file or something as the run is
> still going...this might offer better performance for long runs.
> 3) Use the Image I/O Framework to save results graphs
> 4) Use Swing JFormattedTextFields to improve input validation
>
> There are probably other minor things as well.
>
> Anyway, I'm obviously in support of requiring 1.4. If there are any
> objections, now would be the best time to voice them -- otherwise, let's
> feel free to start taking advantage of whatever 1.4 offers.
>
> Jeremy
> http://xirr.com/~jeremy_a
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
--
Salut,
Jordi.