One rule-of-thumb: ask yourself "Does it make sense to call this method, even if no object has been constructed yet?" If so, it should definitely be static.

So in a class Car you might have a method:

double convertMpgToKpl(double mpg)

...which would be static, because one might want to know what 35mpg converts to, even if nobody has ever built a Car. But this method (which sets the efficiency of one particular Car):

void setMileage(double mpg)

...can't be static since it's inconceivable to call the method before any Car has been constructed.

(By the way, the converse isn't always true: you might sometimes have a method which involves two Car objects, and still want it to be static. E.g.:

Car theMoreEfficientOf(Car c1, Car c2)

Although this could be converted to a non-static version, some would argue that since there isn't a "privileged" choice of which Car is more important, you shouldn't force a caller to choose one Car as the object you'll invoke the method on. This situation accounts for a fairly small fraction of all static methods, though.

Are you asking about the reference scope or the existence scope? A public static method can be accessed by any class which can access the method's class, given standard Java package naming/scoping rules. Note that this implies (as part of the rules) that access is only available to classes in the same JVM.

The existence of the data is scoped to the instance of java.lang.Class that represents the class being loaded (I'm sure there's some fancy term for this). At most this is until the end of execution of the JVM, but a class can, under some circumstances, be "unloaded" earlier.

It should also be noted that more than one copy (java.lang.Class instance) of a given class can be loaded in a given JVM at the same time, and each copy of the class would have its own static variables. However, this would be pretty rare.

A static method cannot be run, except of course if this method is the main(String... args) method.

However, consider creating a JUnit test case for this method instead.

Create a JUnit Test Case within Eclipse. In the wizard, you can indicate the class that provides your static method in the Class under test: field. Then Eclipse will give you the ability to create one test method per existing method on the class under test.

Once your JUnit test is created, simply right-click on this Java class and select Run as > JUnit test. The shortcut is Alt+Shift+X, then T.

You can also consider doing some Test Driven Development...

Whenever you write a method, you fulfill a contract in a given scope. The narrower the scope is, the smaller the chance is that you write a bug.

When a method is static, you can't access non-static members; hence, your scope is narrower. So, if you don't need and will never need (even in subclasses) non-static members to fulfill your contract, why give access to these fields to your method? Declaring the method static in this case will let the compiler check that you don't use members that you do not intend to use.

And moreover, it will help people reading your code understand the nature of the contract.

That's why it's considered good to declare a method static when it's actually implementing a static contract.

In some cases, your method only means something relative to an instance of your class, and it happens that its implementation doesn't actually use any non-static field or instance. In such cases, you would not mark the method static.

Examples of where you would not use the static keyword:

• An extension hook which does nothing (but could do something with instance data in a subclass)
• A very simple default behavior meant to be customisable in a subclass.
• Event handler implementation: implementation will vary with the class of the event handler but will not use any property of the event handler instance.

Based on your earlier question, I think may not be fully digging the concept of the local variable. In this method:

public String setOption(String option) throws IOException
{
    option = stdin.readLine();
    return option;
}

option is a local variable. You pass the initial value for that variable as an argument to the setOption method each time you call it (and you happen to ignore that value), but with that detail out of the way, this is the same as

public String setOption() throws Exception
{
    String option = stdin.readLine();
    return option;
}

Now, local variables are something completely different from instance or class variables: they are valid only within a method body, and exist only during the time that method is executing. With that in mind, let's look at this code:

static BufferedReader stdin = new BufferedReader(new InputStreamReader(
        System.in));
public static void main(String[] args) throws IOException
{
    Patient.setOption(null);    
}

Here you are basically misusing a class variable stdin for something which should have been a local variable:

public static void main(String[] args) throws IOException
{
    BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
    Patient.setOption(null);    
}

On to the question of your method call... setOption is currently an instance method, which means it must be called in the context of an instance. You are calling it as-is, with no instances of Patient involved. If you continue down this road, you won't be able to represent more than a single patient, probably not your idea. So you want to keep the method as it is and create an instance of Patient:

Patient p = new Patient();
p.setOption(...);

In your overall design it is not clear what role setOption should play, but it is not a good idea that it uses the static stdin variable (I already made it local above). You want to pass any data read from stdin into the setOption method and thus decouple it from the input reading logic.

Put the cursor on the method name (asList) and press Ctrl-Shift-M.

This is the default keyboard shortcut for the 'Add Import' command. You can also find the command on the 'Source' menu.

I'm not sure exactly what the situation is, but if you're looking to execute the static method on a class without knowing the class type (i.e. you don't know it's SomeType, you just have the Class object), if you know the name and parameters of the method you could use reflection and do this:

Class c = getThisClassObjectFromSomewhere();

//myStaticMethod takes a Double and String as an argument
Method m = c.getMethod("myStaticMethod", Double.class, String.class);
Object result = m.invoke(null, 1.5, "foo");