initialising statics

[Roedy Green]

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.

 

[Andrew McDonagh]

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.

 

[Stefan Ram]

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)?

 

[Raymond DeCampo]

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

 

[Roedy Green]

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.

 

[Luke Meyers]

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

 

[Silvio Bierman]

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

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

 

[Chris Smith]

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

 

[John C. Bollinger]

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.)