«

I probably never occurs to most people to initialise static variables
in main. After all, they are all automatically initialised to 0 or to
the values in the declarations.

All works fine if you run your program only from the command line. But
if someone starts automating, and calls your main repeatedly from
Java, the second calls will get whatever static values were left over
from the first invocation of main.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green wrote:
> I probably never occurs to most people to initialise static variables
> in main. After all, they are all automatically initialised to 0 or to
> the values in the declarations.
>
> All works fine if you run your program only from the command line. But
> if someone starts automating, and calls your main repeatedly from
> Java, the second calls will get whatever static values were left over
> from the first invocation of main.

It does occur because its a dumb idea.

Roedy Green < > writes:
>All works fine if you run your program only from the command line. But
>if someone starts automating, and calls your main repeatedly from

What could be done from the point of view of the framework
to force proper initialisation of the main class for the
second time it is activated?

Something like "unloading" it and "reloading" it again via the
standard class loader (I do not know, if this is possible)?

Roedy Green wrote:
> I probably never occurs to most people to initialise static variables
> in main. After all, they are all automatically initialised to 0 or to
> the values in the declarations.
>
> All works fine if you run your program only from the command line. But
> if someone starts automating, and calls your main repeatedly from
> Java, the second calls will get whatever static values were left over
> from the first invocation of main.

One recommendation is to never have non-final static variables.
Following this eliminates the problem and will likely make the program
more object-oriented.

HTH,
Ray

--
This signature intentionally left blank.

On 22 Jan 2006 21:43:49 GMT, (Stefan Ram)
wrote, quoted or indirectly quoted someone who said :

> What could be done from the point of view of the framework
> to force proper initialisation of the main class for the
> second time it is activated?

If you were trying to automate badly behaved main code, you could use
a custom loader each time, but of course that partly defeats the
purpose. You want the speed of avoiding the program load each time. It
least it beats loading a new JVM with exec each time.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Andrew McDonagh wrote:
> Roedy Green wrote:
> > I probably never occurs to most people to initialise static variables
> > in main. After all, they are all automatically initialised to 0 or to
> > the values in the declarations.
>
> It does occur because its a dumb idea.

It's very unfortunate that your newsreader accidentally posted your
reply before you had a chance to replace this inflammatory statement
with a sound technical argument (and correct the amusing typo).

Perhaps you meant to say, for example, that initializing static
variables in main could be problematic if a different class's main()
were called, therefore reducing the modularity of the class in
question?

Luke

"Raymond DeCampo" <> wrote in message
news:W1TAf.111709$.. .
> Roedy Green wrote:
>> I probably never occurs to most people to initialise static variables
>> in main. After all, they are all automatically initialised to 0 or to
>> the values in the declarations.
>>
>> All works fine if you run your program only from the command line. But
>> if someone starts automating, and calls your main repeatedly from
>> Java, the second calls will get whatever static values were left over
>> from the first invocation of main.
>
> One recommendation is to never have non-final static variables. Following
> this eliminates the problem and will likely make the program more
> object-oriented.
>
> HTH,
> Ray
>
> --
> This signature intentionally left blank.

Statics are almost always a bad idea and anyone who uses them is lucky if
they never live to regret this poor choice. Less lucky people will
eventually get into situations where the
thought-of-as-universally-applicable property suddenly has to vary per
customer, country, user, session or whatever. Factoring out statics into
instance based constructs is very tedious. This can be addressed with
multiple classloaders but that is like cleaning dirt with fresh paint.

We made the same mistake in the past. Since we are still developing on the
same system and have been for about three years now we are still in the
process of taking out static constructs. Examples are: serving multiple
customers (each customer owns a database instance) from a single server
instance needing customer-level properties, having different languages for
each customer or possibly user, etc.
We implemented all these mechanisms using statics at first and have suffered
from that. When we could no longer afford to run a server instance per
customer and needed to merge them we where in trouble. Most things have been
repaired since at the expence of a lot of man hours. We have put a
death-penalty on using statics in new code except for static functions in
stateless utility classes, a la Arrays or Collections.

Regards,

Silvio Bierman

Roedy Green < > wrote:
> I probably never occurs to most people to initialise static variables
> in main. After all, they are all automatically initialised to 0 or to
> the values in the declarations.
>
> All works fine if you run your program only from the command line. But
> if someone starts automating, and calls your main repeatedly from
> Java, the second calls will get whatever static values were left over
> from the first invocation of main.

If you call main method programmatically, you get what you get. Since
part of the contract of main is that it's called from a fresh JVM and
the process terminates when it's done. You violate the contract, and
there's no reason to expect your code to do anything in particular.

If you really want to make a program runnable programmatically as well
as an app, create a new method that's NOT main, and document its usage
in the normal way. Call it from main. Far less confusing.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith wrote:
> Roedy Green < > wrote:
>
>>I probably never occurs to most people to initialise static variables
>>in main. After all, they are all automatically initialised to 0 or to
>>the values in the declarations.
>>
>>All works fine if you run your program only from the command line. But
>>if someone starts automating, and calls your main repeatedly from
>>Java, the second calls will get whatever static values were left over
>>from the first invocation of main.
>
>
> If you call main method programmatically, you get what you get. Since
> part of the contract of main is that it's called from a fresh JVM and
> the process terminates when it's done. You violate the contract, and
> there's no reason to expect your code to do anything in particular.
>
> If you really want to make a program runnable programmatically as well
> as an app, create a new method that's NOT main, and document its usage
> in the normal way. Call it from main. Far less confusing.

Or if you want to run an arbitrary Java program directly from another
Java program then do it the application server way: load the relevant
classes with their own ClassLoader. You'd then have to use reflection
to invoke the main() method, but it's considerably safer and more
robust. (Don't take that as absolute safety, however, and don't assume
robustness rivaling what you would achieve by giving the program its
own, dedicated, JVM.)

--
John Bollinger