struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kelly" <>
Subject Re: [OT] Use of Static Methods
Date Thu, 10 Jul 2003 07:56:14 GMT
I'm gonna get shot down in flames here, but I feel this may be a good way of
looking at the differences between static and non-static methods.

If you look at the compiled code for any OO language at the bytes in memory
level, you can clearly see the differences between the two.
When a compiled program is loaded into memory, three (four) clearly defined
areas are seen. [Cut down a bit as there are other areas, specific to the
language used, see last paragraph (The one starting "Of-course...", not
"Hope this ...")]

The First (including the fourth :-) is the program byte code (and the start
code, which is hit first when the program starts and is specific to your
machine) which contains all your code.
The second and third parts are the stack and heap which will hold all the
data at run time.

The difference in static and non-static in this layout is thus.

ALL static classes, methods and variables remain within the byte code
section and are run directly from there (and this is the reason static
methods cannot be overridden but only hidden).  Hidden static methods will
reside here even if never called (and this is the reason static methods
cannot be overridden but only hidden).

ALL non-static classes, methods and variables will be instanciated within
the heap, with pointers to any static classes, methods or variables that are
required. These are run-time created 'images' of code within the byte code,
and are built up to match their hierarchical tree from java.lang.Object
down. And this is why they can override methods, as the methods are loaded
into these 'instances' from the bottom of the brach backwards towards
Object. All methods from the lowest class in the tree are created first,
then up the branch one and all these methods are created. Any method in this
second row, and those above, whose foot-print matches a method already
created are ignored (or over-ridden)

I'm afraid this is all ottomh (off the top of my head) but is accurate as a
brief over-view. If anybody really cares about this subject that much, mail
me and I'll write a full papaer on it ;-) [That's a joke, don't ask, I have
enough work as it is :-)]

Of-course, java that we write is in fact an interpreted language and is run
within the JVM which strictly follows the memory layout above. How the JVM
handles the code is specific to how it was programmed. Other OO languages
like C++ et al. strictly adhere to this stucture in memory. PEARL is an
interpretted language, so whether it is OO or not, it is handled by it's own
interpretter which will handle the code as it is designed to do.

Hope this has been enlightening, and I will follow this up with my long
awaited lecture on "Struts for coffee makers 101" ;-)



----- Original Message -----
From: "Craig R. McClanahan" <>
To: "Struts Users Mailing List" <>;
Sent: Thursday, July 10, 2003 6:00 AM
Subject: RE: [OT] Use of Static Methods

> On Thu, 10 Jul 2003, Andrew Hill wrote:
> > Date: Thu, 10 Jul 2003 10:52:53 +0800
> > From: Andrew Hill <>
> > Reply-To: Struts Users Mailing List <>,
> >
> > To: Struts Users Mailing List <>
> > Subject: RE: [OT] Use of Static Methods
> >
> > Put them as methods of a Singleton instance instead of static methods.
> > (Ive been using lots of static methods so the fact Im telling you to do
> > differently to that should indicate something ;->)
> >
> > -Especially when other people have to use these methods too. The number
> > times Ive cursed classes like PropertyUtils and BeanUtils for being
> > and not singletons because I want to use a slightly different version in
> > some places...
> Note that, at least in the case of PropertyUtils and BeanUtils, we have
> learned the error of our ways, and are refactoring things to use the
> singleton (per webapp, but the same philosophy) pattern :-).
> Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message