What is the exact meaning of static fields in Java?

Question

I would like to share an object between various instances of objects of the same class.

Conceptually, while my program is running, all the objects of class A access the same object of class B.

I've seen that static is system-wide and that its usage is discouraged. Does that mean that if I've got another program running on the same JVM that instantiates objects of class A, these objects could potentially access the same B object as the one accessed in the previous program?

What are generally the flaws behind using static fields?

Are there any alternatives (that do not require a huge effort of implementation)?

static is JVM wide so yes if you have two programs in the same VM they should be acessing the same object B — Nuno Furtado, Apr 28 '09 at 13:39

score 76 · Accepted Answer · answered Apr 28 '09 at 13:39

Static doesn't quite mean "shared by all instances" - it means "not related to a particular instance at all". In other words, you could get at the static field in class A without ever creating any instances.

As for running two programs within the same JVM - it really depends on exactly what you mean by "running two programs". The static field is effectively associated with the class object, which is in turn associated with a classloader. So if these two programs use separate classloader instances, you'll have two independent static variables. If they both use the same classloader, then there'll only be one so they'll see each other's changes.

As for an alternative - there are various options. One is to pass the reference to the "shared" object to the constructor of each object you create which needs it. It will then need to store that reference for later. This can be a bit of a pain and suck up a bit more memory than a static approach, but it does make for easy testability.

thanks for the alternative...that was what i was doing before, i forgot to mention that...but the constructor enabling to pass the shared object is no longer available in the library i use.... — LB40, Apr 28 '09 at 13:58

score 2 · Answer 2 · answered Apr 28 '09 at 13:39

Static methods and members are discouraged because they're so frequently misused, but this sounds like a situation where static is the correct way to go. As to static shared across multiple programs, this is not the case. Each program runs in a completely separate environment.

score 0 · Answer 3 · answered Apr 28 '09 at 13:40

0

What you are looking for is called the Singleton Pattern.

answered Apr 28 '09 at 13:40

Paul Tomblin

179,021
58
319
408

3

He gave no requirement for lazy instantiation of class B. Overapplication of Singleton earns my ire. – Welbog Apr 28 '09 at 13:42
Lazy instantiation isn't the only reason to use Singleton. It's also useful if you need a SINGLE instance of a class to share between other objects, thus the name. – Paul Tomblin Apr 28 '09 at 13:52
3

Static is sufficient to get that single instance. That's what static is for. Singleton is specifically used when you want a single instance and you need to instance it lazily. Using Singleton when this isn't required is a misapplication of Singleton, bottom line. – Welbog Apr 28 '09 at 13:54
1

The OP didn't say there weren't other objects of class B in the system. Singleton is overused, and this is a case of its overuse. – DJClayworth Apr 28 '09 at 18:00

score -1 · Answer 4 · answered Apr 28 '09 at 14:18

-1

Assuming everything is in the same class loader, then why not use the monostate pattern to do this?

Your shared static is hidden in the monostate:


  public class Monostate {

      private static String str = "Default";

      public String getString() {
          return str;
      }

      public void setString(String s) {
          str = s;
      }
  }

Then you are free to create as many instances of the monostate as you like, but they all share the same underlying object due to the static reference.

   Monostate mono = new Monostate();
   mono.setString("Fred");
   System.out.println(mono.getString());

answered Apr 28 '09 at 14:18

A_M

7,693
6
33
37

Why not? Because it lies about what it does. It makes the singleton "pattern" look sensible. – Tom Hawtin - tackline Apr 28 '09 at 23:50
All I was trying to do is give LB an alternative, which is what he asked for. Maybe the example I gave above is too simplistic. Perhaps this paper by Robert Martin which compares and contrasts the monostate and singleton might help: http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf – A_M Apr 29 '09 at 07:18

What is the exact meaning of static fields in Java?

4 Answers4

Linked

Related