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

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.

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

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