You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Trenton D. Adams" <tr...@telusplanet.net> on 2002/06/05 22:43:51 UTC

Improper timing using Calendar class (JSP/servlet)

I'm kind of curious.  I've been trying to do some simple performance
timing with the Calendar class as shown below.  The startTime and
endTime end up being the same value.  How can this be?  There should be
at the very least a ms or two difference between them, shouldn't there?
The same thing happens in JSP pages as it does in servlet pages.  In
fact, in a servlet, I tried doing a Thread.Sleep (10000), and the
startTime and endTime were still the same.  Is this a bug in tomcat?



<%! long startTime = Calendar.getInstance ().getTimeInMillis();%>

Do some HTML output.

<%! long endTime = Calendar.getInstance ().getTimeInMillis();%>
Start Time:&nbsp <%= startTime %><BR>
End Time:&nbsp <%= endTime%><BR>
<%= endTime - startTime %><BR>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by James Williamson <ja...@nameonthe.net>.
>
> >
> > -----Original Message-----
> > From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net]
> > Sent: June 5, 2002 2:44 PM
> > To: 'Tomcat Users List'
> > Subject: Improper timing using Calendar class (JSP/servlet)
> >
> >
> > I'm kind of curious.  I've been trying to do some simple performance
> > timing with the Calendar class as shown below.  The startTime and
> > endTime end up being the same value.  How can this be?  There should be
> > at the very least a ms or two difference between them, shouldn't there?
> > The same thing happens in JSP pages as it does in servlet pages.  In
> > fact, in a servlet, I tried doing a Thread.Sleep (10000), and the
> > startTime and endTime were still the same.  Is this a bug in tomcat?
> >
> >
> >
> > <%! long startTime = Calendar.getInstance ().getTimeInMillis();%>

The <%! is a declaration expression, used for defining functions and class
variables,
this means it appears outside the _jspService subroutine, not what you want.
change it to <%. If you view the generated source code you'll see what I mean.

Regards,

James Williamson
www.nameonthe.net
UK Tomcat Hosting



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
On 6/5/02 4:37 PM, "James Williamson" <ja...@nameonthe.net> wrote:

> 
> 
> George McKinney wrote:
>> 
>>> -----Original Message-----
>>> From: James Williamson [mailto:james@nameonthe.net]
>>> Sent: Wednesday, June 05, 2002 2:58 PM
>>> To: Tomcat Users List
>>> Subject: Re: Improper timing using Calendar class (JSP/servlet)
>>> 
>>> 
>>>> 
>>>> <%!  is seldom used and is largely discouraged except in
>>> certain situations,
>>>> perhaps like yours, although I haven't looked too closely at yours.
>>> 
>>> I'm not being a troll, but who says it's largely discouraged?
>>> 
>>> James
>> 
>> I'd discourage it because usually Tomcat runs its servlets in a multi
>> threaded mode (unless the SINGLE THREAD (or whatever it's really called)
>> flag is set).
>> 
>> If startTime and endTime are member variables, and no synchronization in
>> sight, I think that the various invocations of the servlet are going to
>> tromp all over each other's values. If they are local (inside the <% ... %>
>> block) that won't be a problem.
> 
> True, but what about in circumstances where
> 
> a) you want to share variables (obviously synchronising access to them)
> b) you want to define subroutines in your jsp files (which are thread
> safe since
> each thread gets its own stack)?
> 
> To be frank, I was just wondering if there was a general consensus that
> using the <%!'s is not recommended.

Yes there is a general consensus, from what I can gather.  At least in every
project I have ever worked on (from my solo freelance projects to massive
projects with very senior architects), it has always worked out to do more
harm than good.

This is because:
A.  It is not necessary 9 times out of 10.
B.  It complicates source, architecture, and maintenance far more than it
solves perceived problems.

Synchronizing access to variables which are essentially locals is about the
dumbest thing you can do in Java.  Java's synchronization patterns are known
to be very slow.  Servlets and JSP's should hardly ever have anything
synchronized in them, because the environment is meant to be highly
multithreaded, and synchronization in some sense destroys that, especially
knowing how expensive Java's semaphore system is.  If you need to
synchronize a member in a JSP, you should rethink your design.

If you're actually "programming," if you need "subroutines" etc.--- you
should really be using Servlets anyway.  Servlets are for programming, JSP's
are for scripting the display output.  JSP/Servlet architecture is quite
weak when it comes to PHP/ASP/Perl style behavior and execution paths.  The
environment is designed for flexibility, robustness, and security, not speed
of development for small scale projects.  Kind of the opposite of the ASP or
PHP mentality (not that there's anything wrong with that when it's
appropriate).

I guess this just boils down to my 2 cents, but I still haven't heard anyone
ever tell me why they really needed this design, except to solve
nonexistent, imaginary "problems."
 
> James Williamson

fillup



>> 
>> George McKinney
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by James Williamson <ja...@nameonthe.net>.

George McKinney wrote:
> 
> > -----Original Message-----
> > From: James Williamson [mailto:james@nameonthe.net]
> > Sent: Wednesday, June 05, 2002 2:58 PM
> > To: Tomcat Users List
> > Subject: Re: Improper timing using Calendar class (JSP/servlet)
> >
> >
> > >
> > > <%!  is seldom used and is largely discouraged except in
> > certain situations,
> > > perhaps like yours, although I haven't looked too closely at yours.
> >
> > I'm not being a troll, but who says it's largely discouraged?
> >
> > James
> 
> I'd discourage it because usually Tomcat runs its servlets in a multi
> threaded mode (unless the SINGLE THREAD (or whatever it's really called)
> flag is set).
> 
> If startTime and endTime are member variables, and no synchronization in
> sight, I think that the various invocations of the servlet are going to
> tromp all over each other's values. If they are local (inside the <% ... %>
> block) that won't be a problem.

True, but what about in circumstances where 

a) you want to share variables (obviously synchronising access to them)
b) you want to define subroutines in your jsp files (which are thread
safe since
each thread gets its own stack)?

To be frank, I was just wondering if there was a general consensus that
using the <%!'s is not recommended.

James Williamson
> 
> George McKinney
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Improper timing using Calendar class (JSP/servlet)

Posted by George McKinney <ge...@tantalus.com>.

> -----Original Message-----
> From: James Williamson [mailto:james@nameonthe.net]
> Sent: Wednesday, June 05, 2002 2:58 PM
> To: Tomcat Users List
> Subject: Re: Improper timing using Calendar class (JSP/servlet)
>
>
> >
> > <%!  is seldom used and is largely discouraged except in
> certain situations,
> > perhaps like yours, although I haven't looked too closely at yours.
>
> I'm not being a troll, but who says it's largely discouraged?
>
> James

I'd discourage it because usually Tomcat runs its servlets in a multi
threaded mode (unless the SINGLE THREAD (or whatever it's really called)
flag is set).

If startTime and endTime are member variables, and no synchronization in
sight, I think that the various invocations of the servlet are going to
tromp all over each other's values. If they are local (inside the <% ... %>
block) that won't be a problem.

George McKinney



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by James Williamson <ja...@nameonthe.net>.
>
> <%!  is seldom used and is largely discouraged except in certain situations,
> perhaps like yours, although I haven't looked too closely at yours.

I'm not being a troll, but who says it's largely discouraged?

James

>
> fillup
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
On 6/5/02 2:27 PM, "Trenton D. Adams" <tr...@telusplanet.net> wrote:

> So, essentially <%!%> always makes object variables, and <%%> makes
> local variables?


<%  all this code runs in the service() method which processes the request

<%!  is a declaration and is treated differently, as though you are writing
it elsewhere in the class file.

<%!  is seldom used and is largely discouraged except in certain situations,
perhaps like yours, although I haven't looked too closely at yours.


fillup


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Improper timing using Calendar class (JSP/servlet)

Posted by "Trenton D. Adams" <tr...@telusplanet.net>.
That's great, thanks.  How did you find this out?

I SEE what you mean! :)  Thanks a lot.  I didn't realize Tomcat left the
compiled JSP page in the work directory.  

So, essentially <%!%> always makes object variables, and <%%> makes
local variables?

-----Original Message-----
From: James Williamson [mailto:james@nameonthe.net] 
Sent: June 5, 2002 3:08 PM
To: Tomcat Users List
Subject: Re: Improper timing using Calendar class (JSP/servlet)


>
> >
> > -----Original Message-----
> > From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net]
> > Sent: June 5, 2002 2:44 PM
> > To: 'Tomcat Users List'
> > Subject: Improper timing using Calendar class (JSP/servlet)
> >
> >
> > I'm kind of curious.  I've been trying to do some simple performance

> > timing with the Calendar class as shown below.  The startTime and 
> > endTime end up being the same value.  How can this be?  There should

> > be at the very least a ms or two difference between them, shouldn't 
> > there? The same thing happens in JSP pages as it does in servlet 
> > pages.  In fact, in a servlet, I tried doing a Thread.Sleep (10000),

> > and the startTime and endTime were still the same.  Is this a bug in

> > tomcat?
> >
> >
> >
> > <%! long startTime = Calendar.getInstance ().getTimeInMillis();%>

The <%! is a declaration expression, used for defining functions and
class variables, this means it appears outside the _jspService
subroutine, not what you want. change it to <%. If you view the
generated source code you'll see what I mean.

Regards,

James Williamson
www.nameonthe.net
UK Tomcat Hosting



--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by James Williamson <ja...@nameonthe.net>.
>
> >
> > -----Original Message-----
> > From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net]
> > Sent: June 5, 2002 2:44 PM
> > To: 'Tomcat Users List'
> > Subject: Improper timing using Calendar class (JSP/servlet)
> >
> >
> > I'm kind of curious.  I've been trying to do some simple performance
> > timing with the Calendar class as shown below.  The startTime and
> > endTime end up being the same value.  How can this be?  There should be
> > at the very least a ms or two difference between them, shouldn't there?
> > The same thing happens in JSP pages as it does in servlet pages.  In
> > fact, in a servlet, I tried doing a Thread.Sleep (10000), and the
> > startTime and endTime were still the same.  Is this a bug in tomcat?
> >
> >
> >
> > <%! long startTime = Calendar.getInstance ().getTimeInMillis();%>

The <%! is a declaration expression, used for defining functions and class
variables,
this means it appears outside the _jspService subroutine, not what you want.
change it to <%. If you view the generated source code you'll see what I mean.

Regards,

James Williamson
www.nameonthe.net
UK Tomcat Hosting



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Improper timing using Calendar class (JSP/servlet)

Posted by "Trenton D. Adams" <tr...@telusplanet.net>.
System.currentTimeMillis ().

If I switch to another version of the page, it gets a new value, but
both startTime and endTime are still the same.  Eg.  /contextpath and
/contextpath/appname.jsp both run appname.jsp.  So, I can switch between
the two using the same browser window and then it gets a new value each
time.  Could this be a session problem?  I'm not using any session
classes.

-----Original Message-----
From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com] 
Sent: June 5, 2002 3:09 PM
To: Tomcat Users List
Subject: Re: Improper timing using Calendar class (JSP/servlet)


System.currentTimeMillis()

fillup


Also, the Date class is deprecated, and the Calendar class should be
used via the concrete culture-specific subclass, in Western society this
is GregorianCalendar.



On 6/5/02 1:58 PM, "Trenton D. Adams" <tr...@telusplanet.net>
wrote:

> I've found that he only time that startTime and endTime get a new 
> value is when tomcat is restarted.  You can refresh the page any 
> number of times you want, but it still shows the same numbers until 
> tomcat is restarted.  It's almost as if the value returned by the 
> Calendar class is the startup time of tomcat, and not the actual 
> system time.  Is this correct?  If so, it's a bug right?  If not, how 
> can it be solved?
> 
> -----Original Message-----
> From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net]
> Sent: June 5, 2002 2:44 PM
> To: 'Tomcat Users List'
> Subject: Improper timing using Calendar class (JSP/servlet)
> 
> 
> I'm kind of curious.  I've been trying to do some simple performance 
> timing with the Calendar class as shown below.  The startTime and 
> endTime end up being the same value.  How can this be?  There should 
> be at the very least a ms or two difference between them, shouldn't 
> there? The same thing happens in JSP pages as it does in servlet 
> pages.  In fact, in a servlet, I tried doing a Thread.Sleep (10000), 
> and the startTime and endTime were still the same.  Is this a bug in 
> tomcat?
> 
> 
> 
> <%! long startTime = Calendar.getInstance ().getTimeInMillis();%>
> 
> Do some HTML output.
> 
> <%! long endTime = Calendar.getInstance ().getTimeInMillis();%> Start 
> Time:&nbsp <%= startTime %><BR> End Time:&nbsp <%= endTime%><BR> <%= 
> endTime - startTime %><BR>
> 
> 
> --
> To unsubscribe, e-mail: 
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
System.currentTimeMillis()

fillup


Also, the Date class is deprecated, and the Calendar class should be used
via the concrete culture-specific subclass, in Western society this is
GregorianCalendar.



On 6/5/02 1:58 PM, "Trenton D. Adams" <tr...@telusplanet.net> wrote:

> I've found that he only time that startTime and endTime get a new value
> is when tomcat is restarted.  You can refresh the page any number of
> times you want, but it still shows the same numbers until tomcat is
> restarted.  It's almost as if the value returned by the Calendar class
> is the startup time of tomcat, and not the actual system time.  Is this
> correct?  If so, it's a bug right?  If not, how can it be solved?
> 
> -----Original Message-----
> From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net]
> Sent: June 5, 2002 2:44 PM
> To: 'Tomcat Users List'
> Subject: Improper timing using Calendar class (JSP/servlet)
> 
> 
> I'm kind of curious.  I've been trying to do some simple performance
> timing with the Calendar class as shown below.  The startTime and
> endTime end up being the same value.  How can this be?  There should be
> at the very least a ms or two difference between them, shouldn't there?
> The same thing happens in JSP pages as it does in servlet pages.  In
> fact, in a servlet, I tried doing a Thread.Sleep (10000), and the
> startTime and endTime were still the same.  Is this a bug in tomcat?
> 
> 
> 
> <%! long startTime = Calendar.getInstance ().getTimeInMillis();%>
> 
> Do some HTML output.
> 
> <%! long endTime = Calendar.getInstance ().getTimeInMillis();%> Start
> Time:&nbsp <%= startTime %><BR> End Time:&nbsp <%= endTime%><BR> <%=
> endTime - startTime %><BR>
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Improper timing using Calendar class (JSP/servlet)

Posted by "Trenton D. Adams" <tr...@telusplanet.net>.
I've found that he only time that startTime and endTime get a new value
is when tomcat is restarted.  You can refresh the page any number of
times you want, but it still shows the same numbers until tomcat is
restarted.  It's almost as if the value returned by the Calendar class
is the startup time of tomcat, and not the actual system time.  Is this
correct?  If so, it's a bug right?  If not, how can it be solved?

-----Original Message-----
From: Trenton D. Adams [mailto:trent.nospam@telusplanet.net] 
Sent: June 5, 2002 2:44 PM
To: 'Tomcat Users List'
Subject: Improper timing using Calendar class (JSP/servlet)


I'm kind of curious.  I've been trying to do some simple performance
timing with the Calendar class as shown below.  The startTime and
endTime end up being the same value.  How can this be?  There should be
at the very least a ms or two difference between them, shouldn't there?
The same thing happens in JSP pages as it does in servlet pages.  In
fact, in a servlet, I tried doing a Thread.Sleep (10000), and the
startTime and endTime were still the same.  Is this a bug in tomcat?



<%! long startTime = Calendar.getInstance ().getTimeInMillis();%>

Do some HTML output.

<%! long endTime = Calendar.getInstance ().getTimeInMillis();%> Start
Time:&nbsp <%= startTime %><BR> End Time:&nbsp <%= endTime%><BR> <%=
endTime - startTime %><BR>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
Sorry, that did sound needlessly heated.

All I meant was that this style is much more "the JSP way" -- IMHO means "in
my humble opinion," but in this one case, my opinion was not so humble.

I'll try not to make a habit of it, sorry again ;)

fillup



On 6/5/02 10:50 PM, "Nate Campi" <na...@campin.net> wrote:

> On Wed, Jun 05, 2002 at 11:50:38PM -0600, Trenton D. Adams wrote:
>> IMNSHO?
>> 
>> In My N?? S?? Honest Opinion
> 
> 
> In My Not So Humble Opinion.
>     ^^^ ^^ ^^^^^^
> 
>> 
>> -----Original Message-----
>> From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com]
>> Sent: June 5, 2002 11:38 PM
>> To: Tomcat Users List
>> Subject: Re: Improper timing using Calendar class (JSP/servlet)
>> 
>> 
>> This is the right way to go, IMNSHO.
>> 
>> fillup


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Nate Campi <na...@campin.net>.
On Wed, Jun 05, 2002 at 11:50:38PM -0600, Trenton D. Adams wrote:
> IMNSHO?
> 
> In My N?? S?? Honest Opinion


In My Not So Humble Opinion.
      ^^^ ^^ ^^^^^^

> 
> -----Original Message-----
> From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com] 
> Sent: June 5, 2002 11:38 PM
> To: Tomcat Users List
> Subject: Re: Improper timing using Calendar class (JSP/servlet)
> 
> 
> This is the right way to go, IMNSHO.
> 
> fillup

-- 
"Those who do not understand UNIX are condemned to reinvent it -- badly."
                                                         -- Henry Spencer


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
On 6/6/02 12:55 AM, "James Williamson" <ja...@nameonthe.net> wrote:
> I'm sorry Fillup, this is what raised my earlier (trollish) post, you
> often seem to be feeding this list with invalid information or from what
> I can gather your highly personal perspective on what's right or wrong.

Fair enough!

I guess when people who are unfamiliar with the architecture ask questions
that are not Tomcat-related but jsp/servlet questions -- I opine freely,
trying to save people (perceived?) troubles that I have faced, since I have
been doing this for a while.  Perhaps I should not.  I voice no irony in
saying this....you make a fair point.

And, FWIW, I did not take your comment as a troll.

Troll:
- 1. v   To utter a posting on Usenet designed to attract predictable
responses or flames; or, the post itself.
- 2. n   An individual who chronically trolls in sense 1; regularly posts
specious arguments, flames or personal attacks to a newsgroup, discussion
list, or in email for no other purpose than to annoy someone or disrupt a
discussion. Trolls are recognizable by the fact that they have no real
interest in learning about the topic at hand - they simply want to utter
flame bait

You are no troll, good sir.  You engage in valid discussion without fire.

In fact, I only subscribed to this list around a month or two ago, so that I
could give back to this community -- I have learned a lot from mentors
throughout my career, and I am looking for a way to give back that does not
impede my progress on my current projects that put food on the table, so to
speak.  If my opinions seem strong and (occasionally) fixed, I apologize.  I
have formed some pretty strong opinions about the architecture and about
things that tend to work and not work in Tomcat, and things that tend to
work and not work in Servlet/JSP applications.  Some of this information is
probably outdated or perhaps tied to a particular erroneously-identified
issue I have faced -- in other words I thought it was problem A but in fact
it was a hidden problem B that my workaround for A happened to luckily fix.
This happens.  I think I have been helpful, if only to some, and if only
sometimes.  Such is the best I can do.

In particular -- the issue of <%! declarations at hand: in my dealings with
folks (previous to my time with this list), I found that so-called "newbies"
who are really quite good and experienced in other environments tend to
really want to use <%! declarations all over the place.  They like this
feature, and several of the "intro to jsp" type of books seem to encourage
the practice.  Fair enough.  9 times out of 10 -- or maybe 6, 7 or 8 I
suppose -- the reasoning that was provided to me indicated a
misunderstanding of the JSP architectural foundation.   There probably are
many situations that I have not seen where the usage is appropriate, but it
demands a higher degree of understanding of the architecture than one would
be led to believe by its apparent simplicity.

If / when I give invalid information, or perhaps information that is more
applicable only to my personal situations and opinions, please feel free to
correct me in public, for that is what such presumptuousness deserves.  This
is within the bounds of fair play on a technical list, and certainly not
"trollish."  I take your comments as completely fair.

I just wanted to stick up for myself a bit, and apologize at the same time.
A paradox.  If anyone would like to respond, let's please take this off-list
to save the inboxes and ISP's of others.

respectfully,
fillup


On 6/6/02 12:55 AM, "James Williamson" <ja...@nameonthe.net> wrote:

> 
> 
> "Trenton D. Adams" wrote:
>> 
>> IMNSHO?
>> 
>> In My N?? S?? Honest Opinion
>> 
>> -----Original Message-----
>> From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com]
>> Sent: June 5, 2002 11:38 PM
>> To: Tomcat Users List
>> Subject: Re: Improper timing using Calendar class (JSP/servlet)
>> 
>> This is the right way to go, IMNSHO.
>> 
>> fillup
> 
> I'm sorry Fillup, this is what raised my earlier (trollish) post, you
> often seem to be feeding this list with invalid information or from what
> I can gather your highly personal perspective on what's right or wrong.
> 
> Regards, 
> 
> James
> 
>> 
>> On 6/5/02 5:20 PM, "thorsten frank" <th...@liquidprotocol.com> wrote:
>> 
>>> why not use
>>> <code>
>>> 
>>> long start = System.currentTimeMillis();
>>> // your code here
>>> long end = System.currentTimeMillis();
>>> long theTimeItTookInMillis = end - start;
>>> 
>>> </code>
>> 
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>> 
>> --
>> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by James Williamson <ja...@nameonthe.net>.

"Trenton D. Adams" wrote:
> 
> IMNSHO?
> 
> In My N?? S?? Honest Opinion
> 
> -----Original Message-----
> From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com]
> Sent: June 5, 2002 11:38 PM
> To: Tomcat Users List
> Subject: Re: Improper timing using Calendar class (JSP/servlet)
> 
> This is the right way to go, IMNSHO.
> 
> fillup

I'm sorry Fillup, this is what raised my earlier (trollish) post, you 
often seem to be feeding this list with invalid information or from what
I can gather your highly personal perspective on what's right or wrong. 

Regards, 

James

> 
> On 6/5/02 5:20 PM, "thorsten frank" <th...@liquidprotocol.com> wrote:
> 
> > why not use
> > <code>
> >
> > long start = System.currentTimeMillis();
> > // your code here
> > long end = System.currentTimeMillis();
> > long theTimeItTookInMillis = end - start;
> >
> > </code>
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Improper timing using Calendar class (JSP/servlet)

Posted by "Trenton D. Adams" <tr...@telusplanet.net>.
IMNSHO?

In My N?? S?? Honest Opinion

-----Original Message-----
From: Phillip Morelock [mailto:subscriptions@phillipmorelock.com] 
Sent: June 5, 2002 11:38 PM
To: Tomcat Users List
Subject: Re: Improper timing using Calendar class (JSP/servlet)


This is the right way to go, IMNSHO.

fillup


On 6/5/02 5:20 PM, "thorsten frank" <th...@liquidprotocol.com> wrote:

> why not use
> <code>
> 
> long start = System.currentTimeMillis();
> // your code here
> long end = System.currentTimeMillis();
> long theTimeItTookInMillis = end - start;
> 
> </code>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by Phillip Morelock <su...@phillipmorelock.com>.
This is the right way to go, IMNSHO.

fillup


On 6/5/02 5:20 PM, "thorsten frank" <th...@liquidprotocol.com> wrote:

> why not use
> <code>
> 
> long start = System.currentTimeMillis();
> // your code here
> long end = System.currentTimeMillis();
> long theTimeItTookInMillis = end - start;
> 
> </code>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Improper timing using Calendar class (JSP/servlet)

Posted by thorsten frank <th...@liquidprotocol.com>.
why not use
<code>

long start = System.currentTimeMillis();
// your code here
long end = System.currentTimeMillis();
long theTimeItTookInMillis = end - start;

</code>


thorsten frank
[software developer]
________________________
LPIP Australasia
http://www.liquidprotocol.com
ACN:096 239 039

Level 1/368 Crown Street
Darlinghurst 2010
Sydney, Australia

P: [02] 9332 1933
F: [02] 9332 1822
________________________

Disclaimer

The above information is confidential to the addressee and may be
privileged. Unauthorized access and use is prohibited. Internet
communications are not secure and therefore this company does not accept
legal responsibility for the contents of this message. If you are not the
intended recipient, any disclosure, copying, distribution or any action
taken or omitted in reliance on it, is prohibited and may be unlawful


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>